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

A new CSS-based web attack will crash and restart your iPhone

techcrunch.com

Post reply on HN
Print view View original

41–50 of 140 posts

Re: A new CSS-based web attack will crash and restart your iPhone

#41

Post by JimDabell »

anderskaseorg wrote: post #35
wlesieutre wrote: post #9

Earlier quoted context omitted.

Because web browsers are trying to sandbox executable code from untrusted (and frequently malicious) sources, I would guess. WebKit/Nitro are trusted to keep that executable memory under very tight control, and if they're crashing they may have failed to. IIRC it has special privileges that allow it to run a JIT javascript engine.

It remains disturbing to read that something needs to be privileged just so it can sandbox unprivileged code. Why should I have to choose between trusting the sandbox and trusting the code that runs inside it? Why do we keep collectively forgetting the lesson that the more useful a sandboxing technology becomes, the more likely it becomes that someone will need to run that sandbox inside another sandbox (or inside an…

> It remains disturbing to read that something needs to be privileged just so it can sandbox unprivileged code.

That's not what is happening.

All modern JavaScript implementations use JIT for performance reasons. It's one of the main reasons behind the massive performance increases JavaScript has made in recent years.

JIT requires that the process be able to generate data then execute it as code. This is, historically, something that has been used in many security attacks. So modern CPUs provide the ability to stop this from happening (the NX bit).

iOS sensibly switches this off by default. Which is fine in most cases, but in some situations – like JavaScript JIT – it's necessary, so Apple grant special privileges to the WebKit process (not Safari) in order for it to perform well. This is part of the reason why the WebKit rendering happens in an external process – partly because it reduces the amount of code that needs this special privilege, and partly so that other applications apart from Safari can also get the JIT performance improvements without having to trust them with the special privileges.

There's no indication that this crasher has anything to do with Safari having special privileges, and I think it's likely that other applications can do this too.

Re: A new CSS-based web attack will crash and restart your iPhone

#42

Post by jhabdas »

rixrax wrote: post #38
matthberg wrote: post #3

The tweet announcing it: https://twitter.com/pwnsdx/status/1040944750973595649 The code that causes the crash (safe to open): https://gist.github.com/pwnsdx/ce64de2760996a6c432f06d612e33... The demo itself (causes crash): https://cdn.rawgit.com/pwnsdx/ce64de2760996a6c432f06d612e33a...

Haha! Looks like another modern version of zip-bomb[0] or should I say - div-bomb:) [0] https://en.wikipedia.org/wiki/Zip_bomb

xD

Re: A new CSS-based web attack will crash and restart your iPhone

#43

Post by jhabdas »

KenanSulayman wrote: post #40

I tried it on my iPhone X and it triggers a kernel panic (agxk_mmu.cpp) when trying to allocate memory for WebKit. It seems it exhausts the memory so fast that it triggers an assertion error somewhere? Screenshot: https://i.imgur.com/6tDr44q.png Full serial console log of the device: https://gist.githubusercontent.com/KenanSulayman/867cc399e97...

Have you tried the backdoor yet? https://www.gnu.org/proprietary/malware-apple.html#back-door...

Re: A new CSS-based web attack will crash and restart your iPhone

#44

Post by bitexploder »

sebazzz wrote: post #2

I have always wondered why Safari crashes can reboot the entire telephone. Doesn't iOS have multiple protection rings or is Safari running at ring 0? Or is it a precaution that inhibits jailbreak research?

One of the older iOS jailbreaks, written by comex, was launched via Safari. It generally takes a few vulnerabilities to get to arbitrary code execution in the kernel. You have to (1) break out of the browser sandbox and (2) defeat exploit mitigation technology, such as non-executable stack and finally (3) escalate privileges. There can be some potential shortcuts to this, but that is the basic sketch. Why multiple vulns? To defeat ASLR, for example, you need something that leaks information about how the memory is layed out. This also helps defeat NX (non-executable stack) as you use existing code to do the initial bootstrapping of your exploit.

Re: A new CSS-based web attack will crash and restart your iPhone

#45

Post by amself »

matthberg wrote: post #3

The tweet announcing it: https://twitter.com/pwnsdx/status/1040944750973595649 The code that causes the crash (safe to open): https://gist.github.com/pwnsdx/ce64de2760996a6c432f06d612e33... The demo itself (causes crash): https://cdn.rawgit.com/pwnsdx/ce64de2760996a6c432f06d612e33a...

Worked on iOS 11.4 iPhone 8

Re: A new CSS-based web attack will crash and restart your iPhone

#46

Post by bitexploder »

anderskaseorg wrote: post #35
wlesieutre wrote: post #9

Earlier quoted context omitted.

Because web browsers are trying to sandbox executable code from untrusted (and frequently malicious) sources, I would guess. WebKit/Nitro are trusted to keep that executable memory under very tight control, and if they're crashing they may have failed to. IIRC it has special privileges that allow it to run a JIT javascript engine.

It remains disturbing to read that something needs to be privileged just so it can sandbox unprivileged code. Why should I have to choose between trusting the sandbox and trusting the code that runs inside it? Why do we keep collectively forgetting the lesson that the more useful a sandboxing technology becomes, the more likely it becomes that someone will need to run that sandbox inside another sandbox (or inside an…

Safari still only runs as a low privileged user named “mobile”. Check out pwn2own and other previous full Safari to kernel exploits. It has always taken multiple bugs to get to the kernel for a number of reasons. This thing could be doing all of that, but bugs that legit exploit and crash the kernel are quite valuable and at a minimum jailbreak teams care a lot about bugs (sets of bugs, really) that do this! The author may have been fuzzing and found a true one bug DoS that has no utility beyond crashing Safari. They may not be aware of how cool what they found is, also. Regardless once it becomes public the hole is burned and Apple will fix it. Oh and th mobile user is sandboxes too. Apple has a thing called Seatbelt, check it out.

Re: A new CSS-based web attack will crash and restart your iPhone

#47

Post by barbegal »

KenanSulayman wrote: post #40

I tried it on my iPhone X and it triggers a kernel panic (agxk_mmu.cpp) when trying to allocate memory for WebKit. It seems it exhausts the memory so fast that it triggers an assertion error somewhere? Screenshot: https://i.imgur.com/6tDr44q.png Full serial console log of the device: https://gist.githubusercontent.com/KenanSulayman/867cc399e97...

The log suggests the device is doing everything correctly. The exploit webpage requires huge amounts of memory to render correctly. It is consuming all the available memory causing allocations for backboardd to fail. The kernel then starts killing off idle processes to free up memory.

I don't see a kernel panic there.

Re: A new CSS-based web attack will crash and restart your iPhone

#49

Post by spockz »

aaaaaaaaaab wrote: post #34
zuppy wrote: post #24

Earlier quoted context omitted.

works on iOS 12 GM also

I wonder if they are trying to fix it before tomorrow’s release.

It is more likely that they would fix this in a 12.0.1 that will be available shortly than to change the 12 release as all new iPhones come preloaded with 12.

Re: A new CSS-based web attack will crash and restart your iPhone

#50

Post by comex »

jstanley wrote: post #6
fulafel wrote: post #5

Earlier quoted context omitted.

It's prudent to reboot when a privileged component crashes, since the integrity of the code execution has been compromised. A lot of the time a DoS bug in native code is synonymous with "nobody bothered to craft a RCE". It's unintuitive to many people how many scenarios eventually allow a RCE exploit to be crafted. Check out some null pointer deref RCE's to convince yourself.

But why is Safari a privileged component?

Just to clarify the situation:

fulafel’s comment (parent^4 of this comment) is incorrect. iOS does not automatically reboot when Safari or WebProcess crashes, and Safari is not generally treated as a ‘privileged component’ overall – to the contrary, last I checked it had a tighter sandbox than most apps.

As people have noted, Safari does have special privileges to run a JIT, which is otherwise restricted. This is not because running a JIT can compromise the security of the system as a whole, but simply because having a JIT in your process makes it easier to exploit that process, making it best to avoid except where absolutely necessary.

By the way, I haven’t looked into this crash myself, but my guess is that it’s an unexploitable out-of-memory situation. This would still involve some sort of bug in the kernel, since it shouldn’t be possible for a process to take down the whole system (especially not ‘by accident’). But in general it’s relatively common to have bugs where you can make a more privileged piece of code run out of memory, and most of the time there’s no way to turn them into code execution. Of course, “most of the time” != always, and there’s no way to know for sure without tracking down the root cause :)

Post reply on HN