Apple apps turned upside down writing right to left
Apple’s iOS and OS X are currently under what can only be described as a “jolly irritating attack.”
Certain text strings, when processed by the operating system’s CoreText rendering engine, cause the application that’s trying to display them to crash.
No-one has yet come up with a way to exploit these crashes for code execution, at least as far as I am aware, so they’re vulnerabilities of the fragility sort, rather than the you’re pwned type, but they’re still, well, jolly irritating.
The shortest string I’ve been able to come up with that provokes this bug is just eleven bytes long, and consists of six UTF-8 characters, one of which is a plain old space (hexadecimal code 0x20).
→ UTF-8 is a system for representing text that uses from one to four bytes per character. The bit pattern of each byte in a character tells you how big that character is, so moving backwards and forwards in a string is easy (you don’t need to keep re-calculating from the start of the string), and 7-bit ASCII characters are represented as themselves in one byte (so simple documents in plain ASCII don’t need converting, and don’t waste space).
The crash strings I’ve seen and heard of all include Arabic characters, and Arabic is, of course, written from right to left.
But whether it’s the direction of the text, how the characters are combined and composited, or some other subtlety, I can’t yet tell you.
The problem with this problem is that it can quickly become disruptive, since an offending string can be placed by an outsider into all sorts of otherwise unexceptionable places where you might stumble across it by mistake: web page titles, email subject lines, even Wi-Fi access point names.
If the Apple application that tries to display the string uses the vulnerable rendering library code…
…down she goes.
And if the application tries to recover gracefully when it next loads, for example by reloading the web page it was busy with before…
…down she goes again.
In my testing, I ended up with Safari’s history loaded with a URL aimed at my Bad Page, provoking an HTTP reply no more threatening-looking than this:
HTTP/1.0 200 OK Content-Type: text/plain; charset=utf-8 Content-Length: 11 ...the dreaded 11 bytes...
As long as my web server was running and a network connection available, relaunching Safari caused it to crash again at once.
What to do?
I tried what I thought was the obvious solution, namely removing the file:
~/Library/Safari/LastSession.plist
That file certainly referenced my dodgy URL, but removing it didn’t help, so I tried:
~/Library/Caches/com.apple.Safari
No use, but I fared better when I removed:
~/Library/Saved Application State/com.apple.Safari.savedState
That made Safari forget that it had ever heard of my crashy website, and let me browse again.
Apple notoriously likes to keep completely quiet about software problems until a fix is available, as it did with the equally amusing and embarrassing but less disruptive FILE COLON SLASH SLASH SLASH bug earlier this year.
In this case, therefore, let’s hope that Apple pumps out a fix pretty jolly quickly.
By the way, you can help make Apple aware of the impact of the problem by reporting this crash if it happens to you.
You’ll see something like this:
Choosing Report… will show you what happened, much like you see below, and ask if you want to Send to Apple:
Should you send the crash report in?
Apple assures you it’s anonymous, and although it reveals a little bit about you – your timezone, what sort of Mac you have, and more – I suspect you can send it off without too much concern.
(I’m guessing, but Apple probably learns less about you when you submit a crash report than a search engine does when you try to look for a solution to it.)
Apologies that I don’t have a general workaround or mitigation for you.
If I come across one, I’ll post it here or in the comments.
In the meantime, applications that get derailed by a CRASH: GOTO CRASH loop, like my Safari did, can probably be pointed in the right direction by digging around in the ~/Library directory, as I showed above.
Oh, and as far as browsing is concerned, while Chromium is affected, Firefox isn’t.
Firefox is currently enjoying a really strong lead in our “which browser do you trust” poll – perhaps you’ve just found another reason to try it out.
Bonne chance.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/jf00Dk41wyk/