A major iOS/OS X vulnerability comparable to Android Stagefright | Hacker News Reader

A major iOS/OS X vulnerability comparable to Android Stagefright

forbes.com

108 pointswilllll30 comments

If you're allergic to Forbes, I wrote a short summary on my company blog: https://thisdata.com/blog/bug-in-apple-products-allows-passw...

Tyler Bohan's original disclosure writeup (with some technial details) is here: http://www.talosintelligence.com/reports/TALOS-2016-0171/

Thanks, yes an invalid certificate then a paywall / adwall tends to put me off.

Cert wasn't invalid for me, just adbolock-blockers.

Just for context: almost every update fixes multiple code execution vulnerabilities in WebKit, and browsers are usually much easier and more reliable to exploit than most things due to the JavaScript VM. This bug is arguably more scary than those because it only requires the ability to send someone an image, not an HTML page, but then again, it's not generally hard to get someone to click on your link (think fake URL shortener), and while perhaps this bug is powerful enough to be exploited reliably (100% success/non-crash rate across all unpatched Apple OSes that might receive the message), if it isn't, that would make it considerably less stealthy in practice. (On a webpage you can see the target device and version before even starting the attack.) I don't think it's really worth freaking out much over, unless you're new to the realization that most modern Internet-connected devices are hellishly insecure. :) Though of course you should patch as soon as possible; critically, unlike with Stagefright, all modern iOS devices can, and will be prompted to, install the update.

> This bug is arguably more scary than those because it only requires the ability to send someone an image...

I remember one of the jailbreaks was loading a PNG way back when. This happened before.

FYI, the guy you're replying to jailbroke iOS in 2007 by exploiting a flaw in Safari's TIFF parser: https://en.wikipedia.org/wiki/JailbreakMe

Don't you just love HN?

FYI, the major part of this is actually a vulnerability in the upstream libxml2 library which is an XML C parser maintained by the GNOME project.

The library itself is widely used across various operating systems and software so this is a reminder to please make sure you keep both your OS and your applications up to date. http://xmlsoft.org

Honestly not surprising that the problem came from the gnome project.

Why?

Getting so annoyed by forbes.com welcome message. I don't understand why they stick to it.

This.

Plus "prise" not "prize". I see an increasing number of articles where the writers appear to just use what they think is right. Just yesterday, "tow the line". facepalm

OED lists "prize" as common US spelling. [0]

[0] http://www.oed.com/view/Entry/151652?rskey=W7yb3q&result=6#e...

Maybe it's just me, but I think "pry" is much more common to Americans.

You are correct. Prize is a word in American English, but not one that makes sense in context.

It's so they can show an advertisement that has an extremely high viewability (which correlates to higher CPA, and at the end of the day more money for them to pay people to write articles).

From the article:

> The bugs uncovered by Bohan work across all widely-used Apple operating systems, however, including Mac OS X, tvOS and watchOS. Indeed, Bohan noted that Mac OS X doesn’t have sandboxing, giving an attacker remote access to the PC with the victim’s passwords. That potentially makes it a more severe threat to owners of Apple’s PCs, as a simple email could prize Macs open.

Sounds like it could be pretty bad.

Doesn't _have_ sandboxing? It may not be used much, but there is https://developer.apple.com/library/mac/documentation/Securi..., and Safari uses it, for example to Mail.app, FaceTime, quicklook plug-ins, sandbox its PDF parser and (if still present) Flash player (http://www.apple.com/osx/what-is/security/)

Yep. The main reason I thought this was worth mentioning though was the original title of the article singled out iOS :)

Why is iOS storing wifi passwords in the iMessage process? (Somebody please translate the article from Forbes to reality for me.)

They aren't. When you receive an MMS your iPhone runs code to save and display the content. From my understanding of the article, the code responsible for handling an incoming MMS contains a critical security bug enabling attackers to hide instructions in MMS content capable of reading any memory on the iPhone, even memory stored outside the Messages sandbox (like your passwords).

The bug is in the ImageIO library which would affect SpringBoard, Messages, Safari, and most other applications which process images. I don't understand how having code execution in either of these processes would give up that information unless you explicitly had texted that info.

It's the fact that the code can read any memory, not just app memory, according to GP.

That's now how sandboxing works. You'd need an additional bug to escape the sandbox.

I suppose the idea is that it leads to a full system compromise, which would include either direct access to items like wifi passwords or access to the system as you are inputting the passwords.

If you go down to the bottom of the article they actually provide the link to the Apple Update page[1]. The actual vulnerability report page [2]. They also have a zeroday report for LibTiff so I guess they found something similar in the library.

[1]: https://support.apple.com/en-us/HT206902 [2]: http://www.talosintelligence.com/reports/TALOS-2016-0171/

There's the links I was looking for. "Investigating further we see RAX is pointing to the very end of a heap block yet there is still a lot of data to be written as RDX (counter) is still 0xFE." Why can't Forbes write in such plain English?

Anyone know if the patch has been applied to iOS 10 developer previews?

The latest iOS 9 and 10 builds appear to be patched.

Thanks!

Reply on news.ycombinator.com