iPhone Bugs Are Too Valuable to Report to Apple
motherboard.vice.com
motherboard.vice.com
I find this particularly interesting:
> [the security researchers] asked Apple's security team for special iPhones that don't have certain restrictions so it's easier to hack them [...] these devices would have some security features, such as sandboxing, disabled in order to allow the researchers to continue doing their work.
If I go to Google or Facebook and ask them to, say, turn off some key security features on their site so I can find more bugs they're gong to tell me to go take a hike. It's unclear to me why a security researcher thinks Apple would give them access to a device with the sandbox bypassed. Why would they possibly trust them?
[1]: https://technet.microsoft.com/en-us/library/dn425036.aspx
(My comment is now at -1. I challenge anyone considering to downvote this response to actually answer how asking for the right to modify the software on the one phone in your possession--the one whose security features, if you really want to insist that this is about a security feature, only affects you--is even remotely comparable in an honest setting to "go[ing] to Google or Facebook and ask[ing] them to, say, turn off some key security features on their site".)
Thankfully the UX on Android has caught up to the point where it's as good as or even better, in some respects, than iOS. At least for my purposes, anyway.
For example, if they open the secure enclave so that security researchers can see in full detail how it works, that may expose some master key.
Countermeasure would be to have separate keys, ideally for each such phone, but having them for only this class of phones might be sufficient, too, if they also restrict access to this class of phones. I think that's technically easy, but may be expensive, process wise.
I mean, at some level your comment turns into "we should try to hide the security flaws we have as much as possible, even from the people who are actively trying to help the world be more secure"... if you aren't serious about finding bugs, why bother with security?
Your argument seems (to me) to be there should be no secrets on that phone that make attackers any the wiser (might well be possible, given the existence of asymmetric encryption). If so, why did Apple go to the effort to add the secure enclave?
> Countermeasure would be to have separate keys, ideally for each such phone, but having them for only this class of phones might be sufficient, too, if they also restrict access to this class of phones. I think that's technically easy, but may be expensive, process wise.
...is already something Apple does with the special development devices. Different keys and certificates used, probably to allow easier access for engineers while tightly monitoring and auditing production infrastructure.
The only way I can think of that doesn't have an endless array of problematic edge cases is for Apple to have a "researcher edition" of the phone, but even that isn't problem free.
Thoughts?
The only issue I can come up with would be "what if a researcher who was registered with and known to Apple gave their phone to someone else as a fake gift to spy on them". If you really want to go there we could argue it, but it seems a little far fetched in terms of "amount of damage that can be done via this route that couldn't be done via other ones".
If it's locked to specific hardware, then no, I definitely wouldn't argue the edge case scenario you mentioned.
The bootloaders and kernels for production devices still retain the code for the "special" functionality, that is how researchers are aware of it, but it simply will not work without an actual dev-fused device.
You can just do it! If you can figure out how and don't mind maybe breaking your iPhone.
Apple doesn't sell infinitely customizable devices. Anyone who buys an iPhone knows this going in or is being intentionally obtuse. The idea that it's my phone I should be able to do anything I want with it is completely antithetical to the brand Apple has built over the last 40 years.
I don't quite understand the demand side of this, is it just complacency among customers of these companies not demanding more secure systems.
No bug bounty program has to pay market rate. They just have to pay enough so that $bounty > $market_rate - $fear_of_getting_arrested
Edit: there are actually other non-monetary benefits to being a white hat. Some of them get high-paying contracts or fantastic jobs. Some just like the prestige of finding flaws. So it's a more complicated equation than I presented above.
It isn't that uncommon in bug bounty programs to get specific restrictions (say rate limiting on web apps) turned off.
When I do security audits i'll often ask for shortcuts (give me access to X machine as if I phished it, etc). These shortcuts will shave a month of the low level grunt work off so I can spend my limited time working on the core vulnerability.
If my reading is correct, at Apple that tops out at 50k, you have to compromise the Secure Enclave to go even reach 100k
If I'm not mistaken for MS it's covered under the Mitigation Bypass and Bounty for Defense Program, which is up to 100k + 100k (100k for mitigation bypass, 100k for bounty for defense)
Let's say instead that there were some shady people who liked to hang out outside of the local gas station, and you have heard that they will give you a cut of any heist they pull off based on "tips". Do you call them over to come steal the car? I bet you don't do that either.
Let's say that it is some random person's car. I still doubt you steal the car, and I still doubt you tip off someone else to steal the car. However, I also doubt you go far out of your way to find and tell the owner of the car something is wrong.
What if, though, you knew that you could get a reward; something sizable enough to be at least worth your time, but nowhere near the value of either the car itself or what a band of thieves would be willing give you if you called them and tipped them off?
That's all this bug bounty program is: it is designed to provide a reason for people who come across bugs to even bother coming to Apple at all rather than just putting it in a "pile of fun bugs".
Only, instead of the moral issue being "someone's car might get stolen", it is more like "you found a bug in the Tesla's computer locks, which makes it trivial to walk up to any Tesla anywhere and just drive off (or even tell the Tesla to steal itself!)".
The companies that offer large sums of cash for key bugs, such as Zerodium, tend to be pretty "black hat"... their clients are doing stuff like corporate and governmental espionage; they might even have mafia-like organizations as clients for all you know.
https://www.wired.com/2016/09/top-shelf-iphone-hack-now-goes...
So that's the real ethical question involved here: do you go to Apple and get your $50-200,000, knowing that Apple will give you credit for the bug, let you talk about it at the next conference, and seems to care enough to try to fix these things quickly...
...or do you sell your bug to a group that resells it to some government which then uses it to try to spy on people like Ahmed Mansoor, "an internationally recognized human rights defender, based in the United Arab Emirates (UAE), and recipient of the Martin Ennals Award (sometimes referred to as a “Nobel Prize for human rights”)".
https://citizenlab.org/2016/08/million-dollar-dissident-ipho...
FWIW, I have severe moral issues with this bug bounty program: I am a strong advocate of simultaneous disclosure, and while Apple does tend to fix bugs quickly, they have made it clear that they are not prepared to commit to timelines even while keeping users in the dark about what they need to do to protect themselves.
However, this article makes it sound like the entire concept of the bug bounty program is incompetent or something, as it is failing to pay as much money as the black market... while I have met a few people in the field who are more than happy to sell a bug to literally anyone with cash, the vast majority of people (even the ones whom I have sometimes called "mercenaries" for being willing to "switch sides"), have a pretty serious distaste for the idea of selling a bug to the highest bidder.
The real reasons you don't hear much about people selling their bugs to Apple are that they are like Luca (who started doing this at the age of 17--he's now either 19 or 20?--which is context that I think is really important for this evaluation) and are sitting on bugs because they are personally valuable to them (as without at least one bug, you don't even own your own phone enough to look for others; so there's a really big incentive to not disclose your last bug: this is the thing that Apple should really care to fix), that they are intending to release a public weaponized exploit in the form of a jailbreak (which, given the demand from legitimate users due to Apple's insistence on locking down their devices for reasons that are more about business models than security, can be a ticket to world-wide fame that money just can't buy, and which will also net you at least some donations on the side), or simply that they actually have been but they haven't told anyone (a situation that seems so likely that it seems weird that this article discounts it).
as without at least one bug, you don't even own your own phone enough to look for others
Indeed, the fact that these bugs can lead to freedom, in the form of jailbreaking, certainly complicates the decision.
The physical analogy doesn't help either; I mean if you were somehow kidnapped and physically kept hostage in a "walled garden", would you tell those watching over you that you found a way out, if they told you that telling them would result in some reward --- but that you'd remain inside?
I have, a handful of times, discovered exploits that would break some DRM or allow myself more freedom (e.g. bypassing a registration-wall on a website or other software, found detailed intended-to-be-confidential service and design information for equipment I own, etc.) In all those cases I never considered notifying the author(s) about it. Granted, this was a time when bug bounties were nearly nonexistent, but now that I think about it, even if I was offered some other reward, I wouldn't.
It's more like contracting a security firm to keep your stuff safe. They promise they'll do their best, and in exchange you give them some money and acknowledge that they don't have to explain to you how it works. If you find a flaw in their security system, you can either (a) sell it to somebody, thus compromising all of the firm's clients (including yourself), (b) report it to the company so they can fix it, or (c) keep it secret for some reason. I would always choose (b). I find (c) to be in poor taste, but not appalling by any means. (a) is, in my opinion, never an acceptable option.
How many people would openly admit to being willing to sell bugs to the highest bidder? I certainly wouldn't.
If anything, selling on the black market guarantees that you get what you think is a fair deal. You demo, you reach an agreement, you get your money (or bitcoins or whatever), and you move on. When disclosing a bug to a company, you have no idea how much payout you're going to get, if any.
The bugs that Apple is looking for take time and resources to find yet you can't depend on the $200k of revenue to feed yourself. E.g., even after you spend months of real work you sometimes fail and get no payout. That's an acceptable risk for a $3k bug bounty. It's not at $200k.
Every other issue you cited is secondary to the economic one.
In general, it's not possible to "stumble upon" a $200k bug like the kind Apple is looking for, you have to set out with the intention to find one and work for it. But you're not on a contract and you're not getting paid the whole time. You only get paid on delivery and there's a high chance you won't have anything to deliver. It's just too much risk for an individual or company to commit months of time at potentially $0/hour.
You alluded to it, and it bears mentioning that there is a balancing act with future revenue streams too. If you set up the process to find one $200k bug then presumably you want to use all that know-how to find a second one. But reporting the first one to Apple will, generally, kill your entire revenue stream as Apple knows all your secrets now.
In general, working on $200k bug bounties is a bad business proposition. Period.
Microsoft also had/has mitigation bounties for around the same dollar amounts and it turned out nearly the same: lower than expected interest given the price point. Most of the interested parties tend to be academics, for fairly obvious reasons when you think about the economics of it all.
I think that if Apple wants to find bugs this deep in specialized, hard-to-audit surfaces within iOS, they ought to hire experts at expert rates and provide them the tools they need to look. In my perfect world, I would hire an expert consulting firm at their market base rates and then offer bonuses for findings on top of it. I would make the engagement low intensity and long in length, to build competency and familiarity with the codebase over time.
I'm really curious where this idea that the existence of a bug program means they must have no in-house bug hunting team. A competent, deep pocketed corporation (which I think we all agree Apple is) would certainly do both.
Want to hunt Apple bugs but not work for them? Do that. Want to hunt bugs with a steady salary? Do that.
Edit: now with link to 197 job postings! https://jobs.apple.com/us/search#&ss=Sr.%20Security%20Engine...
I know silicon valley employees' honnesty is above all suspicions and rogue employees is a monopoly of the financial industry but one has to consider the risk.
I would have said the same of bankers and management consultants but the fact is things like insider dealing is a thing.
Insider trading can earn very large amounts of money, and the higher your current position, the larger scale of insider trading becomes available.
Now, for Apple iOS core developers - does it make sense to risk a $200k/year job and possible jailtime to get a $50k bounty (the limit for kernel exploits) that you'd have to share with whoever helps you to launder it?
Many high profile bugs seem to have plausible deniability where they can reasonably be errors but might have been deliberately inserted. Anybody can make mistakes similar to Heartbleed, especially if they want to.
...Apple does this. The people I complain about and call "mercenaries" are the people from the grey hat hacking community who decide to go work for Apple. If I wanted to go work for Apple on this I could probably get myself hired there in a matter of days, if it weren't for the issue that I am morally opposed to it (and they know that at this point, so they would rightfully be highly skeptical of me finally "coming around" ;P). The bug bounty program is not focusing on this issue.
The moral costs of the latter do not pay for the benefits of the former. I look at people who work for Apple on security as similar to people who work for the TSA: yes, they are probably in some way contributing to the safety of people... but they are actively eroding the liberties of people in such a frightful way that the benefits are not worth the cost.
So when I see people working for either the TSA or for Apple, I ask myself "did they really really need this job? or could they have gotten work elsewhere"; and if the answer is that they didn't absolutely need to work for Apple, I model them as someone who has left the Resistance to go work for the Empire because they thought laser guns were cool and the Empire happened to have a larger laser gun for them to work on, and hell: the Empire is managing to maintain order on a large number of planets, right? :/
In case you think that this is just some future concern, it is a war which is already playing out today in countries like China, where the government knows that Apple has centralized control of what can be distributed on that platform and uses that knowledge to lean on Apple with threats of firewalls and import bans to get software and books they dislike redacted.
https://www.nytimes.com/2017/01/04/business/media/new-york-t...
> Apple, complying with what it said was a request from Chinese authorities, removed news apps created by The New York Times from its app store in China late last month.
> The move limits access to one of the few remaining channels for readers in mainland China to read The Times without resorting to special software. The government began blocking The Times’s websites in 2012, after a series of articles on the wealth amassed by the family of Wen Jiabao, who was then prime minister, but it had struggled in recent months to prevent readers from using the Chinese-language app.
Having a centralized point of control at Apple is not helping the lives of these Chinese citizens, at least according to the morals that I have (and I would have guessed you have, but maybe you are more apologetic to these regimes than I; we have never really spent that much time talking as opposed to just kind of "sitting next to each other" ;P).
So, yes: I absolutely am against security experts "helping Apple secure iOS" when what we know is actually happening is that they are "helping Apple enforce censorship by regimes such as the Chinese government on their citizens". There are tons of places in the world you can go work for where your work on security will actually be used for good: go work for one of those companies, not the oligopoly.
I mean, here's a really simple one: they already have "free developer" account profiles. However, you can't install an app that uses the VPN API using a free developer profile. So if I build a VPN service with a protocol designed to be used by people in China to help people bypass the Great Firewall, as VPN services are illegal in China, China has complete control over Apple's app distribution, and Apple not only polices the use of their enterprise certificates but has in the last year or so started playing whack-a-mole on services which use shared paid developer certificates, users in China are not going to be able to install it on their iOS devices.
Why did Apple go out of their way to block access to the VPN API from free developer accounts? I can't come up with any reasons for this that make me feel warm and fuzzy :/. So yes: the US military does a lot of good protecting people on foreign soil, as does the FBI here at home, and I'll even grant that the TSA probably does something good ;P. You can show me a ton of reports of active terrorism in the world, and say "look, this stuff is important, peoples' lives are on the line"... but as long as working for those groups is tied to mass surveillance, installing puppet regimes, and maintaining resource imbalances, the moral issues remain :(.
(I'm also going to note that I find it a lot less weird if someone is consistent and always worked for Apple, whether directly as an employee or indirectly by handing them information and bugs than if they "switch sides" and go from simultaneous disclosure to "responsible" disclosure or even forced disclosure by being an employee. That's why this thread was spawned from me noting that I have at times used the term "mercenary". It makes some sense to me that there are people who work for the Empire because they believe in the goals of the Empire; it just irks me, though, that there are people who once worked for the Resistance who get a job offer from the Empire and are like "wow, that sounds great!" and go work for them without seemingly believing that anything has changed about what they are fighting for... it tells me that, at the end of the day, they really just thought "working with lasers is fun!" and the moral issues of which side they were on never mattered.)
I'm in agreement with you regarding Developer ID. I have no idea why Apple would want to limit that, I know they recently relaxed restrictions on NetworkExtension though (except for Wi-Fi helpers) - Are you referring to the old "e-mail here to apply for the entitlement" process they had in place? Or do they still not allow the entitlement for free developer IDs now?
I really do mean the latter: they still block this entitlement from use by free developer IDs. If you try to activate it you get an error #9999 with the following message.
> The 'Network Extensions' feature is only available to users enrolled in Apple Developer Program. Please visit https://developer.apple.com/programs/ to enroll.
Just disregarding these things and justify it with "economics" or "it's bad business" doesn't make ethics disappear. I'm guessing you wouldn't sell exploits to ISIS even if they were the highest bidder..? What about North Korea? China? Russia? Syria? The US? The US with Trump in charge?
I personally like tptacek's comment on this from last year:
>None of them are adequate compensation for the full-time work of someone who can find those kinds of bugs. Nor are they meant to be. If you can, for instance, find a bug that allows you to violate the integrity of the SEP, you have a market value as a consultant significantly higher than that $100k bug bounty --- which will become apparent pretty quickly after Apple publicly thanks you for submitting the bug, as they've promised to do.
This is the same twisted logic that people try to use to hire photographers or graphic designers to work for them for free, because they will get "exposure". If someone does something valuable for you, you should pay, no matter how famous your brand is. And Apple has enough cash to spare.
(And just to be clear, I do think that fair compensation is a part of that ethics discussion, but it doesn't trump other concerns.)
(edit: typo)
If Apple is not providing reasonable money compensation to white hat security researchers then they are willingly leaving this space opened for black hats.
No, Apple is making money of their walled garden, they should be the ones to pay the bills for wall maintenance.
I think this logic is inherently flawed.
If there was no monetary incentive and the only ROI was a thanks from Apple, maybe the bug in question would not have been found in the first place. Becoming aware of a bug does not suddenly put people at any more risk than they were previously in, prior to bug discovery.
I agree, which is why I said "keep[s] [...] millions of users at risk" not "puts millions of users at risk". An unfound bug is still a potential zero-day. With something as valuable as an iphone exploit, we know multiple entities are desperately looking for it, so I wouldn't err on the side of assuming that any exploit would not be found. (or put more succintly: If you've found it, someone else might've to)
So, I am going to say it again: I believe the article is not actually focusing on the same problem as Apple's bug bounty program. The issue you were quoted for in the article is "how do you get someone already doing this to give the bug to Apple instead of selling it at market rates". Well, if someone is willing to sell it at market rates, then Apple is kind of screwed as that person likely does not have much in the way of morals and Apple is never going to outbid the market rate.
Now, you are focused on a different issue: "how do you incentivize people who otherwise wouldn't work on this stuff at all to work on this stuff". This still isn't something Apple is focused on. If you want to do this but just need a steady salary, I bet Apple would love to hire you.
What a bug bounty program does is it makes the situation that does sometimes come up where you stumble across an issue while working on something else, or you just got really curious about a thing and find yourself two months later having "wasted your life" on scavenging a bug, or you have some other motivation (consulting or academic work) to be panning for gold, and now you don't know what to do next: rather than doing nothing, you give it to Apple for some reasonable payout.
If you were morally OK with selling your bug on the black market, Apple can't be going around trying to outbid evil, so that can't be a goal of this program and you can't judge it for not solving it.
And if you wouldn't have spent your time on this at all, and would have instead gone off to work on some other project, Apple isn't trying to replace "jobs": they have a massive security staff of some extremely talented people (many of whom at this point used to play for the other side).
(_emphasis_ was mine)
I agree with you that dguido has framed Apple's Bug Bounty program incorrectly. The money amounts are deliberately not structured as a incentive to build a remote "red team"[1] to do speculative work. (I would go farther to say it would be folly to attempt to create such a salaried red team to uncover security bugs since history has shown that many types of security exploits that come to light had leaps of creativity that exceeded the imaginations of the systems' designers.)
However, I'd add some nuance to your moral scenarios by stating that a sophisticated buyer of Apple bugs would not present it to the hackers as "selling to evil entities". Instead they're actually selling to the "good guys" -- it's just a different set of good guys from Apple. (E.g. Zerodium may in some instances act as a front to buy the bug on behalf of NSA/FBI/CIA).
The article talks about hackers that are willing to go to dinner with Apple and meet-&-greet Craig Federighi. Since these "security researchers" are willing to show their faces to Apple, we'd probably classify them as "white hat" or "grey hat" hackers instead of evil "black hat" hackers. Therefore, one way to persuade these researchers to sell the secret to the black market is to convince them they are still serving "the greater good"... it's just the black market group is paying $500k instead of Apple's $200k.
Summary of my interpretation of Apple's Bug Bounty:
1) Apple did not set it up to incentivize speculative work. This looks like an economic design flaw but but it actually isn't.
2) Apple is not trying to persuade immoral black hat hackers to sell to Apple. Apple already knows the amounts are too small to compete there. The audience they are trying to appeal to is the white/grey hats.
[0] https://en.wikipedia.org/wiki/Argument_from_authority#Valid_...
You responded to his rebuttal with "I know how these things work, don't you know who I am?" reiterate position without adding any further points or addressing the opposing party's points
How is that not an appeal to authority?
I don't know who you are (and maybe that's why I'm the only one calling you out). If you are as influential in this space as you appear to be, it's important to take the initiative to present strong arguments rather than rely on your name.
Sorry to hear about the insomnia - I'm in the same boat. Hope it gets better.
Well.. except that's not really true. iOS is de facto the most secure consumer OS out there, precisely because it doesn't allow arbitrary code to be run, and because of the restrictions placed on the process of getting software onto them. The value Apple gets from users not worrying about viruses, malware, or other security threats far exceeds the piddling revenue from the App Store, because that peace of mind and brand reputation drives device sales where that value is captured.
Meanwhile, the more permissive consumer OS' of Windows and Android seem to have continued issues with security, and the average - even informed - consumer never really knows what the software on them is really doing.
I don't disagree with the rest of your comment though!
I meant something slightly different wrt 'permissive', namely that the overall market execution of Android is very permissive. To users buying the product, the specific reasons why Android is less secure don't matter. The only thing that matters is that they cannot fully trust software on the device or acquired though stores. Whether its the vendors that don't update the OS or the telecom company that installs crapware or the poorly policed third-party app store, malware has ample ways to get on the average Android device, due to the permissiveness of the full chain of processes and people involved in how it is deployed and managed.
> the reality is that for the first over well-over five years of iOS existing, it was de facto open: jailbreaks were commonly available and easy to use
Agree. The first few years were a whirlwind of rapid evolution and Apple had its hands full, and Apple just wasn't developer-focused. Jailbreaks were likely tolerated because developers were hungry to try things and Apple knew the libraries on iOS weren't that great at the time. Plus, jailbreak developers were like an outsourced R&D group for Apple to pluck ideas from. However, as iOS matured, and our culture rapidly adapted to smartphones, people began trusting them with more and more personal information. The cost of not addressing security became higher and higher. Developer tools and libraries also matured in this time, so overall the negatives of jailbreaks (security) began to far outweigh the positives.
> the idea that the very existence of an ability to control your own device can thereby be shown by simple demonstration to not be a serious concern.
Concerns for security exist on a spectrum (and are weighed against other concerns in development), and concerns can change as the world changes and the product evolves.
> the business reasons are that they want a strong DRM story in order to be able to pitch content producers and developers on why their platform should get to deploy and vend their media
I've never once heard the argument that DRM is the reason iOS is locked down. It also doesn't follow given that Macs are not locked down and can get the very same media, as can other platforms.
Given Apple has consistently focused on making computers for regular people for over four decades, I think it's pretty obvious the reason iOS is locked down is simply because there's an enormous amount of bullshit that comes with having users download software from unknown sources, and that a tightly controlled platform provides a much better user experience for regular users. Any other benefits are incidental.
EDIT: After re-reading your comments, I think we're disagreeing in whether locked down = more secure. In the case of iOS, I think it was a conscious decision made to create a better user experience, and an important subset of user experience is security. As you point out with the history of jailbreaks on iOS, you're saying Apple's permissiveness then suggests they don't have that security concern and they want to lock it down for other reasons (correct me if I'm wrong in characterizing your argument). I disagree and think security was one of many concerns being balanced at the time. Also I believe the types of vulnerabilities used by jailbreaks were probably not the types typical users would encounter in daily use of a device, such as browsing the web or downloading apps from the app store. Correct me if I'm wrong on that.
> As you point out with the history of jailbreaks on iOS, you're saying Apple's permissiveness then suggests they don't have that security concern and they want to lock it down for other reasons (correct me if I'm wrong in characterizing your argument).
No: you completely misunderstand. I am not saying Apple let jailbreaking happen; I am saying Apple's device was so poorly secured (in an absolute, not relative, sense), that in practice you can model the device as being "open to anyone who wants to make their own device open". It was more open than Android for long periods of time as the jailbreaks were more consistent in their ability to give you full control of the device (Android jailbreaks tend to be "hit or miss", really).
The argument then becomes simple: if iOS is a platform you consider secure ("iOS is de facto the most secure consumer OS out there"), in practice this is a device which anyone who wanted to could get complete control over their own device, and so we know that property is unrelated to security.
The only thing it really does is make the device look better from a DRM perspective (particularly the AppleTV). I run into tons of developers constantly who are obsessed about piracy well past the point where it makes sense, and most of them have this weird mental model of Apple's security features that make them think weird stuff like "if I embed a key in my compiled binary no one can read it".
Regardless, I am just going to say it, as me having this information and trying to avoid saying it is probably just causing more problems than it benefits anyone: I have been challenged multiple times by people working at Apple (years ago, and I don't even think these people still work there, which makes me feel at least slightly more comfortable saying this) that if I want them to have a more open device in the ways that I want, I need to tell them how to do it without opening the flood door for piracy.
Interesting paper: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2244111
User lock-in is all that Apple really cares about - the entire app approving dance just adds a nice toolset to find arbitrary reasons for blocking apps that might be interfering with Apple interests (https://www.recode.net/2016/6/30/12067578/spotify-apple-app-...).
FYI: You're not wrong on this, I have found multiple apps which try to grab sensitive info and phone home with it, only pointing out your link may not be the best example to use.
Either:
A) You're already a criminal doing it for the money or
B) You're just trying to help people and not doing it for the money.
Person B probably doesn't exist. So you're probably already A, a criminal and you don't care if people think you're immoral.
I don't? Weird. There are lots of motivations for hunting bugs, many more powerful than money to people who have money already.
Bug bounty are: "do your job almost free and be paid sometimes"
Can't you do both? (First sell to the evil group, and a little later to Apple).
> ...or do you sell your bug to a group that resells it to some government which then uses it to try to spy on people like Ahmed Mansoor, "an internationally recognized human rights defender, based in the United Arab Emirates (UAE), and recipient of the Martin Ennals Award (sometimes referred to as a “Nobel Prize for human rights”)".
Selling the bug to Apple or some black hat group is rather a choice between the devil and the deep blue sea. If you sell it to some exploit vendor, it will have the ugly consequences that you outlined. On the other hand if you use Apple's bug bounty program, Apple will use this information to lock the golden cage even tighter on its users - a consequence that I would also strongly avoid.
So I can understand that if it is a choice between the devil and the deep blue sea, you will sell it to the best-paying buyer. On the other hand, if I could be sure that Apple will never ever not use the provided information to lock the golden cage on its users, I would accept your reasoning. As it stands now, I won't.
Apple is not lacking cash on hand, and while I know that's not a reason to spend it, I figure they could come further toward the going rate. Especially infuriating is the lack of other moral incentives beside "doing the right thing", like when you get a bug bounty for an open source component, and know that the public has free access to it. Even "doing the right thing" when it comes to Apple is morally unrewarding, since they typically treat developers and partners like dirt, and are so isolated from the rest of society.
Because of the lack of true community around Apple and their products, owing largely to how proprietary all of their products and programmes are, I don't see why anyone would do white hat security research on their platforms unless they were paid substantially and directly by Apple or an Apple customer.
From my perspective, it's enough of a smack in the face to use their products. I doubt many want to be fed what amounts to (relatively speaking) table scraps for elite security research on a platform that you don't own at the end of the day even as a customer. To have to be invited to do this just makes it completely not worth starting if your goal is to participate in the white hat market.
What Apple can compete on are the non-monetary incentives, such as prestige, rewards, access, etc.
That is not how supply and demand work.
(Furthermore, it's also not as simple as exploit buyers paying more, because there are reasons for researchers to sell their exploits to Apple even if other buyers might pay more - the problem described (badly) in the article is that the disparity is currently too high).
I don't know, but I'm fairly sure, that Apple _could_ outbid the other exploit buyers if they chose.
I'm a die-hard Android fan, but even I'm forced to admit that iPhone has much better security. And security is a big selling point.
Raising the bug bounty to $10 million and it would still be pocket change to Apple, but it would result in:
1. Free advertisement
2. Good PR
3. Outbid the black market for iOS exploits
4. Encourage more white hats to look into iOS security
That will never work. Zerodium and others are just middlemen that sell to the US/CA/UK/AU/NZ government. They aren't selling these exploits to random companies or underground hackers.
The NSA will pay an unlimited amount of money to have iOS remote 0days sitting on the shelf because they might have a small window where say, an ISIS leader's kid left his iPhone in the room during an important meeting.
There are amounts that they can't afford, but those amounts would stretch Apple's wallet as well.
Apple (and the others) controls how much they invest in writing secure code, and how they manage the trade-offs with, for example, investment in shiny new functionality.
So when they make a security slip up and write code that contains an exploit, it's a good thing that the market punishes them.
He's dead so he cannot weigh in, but I think it's fair to suppose early life/career he may sell it to the highest bidder and use the money to invest in a Pixar type, or sell it to both parties if possible. Later life/career possibly use it to negatively impact a competitor? (weighing legal risk to his company of course) How about WW{Apple/Cook}D? I think we know what Uber would do;)
I don't think there's a need to multiply payouts by ten though. When you give regular people -- as opposed to people familiar with selling exploits on the dark web -- the ability to sell exploits legally to Apple, you motivate a much larger group of people. The honest hackers far outnumber exploit vendors if someone is willing to pay them. That someone could be the company that depends on the software for their business (Apple with iOS), or a software insurance company.
The very reason companies like e.g. Google, Microsoft, Apple are so profitable is because they have many users, which in turn make exploits against their software very valuable. So, unless a company's profit per user is very small, this should always scale (more users = both higher income from users and higher price for exploits). If they were willing to purchase exploits at market price they would, in effect, be functioning as their own insurer -- in my opinion, this practice is the only sensible thing an insurance company can do to insure software of reasonable complexity.
Microsoft paying one million USD per exploit, for 100 high-value exploits per year (0.1bn USD), would decrease their yearly profit (2016: 16.8bn USD) by only 0.6%, but make a huge difference in the security of their software (100 high-value exploits per year is a lot). Stockholders would be foolish to vote no if this were proposed.
> Stockholders would be foolish to vote no if this were proposed.
I doubt that an improvement to security of the type you describe here would have a significant improvement on sales or reputation of MS. So shareholders will see profits go down, who would vote on that?
Uhm, what universe do you live in exactly? Because the universe where I live, I have Apple or Android. Saying that apple's bullshit isn't forced on millions of users is like saying the Republican party's bullshit isn't pushed on millions of citizens. I mean argument aside, let's not do Apple's job for them and paint the world as capitalistic utopia where consumers have all the power and make all the decisions. Consumers do not make 99% of the decisions related to their phone, including the decision to have one.
I think you are analyzing this question from a very US-centric perspective and failing to realize that in other markets (like Europe and South America, the ones I'm familiar with), Apple has a much smaller footprint, and does not possess the "reach" of a political party at all.
Edit: typo
That's not true. Many Android devices have an unlockable bootloader with explicit support for building the Android Open Source Project (AOSP) for the device. Nexus and Pixel devices are directly supported by AOSP without modification. It's the same codebase used to build the stock OS for those device. The stock OS on those devices only adds Google Play apps to the source tree, some of which replace AOSP apps. It doesn't contain any secret sauce changes to AOSP. Android engineers use the same Nexus / Pixel devices that are shipped to consumers as their development devices. You enable OEM unlocking within the OS from the owner account and can then unlock the bootloader via physical access using fastboot over USB, allowing images to be flashed via fastboot. Serial debugging can be toggled on and done via an open source cable design through the headphone port.
Other companies like Sony have emulated this by releasing official sources for building AOSP for their unlockable devices rather than only making the bootloader unlockable and leaving it up to the community to hack together support. However, I think it's only Nexus / Pixel devices where you get support for full verified boot with a third party OS (i.e. you can lock the bootloader again, and have it verify the OS using a third party key) along with the ability to toggle on serial debugging.
It's why the Android security research community is so active. You get the same sources / build system, development devices (Nexus / Pixel), debugging tools, etc. as an Android engineer working at Google. The only major thing you don't get is access to their internal bug tracker. Hopefully they'll move towards the Chromium model where most of that is public once embargoes are over.
I cover the Nexus devices when I give talks. While I haven't looked into the Pixel yet (and I know that I need to, as the arguments I am about to make for quality likely will have begun to change), I can tell you that effectively no one buys the Nexus devices (the market share for them is ~1% with a 1% margin of error), and they are not seen as high quality devices.
The reality of the Android market is that Samsung makes 98% of the profit, and the vast majority of flagship devices are being made by the handful of companies that put the most effort into locking down their devices. If you want the "high-quality phone"--the one with the good screen and the good camera and the fast CPU that can run all of the apps that you increasingly need in this day and age--you are not buying one of the random open devices.
Again, though: I admit that Google's attempt to retake the flagship market and compete with their hardware manufacturer partners with the Pixel (a device which specifically looked at having stuff like a super high quality camera and screen and such) might change things, but this is an incredibly new development in the grand scheme of these things.
I don't know what you mean about AOSP source branches being closed. It's not true. They still release the entirety of every stable branch they ship on the same day that it ships. There isn't any substantial delay and they haven't started doing incomplete releases of the AOSP sources. They don't make things as easy as they should be but things haven't really gotten any better or worse overall for AOSP. It takes more work to assemble the proprietary Qualcomm code from their factory images (see https://github.com/anestisb/android-prepare-vendor) than it did before, but most other things are better now.
It's also not true that any of the core OS in AOSP has been or is being obsoleted. They've stopped maintaining some of the user-facing apps like Calendar, Email, Music and QuickSearchBox and a few providing app-layer services like text-to-speech which all have other implementations available. There's nothing they have stopped maintaining that's critical enough to really matter. There's no shortage of music apps and there are other Android text-to-speech apps, so the AOSP PicoTTS being unmaintained beyond them keeping it building / running as it did before doesn't really matter to anyone. They haven't stopped maintaining any core OS components. Many apps / components that are updated via Google Play and/or have proprietary Google service extensions are still properly maintained in AOSP without those extensions, like the Contacts, Dialer and Launcher apps. Below the application layer though, it's the same. Google builds the stock OS from the same source tree released in AOSP stable branches with their Google Play additions.
There's also the claim that code is moving into Google Play Services, but for the most part that isn't the case. Play Services has expanded but very little has been lost in AOSP. There isn't a movement of stuff to Google Play Services but rather they split out components into apps / components that they can update via Play (which doesn't hurt AOSP as they're still updated there) or they introduce new clients to proprietary server-based services. That's still what defines Play Services: clients to APIs provided by Google servers and out-of-band updates to components that are still maintained / updated in AOSP too. There are very few cases where anything has actually been dropped in favour of Play Services. I can think of a single example: voice to text. That's quite clear to anyone that has actually worked with it or used it.
You're speaking far outside your area of expertise based on anecdotes you've heard, rather than tangible facts.
> and they are not seen as high quality devices
Nexus 6 was as premium as Pixel devices, and the Nexus 6P was a quality device. Nexus 5X and 6P were the generation where Google started shipping good cameras, their own fingerprint reader setup, etc. not Pixels. Nexus 6 was a quality flagship device a year before then. There are plenty of non-Google devices that are 'open' in the same sense though.
> the vast majority of flagship devices are being made by the handful of companies that put the most effort into locking down their devices.
Not true. Vendors like Samsung sell plenty of unlocked / unlockable devices.
> If you want the "high-quality phone"--the one with the good screen and the good camera and the fast CPU that can run all of the apps that you increasingly need in this day and age--you are not buying one of the random open devices.
Not true for the reasons above. Your statements aren't based in reality.
> Again, though: I admit that Google's attempt to retake the flagship market and compete with their hardware manufacturer partners with the Pixel (a device which specifically looked at having stuff like a super high quality camera and screen and such) might change things, but this is an incredibly new development in the grand scheme of these things.
Pixels aren't a substantial departure from the Nexus 6 and Nexus 6P. Compared to the Nexus 6P, the SoC, image sensor, screen, etc. were all just moved ahead a generation. The build quality is comparable and in some ways the Nexus 6P was a nicer device: it definitely had nicer speakers, and
You know you can buy an international Galaxy S8 and unlock the bootloader without any exploits, right? That part works the same way as Nexus / Pixel devices on the S8 variants that can be unlocked (i.e. not US carrier versions, etc.). The difference is that Samsung doesn't give you 100% of their OS sources especially on the day that they release each update and they don't support verified boot for a third party operating system. They also revoke the warranty if you do it, but they permit it. They explicitly implemented a standard unlocking procedure for their consumer devices and it's not in any way forbidden by the terms of use other than voiding the warranty, which is sad but not exactly unfair. Their attempt to void the warranty is not valid in everywhere anyway. They still often need to honor standard warranty requirements unless it's demonstrated that the user is at fault for what went wrong.
We detached this subthread from https://news.ycombinator.com/item?id=14733375 and marked it off-topic.