DoS exploit crashes iOS/OSX devices using WebKit | Hacker News Reader

DoS exploit crashes iOS/OSX devices using WebKit

translate.google.com

116 pointsluastoned84 comments

This isn't a bug inside WebKit. It's a bug inside Apples CoreText font rendering framework.

A `curl https://zhovner.com/tmp/killwebkit.html` in iTerm2 crashes as well.

    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
    0   libvDSP.dylib                   0x00007fff9080ead6 0x7fff907f2000 + 117462
    1   com.apple.CoreText              0x00007fff8892cd5c TRun::TRun(TRun const&, CFRange, TRun::SubrangingStyle) + 850
    2   com.apple.CoreText              0x00007fff8892c9ee CTGlyphRun::CloneRange(CTRun const*, CFRange, TRun::SubrangingStyle) + 142
    3   com.apple.CoreText              0x00007fff8893b764 TLine::SetLevelRange(CFRange, unsigned char, bool) + 162
    ⋮
    8   com.googlecode.iterm2           0x000000010003ce63 -[PTYTextView(Private) drawRun:ctx:initialPoint:] + 99
    9   com.googlecode.iterm2           0x000000010003d498 -[PTYTextView(Private) _drawRuns:runs:] + 344
    ⋮
    41  com.googlecode.iterm2           0x0000000100001bd4 start + 52

WARNING: the 404 page above is definitely NSFW (likely due to HN adding the backtick to the URL).

That's another goatse as far as I'm concerned! Time to scrub my eyeballs...

Nice.

on iOS:

    Thread 0 name: Dispatch queue: com.apple.main-thread
    Thread 0:
    0 libsystem_kernel.dylib 0x3a315e30 mach_msg_trap + 20
    1 libsystem_kernel.dylib 0x3a315fd0 mach_msg + 48
    2 CoreFoundation 0x3210c2b6 __CFRunLoopServiceMachPort + 126
    3 CoreFoundation 0x3210afd6 __CFRunLoopRun + 814
    4 CoreFoundation 0x3207e238 CFRunLoopRunSpecific + 352
    5 CoreFoundation 0x3207e0c4 CFRunLoopRunInMode + 100
    6 GraphicsServices 0x35c5d336 GSEventRunModal + 70
    7 UIKit 0x33f9a2b4 UIApplicationMain + 1116
    8 MobileSafari 0x000ff36e 0xf2000 + 54126
    9 libdyld.dylib 0x3a25fb1c start + 0

...

    Thread 2 name:  WebThread
    Thread 2 Crashed:
    0   WebCore                       	0x382fe95a WebCore::ComplexTextController::adjustGlyphsAndAdvances() + 522
    1   WebCore                       	0x382fb94e WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet<WebCore::SimpleFontData const*, WTF::PtrHash<WebCore::SimpleFontData const*>, WTF::HashTraits<WebCore::SimpleFontData const*> >*, bool) + 318
    2   WebCore                       	0x382fb806 WebCore::ComplexTextController::ComplexTextController(WebCore::Font const*, WebCore::TextRun const&, bool, WTF::HashSet<WebCore::SimpleFontData const*, WTF::PtrHash<WebCore::SimpleFontData const*>, WTF::HashTraits<WebCore::SimpleFontData const*> >*, bool) + 18
    3   WebCore                       	0x382ff990 WebCore::Font::getGlyphsAndAdvancesForComplexText(WebCore::TextRun const&, int, int, WebCore::GlyphBuffer&, WebCore::Font::ForTextEmphasisOrNot) const + 56
    4   WebCore                       	0x382ff862 WebCore::Font::drawComplexText(WebCore::GraphicsContext*, WebCore::TextRun const&, WebCore::FloatPoint const&, int, int) const + 150
    5   WebCore                       	0x3808

PS: I love the C++ namespace 'WTF.'

EDIT: complete dump https://gist.github.com/6374524

> PS: I love the C++ namespace 'WTF.'

I believe that namespace has diagnostic functions that help you answer the question "What's This Function?".

So stack trace helpers, and the like.

Template metaprogramming seemed like a good idea initially, but in production it is a horrible construct that should be buried with nuclear waste.

Thats the "Webkit Template Framework".

Curling the URL was one of the first things I tried, but I found it actually does work perfectly fine for me.

Yes, I cannot reproduce the crash on OS X 10.8.4 and iTerm2 1.0.0.20130624. Maybe Apple has fixed it in the latest OS patch.

UPDATE: It does kill Chrome 31 (individual tab) and Safari 6.0.5 (the whole browser!).

It's a bug inside Apples CoreText font rendering framework

So that means anywhere the string could appear, the application that has CoreText render the string crashes? Makes me wonder if it'd work by just broadcasting the string as an SSID and wait for someone to look up available networks, or sending text files to bluetooth devices with an Apple mac address. That would be cool, on a bus, in a crowded city, during rush hour.

This bug has been reported to Apple already and it's been fixed in Mavericks.

I also believe it's been fixed in iOS7 because they did a lot of changes to the text rendering libraries.

Starting from which version? CoreText 1.0.4 is not affected.

I just tried this inside Terminal.app (with a ZSH shell) on 10.8.3 and it just outputs a string, doesn't crash or cause any problems otherwise.

http://i.imgur.com/wQ6u8cq.png

http://www.paulirish.com/2013/webkit-for-developers/

Seems to be a pretty devastating problem if you send the exploit text to someone in iMessage. Makes the phone immediately crash - when the phone has been restarted and the user clicks on "messages", it crashes again - I think that it'll need a system restore / hacking of the Messages datastore to fix.

Put the exploit text into the SSID for an iOS personal hotspot - crashes iOS devices when they scan for SSID's to connect to.

It can be fixed by sending the attack again, then deleting the entire chat history with the attacker. (According to a comment the report linked to.)

Actually, just by the attacker sending a long enough text message to push the attack off the screen - which you can do yourself by sending a long text message to yourself from another phone, then forwarding that message to the attacker.

Did you test SSID?

As soon as the device found the exploited SSID name, the SSID selector would restart/crash, meaning that the user couldn't select a new SSID.

Using Unicode crashes my router, I learnt that previously.

Terrible router firmware strikes again. Which router are you using?

Pretty interesting discovery.

Direct link: (WARNING THIS CAN KILL WEBKIT) https://zhovner.com/tmp/killwebkit.html

And a similar tweet: (WARNING / CRASH) https://twitter.com/daken_/status/303784082599456768

works fine on Chrome dev running on ML.

Firefox nightly is fine too.

Gee, I wonder why.

This bug isn't particular to Chrome...

But it is "particular" to WebKit (on iOS and OSX, due to CoreText), which Firefox has nothing to do with.

Read the first comment; since when was curl a WebKit tool?

> This isn't a bug inside WebKit. It's a bug inside Apples CoreText font rendering framework.

We do use Core Text in Firefox on OS X, although not for all parts of text layout/rendering nowadays, AIUI. We're using Harfbuzz for some text shaping, so it's possible we're not using the particular Core Text APIs that hit this bug.

Didn't crash for me on Chrome (Stable) in the first place, but when I tried to translate the page it did.

not crashing safari for me... Mavericks beta.

Safari crashes on 10.8.4 for me.

Seems to crash the tab in Chrome 29 on OSX.

I don't know why, but I realized that CoreText is crashing with this combination of three Unicode characters

http://tny.cz/87a09a7c

in js: console.log("\u062E \u0337\u0334\u0310\u062E")

I posted a combination with 5 different characters.

This is also working:

\u062E \u0310\u0310\u0310\u062E

Well it's already fixed in Mavericks then.

Anyone know what Apple's timeline on patches for bugs like this are? TFA says that they've known about this for 6 months now.

Usually this sort of bug would fall under "next point release". No privilege escalation, no potential for leaking private data - i.e., no giant legal/PR disaster waiting to happen means they will likely defer a patch until the next scheduled point release.

There was something similar earlier this year with typing 'File:///' in a OSX text field.

http://thenextweb.com/shareables/2013/02/02/typing-these-eig...

I remember back in the day when you could send ̂ to people on AIM and crash their AIM clients.

My Chrome (in OSX) tab crashes even scrolling past half-way in this comments thread. Doesn't happen in other comment threads or in Safari or Firefox. Any idea why?

I use the HN comment collapse extension plus AdBlock, Ghostery, etc. Some sort of link pre-fetching I'm not aware of?

It happens here as well, Chrome on OSX.

A couple people had posted the text here. If you have showdead off you should be OK for now.

I've been looking at the stack trace in gdb a bit. And it seems that inside CoreText TStorageRange::SetStorageSubRange calls

    void vDSP_sveD(double *__vDSP_A, vDSP_Stride __vDSP_I, double *__vDSP_C, vDSP_Length __vDSP_N)

with a negative length argument.

Wonder if it is exploitable.

AFAIU, the length is negative but it is then treated as an unsigned integer by vDSP_sveD. So the function iterates over the given vector until there is a memory exception (As the length is very close to to UINT_MAX). It doesn't look very exploitable to me but it is surely annoying. I've found it a bit odd that neither TStorageRange::SetStorageSubRange nor vDSP_sveD do any kind of sanity checks for the values they calculate or which are passed to them.

> Since Apple doesn't show any reaction for about half a year.

Why is this happening?

People should put this link in the Apple Crash Report as proof.

You can't put in a chrome error report (The page will crash) I would assume the same will happen if you try to enter it in an Apple crash report.

On my iPad and I can only read half the comments here, then Safari exits: looks like jmuguy rather unhelpfully posted the characters in question.

This seems to be a kind of bug that would be found by fuzz testing. Is apple not using fuzz testing, or what's going on?

What kind of fuzzing heuristic would have found this in the haystack of Unicode permutations?

Well it's not just a single permutation. It'll take some deeper analysis to see how much fuzzing would be needed to find this bug.

Works pretty good, LOL. I hope it gets fixed ASAP. You can try it out and report via the browser feedback information.

It's fixed in 10.9 and iOS7, so I imagine they'll backport a patch at some point.

Though it's only a matter of time before somebody posts it here as a comment.

Is 10.9 usable?

It's not noticeably unusable.

Ummm, I wouldn't install it on a computer that you want to use for general computer usage. As a general rule, I advise people to wait until at least the .1 release, if not the .2 release for each new version. So using the beta is definitely a no-no, unless you actually need the beta, for testing your application against.

Otherwise you can find pretty big things not working - printing, might not work on one release, or bluetooth preferences might not open on another, or Airplay video streaming might not work. You may have graphics glitches, or a run away process that kills battery life. It's simply not worth the pain if you don\t really need it, but if you do really need it, the pain is bareable if you grit your teeth.

Just don't try to compile universal C binaries and you'll be fine

Another argument for decoupling apps from OS. Would be great if this could be an update to a Safari app in the App Store...

Unfortunately, it's a bug in CoreText, not WebKit. Either way, both frameworks are at the OS level.

Safari uses the OS-provided WebKit framework. An App Store update of Safari would only be able to change application-level features, not WebKit bugs.

Unlikely. iOS7 and 10.9 use TextKit which wraps CoreText and in turn they have dramatically enhanced CoreText in the process. The code is unlikely to be compatible. It will likely require a patch for the older code.

Security relevant crash bugs are normally back ported. In any case, TextKit is just a wrapper of CoreText (like you said) for easier use within AppKit/UIKit — all the text handling is still done by CoreText.

Annone testen what happens when you use it as a computername? Could be a problem as well, since machines with fileshares are listed in the finders sidebar. When the SSID already produces such a screwup, that would be even worst.

Works when being e-mailed to an apple phone also. Especially if you're using and ActiveSync enabled account. It will immediately crash the mail app until that e-mail message is deleted from another client.

Fixed in Mavericks and iOS7 apparently. So a fix is probably coming soon.

This crash any app. Try to paste this Unicode combination into any text field and you'll get a crash. http://tny.cz/1a56d253

Wow this actually crashes the entire Chrome browser on Mac OSX. This is the only one that fully crashes the browser instead of just the tab. The weird thing is, though, you need to copy paste it for it to crash not just view it. Weird huh

Does not crash Safari 6.0.4 (7536.29.13) on OSX 10.7.5 for me.

I'm really resisting sending this to my coworkers. Works via email as well, you can just turn Mail sync off and back on for the account to fix (on iOS)

Does this also affect iOS 5 and lower? That would be really annoying, as devices stuck on that version aren't receiving updates anymore...

Here's another: http://rpetri.ch/crash/

same with

    $ python -c "u'\u0647\u0020\u0488\u0488\u0488'

source: https://twitter.com/nst021/status/316124758469120000

Just tested on iOS 7 Safari on a gen3 iPad... The font looks great!

CVE # on this?

HOW DO I FIX THIS.

send enough non malicious messages to put the malicious one out of the auto load area

open messages, delete the conversation

I had to send about 30 messages, each had about 200 words

iOS is the only platform where I don't support full disclosure, or for that matter, any disclosure. It looks doubtful that this bug would be able to be used in a jailbreak anyway, but it's certain that Apple will patch it once it's known (and especially if it could be used to jailbreak).

Reply on news.ycombinator.com