Slashdot Mirror
Google Bug Hunter Urges Apple To Change Its iOS Security Culture; Asks Tim Cook To Donate $2.45 Million To Amnesty For His Unpaid iPhone Bug Bounties (threatpost.com)
secwatcher writes: Prolific Google bug hunter Ian Beer ripped into Apple on Wednesday, urging the iPhone maker to change its culture when it comes to iOS security. The Verge: "Their focus is on the design of the system and not on exploitation. Please, we need to stop just spot-fixing bugs and learn from them, and act on that," he told a packed audience. Per Beer, Apple researchers are not trying to find the root cause of the problems. "Why is this bug here? How is it being used? How did we miss it earlier? What process problems need to be addressed so we could [have] found it earlier? Who had access to this code and reviewed it and why, for whatever reason, didn't they report it?" He said the company suffers from an all-too-common affliction of patching an iOS bug, but not fixing the systemic roots that contribute to the vulnerability. In a provocative call to Apple's CEO Tim Cook, Beer directly challenged him to donate $2.45 million to Amnesty International -- roughly the equivalence of bug bounty earnings for Beer's 30-plus discovered iOS vulnerabilities.
The company with the most Swiss cheese mobile OS on the market today? Unbelievable.
Google Bug Hunter, who couldn't make Android secure, tries to tell Apple how to do proper security ?
Android is a security nightmare, it ranked way under other systems on that point. They have no solid grounds to talk to people about security.
Apple does have a well-thought-out security design. Maybe there are things wrong with it, but to say they 'just fix bugs' and don't think about overall security ignores the truth. But I suppose that's what you get when you're click-seeking. See: https://www.apple.com/business... Can we find holes in that? I'm sure. But they do have a plan. And that's the public one. I'd wager there's an even more detailed internal one.
We shall soon see how tight Cook's ass really is.
What?
Why would a jewelry maker be interested in security?
You could remove the touch screen and replace it by a "predictive AI" user interface animation that does what it assumes is most likely what the "owner" wants to see, and half the Apple clients would take longer to notice, than the lifetime of the soldered-in battery.
Google shouldn't talk about security anyway, when their primary business model is snooping on users to enable sleazebags to lie to them (aka advertisement) and rip them off better.
This dude is a parasite just trying to suck the blood out of a cash cow.
If you want privacy, you need to ditch your phones. Your friends will contact you the old way.
All phones have backdoors. The NSA wouldn't have it any other way.
You have software that took months/years to plan and develop.
A problem is found.
You need to Fix it Fast, before it goes out to the wild.
It will need to be tested to make sure it doesn't break compatibility or break something else.
If asked to change the infrastructure for every time there is a bug. The fix will take years to get out, and a new infrastructure will introduce new flaws untested.
A security first design of software made in the 1980's would just have a password login and permissions on what the user could see and do.
1990's Memory checking and limitation to prevent buffer overflow
2000's Memory randomization and removing from an ask to allow to don't allow, and you will need to do extra work to allow.
2010's Application Sand-boxing, Full Encryption, tiered design, redundant checking...
iOS being a product of the 2000's Is actually stronger then some other systems, but it has a lot of once good practices which are now bad practices in-place. But there hasn't been a massive iOS outbreak of security issues. Like with Windows a decade ago. Makes me figure that the current patching routine is still good enough.
Will they need an architectural redesign in the future. Probably. Like when Apple moved from MacOS (Classic) to OS X. They will need to upgrade iOS to a new system at some point just to stay current.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Doesnt apple still try and sue people who find bugs in there system.
at security and privacy? I don't trust them 1 bit.
and Tim Cook is not interested in paying for fixing critical bugs. They make spying-devices branded as luxury phones, do you really think they will donate money or fix critical security bugs at the root?
That is not what Apple does.
So the actual owners very well can put malware on there. You just can't, because it is not your phone. You are just the livestock resource that's milked. The clients are the "apply app app" (as a troll here put it) developers, and they get to milk you in every way, as long as Google isn't angered.
Hey Google... Why not fix your own shit first and mind your own business. Maybe you could start with your API's for products that don't work as documented....
"... we need to stop just spot-fixing bugs and learn from them ..."
The entire industry needs to learn from bugs. We need to get over the idea that they just happen and accept responsibility for putting them in.
Advertising isn't all sleazebags. It exists to some degree, but there is also useful advertising.
first, working for google disqualifies you from being taken seriously - especially on security. second, this guy talks in a weasly way - you can tell these pricks by the fact they always knowingly ask totally basic questions as if nobody else knows anything.
Of course, seriously doubt bugs he has found are worth anywhere near 2M - the typical bullshit from âoesecurity researchersâ overinflates the severity.
> Two recent Apple bugs are perfect examples of this: "goto fail" and "passwordless root." Both are symptoms of either Apple not testing, or more likely, Apple only doing positive testing (this works with the values it's supposed to), but never any negative testing (this fails properly when given bad values). ...
> Both of those are process problems. Failing to do negative tests is a very common process flaw: it's very easy to write a "positive test" that ensures that a correct value produces a correct result.
Exactly. It is common. They tested that "it works" putting in the correct password gets you access. They totally forgot to test what happens when you DON'T put in the correct password - you still get access anyway.
In the famous "go-to fail" bug, a TLS certificate was accepted of it was valid - and accepted just the same of it was invalid. They probably tested that worked, that it trusted a valid cert. But they didn't test that it did not trust an invoice cert.
There is no "architectural redesign" required to start testing the negatives, checking that NOT entering a password does NOT log you in. It's just a policy change - all Pull Requests need at least two test logs attached - one showing that it does the new / positive thing when it should, one showing it does NOT do it when it shouldn't.
At my own company, on my team, we recently had the same problem. We added some code to handle the eccentricities of a certain CDN (proxy network) whose engineers have obviously never glanced at the RFC for how proxies are supposed to work. Our code was basically:
if (looks_like_akamai) {
do_weird_akamai_stuff;
}
We tested that it did in fact invoke the special behavior for Akamai. We didn't test that it did NOT invoke the special behavior when it's NOT Akamai.
Wow that had a lot of typos. Let's try that paragraph again:
In the famous "go-to fail" bug, a TLS certificate was accepted if it was valid - and accepted just the same if it was invalid. They probably tested that it worked - that it trusted a valid cert. But they didn't test that it did not trust an invalid cert.
There is no "architectural redesign" required to start testing the negatives, checking that NOT entering a password does NOT log you in.
Their major security bugs show a simple PROCESS issue, not an architectural issue.
You don't have to completely rewrite the architecture in order to test that NOT entering a password, leaving the password field empty, doesn't log you in. You just have to start testing not only "it does the good thing with good input", but also "it does the negative / error case with bad input".
Their famous "go-to fail" is another example. Their code was basically:
If certificate is valid {
trust the certificate
}
trust the certificate
That bug would have been prevented by testing their "validate certificate" code with an invalid cert. They. Probably tested that it correctly trusted a valid certificate, but clearly never tested it with an invalid certificate. That's kind of important for code that's supposed to tell the difference between the two.
See also this post and its parent:
https://slashdot.org/comments....