collingreene

Pysa - https://engineering.fb.com/2020/08/07/security/pysa/

Here is our experience building and using program analysis as part of our product security efforts at facebook: https://engineering.fb.com/security/zoncolan/.

Its run in both self-service (output to developers), guided (output to product security oncall of security engineers) and used ad-hoc to power up manual security reviews. Depending on the accuracy of each rule and the impact of the pattern of security flaw the rule finds it is promoted to ultimately output to developers directly.

It finds about a third of the security vulns we unearth each year.

https://www.facebook.com/data-abuse - as mentioned in the article this scenario (non-fb companies mishandling fb user data) is exactly the reason Facebooks data abuse bounty program exists. Hopefully the finders of this submitted to the program.

This exists, https://internetbugbounty.org/

Facebook, microsoft, github, etc all pay $$ and our time into a pool that is used to incentivize the finding, vetting and fixing of security flaws in major software running the internet.

I work at Facebook and have personally seen no evidence of this.

The article cites one designer who left (out of ~25,000+ total Facebook employees).

The two people interviewed were fired for cause from this same program, of course they will have a negative opinion. One even fired for the same thing this safety driver failed to do.

Both Kelley and the former driver in Tempe were dismissed from their jobs with Uber earlier this year for safety infractions: Kelley said he was let go after rolling through a stop sign while he was operating the car, which he disputes; the individual in Tempe said he was dismissed for using his phone while the vehicle was in motion.

The bit about level 3 considered harmful makes a lot of sense and isn't something that I would have intuitively thought of

Why do you think the LIDAR did not work? The LIDAR might have worked just fine but what the system taking the output of the sensor did with the data is the question.

Very true. I don't know either way.

I remain interested in why the lidar didn't work in this case and I hope more details emerge so we can learn what happened.

But it seems logical that Uber would disable the onboard built-in volvo crash detection feature, it would be adding another variable for a car that is intended to test one thing at a time. Its hard to see this solely as the "uber is being reckless" narrative instead of "maybe this is just how all self-driving cars are tested".

I am happy to be proven wrong certainly

Internal abuse is a big area of effort for Facebook and google but things still go wrong. Here was googles moment for that back in 2010:

https://www.wired.com/2010/09/google-spy/

I don’t understand ... why aren’t the default settings of an account more secure and private?

They are (for the most relevant definition of your question).

Specifically a Facebook app you choose to install can no longer see any of your friends information. That was done in 2014 before any of this happened, more details and timeline here: https://www.facebook.com/boz/posts/10104702799873151

This exists and companies purchase it, ex: https://www.thehartford.com/data-breach-insurance

Risks (all kinds, not just technical) can be accepted, ignored, transferred and mitigated so it is important to have this option.

Its still not a great option for anyone involved as it is hard to price and last I checked had pretty low ceiling on payouts.

I don't think anyone in security would disagree with you.

The problem is measuring something that is sort of definitionally unknowable (how many vulns are in this code, where, how likely is it someone outside the company will find it, then exploit it?) is hard (the book referenced has some ideas which boil down to "get some experts in a room and ask them, then average it")

A good security team will do their best at this but its unfortunately not as easy as "ok we found all the xss bugs which reduces our chances of getting owned by %2.5".

The further (maybe depressing) question is to the degree getting breached actually harms a company, my favorite argument that the two are tenuously related is this: http://www.cs.umd.edu/~awruef/HNYM.pdf and my favorite within is comodo. Comodo was hacked and the hacker gained the ability to sign certificates of their choice with comodo key. Comodo had one job, be worthy of trust and not get hacked. Did it harm them? They are still the #1 cert company. Look at the target breach or any others.

The only spot where a breach can be company-ending is all these bitcoin companies, which from my spot in application security makes them fascinating test cases. Here are a bunch that blew up after they got hacked: https://magoo.github.io/Blockchain-Graveyard/

If you like that book he wrote one about applying those ideas to this exact problem! https://www.amazon.com/How-Measure-Anything-Cybersecurity-Ri...

I've never managed to make the effort to apply his ideas with much rigor but they are definitely appealing and possibly better than the alternative of "maybe nothing".

+1 to starting a private program first which is recommended by all bounty programs.

If helpful I wrote down my notes about starting a bounty program although my experiences were formed by larger companies https://medium.com/@collingreene/bug-bounty-5-years-in-c95cd...

Nice, these look superior to the intel books (which intel graciously printed then mailed to me for free like 10 years ago, go intel!). Ill check them out.

Assembly Language step by step by Jeff Duntemann remains one of my favorite books overall (not just programming, not just computers). It was updated in the last few years and the 3rd edition remains quite good.

Your acute mistaken conclusion> Simply throwing money at FOSS will not fix any security bugs.

I can't think of anything closer to "throwing money at FOSS" than something like the internet bug bounty. Google/Facebook/etc collected a pile of money and put it up for a bug bounty for software used by most of us on the internet. https://hackerone.com/ibb click through to the projects and look at all the bugs that have been rewarded. https://hackerone.com/internet and https://hackerone.com/sandbox are the coolest.

My interpretation of your general conclusion is: without quantification spending money/effort on security is not useful. I disagree with that because its the nature of the beast. Its useful to have people look through code and some weeks there will not be a lot of findings. Its absolutely okay for a status report to read "I tried this, thought think might work, investigated the way X works to ensure it doesn't do Y - 0 total findings".

What people to pay & how to know you are getting your moneys worth are not unsolvable problems. For example at the company I work with we hold yearly bake-offs giving different security consultants the same code to see what bugs they find, we then use the best 2 or 3. Thats an approximation sure, but it solves your what people to pay problem.

How to know if you are getting your moneys worth, this is harder and rubs against the essence of security/QA work. No one knows what lurks in randomCode.tar.gz. That is the whole point of the exercise. But apparently the world agrees its useful to have corporate application security teams to do some vetting of the code looking for vulns, more useful that nothing at least. More useful than tools? Well thats a weird comparison because you likely need security people (or engineers with a bit of security background at least) to run some tools. I think tools vs people is a different debate but I would bet on people even at an equal cost point.

I agree quantification of security research is hard, I disagree that because we can't quantify something it is not useful.

Maybe you just enjoy hyperbole but while part of what you say is correct (finding security vulns in software is unavoidably a bit of a crapshoot) your conclusions are wrong.

Finding deep, serious vulns like this in software can currently only be done by human beings. Tools are better at being authoritative but can only find vulns of a given type. For example static analysis is a great fit for any vuln that boils down to a dataflow problem, user controlled source -> ... -> dangerous sink. XSS, sql injection, etc fit this model. Fuzzers are great at finding bugs in parsers (and there are a surprising amount of parsers in the world, 90% of which should never have been written). Instrumented dynamic analysis can do awesome work for memory issues. I explain all this to show there are areas where tools are fantastic for their area. But there are many areas for which tools cannot help at all, heartbleed was one of these areas.

The best security tools available were (presumably) run across openssl before and (certainly) with increased scrutiny after heartbleed. None of them found it. Simple limitations in static analysis lead me to believe they would never have found it on their own (most static analysis tools stop at 5 levels of indirection) Some background:

1. http://blog.trailofbits.com/2014/04/27/using-static-analysis... 2. http://security.coverity.com/blog/2014/Apr/on-detecting-hear... 3. http://www.grammatech.com/blog/finding-heartbleed-with-codes...

If you have immature projects sure run tools against it and some bugs will shake out. But if you want to find the next heartbleed a tool wont do it which is your mistaken conclusion.

The question then becomes how to cultivate and encourage more people to find vulns like this. Money seems like a good incentive for most, although Neel Mehta did it of his own volition. I dont know the answer to that question but things like googles project zero are exactly what I would try first.

Cool article! A friend and I once did this but then recorded the commands attackers ran and replayed them on a big tv in our office. We called it hacker fishtank.

To echo this sentiment: In 2013 facebook received 14,763 submissions which lead to 687 paid issues, 1 : 21 signal to noise. Facebook errs on the side of paying out as often as possible even for lame bugs (apache shows its version number in some talent acquisitions blog), code we didn't write, defense in depth type stuff, instances where the reporter was wrong and there wasn't actually a bug but in the process of investigating the non-bug we happened to find a bug on our own etc. Given all that, I would (personal opinion) put the number of useful, impactful security issues we received in 2013 at about 70. If we use this guide its 1 : 211 signal to noise. In this sea of noise the reports submitted are often in other languages or submitted by less clueful people. This yahoo example the reporter explained the issue pretty well but in my experience this is a rarity. A legit issue could come from anyone though, even the guy who writes a sentence of Polish and sends you a 30sec youtube video in 320x480.

Basically doing a bug bounty right is very hard.

Stuff like this will happen. By running a bug bounty at all you are opening your company up to situations like this but the bigger picture is that you care about security enough to still do it for the valid security issues bug bounties find. It is a strong signal to me that a company actually cares about security and we shouldn't lose focus of that in the midst of pitchfork-waving "but yahoo was WRONG".

We recently released some stats that support all this here: https://www.facebook.com/notes/facebook-bug-bounty/bug-bount...

We first learned of this claim a few hours ago. We've been in touch with MyPermissions directly and are waiting to receive more information from them.

At this point, we haven't been able to reproduce the reported issue or validate the existence of a vulnerability.

This is really great. I have found myself saying some of these same things when explaining things. Going to keep this in my pocket to use in the future. Thanks!

Replying as discussion originally seemed to be about first/last/profile picture privacy.

The scenario is: you are not able to get into your rightful facebook account but you know some information (phone, email) that is associated with it. If you are coming from a semi-trusted computer/ip/browser/etc that has a history of being associated with your account Facebook displays some public information about that account to ensure one doesn't try to recover the wrong account. The posts here about people getting differing results when hitting this endpoint with other peoples information are a result of these factors.

Important note: If a user you are initiating a recovery for has their "who can look me up" privacy setting set to "everyone" then we will always display such information for that user. That setting discussed a bit more here: https://www.facebook.com/help/www/131297846947406

Hope that clears things up, this is one of the most common false positives we get via our bug bounty program and I certainly see how it can be alarming at first.

I work at facebook on the security team.

This is an account recovery endpoint used if your account was hacked for example.

Your name, profile picture and a few other things are considered public information so there is no security issue displaying them. See: https://www.facebook.com/help/167709519956542

Google is on board.

""" is sponsored by Microsoft and Facebook. It will be jointly controlled by researchers from those companies along with their counterparts at Google, """

Cool, found it. Will respond in the email thread.

I need more information if you want me to look into this issue.

We have paid out on such issues before but there is no hard rule. In general we err on paying out if there is any question. We have paid out before when a submission wasn't a bug at all but lead us to some part of the code that we ourselves then found a security bug in.

It is in our best interest to payout whenever possible. More payouts = more submissions = more security bugs found and fixed.

I work at facebook on the bug bounty program, if you have an email, name or ticket id I can look into it for you.

There could be a few things going on here, maybe your bug was classified as low pri, maybe we misdiagnosed the bug.

Speculation but I would call into question your assertion that we fixed something based on your submission and then attempted to hide/delay it. We have not and would not do such a thing.

Because of the volume of reports we have settled on a scan every new item quickly, categorize it into severity and then respond. As you say it is a minor privacy issue so it looks like it went into a lower-pri area. I will make sure you hear back soon.

I work at facebook on our whitehat program. To clear this up we have not, and would never come after someone properly submitting bugs to us. Quite the opposite we are very appreciative when someone takes the time to find something and send it our way. Everything is aligned around rewarding responsible disclosure instead of punishing its inverse.

Nir in particular is one of our best supporters (rough rankings https://www.facebook.com/whitehat/thanks/) we certainly have no intention to sue him or anyone submitting bugs to us. He even stopped by our office last week to talk about bugs.

Some external opinions of our program - https://www.eff.org/deeplinks/2010/12/knowledge-power-facebo...