This reminds me of how I was unemployed for a good chunk of the year 2001.
I was making a fresh start in a new city, and shopping my resumé to various graphics design firms. There was a prominent link to my portfolio site up top. After months of looking I didn’t get a single call-back.
Eventually I got a job in another industry, and noticed a bunch of Macs in the corner that they used for testing. One day I decided to load my portfolio site for fun... turned out there was a glitch in CSS support in Internet Explorer that would crash the browser, and since this was Mac OS “Classic”, that took down the entire machine.
Graphic design firms were all still on Macs with the old OS back in those days; I had been walking around crashing computers and destroying people’s work for months.
In my first commercial attempt at web development I utilised a png transparency fix for IE6 (written in that IE6 specific filter thing). A few months later the client passed on a complaint from one of his customers whom's machine crashed whenever he visited the website... I removed the IE6 fix and all was well in the world - You can have nice things or MS, you can't have both.
Interesting, it's simply a few thousand nested divs with a huge blur on them. Is it something specific about blur? Or could you do the same thing with box-shadows, etc, if there are enough of them?
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?
Safari does not run at ring zero. However, it can make system calls into the ring-zero kernel and drivers. If there's a bug in the kernel or drivers, that can cause the kernel to crash.
There are other scenarios that don't involve a ring-zero vulnerability but still result in a "reboot". Safari coordinates with other system processes, like the one that shows the home screen. If a web site can cause Safari to cause that process to crash, it would feel like a "reboot", even though no ring-zero code was attacked.
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.
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.
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.
This isn't just an iOS bug. The affected CSS property is just not available on most platforms.
Sinfe I do not have access to any apple hardware, I tried turning on the experimental web features in Chrome Canary on my phone and it managed to freeze Android as well. The Chrome browser crashed on Windows with this setting on. Microsoft Edge, the only browser other than Safari to have support this property without messing with config, just showed a generic "this page can not be displayed" message.
I think this problem affects the entire WebKit/Blink code base, the only reason the crashes are not being detected on other platforms is that most browsers just don't support this feature yet.
This is basically 3,485 nested <div>s (balanced; same number of </div>s) with width and height both set to 10,000px.
I have no idea is this is an internal DOM overflow or it's because of the tiled background-image. (I don't have an iPhone to test against.)
EDIT: I actually read the article properly :) all 3,485 the <divs> have a 10px backdrop-filter set on them.
> He explained that nesting a ton of elements — such as <div> tags — inside a backdrop filter property in CSS, you can use up all of the device’s resources and cause a kernel panic
Fun trivia: ^F for <div> on the GitHub gist page, and Chrome will inch... forward... so... very... slowly... finding... matches. You have to search the raw file if you want it to complete this century.
It's because of the nested backdrop-filters being applied. I would've thought the css parser / rendering engine stops this from happening, but apparently not.
Why the downvotes? The guy is a security research, and published a bug that can crash the app or OS (reports in this thread have reported mixed results, and others are saying it may impact OSX as well). The guy goes to Twitter the announce the bug.
Most people that call themselves security researchers will notify the vendor and give them some amount of time before publishing it. He waited 1 day.
My best guess is that since it's just a OS crash, he felt he could release it. But for something that is easy for any website to do, seems like he should have given them some more time.
Dug through WebKit Bugzilla and Trac and the only recent visible "crash backdrop" issue seems to be "Fix crash when reflections and backdrop filter are combined" [1], which references bug that requires authorization [2].
It’s cruel of them to make this discovery public without a fix.
Thousands upon thousands of normal, non-tech, non-fanatic people are going to be sent a link to this page by someone mean who wants to crash their phone and laugh at their pain as they’re locked out of their life by a crash bug.
I've stopped accepting iOS/OSX seriously after those iCloud celebs leaks and especially after 'empty string' root prompt bug. How anyone can still trust this black box concept.
How is it that browserland always seems to impact the OS? Is it the browser's need for graphics drivers? Or are these browsers embedded at a different level compared to a traditional OS?
What other apps do you have on your phone that are executing what is essentially an enormous amount of untrusted code?
There is nothing different about browsers than other apps, but given how they work people are far more likely to discover these kinds of bugs in browsers.
DoS of safari or the kernel? It's a kernel panic, which is not a safari dos; no user space app should be allowed to crash the kernel. Memory exhaustion should just trigger an OOM kill at worst.
It didn’t ask for their sim PIN, which is expected if the sim does not lose power, like in a full reboot without power off (eg kernel panic auto restart).
This is not to be confused with iOS unlock. SIM PINs are not commonly used in the USA.
Some reboots on iPhone (including if you force it yourself by holding HOME + Power on iPhone 6) don't relock the SIM card, so that might be the "PIN" that was missing.
> If so, does Safari not have limits applied that cause it to be killed for running into OOM?
It does. The memory allocation that causes the crash doesn't come from Safari, though: it's a memory allocation in the kernel (likely somewhere graphics related), and that counts towards XNU's memory consumption and not Safari's.
I take it some Apple engineers were/will be called in on a Sunday in order to push a WebKit / Mobile Safari "11.4.2" security update. Thoughts, prayers and coffee.
Eric_WVGG|7 years ago
I was making a fresh start in a new city, and shopping my resumé to various graphics design firms. There was a prominent link to my portfolio site up top. After months of looking I didn’t get a single call-back.
Eventually I got a job in another industry, and noticed a bunch of Macs in the corner that they used for testing. One day I decided to load my portfolio site for fun... turned out there was a glitch in CSS support in Internet Explorer that would crash the browser, and since this was Mac OS “Classic”, that took down the entire machine.
Graphic design firms were all still on Macs with the old OS back in those days; I had been walking around crashing computers and destroying people’s work for months.
tomxor|7 years ago
chrisper|7 years ago
sizzle|7 years ago
matthberg|7 years ago
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...
rixrax|7 years ago
[0] https://en.wikipedia.org/wiki/Zip_bomb
Reedx|7 years ago
squaredpants|7 years ago
amself|7 years ago
avip|7 years ago
sebazzz|7 years ago
valleyer|7 years ago
There are other scenarios that don't involve a ring-zero vulnerability but still result in a "reboot". Safari coordinates with other system processes, like the one that shows the home screen. If a web site can cause Safari to cause that process to crash, it would feel like a "reboot", even though no ring-zero code was attacked.
bitexploder|7 years ago
fulafel|7 years ago
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.
howdydoo|7 years ago
avip|7 years ago
qrbLPHiKpiux|7 years ago
KenanSulayman|7 years ago
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...
barbegal|7 years ago
I don't see a kernel panic there.
amaccuish|7 years ago
jhabdas|7 years ago
jeroenhd|7 years ago
Sinfe I do not have access to any apple hardware, I tried turning on the experimental web features in Chrome Canary on my phone and it managed to freeze Android as well. The Chrome browser crashed on Windows with this setting on. Microsoft Edge, the only browser other than Safari to have support this property without messing with config, just showed a generic "this page can not be displayed" message.
I think this problem affects the entire WebKit/Blink code base, the only reason the crashes are not being detected on other platforms is that most browsers just don't support this feature yet.
exikyut|7 years ago
I have no idea is this is an internal DOM overflow or it's because of the tiled background-image. (I don't have an iPhone to test against.)
EDIT: I actually read the article properly :) all 3,485 the <divs> have a 10px backdrop-filter set on them.
> He explained that nesting a ton of elements — such as <div> tags — inside a backdrop filter property in CSS, you can use up all of the device’s resources and cause a kernel panic
Fun trivia: ^F for <div> on the GitHub gist page, and Chrome will inch... forward... so... very... slowly... finding... matches. You have to search the raw file if you want it to complete this century.
endless1234|7 years ago
Ducki|7 years ago
wumms|7 years ago
kyrra|7 years ago
kyrra|7 years ago
Most people that call themselves security researchers will notify the vendor and give them some amount of time before publishing it. He waited 1 day.
My best guess is that since it's just a OS crash, he felt he could release it. But for something that is easy for any website to do, seems like he should have given them some more time.
bluesign|7 years ago
can be related to AppleJPEGDriver-memleak [1]
[0] https://news.ycombinator.com/item?id=17998178 [1] https://github.com/bazad/AppleJPEGDriver-memleak
myfonj|7 years ago
[1] https://trac.webkit.org/changeset/235475/webkit [2] https://bugs.webkit.org/show_bug.cgi?id=188504
XCSme|7 years ago
I guess that restarting is less important than modifying memory it shouldn't.
ccnafr|7 years ago
Safari on MacOS is also affected, and you can make it persist with a little bit of JS.
nereid666|7 years ago
floatingatoll|7 years ago
Thousands upon thousands of normal, non-tech, non-fanatic people are going to be sent a link to this page by someone mean who wants to crash their phone and laugh at their pain as they’re locked out of their life by a crash bug.
This is irresponsible disclosure.
codedokode|7 years ago
seddin|7 years ago
MrKristopher|7 years ago
novaRom|7 years ago
qrbLPHiKpiux|7 years ago
askmike|7 years ago
wepple|7 years ago
Its truly awesome that you audited the whole Linux kernel and everything on top of it you run, mind sharing your notes?
jorblumesea|7 years ago
hn_throwaway_99|7 years ago
There is nothing different about browsers than other apps, but given how they work people are far more likely to discover these kinds of bugs in browsers.
runeks|7 years ago
I’m no security researcher but, as I understand, it shouldn’t be exploitable if this is the case.
nothrabannosir|7 years ago
zitterbewegung|7 years ago
exikyut|7 years ago
- This is a full kernel panic; I wonder if it's exploitable (...probably not)
- Someone's iPhone didn't ask for their PIN on reboot?
- It apparently crashes watchOS 5 too
saagarjha|7 years ago
That's because the iPhone didn't reboot fully. This doesn't deterministically cause a panic, sometimes it just takes down parts of the system.
sneak|7 years ago
This is not to be confused with iOS unlock. SIM PINs are not commonly used in the USA.
unilynx|7 years ago
amaccuish|7 years ago
gsnedders|7 years ago
It does. The memory allocation that causes the crash doesn't come from Safari, though: it's a memory allocation in the kernel (likely somewhere graphics related), and that counts towards XNU's memory consumption and not Safari's.
ilumanty|7 years ago
feketegy|7 years ago
systoll|7 years ago
marcellus777|7 years ago
Froyoh|7 years ago
swingline-747|7 years ago