Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zero click vulnerability in Apple’s macOS Mail

mikko-kenttala.medium.com

Post reply on HN
Print view View original

141–150 of 269 posts

Re: Zero click vulnerability in Apple’s macOS Mail

#141

Post by woodruffw »

techrat wrote: post #88
musicale wrote: post #66

> 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.

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.

Re: Zero click vulnerability in Apple’s macOS Mail

#142

Post by woodruffw »

hn_throwaway_99 wrote: post #132
musicale wrote: post #66

> 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? ;-/

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.

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.

Re: Zero click vulnerability in Apple’s macOS Mail

#143

Post by saagarjha »

philosopher1234 wrote: post #121
Zhenya wrote: post #19

It seems backwards that Apple acknowledges the issue, PATCHES it, but still hasn't paid out. Maybe a good business is bug escrow company.

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?

Re: Zero click vulnerability in Apple’s macOS Mail

#144

Post by PeterisP »

2OEH8eoCRo0 wrote: post #133
jagger27 wrote: post #126

Earlier quoted context omitted.

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.

Re: Zero click vulnerability in Apple’s macOS Mail

#145

Post by smoldesu »

megablast wrote: post #85
Zhenya wrote: post #19

It seems backwards that Apple acknowledges the issue, PATCHES it, but still hasn't paid out. Maybe a good business is bug escrow company.

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

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

Re: Zero click vulnerability in Apple’s macOS Mail

#146

Post by saagarjha »

slimsag wrote: post #106
swiley wrote: post #33

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.

Yep, it’s a confused deputy problem.

Re: Zero click vulnerability in Apple’s macOS Mail

#148

Post by rfd4sgmk8u »

whimsicalism wrote: post #140
distribot wrote: post #103

Earlier quoted context omitted.

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.

Re: Zero click vulnerability in Apple’s macOS Mail

#149

Post by saagarjha »

fortran77 wrote: post #92

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...

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

Re: Zero click vulnerability in Apple’s macOS Mail

#150

Post by gumby »

codemac wrote: post #115
rnikander wrote: post #91

Earlier quoted context omitted.

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 i…

> 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)

Post reply on HN