Zero click vulnerability in Apple’s macOS Mail | Hacker News Reader

Zero click vulnerability in Apple’s macOS Mail

mikko-kenttala.medium.com

443 pointsjviide257 comments

Open articleView on HN

It seems backwards that Apple acknowledges the issue, PATCHES it, but still hasn't paid out.

Maybe a good business is bug escrow company.

zerodium

Does it? It seems the priority should be fixing the issue.

Do you think the finance department is pushing the changes?

Presumably not paying out has a chilling effect on bug identification by good guys.

A considerably larger priority is identifying the issues before bad actors can take advantage of it.

Bug bounty factoring!

From wikipedia:

> Factoring is a financial transaction and a type of debtor finance in which a business sells its accounts receivable (i.e., invoices) to a third party (called a factor) at a discount.[1][2][3] A business will sometimes factor its receivable assets to meet its present and immediate cash needs.[4][5] Forfaiting is a factoring arrangement used in international trade finance by exporters who wish to sell their receivables to a forfaiter.[6] Factoring is commonly referred to as accounts receivable factoring, invoice factoring, and sometimes accounts receivable financing. Accounts receivable financing is a term more accurately used to describe a form of asset based lending against accounts receivable. The Commercial Finance Association is the leading trade association of the asset-based lending and factoring industries.[7]

This sounds like discounting a Bill of Exchange. Although the Bill of Exchange is drawn only against the delivery of a physical good, so this may be the difference between the two.

For example, let's say I own a sheep farm. I hire people to trim the sheep, and they produce a bunch of cotton. Without the Bill of Exchange, if I want to pay the people I've hired then I will need to ship this cotton to the spinner, who then ships the spun cotton to the weaver, who then ships the woven cotton to the clothier, who then makes clothes and sells it to a consumer. Only after this has happened can I pay my employees with the money of the paying consumer.

With the Bill of Exchange, a bill is created when I deliver cotton to the spinner. This bill will require the spinner to pay me for the cotton delivered in e.g. three months. I can then take this bill to someone who trusts that the spinner will pay me in three months and ask them to buy the bill at a discount, such that they are paid in three months (when the bill expires). I can then use the proceeds from the sale of the bill to pay my employees immediately. And the buyer of the bill earns a bit of interest because he pays less for the bill than he is paid at maturity.

[1] https://professorfekete.com/articles/AEFMonEcon101Lecture5.p...

[2] https://professorfekete.com/articles/AEFMonEcon101Lecture6.p...

I think the general category this falls under is supply chain finance.

Small nit: you get wool from sheep, not cotton :). Otherwise, that’s really interesting and I didn’t know that was a thing!

Places like Bugcrowd act as a go-between but the company will have to be on there.

I like this idea.

1. Company verifies the bug

2. Assigns it a price according to impact

3. Keeps details hidden until Apple pays them, then reveals the bug. Thus Apple is forced to pay, but bad actors dont get access.

Different bug markets can compete to correctly price bugs.

Who does the verification?

NSA front company probably. They will do it for free so they can front-run the zero days.

Apple's own subdivision :)

An alternative is public offer when Apple promises to not release a fix without payment. If it's not a bug, no need for a fix.

That may be considered black-mail by some courts.

I guess that's true. Whats the end state if Apple refuses to pay?

“It would be a shame if someone used this vulnerability”

Then Apple gets a reputation for refusing to pay, less folks look for and responsibly disclose vulns in Apple products, and their security posture as as whole suffers.

I dont think apple is entitled to that information on any basis, and i dont think its a legitimate threat to expose actual ill behaviour

I think they're talking about the implication that if Apple don't pay, then the vulnerability is published.

I agree with you on a moral basis: what difference does it make if I get payed not to publish it vs. If I just publish it without even asking to get paid. But I'm not sure the law would agree with us.

I think, like in many legal matters, precedent and intent is key. Without ill intent there is no 'mens rea', or "guilty mind".

In this case you aren't just a vigilante targetting apple, there is established practice stretching decades.

There is also a duty on you as a security proffeshional, and there is a significant public interest in knowing about the vulnerability. So , most likely, it will be you doing your job.

All blackmail involves exposing something that someone doesn't want exposed - usually because the "something" is illegal. And yet, blackmail itself is illegal.

Most countries have a culture against whistleblowers, starting from childhood ("don't be a tattletale", "don't be a rat").

And that anti-whistleblower culture enables fraud like theranos to be undiscovered for years

Can you explain it more? What can make it a black-mail and why?

If there is no intent to abuse the bug when not paied then there is no additional threat there from simply notifying the company that some threat is already present. How it can become a black-mail?

So every report about discovered bug can be considered as black-mail? If one discovers a bug, reports it to the company and says that after 3 months it will be public it's a black-mail too?

Or the payment request makes it different? And if person doesn't threat to publish the bug then it's ok?

Definition: Blackmail involves a threat to do something that would cause a person to suffer embarrassment or financial loss, unless that person meets certain demands. [0]

[0] https://www.justia.com/criminal/offenses/white-collar-crimes...

The longer a bug goes without being reported, the greater the potential impact. So not reporting a bug could be considered a form of abusing the bug. There's probably a moral obligation to report bugs promptly. Bug bounty programs that companies have are ultimately a reward for being a nice person, as opposed to being a payment for services rendered.

Yes, it's the payment request.

It's only blackmail if the threat is to do something you are not otherwise legally allowed to do. It is legal to, say, announce a zero-day on Twitter. Or to sell the zero-day to the NSA, or some grey hat broker like Zerodium.

In the US at least I don’t believe the act has to be illegal.

No it's not. Pay me $10,000 or I tell everyone you slept with your secretary is blackmail.

Ok, you got me. But there must be more to the definition of blackmail than simply, pay me or else. If that were the definition, then everyone would be a blackmailer by virtue of "pay me for this or else I'll sell it to someone else," which is a "threat" we all implicitly make every day.

In the US, blackmail has a very specific meaning: it is a threat to inform law enforcement of a violation of federal law under demand of a thing of value. This would actually be extortion, which is defined in 18 USC 875(d):

Whoever, with intent to extort from any person, firm, association, or corporation, any money or other thing of value, transmits in interstate or foreign commerce any communication containing any threat to injure the property or reputation of the addressee or of another or the reputation of a deceased person or any threat to accuse the addressee or any other person of a crime, shall be fined under this title or imprisoned not more than two years, or both.

https://uscode.house.gov/view.xhtml?path=/prelim@title18/par...

How would price discovery work to "correctly price bugs"

What is a bugs correct price? The price that a bad actor would pay for it?

Some value between the cost of not fixing it and the value of exploiting it

We have CVSS scores for grading vulnerabilities. So that could be useful as a start.

CVSS is pretty useless for categorizing severity.

Bug bounty doesn't mean that the reporter is selling the bug they find for a reward. It's a gesture of gratitude from the company. This whole conversation is coming from a place of entitlement.

Here's an alternative view:

- Apple is a $2T company, that we trust with our data. That valuation is in part based on that trust. It's entitled of Apple to produce a product that contains shitty exploitable symlink handling and continue to have no meaningful repercussions (which is true in the industry as a whole).

If this was a bug in a small, under-resourced FOSS email client, or the exploit required many highly skilled person-years to find, maybe I'd feel differently.

Both of these points can be true.

In all likelihood, Apple would just refuse to play ball and tell them to go ahead and sell it to someone else if they're so confident. Zerodium and other markets already exist, and I don't think people at Apple lose much sleep over it. And you better hope you close that deal before Google Project Zero finds it independently and tells Apple for free. Plus the mere mention that a vulnerability exists in a specific piece of software may lead Apple engineers to finding and patching it before you can sell it. Give away too many details and it's burned.

People tend to vastly overestimate the economic impact of an exploited security vulnerability. A vulnerability which can be patched in a centralized manner has a low value half-life: it rapidly decreases in value over time. I would guess over 90% of active daily users of macOS already have the patch for this bug due to automatic updates. New buyers are essentially guaranteed not to have the vulnerability at all. The vulnerability would have to be absolutely catastrophic to be worth something, and in that case it would probably be used for targeted exploitation and burned after a short period of time.

Contrast with something like heartbleed, which is still around. That is a vulnerability with serious half-life and significant economic impact. The pool of available victims who can be exploited by heartbleed is nontrivial and persistent years later. Criminals will actually pay for something like that.

Did he phone them to check? I get a lot of fake invoices in my junk mail. I also know someone who lost £50k paying an invoice with bank details that had been tampered with by hackers. I hate phoning people but I always phone about invoices.

> 2020–05–16: Issue found

> 2020–05–24: PoC done and reported to Apple

> 2020–06–04: Catalina 10.15.6 Beta 4 with [hotfix released]

> 2020–07–15: Catalina 10.15.6 Update with hotfix released

> 2021–03–30: Bug Bounty is still being evaluated

If Apple are actually serious, why are they taking so long to give the bounty? It's sounds like madness to me.

This is clearly what triggered the post.

Work was done but not paid. Shitty business on Apple side...

Those who fix the bug and those who issue payment are likely in two different groups with two different sets of motivators. Not excusing but explaining.

The company has billions of dollars. I don't think a $50k-$100k bug bounty payout for them is a big deal. Even $1m wouldn't be a big deal to them.

A company sufficiently large enough for such an amount to not be a big deal will have a money disbursal process nobody understands enough to make a one time transaction of that size in a reasonable amount of time.

Finance can always be subverted by management, but it has to be a priority.

Maybe a company so large it can’t track its own finances is too large to be responsible for its obligations and should be held to standards at least as strict as its less capable business and human peers. And I’m an Apple fan to be clear. But their wealth is the opposite of an excuse.

That's not an excuse. It's just a blunt explanation. Out of the ordinary processes can only proceed so quickly in the presence of massive bureaucracy.

It isn’t that finances aren’t tracked. They are tracked and audited and the audits are audited and there are many safeguards in place so that money doesn’t leak out and the knowledge for that operation is specialized, so much so that entire departments handle only part of the process and can’t just talk to one another due to the “segregation of duties” the auditors want. A company that decided to incentivize bug bounty like Google got support for the program on high and all the wheels of the org went to work to create policy, procedure, forms, auditor review, SARBOX compliance, etc and payouts will move like any other invoice. A company where some mid rank sees a need for such a program but doesn’t get full organizational alignment will be stuck with a pre-broken unreliable process.

That's still an organization that's too large or mismanaged to be trusted. We trust people who are capricious with their personal finances far less. A large organization with wealth impossible to humans but systems failing them and everyone else who depends on it... is a large corporation with wealth that has no excuse for not solving it.

The value of a bug isn't proportional to how much money the company has.

Why not? The potential damage certainly is proportional.

You state this confidently but I don't see why it's true a priori. I don't see a strong correlation between Apple's cash on hand, assets or market cap and the severity of a zero day in Mail.app.

The better comparison is active users, weighted according to how many apply automatic updates. The vulnerability half-life probably isn't as devastating as you might think it is since Apple has centralized control to push out updates, limited only by users deliberately not installing them.

I would consider a vulnerability in OpenSSH to be far more economically devastating, and there isn't even a company with a market cap behind that software.

Then I'm sure you can easily see why Apple having money matters. openssh users may be damaged and yet there isn't an apparatus in place to reward those who can provide value. What a shame, but who is confused?

Who is wondering why Patreon and a blog post isn't sufficient to facilitate value transfer in metaphorical openssh scenarios?

Your estimates of bug bounty money are orders of magnitude off.

Guess how much Microsoft pays for breaking the Windows Secure Boot implementation? $9k.

Sounds like the sandbox still worked. Of course it's still bad but it show how sandboxing applications works well to contain exploits.

Makes we wonder how many applications on Windows and MacOS actually support the system sandbox.

Thats true. Without sandbox this would have been much worse. Sandboxes are good speed bumps.

Thanks for an exceptionally clear writeup. Pay that person their bounty!

Thanks!

I can't find any information on the following questions:

Are all past versions of OS X / Apple Mail affected? For what OS X Version does Apple provide a security update regarding this issue? Has anyone found a fix that prevents auto-uncompression (such as a "defaults write com.apple.mail xyz False" command)?

Due to several reasons, I am also on an older Version of OS X and this issue makes me a bit nervous.

From Apple's patch notes [0]:

> Available for: macOS Mojave 10.14.6, macOS High Sierra 10.13.6, macOS Catalina 10.15.5

[0]: https://support.apple.com/en-us/HT211289

I thought macOS mail rules could also run a snippet of AppleScript. Wouldn't that make this an RCE?

Or maybe the script has to exist in some folder this vulnerability doesn't have access to?

Thats what I thought first too (I am the author). And your guess for the reason is right. AppleScripts need to be stored in ~/Library/Application Scripts/com.apple.mail directory which is outside of the sandbox.

That's a terrible unzip program. Unzip Programs should not write to arbitrary locations while unzipping.

Not only are symlinks a danger with unzipping libraries / utilities, but so are files with “..” in their path.

So, is this an issue on my old mac running 10.11.6 that will not get fixed?

10.11 is unsupported since September 2018. This is definitely not the only security issue you have.

I'm on 10.9 and I don't want to use anything newer. I can deal with some risk, but this vulnerability is unacceptably bad.

The core problem is that really dumb feature which auto-expands certain zip files. I need to turn that off.

MailWebAttachment.h contains a method:

    - (BOOL)isAutoArchiveAttachment;

I bet that if I Swizzle that to always return false, this "feature" will go away. I'll found out this weekend...

Edit: Is the author's PoC available anywhere? Not that I really need it...

I’m curious and not attacking.

Do you follow all security-related announcements for Mac OS and do your own back ports and fixes?

How did you decide 10.9 is the right balance of risk for you?

It might not be a matter of risk balance.

MacOS 10.9 was pretty much when Apple jumped the shark. That was the last version I ran before switching back to Linux, and I ran it pretty damn long in the tooth as well -- until ~2018ish.

I still have a few VM images with MacOS 10.9 that I spin up from time to time in order to run commercial software like Adobe Acrobat.

Just curious, what did Apple do (or not do) in 10.10 to earn the “jumped the shark” description?

I use 10.9 because out of all the OS's I've ever used, I like 10.9 the most by far, and I consider that worth the security risks. I browse the web in an up-to-date version of Chromium[0], I keep my computer behind an up-to-date router, and I trust my local software. An experienced hacker who wants to spend a few days getting into my computer will succeed, but they'd probably succeed anyway, and that's why I take measures like keeping backups in cold storage.

This was the first time I've actually backported a security fix. Apple Mail is easily where I'm most vulnerable, because it's not merely an outdated app which opens untrusted content—it opens untrusted content which anyone can push to me!

0: https://github.com/blueboxd/chromium-legacy

^ Yeah, that didn't work, the method never gets called. I'll have dig more...

Got it. Made very quickly but is working for me (which is all that really matters.) https://github.com/Wowfunhappy/Fix-Apple-Mail-CVE-2020-9922

Had to make `-(BOOL)isAutoArchivePart` in `MCMimePart` return false.

https://cve.report/CVE-2020-9922

https://support.apple.com/en-us/HT211289

> Mail will parse it to find out any attachments with x-mac-auto-archive=yes header in place. Mail will uncompress those files automatically.

What could possibly go wrong? ;-/

This is the same exact issue that used to plague Outlook back in the day with the automatic handling of attachments. You'd think Apple would have learned from others' mistakes.

> You'd think Apple would have learned from others' mistakes.

Why would you think that?

I don't exactly have a dog in this, but I think this is a strange framing: this feels like exactly the kind of niche feature that was added by one engineer and then forgotten about. MS and Apple are both large companies that maintain individual pieces of software that are probably older than many of the engineers who currently work on them; the lessons here are more organizational than technical.

It's because Apple framed themselves as the company of "LOL Macs don't get viruses" and emphasize themselves to be more privacy focused than Android...

...and they made the same basic mistake of allowing one of the single most exploitable attack vectors ever. They kinda shoulda known better, honestly.

They still treat PDF files as “safe” to automatically open when downloaded so nope.

What’s dangerous in a PDF besides JS which is not executed in macos Preview.app?

PDF has had a zillion vulnerabilities over the years. And Apple doesn’t guarantee in Safari that Preview.app is the default handler, so that expands the scope of potential vulnerabilities to Acrobat, which is notorious for its history of vulnerabilities.

Perhaps someone more knowledgeable could explain it to me, but uncompressing the files automatically doesn't seem like that big a deal to me. The much bigger sin appears to be allowing symlinks or a reference of any kind outside of a sandboxed directory.

Whilst we wait on someone knowledgeable I'll butt in, I once listened to a podcast on pentesting: other than zip bombs the issue I see is that other vulns can have code execution exploits against them if only the haxor can get the code on to the host. With automatic uncompression the code can be placed on a host by emailing a user -- no need to convince them to click anything.

Uncompressing files is a big complicated task with lots of fiddly little details. There are tons and tons of options, and that means tons and tons of attack surface. Besides symlinks, there could easily be all sorts of other errors that would produce a similar kind of exploit.

Conventional security wisdom says that there are three primary problems with decompressing arbitrary inputs:

* Most compression container formats support relative and absolute paths outside of the current directory, for semi-legitimate reasons (like decompressing an entire raw filesystem, or using an archive format as an ad-hoc installation system). Many high-level languages have bindings that are unsafe by default in this regard.

* Most compression formats can be manipulated to contribe pathological inputs that require massive amounts of memory or CPU time. This makes them good vectors for DoSes.

* Compression and compression container formats themselves are complicated, for historical reasons. Many also have reference implementations with colorful security histories with regards to memory safety.

I may be wrong, but I thought the symlinks have to be in the sandbox. The problem is that the sandbox includes config files, preferences, etc. that can affect the way the Mail application works.

How does Apple claim they're "secure by design?" [1]

They seem to have the same issues as everyone else.

[1] https://www.apple.com/business/docs/site/AAW_Platform_Securi...

It's fairly clear most of their focus is on iOS and not macOS.

More content for the linked list: https://news.ycombinator.com/item?id=24958256

Thanks for taking the time to track this.

The claim is not "there's no exploitable bugs". Secure by design usually means that certain mechanisms are present in the system that mitigate security issues. Sandbox is one of them.

It's hardly surprising, you can run into memory corruption bugs just using desktop mail.app the way it's intended (there's been a bug that corrupts the account list for probably a decade which just hasn't been fixed.)

Mutt may look old but at least it actually works.

Important to note this isn't a memory corruption bug, though.

This is a case of the application working as designed, but in unintended ways. A logic flaw.

I say this because I don't see a lot of effort being put into solving these types of security issues, compared to e.g. memory safety issues.

Unlike memory safety issues it's not really a category that tends to have category-wide solutions

V1: “This file we downloaded for your convenience is requesting access to [folder]. This may harm your computer or expose you to unknown security risk. Are you sure?”

V2: “This file unexpectedly tried to access [folder].”

The exact same mechanism Apple already used with GateKeeper and FS access for programs at runtime.

Why does it need to be more complicated than that?

Yep, it’s a confused deputy problem.

Mutt has also had a number of remote code execution vulnerabilities over the years: https://www.cvedetails.com/product/274/Mutt-Mutt.html?vendor...

I don't use mutt with IMAP, so the last of those CVE issues that could have an effect was in 2005. And most of the rest of code execution bugs are related to IMAP. Pretty good.

Though I certainly shouldn't trust mutt to be bug free, given that it processes data that someone can send me freely. Gladly TUI programs are fairly easy to isolate in their own UNIX user account.

Use MailMate!

https://freron.com/

How has maintenance & bug fixing been? I'm OK with mature apps stabilizing and needing few updates, though since it is a single dev with somewhat infrequent changes I thought I'd ask (https://updates.mailmate-app.com/release_notes).

I’ve not noticed any issues. The author is very active on the mailing list.

Is it true that Apple devices are more secure than good Android devices(like Google's Pixel)?

Or is it just security theater ?

Apple's entire business model is based on appearances. To be fair so is Microsoft's and many others.

Security is usually the last priority for nearly every for profit entity because it doesn't drive revenue.

Apple puts rather extreme security effort into preventing iOS jailbreaks. They are pretty serious about trying to prevent data exfiltration from locked iOS devices as well.

They aren’t perfect but I don’t think it’s fair to say they don’t try.

I wouldn't call it extreme when there was a known public website allowing one-click jailbreak for good few months (not sure if it was actually ever patched or just the iOS version got eol)

10 years ago, yeah.

https://en.m.wikipedia.org/wiki/JailbreakMe

Actually, Safari has been used for exploits much more recently than that! https://totally-not.spyware.lol/ (iOS 10, 2018)

They then hired the guy creating those exploit chains.

It's unsurprising that the main vector for iOS jailbreaks would be through the web engine. The FreeBSD-based PlayStation 4 was also jailbroken via it's browser.

If you have written a hardened, safe browser engine then you are free to share it to the world, otherwise I wouldn't downplay their efforts.

Chrome/Chromium has a better track record and it is shared with the world. The number of Safari-based iOS exploits found in the wild is embarrassing.

Not OP, but I'll stop complaining when Apple lets me use other browser engines.

What would be an acceptable response from Apple?

> Apple puts rather extreme security effort into preventing iOS jailbreaks.

Yes, IMO their business model is more accurately described as “gilded cages/jails” than just general “gilded/good-appearing stuff”. They deeply care about the strength of their DRM — including at the expense of end-user security, eg. you can’t access the internet through the Tor browser installed the normal macOS way without macOS broadcasting that you used Tor Project products to Apple’s DRM servers.¹

> They are pretty serious about trying to prevent data exfiltration from locked iOS devices as well.

They definitely care about the appearance of trying to prevent that exfiltrating (they don’t publicly appear to help the FBI do it), but they don’t try hard enough to actually prevent it (including in situations were preventing exfiltration seems to have been proven possible, see nearby comment https://news.ycombinator.com/item?id=26667141).

¹Edit: ocsp.apple.com, enabling targeting of the people who need or want security the most.

To the people downvoting: I’m trying to make an evidence based refutation of the less supported speculation/assertions in the parent post. If you have counter-evidence or any reason to downvote other than fanboyism, please explain it so we or I can learn.

You don’t provide much evidence. Your second point is just opinion, “they don’t try hard enough.”

Your first point is intended to refute the effort put into stopping jailbreaking in iOS. The example you give is about privacy on Mac OS.

Last, accusing folks of being fanboys is a particularly weak argument. It says, if you don’t agree with me then your blind allegiance to a corporation renders you incapable of critical thought. Basically, if you don’t agree with me, you’re dumb. There is no practical engagement with that thesis.

Security drives profit if it is marketed well. Apple does this. Think about even their branding for certain things, e.g. “Secure Enclave”.

A big difference is that the software running on Apple devices is less complex. For example there is significantly less hardware support. iMessage only talks to other iMessage instances (eg no browser support). There is only one web browser engine. Third party apps can't do JIT code generation. Older APIs are actively removed, breaking existing apps (vs providing backwards compatibility).

In general less complexity is better, but it also constrains things. For example it took until recently for third party iOS to be able to do NFC. Android had it since ~2012.

> Android had it since ~2012.

I seriously wonder: what difference did it make? Was there any groundbreaking thing iOS users missed for 8 years?

Apple is just great in omitting things and keeping focus to deliver a great product and then expand on that basis.

Most famous example: First iPhones didn’t have MMS

> First iPhones didn’t have MMS

Or cut and paste. ;-)

MMS is whack though

I am guessing they already knew GPRS/UMTS and data plans were the future, hence they invested in iMessage. MMS already had an expiration date. Quite sure they only added it because of the PR disaster it had become.

I often use MMS. Whats the expiration date?

and MMS is still the only thing that works on every phone out of the box...

MMS could've been (and still kindof is AFAIK) the only way to send rich text semi-anonymously for money with carrier billing ie not requiring platforms, app stores, and sign-up. Is was also blocked on Android due to the Stagefreight bug. MMS was used at lot for ringtones and wallpapers before the Smartphone era.

"No wireless. Less space than a nomad. Lame."

I think there has been a lack of interest in smartphone NFC because iOS has no support for it.

For example, I have set up a tag to automatically connect friends phones to my WiFi network. You can also stick tags on places to trigger specific actions/mode/app: office, meeting room, car, bedroom.

Also one thing that could have been great to share pictures/files/urls with your computer or other phones: Android beam [1]. Sadly Google is removing it.

[1]https://en.wikipedia.org/wiki/Android_Beam#Usage

Sharing what's currently on screen (be it either a picture, a webpage or mean entire app) by touching two phones (Android Beam) was really convenient and ahead of its time. It is now being replaced by Nearby Share though, which works similar to AirDrop.

I like the way (I think) the grugq described it: out of the box iPhones are great with security, but Android allows you to build / get better yourself. See the copperhead project for example https://copperhead.co/android/

As far as what is feasible, Apple does a very good job with their iPhone/iPad security. With both hardware and software. You can read about it how it all works in their platform security guide.

On the Android side, Google makes good software changes to Android, but ultimately the security is dependent on the handset maker (e.g. Samsung) and SoC maker (e.g. Qualcomm). Security will vary between Android phones. The bigger Android phone makers are more able to make security investments than the cheaper phone makers.

>While the police managed to crack into Wong’s iPhone, which was locked with a four-digit passcode, they did not manage to access the contents of Chow’s Google Pixel phone using the force’s existing digital forensics tools, according to the court filing. Chow says her phone is still in police possession.

https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...

There is literally no other detail than the phone model name. For all we know it could be an ancient iPhone with a severely outdated OS and a brand new Pixel phone.

4-digit passcode hasn't been the default passcode option in iOS for a long time.

https://www.tomsguide.com/news/police-say-android-phones-are...

>This is supported by a look at smartphone cracking company Cellebrite’s effectiveness at breaking into different phones. Cellebrite can easily open up any iPhone X or earlier iPhone, but the same software used on a Google Pixel 2 or Galaxy S9 extracts very little information, and nothing at all in the case of the Huawei P20 Pro.

>That’s not to say that these Android devices are unbreakable. It's just that it requires a different, more labor-intensive process to get the data requested.

>The sheer variety of Android hardware and customized software builds makes it hard for phone-crackers to build a universal tool to break into Android phones. Meanwhile, a "jailbreak" released late last year permanently bypasses the security functions of every iPhone model from the iPhone 4s to the iPhone X.

This perfectly squares with what I personally know from law enforcement friends but I'm just an internet stranger.

It's called security through obscurity.

What? the iPhone's closed-source operating system?

No, more diversity for Android devices.

If you turn on iCloud, it's theater.

Android with syncing enabled does much better in real world tests. Notably in hong kong, they were able to crack the iPhones, but not the Pixels[0]

I'm pretty sure without iCloud and a long enough password (or fast enough self destruct mode) iPhones could be as secure, but I don't know anyone that uses an iPhone and does not use iCloud in any way.

[0]: https://qz.com/1844937/hong-kongs-mass-arrests-give-police-a...

What part of iCloud is the problem?

The part where it backs up all your messages without using a device specific key.

The only things end to end encrypted are listed on this page: https://support.apple.com/en-us/HT202303

If you turn on iCloud syncing, basically you're falling back to simple "in transit" and "at rest" encryption.

A lot of iPhone cracks involve just attacking your iCloud account, and then reading all of your messages from backups. This is not possible on Pixel which encrypt your device backups with on-device hardware encryption.

> Pixel which encrypt your device backups with on-device hardware encryption.

Can you set up a new android phone from an old phone’s backup? If so, how could this work?

This is a standard way to set up a new iPhone: “restore” from a backup of your previous phone. Especially handy when your old phone is no longer available (lost/broken)

Yes, decryption requires the original device's unlock PIN/pattern/password:

https://security.googleblog.com/2018/10/google-and-android-h...

Not that I fully understand how hard it is to circumvent.

Oh, I see. Apple has done that since the original iPhone too, and I believe iPod before it. I thought you meant they used a hardware key.

For your backups - but once you use iCloud to sync devices in real time, they just use their service keys, and your iCloud credentials are enough to read your iMessage history.

Okay, so if I understand correctly, the data in those Apple products is not secured, but turning on iCloud on a device does not ruin encryption for other apps that take it seriously. So if I have an app that uses Keychain (end-to-end encrypted) and encrypts it's data properly, it is still secure.

Unless Apple is really bad and somehow collects my keys from keychain, or collects keys passed to CryptoKit, etc., straight out of RAM, and sends them to 3-letter agencies ... if I think that's happening, then I will look for new devices.

I'm not sure I understand your keychain point. With iMessage you can message others with just your iCloud credentials if you turn it on, and you have access to full conversation history - without needing any particular device keys.

The agencies are believed to have the iCloud decryption keys.

iCloud has always been suspicious: Apple cancelled end-to-end encryption on iCloud after a certain three-letter agency filed a complaint, saying that it would disrupt investigations and have a considerable impact on the law enforcement capabilities of our country. Not to mention, Apple's behavior has been decreasingly auspicious in places like Russia and China, where they've started preinstalling state-sponsored apps and relocating servers to government-controlled provinces, respectively.

> Apple's behavior has been decreasingly auspicious in places like Russia and China, where they've started preinstalling state-sponsored apps and relocating servers to government-controlled provinces, respectively.

This is a legal requirement to operate the service in China. Apple’s choice is between offering iCloud in China or not offering it at all in China, not between offering it with local servers or with out-of-country servers.

It is indeed a legal requirement, and both Google and Microsoft have chosen not to provide services in those areas for this exact reason. Apple is the only major tech company that still operates in China, and has become pretty politically passive in the region. I only bring this up because Apple claims that "privacy is a human right", which I suppose is pretty conditional to what kind of human you are.

> Apple is the only major tech company that still operates in China

This is not even remotely true, even if you define "major tech company" to mean "major US tech company".

Both AWS and Azure have actual cloud regions in China (delivered with a local JV partner just like Apple's cloud services are).

Even Google operates there in various ways - they have four offices there, they manufacture hardware there, and they sell tons of ads to Chinese companies via their local subsidiaries (for display outside of China obviously).

Apple isn‘t simply running iCloud locally as the law may require. They have transferred the operations of their entire iCloud service to a government owned company, including all keys.

What Apple does in China is more than complying with local laws. They appear to be exceptionally proactive in staying in the regime‘s good graces.

Running cloud services in China requires establishing a JV with a local partner. Look at AWS China as another example of this, but there are many.

Can you provide a reference for Apple's JV partners being government owned? Any company in China of course has to do as the Party tells them to, so I guess the difference is largely academic, but I haven't seen it mentioned before that Apple's China partners are government-owned.

This is what was reported at the time:

https://techcrunch.com/2018/07/17/apples-icloud-user-data-in...

There are conflicting reports and vague language around how exactly the keys are handled.

Thanks for the link, very interesting.

This is true of your primary worry is nation states. If your primary worry is criminals/domestic partners/employers, this isn't the case. You can't give security advice without considering what you're protecting against.

Edit: your linked article says nothing about icloud

The difficulty is so low that it does not really matter. If you go by their bug bounties [1][2], then it is only $1M to full remote zero-click persistent compromise in both systems. If you go by Zerodium, which is a 3rd party purchaser and thus establishes a third party commercial market price, [3] then it is only $2M for iOS and $2.5M for Android. If we were to divide that price for an iPhone exploit by the number of iPhones sold in a year [4], then that is a mere 1 cent per iPhone.

As you can see, the price is so low it hardly even matters if there is a difference. There are literally millions of people in the US alone who personally have the liquid net worth to purchase a remote wormable persistent compromise that you can use to mass infect any Android or iPhone. Essentially every business with more than maybe 10 employees has enough assets to purchase such a weapon on the market. Just today I read on HN that the US government inked a deal for $22B over 10 years for 120k AR headsets from Microsoft [5] which comes out to ~$183k/headset. So, a weapon you can use to fully compromise any phone you want is equal in cost to a mere 15(!) headsets. That contract alone would be enough to purchase 10,000(!) vulnerabilities at existing clearing prices and $22B is only ~1/200th of the yearly US government budget.

Frankly, the entire thing is like two people jumping and comparing who is closer to landing on the moon.

[1] https://www.google.com/about/appsecurity/android-rewards/

[2] https://developer.apple.com/security-bounty/

[3] https://zerodium.com/program.html See Mobiles payout.

[4] https://www.statista.com/statistics/276306/global-apple-ipho....

[5] https://techcrunch.com/2021/03/31/microsoft-wins-contract-wo...

From what I've seen, the majority of it is theater. Does that mean it's more secure than Android devices? Not necessarily.

In any case, the biggest vulnerability in any system is the end user. No amount of idiot-proofing will stop people from being scammed on an iPhone, nor will it stop someone on Android. When these companies market their "Secure Enclave" or "Titan Security", they're really just dressing up otherwise expected or boring features. The T2 chip was basically a dedicated PRNG chip with basic encoding capabilities, yet Apple paraded it as a boon for device security and game-changer for the end user. In reality, it doesn't solve any practical issues with computer security.

I've tried about every OS on the planet, and I've used them on a decent handful of different devices. I won't tell you what to think or do, but Apple's devices are difficult to appraise and hurt my head when I try to consider their impact on my overall "security". I'd much rather just use a Linux system that's transparent about it's vulnerabilities. Much of that same reasoning is why I still use Android these days.

And your point being that Android gets more updates/fixes than Apple? Lol, only Apple has a proven track record of providing 5 year old devices with updates/fixes unlike anything from Android, unless you are comfortable flashing your own builds.

No, I specifically said in my original post, "Does that mean it's more secure than Android devices? Not necessarily."

My ultimate point is that the biggest liability is the user, and those "security updates" don't really matter when the biggest attack vectors don't even consider these exploits in the first place.

> The T2 chip was basically a dedicated PRNG chip with basic encoding capabilities

This is an extremely misleading description of the scope of T2’s duties.

good old symlinks, always wreaking havoc

how stupid do you have to be to think automatically handling mail attachment compression in any way is a good idea

For all those people who are complaining that Apple is taking its time paying out a bounty, and suggesting Zerodium:

The end result of selling 0-click RCE vectors like this to brokers is sliced up bodies in embassies. Do folks think where the money coming from, and who would pay? No, its an 'easy' pay day.

Some of us fix security bugs to keep people safe. Some of us try to earn an honest living doing so. Others try to earn a dishonest living with pain and death in their wake. Are you using your skills to improve life on this rock, or are you trying to make it worse for a pay day?

I agree with and appreciate your position. I'm more annoyed with Apple than with the security researchers. Apple is preying on your desire to do good. They could easily afford to pay a reasonable amount and promptly.

I don't see how selling to zerodium is more morally bankrupt than working for defense contractors, which plenty of tech people do.

The output of the defense industry is used to hurt civilians less frequently. But I'm not here to excuse either.

> defense industry is used to hurt civilians less frequently

... based on?

Um, how does that gel with thousands of engineers who work for FB?

is there any reason to not just sell to zerodium and then report to apple afterwards?

From Zerodium’s FAQ:

“By signing the agreement, you will accept an exclusive sale of your research to ZERODIUM and transfer all related intellectual property rights to us, meaning that the research becomes the exclusive property of ZERODIUM and you are not allowed to re-sell, share, publish, or report the research to any other person or entity.”

How would they enforce that? Even if Apple patches it Zerodium would have to sue Apple to find out.

Money in escrow, paid out in multiple installments if certain conditions are met e.g. the bug does not become public until a certain date.

Nice morals. In reality, people often take their morals with a side of cash.

Let's turn it around. In Russia, the average salary is around $600 per year. Would you turn down a $50k payout? That's 83 years of an average salary.

Consider that you may be in a privileged position if you can say no to that kind of money.

The solution to this is for vendors to match what the market is paying. If an RCE is worth $50k on Zerodium, perhaps it's worth something similar to Apple not to have headlines about so-and-so exploit being used for cutting up bodies in an embassy.

EDIT: Oops. Divide 83 by 12. But you'll find it hard to locate someone willing to say no to 7 years of salary for ~zero additional work.

$600 / month is the average salary per month (according to probably the same Google search you did). Presumably someone reporting security vulnerabilities makes well more than the average.

Oof. It's what I get for groggily typing something.

7 years of salary is a lifechanging amount of money too, but I admit the thrust of the argument isn't quite as strong with a basic error. :)

A better comment is probably "We've tried the alternative, and it doesn't seem to work. It's better to pay market rate."

That said... if someone pays me one or multiple annual salaries for something perfectly legal that's slightly morally questionable and indirectly linked to nasty things... I wish I could confidently say I'd say no, but I'm making no guarantees.

Can you be a bit more clear on what you're implying? Genuinely curious. I thought Zerodium was selling to government agencies.. so I'm not sure what you mean by sliced up bodies in embassies. Perhaps I'm just not thinking creatively/pessimistically enough.

The sliced up bodies seems like a reference to Jamil Khashoggi. [1] I am not sure why GP links Khashoggi’s death to Zerodium.

1- https://en.m.wikipedia.org/wiki/Jamal_Khashoggi

Very confusing; A Saudi national was assassinated in the Saudi embassy by agents of the Saudi government. Linking this to Zerodium makes Zero sense. You don't need to do any digging to find out when someone is at your doorstep

Wrong. They used tools by the Israeli NSO group to track him.

https://edition.cnn.com/2019/01/12/middleeast/khashoggi-phon...

The Saudi's secret service is infamous for hacking dissidents' phones.

Not Zerodium, but there's some evidence a different hacking for hire group helped them track him

https://edition.cnn.com/2019/01/12/middleeast/khashoggi-phon...

I think the real alternative here is that fewer folks will spend time looking at Apple products or not fully investigating weird behavior encountered normally that could be a security issue.

The author specifically said that they were looking based on bug bounty guidelines. The next person in the same shoes will look at some other company's products instead.

Ok, remind me never to approach Apple directly if I happen to find a vulnerability. Zerodium (or a 3-letter agency) it is!

> 3-letter agency

From the wikipedia page for Meltdown: "On 8 May 1995, a paper called "The Intel 80x86 Processor Architecture: Pitfalls for Secure Systems" published at the 1995 IEEE Symposium on Security and Privacy warned against a covert timing channel in the CPU cache and translation lookaside buffer (TLB). This analysis was performed under the auspices of the National Security Agency's Trusted Products Evaluation Program (TPEP)."

i.e. did they know even in 1995?

My understanding is that people at the time were aware of potential problems but no vulnerability had been identified. I found some discussion here: https://security.stackexchange.com/a/177256

NSA used to have an active effort on information assurance, under the philosophy that it defended the country to have good civilian security (same reason for the NSA’s modification to the DES S-box). This unfortunately has fallen by the wayside.

(NSA shortened the key as well so it wasn’t all bunnies and chocolate)

Is this referencing the slow turnaround time, or the lack of a bounty paid so far? If it's the latter, I think it's already well known that bug bounties pay far less than the "market" value of such exploits.

> well known

Well I didn't know, until now. I saw the bug bounty page at Apple before, was dazzled by the numbers, and didn't think twice about approaching them if I found a bug. Now after this article I know better than to trust them to pay.

Zerodium is interesting. Apparently this bug would fetch "Up to $50k": https://zerodium.com/images/zerodium_prices.png

Is there a way to verify whether Zerodium might be advertising large payouts (for attention) and then offering much smaller payouts for the actual bugs?

It's pretty risky for Zerodium. There's nothing stopping a researcher from collecting a payout and then reporting the bug to the vendor.

> There's nothing stopping a researcher from collecting a payout and then reporting the bug to the vendor.

Wouldn't the payout contract prohibit reporting to anyone else?

What're they going to do if you break it? Sue?

They might pay out over a long period of time for some guarantee that you'll play by their rules, though.

There is a non-zero probability of not being alive any more. I don't think you understand the nature of that game.

I think so, but would Zerodium etc be able to prove it was the same person in each case? An independent researcher might have submitted the same issue to Apple coincidentally shortly after, presented in a slightly different way.

Contracts usually pay out on a schedule. If the bug gets patched then you don’t get paid.

Makes sense, thanks. Must be tense waiting.

$50k seems super low considering where Outlook is though. The exploit author hints at RCE being a possibility.

Yes, the current meaning of “responsible disclosure” is bullshit

There should likely be a governing body that independently values an exploit and forces companies to pay

Like how the SEC’s whistleblower program works

Its completely broken to have corporations pinky promise not to sue you if you tell them and arbitrarily decide payouts if at all

Oh yeah, for Apple, just throw it up on Twitter.

and tbh, it's probably the same answer for most providers these days.

What's to stop someone from selling a vuln to Zerodium and then just reporting it to Apple shortly after? You get paid and Apple gets to fix it.

Probably a payout over a long period of time. Lots of people would prefer a free $50k over the course of one year.

(Just guessing though.)

I would guess it would have a Non Disclosure Agreement attached, along with the mercenary reputation damage one take on by breaking the contract. One would not be let back in the club. Do you think it wise to break a contract (eg: steal from) a weapons dealer?

Please don't use "zero" and "vulnerability" in the same sentence, unless you mean a zero-day one. The author could have said "no click vulnerability" with the same meaning. Almost caused me a concern with that title! :D :D

Sorry about that. But thats the term what is used by Apple to these type of bugs: https://developer.apple.com/security-bounty/ ( Zero-click unauthorized access to sensitive data )

Reply on news.ycombinator.com