Google Hands Over $3M in Bug Bounties as Payouts Soar For New Android Flaws (zdnet.com)

Google paid researchers over $3m last year for their contributions to its vulnerability rewards programs. From a ZDNet report: Payouts in 2016 take Google's total payments under its bug bounty schemes to $9m since it started rewarding researchers in 2010. In 2015 it paid researchers $2m, which brought its total then to $6m. It's not uncommon for tech companies to run bug bounties these days, but while many rely on third-party platforms, Google has been responsible for verifying bugs for over six years now. Occasionally, Google expands its program to cover new products, such as Android, and new devices such as OnHub and Nest. Facebook, Microsoft, and most recently Apple are also running their own bug bounties.

Comments

Translation

[Anonymous Coward]

Translation: Android is full of holes, so Google has to recruit an army of underpaid consultants to fix it for them.

Security

[phantomfive]

Security is not something that can be tacked on as an afterthought, it has to be designed in from the beginning. If programmers don't worry about security, if managers don't give time in a sprint to do a security check, then your software will have more and more security holes.

Re:Security

[Anonymous Coward]

Google's lack of care for security is institutionalized. It is part of their MO.

Just look at the play store. Just the other day, a bunch of popular apps were found to be infected with malware. Not one or two, but dozens of them. And this isn't unique: it has happened a bunch of times

How does this even happen? The ENTIRE POINT of the store is that applications should be safe. Someone should be verifying that the apps don't do anything nasty, but I guess all they do is check if the app doesn't mistakenly show boobs or offends some fringe group of lunatics.

Do they care? Nope. Gotta keep pumping apps to keep that sweet ad revenue coming (or a criminal percentage of the developer's blood, sweat and tears).

Re:Security

[Anonymous Coward]

Is it that the app store mirrors are infected, or that the original copy supplied to the store by the developers was already infected?

Re:Security

[Anonymous Coward]

The people writing code for Google are third world south asian foreigners with no foundational training in IT. Their "degrees" are equivalent to a community college certificate of completion, not even equivalent to an associates degree. They are trained to bang on keyboards and generate code. They are not engineers; they are code monkeys.

Re:Security

[phantomfive]

I don't know about that, it's actually pretty tough to get through the Google job interview.

Re:Security

[Anonymous Coward]

It really depends if you are an H1B or not.

Re:Security

[swillden]

The people writing code for Google are third world south asian foreigners with no foundational training in IT. Their "degrees" are equivalent to a community college certificate of completion, not even equivalent to an associates degree. They are trained to bang on keyboards and generate code. They are not engineers; they are code monkeys.

This is a troll, but I'l respond anyway, just because some might find the response interesting.

The majority of Google engineers have masters degrees, the largest portion of them from top tier universities. Not that Google particularly cares about degrees; it's entirely possible (though rare) to get hired as a Google software engineer without any degree at all, assuming you get an employee referral or have something on your resume that convinces the recruiters that you have a shot. Assuming that's the case, you get a phone screen, and if you pass that a series of fairly tough onsite interviews. To get through those interviews you need to have an excellent command of CompSci and software engineering topics, and you need to be good at problem solving and be able to think and code on your feet. "Code monkeys" will not make it. If anything it's harder than it should be, which unfortunately results in rejection of lots of good people. Since interviewing is an imprecise science (art?), Google chooses to err on the side of making it too hard and rejecting good people.

Anyone who is interested in interviewing with Google should do a couple of things first.

One, brush up on your CS fundamentals. Algorithms, data structures, big-O complexity analysis and testing methodology are all essential. With regard to data structures and algorithms, it's more important that you deeply understand the basic ones, including less-obvious aspects of how they get executed on real machines (e.g. cache line usage) than it is that you know about all the obscure ones. For example, you absolutely should thoroughly understand hash tables, their construction and growth costs, space overhead, etc., while knowing the details of tries, bloom (and bloomier) filters, etc., is certainly good but probably not going to have an impact on whether you get hired. Regarding programming languages, it doesn't matter which one you know, but you must be quite competent in one because you will be asked to write code, and it must be good code -- tight, professional, readable and correct. Minor details of syntax don't matter (no one will care if you drop a semi-colon; compilers catch those errors), and you don't have to remember every obscure corner of the standard library, or even precise function/method names.

Two, practice beforehand to blow off any rust and/or smooth out any rough spots. There's a great book "Cracking the Coding Interview" that has about 150 sample problems of the same level of difficulty and complexity as found in real interviews. Work through them all (or at least enough to feel confident of your ability), solve them, code them (on paper, not in an IDE) and evaluate your solutions. Note that the goal is not to memorize the solutions, because none of the questions you receive in the interviews will be from the book. Those questions are banned, as are many others that are found online or elsewhere that many candidates might have seen them.

Doing those two things will maximize your chances of getting an offer. They won't guarantee it, of course. As I said, the interview process is tough, but being prepared will allow you to present the best version of you and give you the best chance.

Re:Security

[swillden]

It really depends if you are an H1B or not.

Actually it doesn't matter in the slightest. If you can pass the interview, Google will attempt to hire you. If you're a citizen, that'll be easy. If you're not, it'll be harder, but Google will work through whatever visa options are available.

Re:Security

[swillden]

Security is not something that can be tacked on as an afterthought, it has to be designed in from the beginning. If programmers don't worry about security, if managers don't give time in a sprint to do a security check, then your software will have more and more security holes.

This is all true. In Google's Android team, all designs must go through security and privacy reviews before implementation, and all code must be reviewed first by a peer before it can be submitted to the code repository, and then by a security reviewer after completion, on a feature-by-feature basis. Automated security testing and fuzzing tools are also applied, and there is a dedicated attack team that is focused on trying to (a) find vulnerabilities and (b) systematize architectural and procedural countermeasures. Google's Project Zero team also regularly attacks Android, as well as other important software from other companies.

However, in any large system vulnerabilities are an unavoidable fact of life even after all that conscientious developers can do, and modern mobile systems are very large. The only solutions are (a) defense in depth, which attempts to ensure that when vulnerabilities are found other layers of the defenses make them unexploitable and (b) find and fix them before the bad guys do. Vulnerability rewards programs are the latter, and higher payouts are better, not worse, as they provide incentive for researchers to stay "white hat" and to find as many as possible and report them along with detailed explanations, demonstration exploits, validation tests and fixes. Due to the Android update problem (i.e. many devices don't get updates quickly, if at all) Android focuses more on defense in depth than most systems, but also invests significantly in vulnerability discovery.

Note: I'm a member of Google's Android security platform team. My job is to build platform components that are used by the system and by apps to build secure systems.

Re:Security

[swillden]

Google's lack of care for security is institutionalized. It is part of their MO.

Yeah, that's why we so often hear about security breaches at Google leaking millions of users' private data.

Oh, wait... that's never happened.

Actually, I was a software and systems security consultant for 15 years before I joined Google. In that time I worked for many fortune 500 companies, financial institutions, even government and military organizations. Based on that experience and on my six years working on security at Google, I'll tell you that Google is better at security than any private company I've ever seen, and better than all but the most security-conscious of government agencies and military organizations. Further, the only way in which Google is less secure than the best is that Google doesn't have armed guards.

Heh. I once made the mistake of carrying a USB drive into a Google data center. The frisk on the way out found it, and I thought for a while I might lose my job, and was trying to figure out if there was anything I might be prosecuted for. In the end, they settled for reprimanding me and keeping the USB drive. They wouldn't even give me a copy of its contents (lest I'd managed to steganographically hide some data).

Re:Security

[Anonymous Coward]

Please stop shitting in the street. This is America, not Paki/India/Banledesh. And use toilet paper, not your hand.

Re:Security

[phantomfive]

So then......what sort of bugs are getting by these 'conscientious developers' (I'm seriously doubting that tbh, I've seen a lot of crap in Android osp. But it's good at least at a management level you are pushing these things)? It is true that Android is big, but that's not an excuse for insecurity, because there are a lot of people working on it, also.

Re:Security

[Anonymous Coward]

Apparently you are too dumb to even Google the MANY times Google has being hacked.

And YES. They have leaked private data from millions of users in MANY occasions.

Re:Security

[swillden]

So then......what sort of bugs are getting by these 'conscientious developers'

Various; check the CVEs.

(I'm seriously doubting that tbh, I've seen a lot of crap in Android osp.

For example? If you find something that's exploitable you can get paid for it, you know.

But it's good at least at a management level you are pushing these things)? It is true that Android is big, but that's not an excuse for insecurity, because there are a lot of people working on it, also.

Increasing the number people working on a project doesn't decrease security bugs, it increases them. Some security bugs arise due to simple developer mistakes, reviews can catch those and more staff helps there. But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.

In addition, any given set of development processes produces a certain number of bugs per line of code. Better processes can drive this number down, but no one knows how to make it zero. That fact in turn means that as a project grows, the number of bugs in it also grow. Big projects have lots of bugs, period.

I should also point out that Android is actually pretty good in terms of vulnerabilities per line of code. I think it's better than iOS, for example, though that's not something I can substantiate with data. One item I can point to, though: There are some flagship Android devices which have no known rooting method, and which have remained unrootable for long periods of time. As far as I know, no version of iOS has been resistant to jailbreaking for more than a few days after release, and rarely does it take more than a couple of weeks to get even a persistent jailbreak.

Re:Security

[phantomfive]

For example? If you find something that's exploitable you can get paid for it, you know.

There's one bug that gives a warning if you compile it. Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.

But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.

Sounds like Google has improperly partitioned developers into silos. Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things get uncomfortable. What a heaping mess of stink. Oh yeah, and the build process starts with a giant 'find' command. What a joke. Don't even get me started on repo, I hate that thing. Oh yeah, and adb.......sysdeps_win32.cpp wtf. Who on earth taught them to do cross-platform development like that? And the whole ADB design is wrong, how many types of sockets are there? A smart-socket is a dumb idea. If you want to see how to do device communication, look at what Apple did. They have a beautiful design on that section. I will say the lockless algorithm in adb is quite nice. Kudos to whoever did that one. In short, the problems in Android come from poor design, and poor division of labor (not mapping to the underlying problem), not from the raw number of developers. You are right that more lines of code means more chances for mistakes, but that is not the dominating factor.

I think it's better than iOS, for example,

I've spent a lot of time working at the low levels of both Android and iOS and I am certain this is true.

Re:Security

[swillden]

For example? If you find something that's exploitable you can get paid for it, you know.

There's one bug that gives a warning if you compile it.

There are a few warnings, but none that represent actual problems, AFAIK. Point me to the on you're mentioning?

Because it hasn't been fixed, I know crappy Android developers aren't even checking their warnings. More generally, I get annoyed at all the giant refactors for no particularly good reason.

You're surmising there isn't a good reason, but you don't know.

But many other security bugs are ultimately the result of miscommunication, and the opportunities for that increase as the number of people working on a project increases.

Sounds like Google has improperly partitioned developers into silos.

Not any more than is unavoidable.

Oh yeah, that brings up another problem I have with Android: in some places, the documentation sucks and the metaphors aren't well-thought out. Which of course, leads to more refactoring when things get uncomfortable.

I can't respond to this without more detail. But... of course. Like all software (and perhaps more than some), Android grows organically and stuff that seemed to be a good idea turns out not to be.

Oh yeah, and the build process starts with a giant 'find' command. What a joke.

Yeah, the build system is terrible. It's especially bad when compared with the system used by the rest of Google, which is the most elegant and powerful system I've seen in 30 years of programming. Android can't use that one because it depends deeply on internal Google infrastructure. The move from make to ninja improved build times, but didn't fundamentally change the ramshackle nature of the build system.

Don't even get me started on repo, I hate that thing.

It seems to me that it's like democracy... the worst possible way to make git work for large projects, except for all of the others. Git is a nice tool in many ways, but it doesn't scale well.

Oh yeah, and adb.......sysdeps_win32.cpp wtf. Who on earth taught them to do cross-platform development like that?

Windows? Well there's your problem; get a real dev platform :P

And the whole ADB design is wrong, how many types of sockets are there? A smart-socket is a dumb idea. If you want to see how to do device communication, look at what Apple did. They have a beautiful design on that section. I will say the lockless algorithm in adb is quite nice. Kudos to whoever did that one. In short, the problems in Android come from poor design, and poor division of labor (not mapping to the underlying problem), not from the raw number of developers. You are right that more lines of code means more chances for mistakes, but that is not the dominating factor.

More components, more interactions, more points of possible miscommunication, those are the dominating factors. And modern mobile platforms are big and complicated.

I think it's better than iOS, for example,

I've spent a lot of time working at the low levels of both Android and iOS and I am certain this is true.

Heh. Damning with faint praise, eh?

Re:Security

[phantomfive]

I can go on pointing out the bad parts of Android, and you'll continue saying, "that's not bad." We can go on forever. Some parts of Android are good: Bionic is an interesting attempt at taming some complexity, for example. Also, two points:

1) For as long as I've followed Android, Googlers have said, "Android is really big! You have no idea how to handle such bigness!" Which is frankly, ignorant. Android isn't the biggest project out there, not particularly complex (which goes to show it's not entirely poorly designed), and even if it were, that's not an excuse........if it were the largest project out there, you could do some systems engineering, solve the problems, and write a book about your solutions. Call it "Non-Mythical Man-Month" or something. But as it is, the complexities you have are largely because you caused them yourselves. That excuse is annoying because it's not true.

2) This is important: I don't think you can have security with a team that big without having good, solid interfaces between sections of code (and sections of the project, since a set of command-line tools are an interface, even though it's not a traditional API). When you say, "security bugs are ultimately the result of miscommunication", that's a clear sign of poorly defined interfaces (and actually, just looking at the code it becomes obvious). Android is just another distro. It's not revolutionary in terms of project organization.

I have more but that's enough for now haha. Good luck

at this rate

[Anonymous Coward]

Teh G will be broke in 8,003 years.

Re:Gay anal sex - bed bug style

[Anonymous Coward]

Three millimillion? Three megamillion? Three metric million?

I wonder...

[the_skywise]

Do they dock the salaries of the programmers who made those bugs?

"Hey you just made us pay out a $5000 bug bounty!"

And if not.. how long before Google and other tech companies DO?

Re:I wonder...

[phantomfive]

Finding blame for a bug is often rather difficult, because it involves a combination of commits from different people.

Re:Boring

[Anonymous Coward]

I'm signing an executive order to make this article interesting

This is a good thing...

[Timothy2.0]

I got the distinct impression that the blurb makes the $3 million paid out by Google seem excessive. Considering their bug bounty program allows fixes to get rolled out quicker (manufacturers rolling out updates is a whole other matter!), this $3 million is a pittance compared to the harms that *could* be wrought if htey dind't have the program in place at all. Looks like a good investment on Google's part.

and still no way to turn off tabs completly

[Anonymous Coward]

lol this browser is very infectable with old virii