Onderzoeker publiceert 'ernstig' lek in IE8

Een beveiligingsonderzoeker heeft een lek in IE 8 gepubliceerd waarvan Microsoft al sinds 2008 op de hoogte zou zijn, maar dat nog steeds niet is gedicht. Door de kwetsbaarheid kunnen onder andere ongemerkt twitterberichten worden verstuurd.

Microsoft Internet Explorer logo (groot) Chris Evans stelt dat de 'ernstige' bug Internet Explorer 8 gevoelig maakt voor cross-browser cross-domain theft-aanvallen. Daarbij kunnen kwaadwillenden browsersessies overnemen. Als proof of concept heeft Evans een script gemaakt waarmee Twitter-berichten kunnen worden verstuurd als een gebruiker op de twitterdienst is ingelogd. Evans stelt dat vooral gebruikers die klikken op verkorte url's kwetsbaar zijn.

Volgens Evans zijn browsers als Firefox en Chrome al enige tijd resistent tegen de aanvalsmethode. Microsoft zou het beveiligingsgat in IE8, en vermoedelijk ook oudere IE-versies, echter nog steeds niet hebben gedicht, hoewel het vermoedelijk al sinds 2008 van het probleem op de hoogte is. Door de publicatie hoopt de beveiligingsonderzoeker dat Microsoft alsnog met een patch op de proppen komt.

Lees meer

Reacties (110)

RoelRoel
6 september 2010 15:40

Alle negatieve aandacht voor Internet Explorer ben ik als websitebouwer erg blijf mee. Hoe meer gewone consumenten overstappen hoe beter is dit voor de lang in een slop geraakte ontwikkeling van de webtechnologie. Omdat IE 9 alleen op Windows XP gaat werken duurt het nog jaren voordat html5 en css3 gebruikt kunnen worden. Vandaar dat ik liever heb dat mensen overstappen op dit moment.

Anoniem: 346786
@RoelRoel • 6 september 2010 15:58

internet explorer werkt juist niet op windows xp juist net het meest gebruikte OS van de wereld . dus get duurt nog even voordat html 5 echt door de grote massa wordt gebruikt.

slecht dat er zo veel kritische bugs in internet explorer zitten weer een extra reden om naar een concurrent te gaan

keppie3
6 september 2010 14:31

Hoe werkt dat script dan?

elmuerte
@keppie3 • 6 september 2010 14:47

Via CSS wordt een pagina geladen die een submit form heeft (note: een normale HTML pagina en niet een css file). Dit submit form heeft zoals gebruikelijk een security token om er voor te zorgen dat er het form niet vanuit een andere pagina misbruik kant worden. Om deze token uit de html pagina die via CSS geladen is te kunnen halen is er gebruikt gemaakt van een fout in de CSS parser van MSIE. Op de gedownloadde website staat namelijk : {}body{font-family:"
Nu is alles vanaf die locatie als string in de 'font-family' property van de body tag en is het dus mogelijk om alle informatie uit de HTML vanaf die locatie te grijken, dus ook de security token. Vervolgens word er gewoon een cross-site form request uitgevoerd. twitter voert op het laatste geen controle (er is ook geen betrouwbare manier om die controle uit te voeren).

Anoniem: 80466
@elmuerte • 6 september 2010 15:27

Dan moet je dus wel iemand op een arbitraire site met die CSS hack laten klikken terwijl je tegelijkertijd op een andere site bent ingelogd.

kimborntobewild
@Anoniem: 80466 • 6 september 2010 16:55

Nou da's niet bepaald moeilijk... Gewoon 100 sites maken en die op gratis hostingsites plaatsen. Vervolgens de boel volplempen met schaarsgeklede meiden en bijbehorende termen. Succes gegarandeerd...

Anoniem: 80466
@kimborntobewild • 7 september 2010 07:57

IE8 heeft heel effectieve Smartscreen filtering.
Dergelijke sites staan net zo snel in dat filter als dat ze te vinden zijn in een zoekmachine en dan heb je een hoop effort verspild voor niks.

Anoniem: 372347
6 september 2010 14:22

IE 8 zou goed beveiligd moeten zijn terwijl ze een lek van 2 jaar oud nog niet gefixt hebben

mschol
@Anoniem: 372347 • 6 september 2010 14:35

lezen, de "onderzoeker" weet niet eens of microsft wel bekend is met het lek...

(en ja, bewust onderzoeker tussen haakjes, als je niet eens zeker weet of een bedrijf het al weet (m.a.w.: je hebt het zelf nooit aangekaart) en je publiseert een lek, mag je niet jezelf onderzoeker noemen)

joppe.s
@mschol • 6 september 2010 15:38

quote van de website:
"I have been unsuccessful in persuading the vendor to issue a fix." dat impliceert dat hij het wel gebprobeerd heeft... nóg beter lezen dus.

Cronax
@mschol • 6 september 2010 15:55

Dat lees je verkeerd. De onderzoeker heeft het lek persoonlijk herhaaldelijk gemeld, het enige wat nog in twijfel getrokken wordt is of Microsoft al 2 jaar op de hoogte is, of pas later. Als disclaimer om het lek openbaar te maken beroept hij zich immers op het volgende:

"I have been
unsuccessful in persuading the vendor to issue a fix."

Letterlijk:
"Ik ben er niet in geslaagd de fabrikant over te halen het probleem te verhelpen."

Dit soort mensen meldt geregeld bugs en lekken bij fabrikanten van software, ze zijn echt wel zo slim om zich te realiseren dat drie regeltjes ergens op een website niet hetzelfde is als een lek daadwerkelijk melden.

Joostk
6 september 2010 14:19

Dat is toch wel jammer van Microsoft dat ze een bug die al 2 jaar bekend is nog niet gedicht hebben.
En helemaal als andere browers de bug al wel gedicht hebben.

Exorcist
@Joostk • 6 september 2010 14:32

"hoewel het vermoedelijk al sinds 2008 van het probleem op de hoogte is"

Vermoedelijk is niet zeker.

Niemand_Anders

Beveiliging

@Exorcist • 6 september 2010 14:59

Ik kan de bug (ook) niet vinden op Microsoft Connect. Heeft ScaryBeast de mail soms naar devnull@microsoft.nl gestuurt of zo?

There's evidence to suggest that Microsoft has been aware of this since at
least 2008.

Maar die bewijzen noemt de *onderzoeker* dan weer net niet.

Overigens hadden alle vijf de browsers in eind december 2009 (volgens zijn eigen blog) een vergelijkbare bug.

Het probleem heeft gewoon te maken met de cookies welke worden meegezonden met de CSS requests. Op zijn eigen blog staan meerdere varianten van de cross-domain css theft issue.

Wat ik daarnaast mis is of scary beast de bug ook heeft kunnen reproduceren in MSIE 9 welke nu in beta is. Er is een grote kans dat Microsoft meerdere bug fixes terug port als MSIE 9 is gereleased. MSIE 9 wordt door een zeer grote groep testers getest. MSIE 8 en eerdere versies worden niet meer masaal getest waardoor de kans veel groter is dan andere onderdelen (het betreft hier namelijk een beveiligings gat in de HTTP specificatie, welke aangeeft dat cookies moet worden meegestuurd met *ELK* als het path overeenkomt) niet meer werken..

Little Penguin

Browsers

@Niemand_Anders • 6 september 2010 15:50

Het probleem heeft gewoon te maken met de cookies welke worden meegezonden met de CSS requests. Op zijn eigen blog staan meerdere varianten van de cross-domain css theft issue.

Het probleem heeft niets te maken met cookies, het is ook helemaal geen probleem dat deze met CSS-requests meegestuurd worden (als dit niet gebeurt kun je bijvoorbeeld niet meer een op een bepaalde gebruiker toegesneden CSS-bestand terugsturen).

MSIE 8 en eerdere versies worden niet meer masaal getest waardoor de kans veel groter is dan andere onderdelen (het betreft hier namelijk een beveiligings gat in de HTTP specificatie, welke aangeeft dat cookies moet worden meegestuurd met *ELK* als het path overeenkomt) niet meer werken..

Nogmaals, het gaat hier niet om een fout in de HTTP-specificatie. Het is een fout in de CSS-parser, die zo'n beetje alles wat op CSS lijkt in een CSS-tree probeert te stoppen - zeg maar CSS-rule-soup. Onder andere Mozilla hebben die gefixt door het parsen van CSS te annuleren, zodat het niet meer op valide-CSS lijkt.

Dit veiligheidslek is gelijk weer een bewijs dat het niet parsen van CSS als het MIME-type niet klopt de beste oplossing is. Het sniffen van het documenttype is gewoon per definitie fout en is een medeoorzaak van dit lek. Juist het correct volgen van de HTTP-specificatie had dit lek voorkomen en laat het nu net MSIE zijn die het sniffen van het documenttype als 1 van de eerste toegepast heeft.

Verder is dit naar mijn mening, ook gelijk weer het bewijs dat stricte parsers beter zijn dan lenient parsers - als alle browsers (inclusies MSIE) altijd al CSS zeer strict behandeld zouden hebben, dan zou dit lek helemaal niet mogelijk zijn geweest.

roy-t
@Little Penguin • 6 september 2010 17:27

Ja maar MS (en de overige browser makers) deden dit eerst toch omdat anders vele 'hobby' websites niet werken omdat het deaar zo vaak fout gedaan wordt. Je kunt niet op de ene dag van vrij interpreteren naar strict.

Niet dat ik vind dat deze bug niet gefixed moet worden

Cronax
@Niemand_Anders • 6 september 2010 15:49

Sorry hoor, maar deze post vind ik een beetje vreemd. Je hebt gelijk dat hij best mag laten zien wat voor bewijzen hij heeft dat Microsoft al sinds 2008 van de bug weet maar de rest...

Dat meerdere browsers eind 2009 de bug hadden is niet relevant voor de huidige situatie, bijna een jaar later.

Of de bug in de beta van de nieuwe browser te reproduceren is is inderdaad interessant, als ze het nu NOG niet fixen is er iets grondig fout.

Dat je maar gewoon kan wachten tot je een nieuwe versie van je programma uitbrengt met het oplossen van dit soort belangrijke problemen is natuurlijk waanzin. Voor producten die End of Life zijn hoef je het niet op te lossen, alles wat nog onder support valt dient gewoon tegen dit soort gaten bescherld te worden.

Raventhorn
@Niemand_Anders • 6 september 2010 15:59

Overigens hadden alle vijf de browsers in eind december 2009 (volgens zijn eigen blog) een vergelijkbare bug.

Maar zoals ook al in het artikel staat, hebben in ieder geval Firefox en Chrome de bug wel gefixt, terwijl Microsoft deze bug waarschijnlijk al het langste 'kent' en er nog niks mee heeft gedaan.

En het terug porten van bugfixes lijkt mij meer werk dan gewoon een patch maken voor IE8, die uitbrengen en eventueel (deels) gebruiken in IE9... Zeker gezien IE9 nog grondig getest moet worden en nog niet eens helemaal 'af' is.

CH4OS
@Niemand_Anders • 6 september 2010 23:22

Wat ik daarnaast mis is of scary beast de bug ook heeft kunnen reproduceren in MSIE 9 welke nu in beta is. Er is een grote kans dat Microsoft meerdere bug fixes terug port als MSIE 9 is gereleased. MSIE 9 wordt door een zeer grote groep testers getest.

Scary Beast heeft een testcase gepubliceerd; zou zeggen, probeer het en je weet het ook?

Gepetto
@CH4OS • 7 september 2010 13:51

Daarom heet het misschien ook Beta, omdat het nog niet af is. Ik ga er vanuit dat het in de definitieve versie van IE9 gewoon opgelost is.

ameesters
@Exorcist • 6 september 2010 14:41

In an attempt to get this bug fixed...

A nasty vulnerability exists in the latest Internet Explorer 8. I have been
unsuccessful in persuading the vendor to issue a fix.
The bug permits -- for example -- an arbitrary web site to force the victim
to make tweets.

gewoon ff het linkje volgen naar de orginele post
en dan wil ik vooral het volgende benadrukken:
unsuccessful in persuading the vendor to issue a fix.

HotFix
@ameesters • 6 september 2010 14:50

"A nasty vulnerability exists in the latest Internet Explorer 8"

IE8 komt uit 2009

Cronax
@HotFix • 6 september 2010 15:45

Men gebruikt de term "latest" om aan te geven dat de bug bestaat in de versie van het programma inclusief de meest recente updates. Wanneer het uitkwam is dus compleet niet relevant.

Hij zegt hiermee dus dat er wel updates zijn geweest sinds hij het probleem heeft gemeldt, maar dat in geen van die updates iets aan het probleem werd gedaan. Erg kwalijke zaak dus.

Gepetto
@ameesters • 7 september 2010 13:46

"Evans stelt dat vooral gebruikers die klikken op verkorte url's kwetsbaar zijn".

Ik denk dat daar een groter gevaar in schuilt dan in welke browser dan ook.
Verkorte url's maken het kwaadwillende personen met fishing wel heel erg makkelijk.

Dark Angel 58
@Joostk • 6 september 2010 15:02

Exorcist heeft met zijn "vermoedelijk" wel gelijk.

Maar er is misschien nog 1 reden...
het is Microsoft nog niet gelukt om die nasty bug te fixen.

roy-t
@Dark Angel 58 • 6 september 2010 17:28

Het is niet bepaald een moeilijke bug, zoals Little Pinguin hierboven mooi zegt is MS' parser voor CSS gewoon nogsteeds te vrij, deze stricter maken en laten stoppen als er iets niet pluis is, is alles wat er moet gebeuren.

Probleem: websites gemaakt door noobs die hun CSS niet goed gemarkeerd hebben werken dan niet meer goed.

crisp
@roy-t • 6 september 2010 22:02

[...]
Probleem: websites gemaakt door noobs die hun CSS niet goed gemarkeerd hebben werken dan niet meer goed.

De voorgestelde methode (die andere browsers ook toepassen) om dit tegen te gaan is minder strict dan puur een check op mimetype; het moet ook gaan om een CSS-bestand dat wordt geladen van een ander domein, en waarvan het eerste deel al de foutcorrectie in de CSS-parser triggert.

deadeyes
@Joostk • 7 september 2010 11:02

Same old story...

SinergyX

Microsoft

6 september 2010 14:28

Dus eigelijk enkel voor de 'ingelogde twitter IE8 gebruikers' is dit 'gevaarlijk', maar als ik zo de bron bekijk, is het ook twitter die dus een submit-form accepteerd van een externe site?

Little Penguin

Browsers

@SinergyX • 6 september 2010 14:55

Dit proof of concept is gericht op twitter, maar dat wil niet zeggen dat het niet mogelijk is om dit op andere sites (denk aan t.net) toe te passen.

Twitter zou de boel dicht kunnen spijkeren, maar misschien zijn er nog wel andere manieren om berichten te plaatsen - denk aan XMLHttpRequest...

johnbetonschaar
@Little Penguin • 6 september 2010 15:26

In zijn PDF bij het gelinkte artikel geeft hij inderdaad zelfs letterlijke (code) voorbeelden hoe deze bug kan worden gebruikt met Yahoo! Mail, Hotmail en IMDB. Vooral die eerste 2 lijken me toch een teken van een vrij serieus probleem, op het moment dat je valide mailtjes kunt rondsturen via een browser hack ligt de weg naar allerlei vormen van social engineering en aanverwante malware natuurlijk wagenwijd open.

_Thanatos_
@Little Penguin • 6 september 2010 18:40

Gelukkig hebben veel sites inmiddels een captcha... Helaas is dat bijna altijd een extremely-obtrusive-captcha (een moeilijk leesbaar word in plaatje - de audioversies zijn vaak helemaal onverstaanbaar), terwijl er genoeg minder obtrusieve manieren zijn.

[Reactie gewijzigd door _Thanatos_ op 6 september 2010 18:40]

analog_
@SinergyX • 6 september 2010 14:38

Een externe site is voor twitter hetzelfde als een externe gebruiker, HTTP POST blijft HTTP POST. Zolang het structureel en syntactisch overeen komt.

_Thanatos_
@SinergyX • 6 september 2010 14:42

Het is niet de site die de POST uitvoert, maar de browser, en dus de gebruiker. Behalve de referer (waarop je overigens nooit iets mag laten falen) is er dus geen verschil met een POST vanaf twitter zelf.

Anoniem: 265280
6 september 2010 15:54

Ik gebruik zelf Chrome, met plezier. Maar dat terzijde.

Maar ik vraag mij het volgende af:
IE is een gratis programma. Is het dan wel vanzelfsprekend dat we verwachten dat Microsoft of wie dan ook, gaten dicht van (ernstige) lekken.

Als ik jou iets cadeau geef, is het dan vanzelfsprekend dat ik jouw cadeau in lengte van jaren ga onderhouden?

DutchYoda
@Anoniem: 265280 • 6 september 2010 16:13

Je moet het meer zien als een dienst.
En een dienst blijf je meestal ondersteunen totdat je een betere hebt of de gebruiker voor een ander gaat.

ClankStar
@Anoniem: 265280 • 6 september 2010 17:12

Die vergelijking gaat denk ik niet op.

IE is op dit moment gewoon een van de meestegebruikte browsers op dit moment - is het dan niet normaal dat Microsoft, die adverteert met een veilige browser, er voor zorgt dat dit soort lekken worden gedicht? Ik denk van wel.

En ik neem aan dat Microsoft wilt dat IE de meestgebruikte browser blijft. Ik zie geen reden waarom ze dit niet zullen fixen.

kimborntobewild
@Anoniem: 265280 • 6 september 2010 17:18

Als browsermarktleider en als OS-marktleider waarop diezelfde browser eigenlijk zowat verplicht is (althans onderdelen ervan, zelfs als je 't niet gebruikt), heb je toch extra verantwoordelijkheid. Die nemen ze dus lang niet voldoende.

Matthijs Hoekstra
6 september 2010 14:37

Heeft iemand het al getest of dit werkt met IE8? Met IE9 in ieder geval niet.

Mnstrspeed
@Matthijs Hoekstra • 6 september 2010 14:42

Net even getest en het werk in IE8. Chrome dev-channel is veilig (versie 7.x)

Gelukkig maak ik van zowel Twitter als IE8 geen gebruik, dus dat scheelt.

[Reactie gewijzigd door Mnstrspeed op 6 september 2010 14:42]

Cronax
@Mnstrspeed • 6 september 2010 16:01

Je mist even het feit dat dit lek niets met twitter te maken heeft, de onderzoeker heeft twitter alleen maar als voorbeeld genomen omdat het voor veel mensen herkenbaar is, als je de exploit 'droog' uitlegt zal niemand het snappen, maar als je iemand vertelt dat door een bug in IE8 iemand anders berichtjes kan posten op zijn/haar Twitter dan snapt (bijna) iedereen wat er bedoeld wordt.

kimborntobewild
@Cronax • 6 september 2010 17:07

Weet je dat wel zeker - want zelfs veel tweakers hier snappen blijkbaar niet dat Twitter slechts een voorbeeld is, en dat je systeem eigenlijk gewoon helemaal open ligt met IE8. Om maar iets te noemen: i.p.v. twitteren kan de crack evengoed bijv. een keylogger installeren. Als die keylogger dan je paypal wachtwoord leest bijvoorbeeld... Tja vul zelf maar in.

GenomDalar1983
6 september 2010 14:33

Grappig, soms wordt er in een artikel gesproken over een Hacker en soms over een Onderzoeker, laatste klinkt veel netter maar ze zijn eigenlijk hetzelfde...

kimborntobewild
@GenomDalar1983 • 6 september 2010 16:57

Dat komt omdat de term 'hacker' vernield is door aanklagers die 't verschil tussen hacken en cracken niet kenden. Vervolgens werd met hacken steeds vaker cracken bedoeld, waardoor cracken eigenlijk een overbodig woord is geworden (behalve voor de 'insiders').

Anoniem: 319290
6 september 2010 14:35

Dit bericht is geloof ik 2 á 3 weken geleden ook al eens langs gekomen, of dat was een ander lek wat was ontdekt.. Maar ik hoor het de laatste tijd meer, dat er lekken zijn binnen IE, die al voor een lange tijd (denk aan 2 jaar, of langer) aangegeven zijn bij Microsoft, en gewoon nog steeds niks aan gedaan is... Jammerlijk, gelukkig gebruik ik zelf Firefox!

Anoniem: 88197
6 september 2010 14:42

Hier werkt het wel hoor.
In Firefox inderdaad een forbidden.

1 2 3 Volgende

Op dit item kan niet meer gereageerd worden.

Onderzoeker publiceert 'ernstig' lek in IE8

Lees meer

Reacties (110)

Sorteer op:

Weergave:

Tweakers maakt gebruik van cookies

Toestemming beheren

Functioneel en analytisch

Relevantere advertenties

Ingesloten content van derden