Slashdot Mirror


Vulnerability in WebKit Crashes and Restarts iPhones and iPads (zdnet.com)

Catalin Cimpanu, writing for ZDNet: A security researcher has discovered a vulnerability in the WebKit rendering engine used by Safari that crashes and restarts the iOS devices -- iPhones and iPads. The vulnerability can be exploited by loading an HTML page that uses specially crafted CSS code. The CSS code isn't very complex and tries to apply a CSS effect known as backdrop-filter to a series of nested page segments (DIVs). Backdrop-filter is a relative new CSS property and works by blurring or color shifting to the area behind an element. This is a heavy processing task, and some software engineers and web developers have speculated that the rendering of this effect takes a toll on iOS' graphics processing library, eventually leading to a crash of the mobile OS altogether.

16 of 57 comments (clear)

  1. Really? by grep+-v+'.*'+* · · Score: 2, Insightful

    apply a CSS effect known as backdrop-filter

    Just display the text. DISPLAY. THE. TEXT. That's all I want in a browser (well, accepting forms too I suppose, that is fairly handy.)

    Movement and special effects and such are for movies. If I wanted blurry text I'd take off my glasses.

    --
    If the universe is someone's simulation -- does that mean the stars are just stuck pixels?
    1. Re:Really? by Gr8Apes · · Score: 3, Insightful

      The entire HTML/CSS rendering concept is flawed from the get-go, with piss poor standardization and failure to maintain boundaries within graphical elements. It's effectively a pinup board with no boundaries and no real rules on rendering. But it's Agile! ;)

      --
      The cesspool just got a check and balance.
    2. Re:Really? by Anonymous Coward · · Score: 1

      We tried leaving this junk out of the spec.

      That got us Flash because web "developers" love the shiny graphical bullshit.

      There's a reason all this shit is getting dumped into browsers now, and it's because if it weren't, web "developers" would find some way to do it anyway.

      Also, if you want to see this bullshit in use, just go to Apple's homepage. They use that crap all the time. (Note: it's most egregious on their "learn more" pages.)

    3. Re:Really? by Anonymous Coward · · Score: 1

      Just display the text. DISPLAY. THE. TEXT. That's all I want in a browser (well, accepting forms too I suppose, that is fairly handy.)

      That assertion is bullshit because if that's all you want then you would just use Lynx. Of course if you're using an iDevice then you have obviously chosen the wrong platform but even then there is Text Browser.

    4. Re:Really? by Shikaku · · Score: 1

      https://play.google.com/store/...

      At least Android has the option. The app name isn't Lynx but yes it's Lynx with some menus.

    5. Re:Really? by CanadianMacFan · · Score: 4, Insightful

      It's not the developers. It's the designers who f*cking think that their site should look the same on every browser and every computer no matter what. They were the idiots that used to think that because your screen had n pixels in width then their website could be n pixels wide too. I mean, everybody has their browser maximized right?!?!? They also think that everyone has a high-speed connection to download unoptimized graphic files.

      It's HTML, it's going to look slightly different on different browsers and different platforms. Live with it. If it really needs to look the same then make a PDF to download.

    6. Re:Really? by gweihir · · Score: 1

      How old-school. Today everything must be blinking and beeping or it is not real, have you not heard?

      In other news, I am waiting for a browser that has a "plain" no-bullshit mode, without quite going back to links or the like.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    7. Re:Really? by Anonymous Coward · · Score: 1

      Everything w3c touches is flawed from the get-go

      Let ISO/ANSI/ECMA or even JEDEC handle it and at least they will write down what is implementation defined and what is not in a clear way.
      At least we will be able to tell if it is the page that is broken or the browser that can't handle it.

    8. Re:Really? by thegarbz · · Score: 3, Insightful

      Just display the text.

      1990 called, they want their HTML 1.0 back.

      That's all I want in a browser

      Use Lynx, and leave the rest of us alone.

  2. Re: quality software apple by Anonymous Coward · · Score: 2, Informative

    Doesn't actually crash or reboot iOS. It just looks like it while it reloads the graphic system. Comes back way too fast to be a restart, all apps still running, all Safari tabs saved except the offending tab, phone doesn't say it was restarted on the lock screen like it does after a restart.

    Tested on iPhone 5c, iOS 10.3.3.

  3. Fixed in iOS 12? by antdude · · Score: 1

    Will it fixed in tomorrow's iOS 12 release?

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  4. Try Reader mode by andrewbaldwin · · Score: 1

    A lot of browsers have a reader mode which just displays text and inline images - no adverts, no flash....

    It's a real pleasure to see some pages 'old school' without all the rubbish.

  5. Re:quality software apple by SharpFang · · Score: 3, Interesting

    It's not *that bad* really. The crash occurs in the gfx library / rendering engine, on a lower level. It's just given a single absolutely massive rendering task it's unable to complete within the watchdog duty cycle. Someone didn't foresee this - normally the library should be done with its job within microseconds, but this specific job was engineered to take a "macroscopic" time slice, and so, the watchdog bites.

    There are solutions - but not easy. It would be fairly difficult to design a subsystem that estimates time required to render a specific effect, before deciding "just don't do it", An easier approach would be to abort the rendering job after a preset time, and restore the subsystem to a stable state. This would require a separate dedicated watchdog, and a special subsystem that is capable to abort and unroll an arbitrary job mid-way through. Or they could slice the rendering engine vertically, and make it perform only a specific amount of work per time slice. And this gets quite convoluted because you're replacing simple loops with a finite state machine.

    All doable, all difficult and costly... and not contributing to normal web experience, just protecting against malicious attacks. Yeah, they fucked up, but it's a 'the fucking incompetent idiots' fuckup type, it's just 'for fuck's sake, do we really have to protect against THIS too?' one.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  6. Programmer humor by volodymyrbiryuk · · Score: 2

    So the "I hack people with HTML" memes are true at last. Thank you Apple.

    --
    sudo rm -r -f --no-preserve-root /
  7. Maybe We Don't Need Styled Information by BrendaEM · · Score: 1

    I would rather have the user determine the look of a webpage. We want text, images, videos, and audio, and menu, and a search box that we don't need to use a find function to find.

    --
    https://www.youtube.com/c/BrendaEM
  8. Re:quality software apple by Warhaven · · Score: 1

    It's not *that bad* really. The crash occurs in the gfx library / rendering engine, on a lower level. It's just given a single absolutely massive rendering task it's unable to complete within the watchdog duty cycle. Someone didn't foresee this - normally the library should be done with its job within microseconds, but this specific job was engineered to take a "macroscopic" time slice, and so, the watchdog bites.

    There are solutions - but not easy. It would be fairly difficult to design a subsystem that estimates time required to render a specific effect, before deciding "just don't do it", An easier approach would be to abort the rendering job after a preset time, and restore the subsystem to a stable state. This would require a separate dedicated watchdog, and a special subsystem that is capable to abort and unroll an arbitrary job mid-way through. Or they could slice the rendering engine vertically, and make it perform only a specific amount of work per time slice. And this gets quite convoluted because you're replacing simple loops with a finite state machine.

    All doable, all difficult and costly... and not contributing to normal web experience, just protecting against malicious attacks. Yeah, they fucked up, but it's a 'the fucking incompetent idiots' fuckup type, it's just 'for fuck's sake, do we really have to protect against THIS too?' one.

    Yup. Didn't crash my little Mini (Late 2012 model, 16GB RAM, 2.5GHz Ivy Bridge Core i5), but it did max out the CPU and bring it to a crawl until I closed the window. Didn't test it on my iPhone 6s, but I presume it'd fair even worse.