Beveiligingsonderzoeker laat iOS crashen met css-code

Een beveiligingsonderzoeker heeft een kwetsbaarheid in iOS gevonden die ervoor zorgt dat het besturingssysteem door een simpel stuk css-code crasht. De kwetsbaarheid zit in de WebKit-engine voor de Safari-browser. Ook macOS zou last hebben van de fout.

Op Twitter liet Sabri Haddouche zien hoe het gebruik van bepaalde css-code kan leiden tot een crash van het besturingssysteem, waarna het apparaat herstart. Hij plaatste daarbij ook een link naar een webpagina met de bewuste css-code, waardoor gebruikers zelf kunnen zien of hun iOS-apparaat crasht. Ook plaatste Haddouche een link naar de broncode die hij gebruikte om iOS-toestellen te laten crashen.

Dat iOS-apparaten door bepaalde broncode niet meer goed functioneren, komt door het backdrop-filter-effect, een relatief nieuwe css-functie. Als het backdrop-filter-effect wordt toegepast op een aantal geneste div-elementen loopt WebKit, de engine van de Safari-browser, vast. Dit komt vermoedelijk doordat backdrop-filter relatief zwaar is om te verwerken waardoor alle processorkracht voor het verwerken van graphics wordt gebruikt. Volgens de onderzoeker resulteert dit uiteindelijk in een kernel panic.

Volgens Haddouche werkt de methode ook op macOS, al loopt daar de browsertab slechts korte tijd vast en treedt er geen reboot op. Wel stelt de beveiligingsonderzoeker dat ook macOS-apparaten te crashen zijn, maar daarvoor is een gemodificeerde versie van de kwaadaardige code nodig met onder andere javascript-elementen. Haddouche liet hier geen voorbeeld van zien.

Apple is op de hoogte gesteld van de bevindingen, en heeft laten weten dat het onderzoek doet. Of en wanneer dat leidt tot het uitbrengen van een fix is echter nog onduidelijk.

Het is niet de eerste keer dat er een kwetsbaarheid wordt ontdekt in iOS die voor een crash zorgt. Zo repareerde Apple onlangs een fout in het besturingssysteem waardoor Whatsapp kon crashen door het sturen van een Indiaas teken. Ook werd er een update uitgebracht om het vastlopen van chatapps te voorkomen als gevolg van het typen van het woord Taiwan of het ontvangen van een emoji van de Taiwanese vlag.

Reacties (145)

[TonnyTonny]

Net even geprobreed op een i7 iMac met 24 GB RAM. Die moet toch wat kunnen hebben zou je zo zeggen...
Safari vreet 9 GB RAM voor die ene tab en legt de hele Mac lam.
Gek genoeg gaat de CPU load nauwelijks omhoog maar het vreet blijkbaar zoveel resources van de GUI dat die volledig unresponsive wordt.
Aktiveren van het Force Quit window (command-option-escape) duurde 3 minuten en het was niet te bedienen.
Gelukkig was ik zo slim om voor ik de link aanklikte een terminal window open te hebben gezet met kill -9 <safari-pid> al ingetyped. hoefde daar alleen op enter te drukken. Duurde nog een minuut of 2 voordat Safari weg was en het systeem weer normaal funktioneerde.
Daar zit iets heel doms in de logica van de webkit engine....
Vraag me af of Safari onder WIndows het ook zo lam kan leggen (eigenlijk meer benieuwd hoe goed Windows zo'n run-away process handelt), maar Safari op Windows is zo'n wangedrocht dat ik weiger dat op mijn Windows dozen te installeren.

[GekkePrutser]

Safari op Windows is zo'n wangedrocht

Het is ook sinds 2012 niet meer ontwikkeld dus nauwelijks relevant.

[TonnyTonny]

Noem het ook niet voor niks een wangedrocht.
Helaas heb ik te maken met klanten die zulke Apple fanboys zijn dat ze per se op Windows Safari willen draaien (en permanent met admin-rechten draaien, UAC uit, virusscanner uit, etc...)..
Dat is dan uiteraard egen alle bedrijfs-security regels in, maar d'r zitten er een paar bij met voldoende politieke macht in het bedrijf om een uitzondering op de regels te krijgen. Komt er in feite op neer dat ze op hun persoonlijke bedrijfslaptop mogen doen en laten wat ze willen, ongeacht wat wij als IT afdelng voorschrijven,

De enige "saving grace" is dat we zwart op wit van het hoogste management hebben dat onze enige vorm van support "Format C:" en herinstallatie zal zijn bij deze eigenheimers.
En dat doen we dan ook met alle liefde en plezier bij de geringste aanleiding :-)

[GekkePrutser]

Oei, als IT zou ik toch echt Windows-Safari verbieden, het is een browser die 6 jaar geen security updates meer heeft gehad. Daarmee zijn ze een gevaar voor het hele bedrijf. Maargoed dat weet je net zo goed als ik natuurlijk. Je kan het niet eens meer downloaden van Apple. Politiek of niet, als mensen willens en wetens tegen de security policy in kunnen werken heb je echt een probleem.

En inderdaad zoals de anderen zeggen: Dan zou me een MacBook nog beter lijken.

Bij ons op het werk hebben we ook enkele mensen die een privé MacBook gebruiken, tot nu toe werd dat getolereerd maar sinds we zijn begonnen met een officiëel Mac support project doen we dat niet meer. Het was een beetje lastig om ze dit te verbieden na zoveel jaar maar de meeste zijn hooggeplaatst genoeg om gewoon een officiële bedrijfs Mac te krijgen dus is het probleem opgelost.

En zoals @BikkelZ zegt, Windows op Mac doen we gelukkig niet. Er zijn wel eens mensen die dit willen puur voor de bling-bling terwijl ze toch iets nodig hebben dat Windows only is (denk aan MS Project, Visio enz) maar dat is gelukkig vanuit de hoogste sferen bij ons verklaard als een absolute NEE

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:27]

[Hackus]

Noem het ook niet voor niks een wangedrocht.
Helaas heb ik te maken met klanten die zulke Apple fanboys zijn dat ze per se op Windows Safari willen draaien (en permanent met admin-rechten draaien, UAC uit, virusscanner uit, etc...)..
Dat is dan uiteraard egen alle bedrijfs-security regels in, maar d'r zitten er een paar bij met voldoende politieke macht in het bedrijf om een uitzondering op de regels te krijgen. Komt er in feite op neer dat ze op hun persoonlijke bedrijfslaptop mogen doen en laten wat ze willen, ongeacht wat wij als IT afdelng voorschrijven,

De enige "saving grace" is dat we zwart op wit van het hoogste management hebben dat onze enige vorm van support "Format C:" en herinstallatie zal zijn bij deze eigenheimers.
En dat doen we dan ook met alle liefde en plezier bij de geringste aanleiding :-)

Ik ken werkelijk niemand die dat tracht te gebruiken of gebruikt. De meeste Fanboys zoals jij het noemt hebben geen windows pc. en zo wel, dan ken ik niemand die Safari op zijn windows pc heeft. Mijn enige windows laptop draait ook niet op Safari. iTunes en iCloud for windows werkt prima en er zijn meer browsers dan Edge en Safari. Op je werkplek kun je gewoon vaste browser instellen en beperkingen voor gebruikers, zodat niet iedere (handige Harry) gaat klooien.

[BikkelZ]

Wat voor macht heb je als je niet gewoon een MacBook Pro 15" 2018 met alle toeters en bellen krijgt om Windows gewoon in Parallels te gebruiken? Alsof je rode remschijven bedingt op je Alfa Romeo Giulietta terwijl de echte patsers gewoon een Audi A8 krijgen.

[TonnyTonny]

Omdat MacOS niet kan. Kunnen we niet inpassen in ons basis security model.
Full disk-encryptie, die te unlocken is door de IT afdeling indien nodig/gebruiker key vergeet, is op MacOS een issue. En dat is een verplichting waar zelfs de "speciale gebruikers" niet omheen kunnen.
Wat we wel supporten is SecureBoot met een Debian based Linux (Ubuntu of Mint, b.v.) waar full-disk-encryptie is gelinked aan SecureBoot/TPM chip. Daarop eventueel Windows in een VM.
(In dat geval is het net zo goed, of zefls beter, dichtgetimmerd dan in Windows met SecureBoot/Bitlocker.)

Maar Linux is vuels te moeilijk voor onze "speciale gebruikers" :-)

Alle bedrijfs-software is overigens Windows-only (veel Internet Explorer 11 met ActiveX (sic)) en zonder AD integratie werkt het niet. Dus je moet nog steeds Windows in een VM draaien.

Wat voor macht heb je als je niet gewoon een MacBook Pro 15" 2018 met alle toeters en bellen krijgt om Windows gewoon in Parallels te gebruiken? Alsof je rode remschijven bedingt op je Alfa Romeo Giulietta terwijl de echte patsers gewoon een Audi A8 krijgen.

Ik rij overigens in een Giulia Quadrifoglio, is dat ook goed ?

[GekkePrutser]

Omdat MacOS niet kan. Kunnen we niet inpassen in ons basis security model.
Full disk-encryptie, die te unlocken is door de IT afdeling indien nodig/gebruiker key vergeet, is op MacOS een issue. En dat is een verplichting waar zelfs de "speciale gebruikers" niet omheen kunnen.

Dat kan prima hoor, dat hebben wij ook gewoon. Elke goede MDM kan dit, die slaat de backup FileVault key op. Wij beheren de Macs met Airwatch van VMWare (tegenwoordig Workspace ONE genoemd) en die doet dit prima, en het kan ook via bijvoorbeeld McAfee. JAMF Pro, zo'n beetje de gouden standaard op Mac MDM gebied, kan het ook.

Als je niet aan de MDM wil dan kan het ook via een Apple ID, al is dat wat moeilijker te beheren als bedrijf zijnde, kan ik niet echt aanraden. Apple DEP met MDM is de door Apple aangeraden beheermethode tegenwoordig. MDM betaal je meestal per gebruiker per maand dus hoeft ook niet heel veel te kosten als je weinig Macs hebt.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:27]

[TonnyTonny]

Ik weet dat het in principe kan.
Maar dan zouden we voor een handjevol (10 hooguit) gebruikers (op een totaal van zo'n 1500) een hele hoop tijd en geld moeten investeren in afwijkende software, training van de IT staff, beheersprocessen, procedures, audits, etc.
Als je daar het kostenplaatje naast zet...
Het is het gewoon niet waard.

Voro de Linux operatie was het een ander verhaal. 150 werkplekken en groeiende. We verwachten er uiteindelijk zo'n 300 a 400 op Linux te hebben. Dat heeft voldoende schaal-grootte om de extar effort rendabel te laeten zijn.

[GekkePrutser]

Oh interessant.. Bij ons is het net andersom. Een paar jaar geleden zat heel veel R&D op Linux en dat wordt steeds meer Mac. Met name omdat ze dan geen Windows VM nodig hebben om de gewone office bezigheden uit te voeren. Er zijn nog wel wat 'app gaps' maar niet veel die voor developers belangrijk zijn.

Ook helpt het mobiele gedeelte wel mee: Steeds meer focus op mobiele apps, dus komt iOS devving er bij kijken dat nou eenmaal alleen op een Mac kan.

Maar inderdaad zoals ik ook al zei kost het wel een serieuze hoeveelheid inspanning, en voor 10 Mac's doe je dat niet. Bij ons ligt de verhouding ongeveer hetzelfde alleen zijn de absolute aantallen groter dus daarom kon het wel uit.

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:27]

[BikkelZ]

Geloof me maar dat macOS altijd kan als je maar genoeg te zeggen hebt. Hoeveel IT afdelingen hebben al uitzonderingen-die-later-regel-werden moeten implementeren omdat de baas liever zijn shiny nieuwe iPhone gebruikt in plaats van een BlackBerry van de zaak? Dat was het begin van het BYOD verhaal. Nog los van het probleem dat je geen (serieuze) apps kunt ontwikkelen zonder Mac.

Alle bedrijfs-software is overigens Windows-only (veel Internet Explorer 11 met ActiveX (sic)) en zonder AD integratie werkt het niet. Dus je moet nog steeds Windows in een VM draaien.

Parallels. Zo werkte ik altijd in Visual Studio en dat werkte uitstekend, je verziekt je Windows ook niet door nog eens tig andere dingen te installeren omdat het niet je main OS is. Ik zat dan ook wel eens op netwerken waar ik met mijn Mac niet op zat.

Ik rij overigens in een Giulia Quadrifoglio, is dat ook goed ?

Da's helemaal goed

[Reactie gewijzigd door BikkelZ op 24 juli 2024 05:27]

[Krulliebol]

Even uit nieuwsgierigheid: waarom draaien die mensen dan überhaupt Windows?

[Yalopa]

Voor mij is dat 1 keer per week Visio opstarten, de rest gebeurt in Mac OS.

[jimzz]

Naar mijn weten is safari voor Windows al jaren niet meer officieel te downloaden. Dus dat gedrocht dat je kende van toen, is nu nog exact dezelfde (als je m nog gevonden krijgt).

[poNgz0r]

Tja daar heb je het al, safari. Misschien off topic, maar als Microsoft niet standaard internet explorer mag installeren, waarom mag Apple dan wel standaard safari erop zetten?

[logix147]

Omdat in 2009 de markt heel anders in elkaar zat. Zo’n beetje alles wat je aanraakte was Windows. Ook is Windows slechts een OS, geen groot hardware verkoper zoals de rest van de industrie terwijl nu nog geen 10 jaar later we Chrome OS, Mac OS en Linux verdeling kennen. Daarom mag het weer althans van de Euro Commissie dat je eigen browser software installeert op je device.

Om topic; toch knap dat foutief lezen(?) van 1tjes en 0tjes nog steeds een apparaat geheel op hol kan laten slaan. Gelukkig kunnen we tegenwoordig wel reboot en je kan weer verder.

[kevinkrs]

Bij mij herstelde de 'freeze' zich weer naar een aantal minuten. Als je cmd + q drukt voert hij later deze actie uit en sluit hij de tabbladen. Ik heb dit getest op een Macbook Pro 2017 met een i7en 16gb werkgeheugen

Bij een collega van mij met een macbook pro uit late 2013 liep de hele macbook vast en resulteerde zelfs tot een automatische hard reboot.

Hoop dat ze deze bug snel gaan oplossen, beetje irritant om straks allemaal troll sites te hebben

[Aaargh!]

Als het backdrop-filter-effect wordt toegepast op een aantal geneste div-elementen loopt WebKit, de engine van de Safari-browser, vast. Dit komt vermoedelijk doordat backdrop-filter relatief zwaar is om te verwerken, wat vervolgens resulteert in een kernel panic.

Geschreven door iemand zonder enige kennis van zaken ? Valt me tegen van Tweakers.

Dat iets ‘zwaar is om te verwerken’, betekent niet dat het een kernel panic kan veroorzaken. Die twee dingen hebben letterlijk niets met elkaar te maken. Een KP komt door een bug in het kernel of hardware falen, hoe zwaar een systeem belast is doet er niet toe.

Overigens gaat het hier blijkbaar om een respring en niet om een KP.

[Anoniem: 105188]

Dat iets ‘zwaar is om te verwerken’, betekent niet dat het een kernel panic kan veroorzaken.

Met iOS wel. De scheduler gaat helemaal opslot waardoor de WDT niet wordt gerefreshed, dat zorgt dan weer voor een kernel panic met een reboot als gevolg.

[Diamondo25]

Grappig dat een WatchDogTimer een kernel panic veroorzaakt, terwijl het op dat moment al niets meer kan doen dan de CPU resetten.
Of is dit een kernel watchdog aka selfcheck thread? In dat geval zou je nog wel wat kunnen doen...

In ieder geval hebben panic meestal een backtrace, en een watchdog reset helemaal niets. Maar ja, ze hebben zelf de CPU ontworpen dus het zou zo maar kunnen zijn dat ze een externe doch geintegreerde stuk hardware hebben ontwikkeld om deze resets te genereren, die toevallig ook kernel panics zijn?

[johnkeates]

Het is geen WDT reset maar een WDT NMI die tot een reset leidt als de kernel er niks mee doet.

[Anoniem: 105188]

Waarschijnlijk denk jij nog aan een simpele WDT die je kan vinden in een 8051 ofzo. Moderne CPU's beschikken over een WDT Module welke programmeerbaar is en welke meerdere complexe vectoren kan aanroepen.

Als de WDT wordt getript roept hij de panic vector in de kernel aan en die handelt het verder af.

[Aaargh!]

Waarom kan een user-mode process de scheduler ‘op slot’ zetten ? In een OS dat gebruik maakt van preemptive multitasking zou dat niet mogen kunnen. Enige manier waarop ik me kan voorstellen dat dat gebeurt is als een process een call doet naar het kernel die een kernel lock vasthoud, maar in dat geval is het gewoon een kernel bug.

[Anoniem: 105188]

De stelling was dat een "zware verwerking" niet het OS kan laten crashen, de bouw van iOS maakt dat mogelijk. de WDT veroorzaakt een kernel panic.

[Reactie gewijzigd door Anoniem: 105188 op 24 juli 2024 05:27]

[Aaargh!]

Nee, de stelling was dat een kernel panic niet direct door zware verwerking zou moeten kunnen worden veroorzaakt. Als dit wel kan dan is dit een bug in het kernel.

Of anders gezegd: als het kernel correct geïmplementeerd is en bugvrij, dan zou niets wat een user-mode applicatie kan doen een kernel-panic kunnen veroorzaken.

[johnkeates]

Een kernel panic hoeft niet door een fout te komen, en kan ook door een NMI komen, die bijvoorbeeld door een WDT gegenereerd kan worden. Een KP door een NMI is ook 'goed functioneren' van een kernel, als het zo ontworpen is.

[Aaargh!]

Maar niets wat een user-mode applicatie doet zou mogen veroorzaken dat de WDT triggered, dat zou namelijk betekenen dat een user een DoS attack op het systeem kan uitvoeren.

[johnkeates]

Waarom zou dat niet mogen? En sinds wanneer kan een user space thread geen DoS uitvoeren? Dat kan prima. Ik ken eigenlijk geen enkel systeem waarbij je code kan draaien en geen DoS kan uitvoeren.

De meeste half-werkende oplossingen voor dat type probleem zitten in de buurt van beperkingen op CPU cycles, RAM, Swap enz. maar niet echt 'DoS not allowed'. Een muiscursor vastpakken kan bijvoorbeeld in user mode/user space en als je die in een 1x1 pixel vastpakt zonder escape methode heb je effectief ook een DoS. Dat werkt met een toetsenbord overigens ook. In principe is dat dan weer af te vangen door bepaalde toetsencombinaties door het OS af te laten vangen (denk aan ctrl-alt-del, ctrl-alt-bksp, cmd-opt-esc), maar ook daar heb je eigenlijk al de situaties waarbij ring 3 software het gebruik van het systeem onmogelijk gemaakt heeft tot dat je speciale acties onderneemt.

Als je random code kan uitvoeren op een systeem kan je eigenlijk altijd wel het systeem zo belasten of taken laten uitvoeren dat de gebruiker niet meer de dingen kan doen die hij/zij wil doen. Dat was altijd al zo en zal nog wel een tijd zo blijven. Een browser (en dus ook een webview, CEF applicaties enz.) is in feite een stuk software dat random niet-ondertekende software van internet plukt en het uitvoert.

Al die technieken die bedacht worden zijn eigenlijk meer pleisters op het grotere probleem, sandboxing, task management, resource limits enz helpen wel, maar je zal nog steeds op de lijn zitten waarbij je alleen maar exploits die je kent, en exploits die je niet kent hebt; echt veilig of waterdicht is het niet.

Nu zijn veel zaken een beetje algemeen geworden (ring model, NMI, SMM enz zijn x86-specifiek maar ook gemeengoed geworden tot op het punt dat andere non-x86 technologieën met die aanduidingen aangewezen worden terwijl ze wezenlijk anders zijn), maar het probleem dat code uitvoeren van alles kan veroorzaken is er nog steeds.

[Reactie gewijzigd door johnkeates op 24 juli 2024 05:27]

[blorf]

Natuurlijk kan een gebruiker van een consumenten-computer meestal gewoon een scriptje runnen die dermate veel resources opeist dat het hele systeem plat gaat. Maar dan betekent het nog wel dat die gebruiker ook permissies heeft gekregen over apparaten plus een te hoge prioriteit is bij het gebruik van resources door users t.o.v. systeemprocessen.
Een normale gebruiker op een publiek UNIX-achtig systeem gaat dat waarschijnlijk gewoon niet lukken vanwege te weinig mogelijkheden in gebruik van storage, bandbreedte en toegang tot apparaten. Maar ja, als je browser of andere programma's om wat voor reden dan ook meer permissies krijgen dan gebruikers, dan wordt die laatste logischerwijs een gevaar wanneer het gebruikte systeem geen eigendom is.

[Reactie gewijzigd door blorf op 24 juli 2024 05:27]

[johnkeates]

Maakt op zich niet uit, het gaat bij resource exhaustion niet perse om de libraries, het OS of de initiator, maar als je je op bepaalde architectuur richt kan CPU en/of GPU instructie-specifieke code al voldoende zijn.

Een klassiek publiek timesharing UNIX systeem (klassiek a la 1990-2018) kan je prima om zeep helpen door bijv. 10000000 lege bestanden aan te maken per ±128GB disk storage met default FS block sizes, dan kan je puur met inode exhaustion je systeem platleggen. Wat daar tegen helpt is per-user inode limits, of losse mounts. Softlimits en storage quotas werken daar niet bij, en handle limits, chroots, jails en containers met mounts ook niet, want die gaan over size en niet over nodes.

Daar is dan wel weer aan te sleutelen, maar als je je bedenkt dat dit alleen al een enkel aspect is wat in theorie 'simpel' op te lossen zou moeten zijn is het waarschijnlijk al wel een stuk duidelijker dat het erg moeilijk is om te voorkomen dat een user space unprivileged binary een DoS op het lokale systeem veroorzaakt.

Een ander voorbeeld kan zijn dat als je genoeg weet over de GPU die je transformaties gaat uitvoeren, dat je bijv. een shader maakt die op de GPU recursief gaat uitvoeren. Dan kan je met minimale code een gigantische workload veroorzaken. Dan moet je bijna just-in-time statische analyse gaan doen wil je dat voorkomen. Daarom werden/worden veel low-level API's verstopt achter higher level API's en ABI's waar libraries proberen te voorkomen dat dit gebeurt. Dat geldt dus ook voor hardware toegang en bijv. random memory mapped IO toegang voor random systeemadressen; die wil je eigenlijk ook verbannen om dat het een vieze oplossing is die vooral problemen veroorzaakt op systemen waar processen (en gebruikers) moeten samen werken. Dat is ook een van de redenen dat managed code runtimes en sandboxes populair zijn, in plaats van dat je alles crasht crash je in de meeste gevallen alleen jezelf. Maar de 'meeste gevallen' gaat hier ook weer over de gevallen die bekend zijn, niet de gevallen die niet bekend zijn. En stel dat er een miljoen gevallen zijn waarin het mis gaat, en je 8 ton afvangt, dan heb je nog steeds 2 ton gevallen waarin je wel een lokale DoS veroorzaakt.

In het geval van een lokale DoS door lokaal uitgevoerde code (zij het scripts, bytecode, runtime binaries of machine code) maakt het vaak niet uit hoeveel rechten je hebt. Je kan dus ook als gast op een systeem waar je alleen een browser mag gebruiken prima code uitvoeren die het systeem platlegt.

Wat deze WebKit bug + exploit betreft: de CSS filter draait onder water in de browser engine een set grafische transformaties af. Door de transformatie(s) zo op te zetten dat er heel veel resources voor een hele lange tijd nodig zijn kan je dus een (deel van het) systeem platleggen. En stel dat je een GPU plat kan leggen, dan kan een event loop ook niet verder als die synchroon op de GPU zit te wachten, en dan kan je UI niet verder. In principe zou een WDT dan een NMI kunnen aftrappen die SMM code start (SMM is dan weer x86 specifiek, maar ARM based SoCs hebben vast iets vergelijkbaars) die op zijn beurt een NMI handler in het OS kan aftrappen die voorrang heeft boven alles. Zo'n handler kan in het geval van iOS een respring doen (springboard herstart, eigenlijk de hele GUI en alles wat daar op loopt), maar als de handler op een manier opgebouwd is dat er eerst wat inspectie gebeurt voor dat er actie ondernomen wordt kan dat weer te lang duren waardoor de kernel softwarematig een panic start, bijv. onder het mom van 'unhandled NMI'.

[Reactie gewijzigd door johnkeates op 24 juli 2024 05:27]

[Anoniem: 105188]

Het gaat waarschijnlijk om mediaserverd (deamon) welke overloaded is. Deze is redelijk van belang voor het OS en tript daarom de WDT.

[johnkeates]

Lijkt mij eerder een geval com.apple.WebKitContent.

[Aaargh!]

Als je random code kan uitvoeren op een systeem kan je eigenlijk altijd wel het systeem zo belasten of taken laten uitvoeren dat de gebruiker niet meer de dingen kan doen die hij/zij wil doen.

Als user iets doet dat z'n eigen sessie blokkert dan is dat natuurlijk geen DoS attack, da's gewoon een user die binnen z'n eigen sandbox domme dingen doet. Dat mag echter geen invloed hebben op andere gebruiker op hetzelfde systeem.

[johnkeates]

Waarom 'mag' dat niet? Of iets 'mag' of niet kan je in een TO of FO vinden, maar als je de CPU van een derde partij gebruikt die daar lak aan heeft kan je dingen vinden/mogen tot je een ons weegt en de CPU zal nog steeds prima vast lopen.

[Aaargh!]

Waarom 'mag' dat niet?

Omdat het een security risico is ? Het maakt basically een DoS attack mogelijk.

[johnkeates]

Dat maakt nog niet dat het niet 'mag'. Zolang een user zelf kan kiezen arbitraire code te draaien heb je de mogelijkheid een DoS te veroorzaken, zowel met intentie als onbewust door een fout van een derde partij. Dat is de huidige stand van zaken. Bij systemen als Windows RT en iOS is dat wat beter om dat je allee signed code kan draaien en alle scripting code zoals browser code in een sandbox draait, maar ook dat is niet waterdicht.

De afweging tussen bruikbaarheid en veiligheid zorgt er voor dat mensen nog steeds random code van het internet binnen halen en direct uitvoeren (een browser gebruiken dus). Als je vind dat dat niet 'mag' kan je dus geen externe communicatie met je computer toestaan om dat dat alleen al genoeg is om een DoS te triggeren. Maar dan zal je ook een accu in je computer moeten hebben, want de stekker er uit trekken om de stroomvoorziening te onderbreken is ook een DoS.

Het soort absolutisme van 'het mag niet' gaat eigenlijk nooit op. Je moet naar de context en je threat model kijken. Het goed afhandelen van onbekende situaties is een stuk relevanter dan maar hopen dat het goed gaat om dat het niet mag.

[Reactie gewijzigd door johnkeates op 24 juli 2024 05:27]

[Anoniem: 105188]

Dat iets ‘zwaar is om te verwerken’, betekent niet dat het een kernel panic kan veroorzaken.

Dat kan dus wel.

[Aaargh!]

Niet direct. Alleen als het indirect een bug triggered in het kernel. Dan is de KP geen gevolg van de hoge load maar gewoon van een kernel bug.

[Anoniem: 105188]

Dit is geen bug, dit is een feature. De WDT wordt op userspace level gebruikt om apps die hangen op te vangen. Op kernel level wordt het gebruikt om een geheel hangende unit op te vangen.

https://discussions.apple.com/thread/7950577

Een exhaustion aanval is hierboven al uitgelegd.

[Reactie gewijzigd door Anoniem: 105188 op 24 juli 2024 05:27]

[Aaargh!]

De WDT is geen bug, wat wel een bug is dat een userspace applicatie een geheel hangende unit kan veroorzaken. Dat mag gewoon nooit kunnen.

[Anoniem: 105188]

Jah, jij je zin. Het kan niet, het is een bug.

[Aaargh!]

Het kan niet, het is een bug.

Of het kan niet, in welk geval alles werkt zoals het hoort.

Of het kan wel, in welk geval het een bug is.

[Anoniem: 105188]

Ja en die crashdump is ook een bug.

[Aaargh!]

Want crashdumps krijg je normaliter als alles naar behoren werkt

[johnkeates]

Een KP kan je tripleren naar smaak. Dat is gewoon code die wat uitvoert. Dus als je een handler schrijft die triggert als het 12 uur is en dan KP start is dat prima werkende code.

Een bug zou zijn als je USB code schrijf die hot plugging ondersteunt, maar iets verkeerd geschreven hebt en na 2x hotpluggen niet alle registers van de controller goed staan, je kernel daar door foute adresdata krijgt, en door dat adres te lezen of te schrijven in kernel mode een niet-bestaand adres probeert te lezen tijdens zo'n hotplug interrupt. Dan heb je een double fault (om dat het een fault in een interrupt handler is). Dat zorgt er voor dat de CPU de double fault handler probeert in te schakelen wat over het algemeen een panic veroorzaakt. Als die panic niet veroorzaakt zou kunnen worden krijg je een triple fault wat een harde CPU reset zonder melding betekent. En dat is slechts een van de scenario's waarbij je een KP tegen kan komen.

Een KP is eigenlijk niks anders dan 'goede' exception handling. Dat kan door een bug of door een hardware fout afgetrapt worden, maar bijvoorbeeld ook door een audit event die niet goed uit komt (bijv. als dsmos niet positief registreert).

Een andere KP kan zijn als je root device op iSCSI leeft en je de netwerkkabel er uit trekt. Dat is dan geen defect of bug, maar gewoon iemand die dacht dat een kabel lostrekken leuk is.

[lenwar]

Als ik het filmpje bekijk zie ik toch echt een volledige reboot en niet alleen een respring. Er zijn overigens omstandigheden bekend waar userspace processen een kernel panic kan veroorzaken.

Zie hier https://groups.google.com.../HRY5oflBe48/tgnMPZ3vZFQJ
Of https://www.unix.com/hp-ux/54221-boot-failure-init-died.html

Buiten dat is het natuurlijk mogelijk dat er een kernel bug wordt getriggered bij zware belasting onder de juiste omstandigheden.

Edit: typo

[Reactie gewijzigd door lenwar op 24 juli 2024 05:27]

[GekkePrutser]

Hoe zie je in die laatste link dat het om een user-proces gaat? Ik zie daar in de thread vooral het troubleshooten van het boot proces.

Ik gebruik juist die versie van HP-UX (10.20) nog wel eens om nostalgische redenen (HP VUE met name) en ik ben wel benieuwd wat er daar precies gebeurde, maar uit die thread kan ik dat niet echt halen.

[lenwar]

In die laatste gaat het ook om het init proces dat faalt (waardoor er op die versie van HP-UX een kernel panic ontstaat).

Ik denk dat je het kan reproduceren door het init proces af te schieten.

[GekkePrutser]

Ja maar het init proces is geen userland proces. Als dat crasht dan ben je sowieso de sigaar. En het draait als root natuurlijk.

Het zou me niet verbazen als ze dan expres een restart forceren want zonder init loopt alles in de soep. Maar wel raar dat het echt tot een crash leidt ja. Ik zal het hier wel eens proberen!

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:27]

[N8w8]

Misschien is het in HPUX anders, maar iig in Linux/BSD is init wel een userspace (= niet-kernelspace) proces.
Maar idd, init is uitzonderlijk in dat dat zowat het enige userspace proces is dat de kernel "vereist", geen wonder dat dat problemen geeft.

[GekkePrutser]

Dat is waar. Dat is op HP-UX ook zo. Anders kan je het ook niet killen.

Maar ik dacht bij userspace meer aan een eindgebruiker programma zoals een webbrowser, dat die het hele systeem kan laten crashen. Dat init het doet vind ik niet zo heel interessant want als je op het punt komt dat je init kan laten crashen dan is er toch al iets heel erg fout gegaan Wat er in het artikel hierboven gebeurt vind ik een stuk serieuzer.

Maar inderdaad userspace op zich is alles dat als proces draait. Ik haalde twee dingen door elkaar.

[WhatsappHack]

OOM is een dingetje dat ook een kp kan veroorzaken in bepaalde omstandigheden he

[Aaargh!]

Heeft iOS geen OOM-killer? Ik weet dat Linux in zo'n geval begint met het afschieten van user processen.

[WhatsappHack]

Klopt, tot het mis gaat en init niet (tijdig) meer kan syncen. Dan krijg je op Linux ook kans op KP.

iOS heeft een zeer goed geheugenmanagement, redelijk agressief. Webkit gaat echter diep in het systeem en heeft her en der wat voorrang, ik gók dat er met dit probleem simpelweg een race condition ontstaat waardoor de kernel niet anders kan dan panic’en. Verklaart ook waarom apps met wat meer een eigen implementatie vaker een respring veroorzaken ipv KP.

[Christoxz]

Niet bij iedereen is het een respring, bij sommige een volledige reboot

[divvid]

Jup volledige reboot, bijna direct. Dit is echt ernstig. Ik ben benieuwd hoe snel dit wordt opgelost door Apple

[Cerberus_tm]

Geschreven door iemand zonder enige kennis van zaken ?

Als je dit soort soort dingen niet zou zeggen zou je mogelijkerwijs meer mensen overtuigen. Je bent heus niet de enige, hoor, maar een rustige en beleefde toon werkt echt het beste om de redactie van Tweakers toe te spreken, of in welke discussie dan ook. Het zou toch zonde zijn als je gelijk hebt maar hierdoor minder goed overkomt in een discussie.

[Reactie gewijzigd door Cerberus_tm op 24 juli 2024 05:27]

[Aaargh!]

Als je dit soort soort dingen niet zou zeggen zou je mogelijkerwijs meer mensen overtuigen

Het was helemaal niet mijn doel mensen ergens van te overtuigen, alleen om mijn frustratie te uiten.

[Cerberus_tm]

Uiten impliceert dat je je frustratie wilde communiceren. En het geldt in principe voor de meeste vormen en doelen van communicatie.

[Aaargh!]

Communicatie is 2-richtingsverkeer. Dit was bedoelt als 1-richtingsverkeer.

[Cerberus_tm]

Dat is ook communicatie, het overbrengen van een boodschap. En gewoon beleefdheid natuurlijk.

[A4553]

Vraag me vooral af voor welke iOS en MacOs versies dit geldt, of geldt het voor alle versies?

Schijnbaar is dit aan het licht gekomen toen de onderzoeker onderzoek deed naar DoS mogelijkheden in browsers.

[Reactie gewijzigd door A4553 op 24 juli 2024 05:27]

[SupremeRick]

Alles wat CSS 3 ondersteund denk ik zo.

[vdws]

Net geprobeerd op een iPhone 7 met iOS 12 en inderdaad een reboot

[swhnld]

Ga er vanuit in ieder geval de huidige, als het alleen om oudere versies gaat wordt dat over het algemeen gemeld in het bericht.

[CaptainCapslock]

MacOS High Sierra wordt unresponsive, maar loopt niet vast. Uiteindelijk na een minuut de tab kunnen sluiten.

iPhone 8 met iOS 11 resulteert direct in een reboot.

[Reactie gewijzigd door CaptainCapslock op 24 juli 2024 05:27]

[GoT]

Yup, ook een reboot op mijn iPhone SE (van werk )
iOS 11.4.1

[Chopp]

High Sierra 10.13.6 + Safari 11.1.2. Geen reboot wel stevige lagg maar kon Safari gewoon sluiten.

[Reactie gewijzigd door Chopp op 24 juli 2024 05:27]

[Kid_Stevie]

kwaadaardige code

Het is een bestaande css functie en de browser herkent de functie blijkbaar ook, dus hoe kwaadaardig is een dergelijke code dan?

Maar wat ik mij afvraag, waarom crasht de app niet ipv dat de hele telefoon die reboot? Mogen/kunnen apps ongelimiteerd gebruik maken van al de processoren/geheugen/etc?

[Horatius]

Kwaadaardig wordt in dit geval gebruikt als boosdoener en kwaadaardig in de zin van het is geplaatst met een bedoeling om iets te doen.

Webkit zit in iOS ingebouwd, ik denk dat wanneer dat in een loop raakt een deel van het besturingssyteem faalt. Het is meer dan gewoon een app.

[Reactie gewijzigd door Horatius op 24 juli 2024 05:27]

[Dreamvoid]

Blijkbaar inderdaad een kwetsbaarheid in de sandboxing van iOS.

[iamzero456]

Hier geen reboot, maar enkel een respring. Iphone SE 11.4.
In safari gebeurt het direct, in chrome na 2 of 3 keer de link laden (na foutmelding chrome)

Is dat niet ook wat ze bedoelen trouwens? Een hele reboot duurt veel langer, simcode intikken etc.

[Horatius]

Grappig dat chrome anders reageert dan safari, want een browser op iOS is niet heel veel meer dan een skin want ze moeten webkit gebruiken.
En doordat webkit vastloopt door deze css zie ik niet waarom chrome anders zou reageren.

[--Andre--]

Ik ben geen iPhone developer, dus ik heb geen idee hoe dit geïmplementeerd is, maar ik kan me voorstellen dat je de WebKit API aanroept vanuit je applicatie. En onder die aanname kan ik me voorstellen dat verschillende applicaties die deze API aanroepen een net iets andere manier hebben waarop deze API's worden aangeroepen, en net iets anders omgaan met de return values en/of exceptions die vanuit deze API komen.

edit/aanvulling: Hierbij kan het dus ontstaan dat er een vervolgcall wordt gedaan na een gefaalde operatie die tot problemen lijdt. Indien de ene implementatie die vervolgcall wel doet, en de andere hier wel op controleert en deze overslaat.

Een andere mogelijkheid voor verschillend gedrag, indien dit veroorzaakt wordt door een buffer overflow. Als er hierdoor data van de applicatie wordt overschreven, heeft dit dus verschillende effecten.

[Reactie gewijzigd door --Andre-- op 24 juli 2024 05:27]

[batjes]

Wat ik wel weet uit mijn ervaringen is dat als er wat stuk is in webkit, dat het geen soelaas meer biedt om het op Chrome of Firefox te proberen, want het werkt daar dan ook niet. Op 1 of andere manier gaat Safari/Webkit soms stuk bij het doorzetten van cookies naar andere domeinen (tenminste dat is mijn vermoeden) en dan gaat het ook niet werken op andere browsers op iOS. Enige optie is ook het resetten van het device \o/

Geen enkel ander systeem kent dit probleem.

[RobIII]

Chrome en Firefox gebruiken ook webkit; there's your problem. Niks met cookies te maken

[batjes]

In de situatie die ik tegenkom wel. Misschien niet de cookies zelf, maar het mechanisme er van. Centraal systeem wat uit een uitgebreide keten informatie bij elkaar sprokkelt en dit op bijna magische wijze verbind met alle aangesloten partijen. Dit gaat op Trident, Gecko/Quantum en Blink allemaal goed. Maar in Webkit soms niet, en dan werkt het op 1 of andere manier op geen enkele browser op de iPad meer.

Ze gebruiken inderdaad allemaal webkit, jeuj Apple.

[Reactie gewijzigd door batjes op 23 juli 2024 05:07]

[--Andre--]

Bedoel je dat op een iDevice je cookies tussen de verschillende browsers gedeeld worden?

[theblindman]

Mij is verteld dat het hebben van een simpincode in 2018 niet handig is. Als je je telefoon kwijtraakt en hij loopt leeg voordat iemand anders hem heeft gevonden, kun je hem ook niet meer opzoeken in Zoek mijn iPhone totdat de simpincode is ingevoerd.

[GekkePrutser]

Dat is natuurlijk waar, maar als je geen simpin hebt dan kan een dief gewoon de sim er uit trekken en net zo lang naar Nigeriaanse betaalnummers bellen tot je provider denkt dat je nu wel ERG veel kosten hebt gemaakt en de stekker er uit trekt. Providers kennende zal dit lang duren want zij verdienen er ook aan. Tenzij je prepaid hebt want dan kunnen ze alleen je tegoed opmaken.

Inderdaad heb je wel dit probleem als je hem gewoon verliest. Maar ik gok de kans op diefstal een stuk groter (in elk geval hier in Barcelona, veel te veel losse handjes hier)

[Reactie gewijzigd door GekkePrutser op 24 juli 2024 05:27]

[Addict]

Is het niet mogelijk om een apparaat direct te laten crashen op deze manier met het versturen van bijv. een whatsapp bericht?
Hij laadt toch ook (iets van) css in bij het genereren van een preview thumbnail?

Edit: Bij nader inzien denk ik van niet, aangezien het via de browser gaat

[Reactie gewijzigd door Addict op 24 juli 2024 05:27]

[xFeverr]

Nee... de preview gebruikt geen CSS. Zou ook nergens voor nodig zijn...

[jordynegen11]

Iphone X en ios 11.4. Ik kreeg de reboot. Ik merk wel op dat hij niet volledig reboot. Ik hoef namelijk niet opnieuw mijn sim code in te vullen.

Edit: ik lees dat andere ook melding maken van een “respring”

[Reactie gewijzigd door jordynegen11 op 24 juli 2024 05:27]

[Yzord]

X en 11.4 idd een respring. Best flink ook nog, het is meteen aant respringen.

[Kek]

Volle reboot op een iPhone x met iOS 12 GM

[Piemol]

3485 nested divs ....
Misschien zijn er wel meerdere mogelijkheden om een browser / OS te laten crashen dan enkel deze css functie.
Kan mij zo voorstellen dat het (eerder) een combinatie is van het aantal geneste elementen en bepaalde cpu of memory intensieve functies ipv enkel een specifieke css functie.
Zit er nog een maximum aan het aantal geneste html elementen? en aantal attributen per element?