Hacker News Reader

Comment by musicale | Hacker News Reader

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

View on HN

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.

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.

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

Why would you think that?

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.

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.

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.

Reply on news.ycombinator.com