Notepad-popups mogelijk met Internet Explorer

Op 4 augustus 2003 heeft Richard M. Smith een Advisory Report online gezet, waarin hij melding maakt van een lek in Internet Explorer. Via dit lek kunnen automatisch popups geopend worden in Notepad. In deze popups kan de broncode geladen worden van een willekeurige site. Het is echter ook mogelijk om op deze manier een bestand te openen op de computer waar de pagina wordt uitgevoerd. Om het bestand automatisch te openen, wordt gebruikgemaakt van de src-eigenschap van de <img>-tag. Hierin wordt het volgende neergezet: src="view-source:pad_naar_bestand". Er wordt dus niet gebruikgemaakt van JavaScript of een andere scripttaal om het bestand te openen.

view-source:file:///c:\windows\win.ini

Volgens Smith is dit echter geen groot lek, het is namelijk niet mogelijk om bewust bepaalde dingen te veranderen door het openen van een popup. Hij legt echter de nadruk op het gevaar dat onwetende gebruikers het bestand in de geopende popup aanpassen en bewaren. Hierdoor zou het systeem weldegelijk beschadigd kunnen worden. Ook is het mogelijk de computer voor het moment onbruikbaar te maken door een aantal grote bestanden te openen, hierdoor loopt het geheugen vol. Ook is het mogelijk om het lek te gebruiken voor ongewilde popups met reclame erin. Thor Larhol, medewerker van het PivX Research Labs, zet het lek in een bredere context. Volgens hem opent Internet Explorer meerdere bestandstypen automatisch en kunnen daardoor ook andere ongewilde acties uitgevoerd worden:

Thor Larholm, Entdecker mehrerer Bugs im Internet Explorer und Mitbetreiber der PivX Research Labs stellt das Problem in einen größeren Zusammenhang. In einer Antwort an Smith weist er darauf hin, dass der Internet Explorer auch andere Dateitypen automatisch und ohne Nachfrage mit der dafür zuständigen Applikation öffnet. Dazu gehören unter anderem MIDI- und ASF-Dateien.

Ob der Internet Explorer Dateien automatisch und ohne Nachfrage öffnet, hängt von dessen MIME-Typ und dem für diesen in der Registry gesetzten EditFlag ab. Dieses Flag legt unter anderem fest, ob für Dateien dieses Typs ein Speichern/Öffnen-Dialog angezeigt wird. Wie man das EditFlag setzt oder löscht wird auf den Seiten von cpcug.org beschrieben.

Reacties (75)

Ok, in navolging van iedereen die zegt : WAA wat een lek :

Nog een aantal 'lekken' die nog destructiever zijn:
- embed een wav file van 500 Mb...(duurt wel ff voor die ingeladen is!)
- zet de background naar een 50 Mb JPG (duurt wel ff voor die ingeladen is!)
- gebruik 500 iframes in 1 pagina die allemaal naar dezelfde pagina verwijzen die naar zichzelf refreshed in 0 seconde
- etc etc etc

Zo kun je ALLE dingen die je cpu op kunnen vreten een lek noemen.... pffff...

Is het pop-up feature trouwens überhaupt niet een lek ?! (D'r wordt behoorlijk gebruik van gemaakt, maar vooral misbruik....)

Het enige echte risico is dat belangrijke systeembestanden geopend worden, en geedit worden door de gebruiker.
De oplossing daarvoor ligt niet zozeer bij IE, maar bij het OS, waarbij readonly rechten voor de user op de belangrijke bestanden gezet moeten worden by default...
Dat ligt _ook_ bij de gebruiker, want die moet zo slim zijn om niet altijd als Administrator te werken...

De 'onnozele' gebruiker is zelfs in gevaar door het Belgische Nimda virus (e.g. stuur deze mail door aan al je vrienden, en formateer daarna je harde schijf), en door alle hoaxes die rondwaren...
En dat lek is actief in Eudora/Outlook/Evolution etc.

Ergo : de gebruiker is het grootste lek

Dat zijn geen lekken die je noemt, maar misbruik van normale functionaliteit...

Een wave file embedden van 100Kb vind ik ook irritant (ik vind iedere ge-embedde geluidsfile irritant ), maar dat is geen probleem. Als jij zo 'dom' bent om dat met een file van 500Mb te doen...

Background van 50Mb geldt hetzelfde voor.

Je kunt daarvan hooguit zeggen dat een browser de filesize kan opvragen, maar ja, waar leg je dan de grens. Is 1Mb ok, maar 1,01 Mb niet meer? Of pas op 10Mb, pc's hebben tegenwoordig tenslotte wat meer geheugen...

iframes op die manier misbruiken zou een browser wel kunnen afvangen, maar dat is dan geen lek, maar niet 'voldoende doorontwikkelde functionaliteit' of zo. Of een bug hoe je het wilt noemen, maar niet zozeer een lek.

Popups zijn ook geen bug, dat is normale functionaliteit die gewoon standaard is (nog ff en target="_blank" noem je ook een lek...). Die idd helaas vaak misbruikt wordt, en daardoor zijn de laatste jaren popup killers zo populair De reactie hier type je trouwens ook in een popup...

Imho is dit probleem wat hier wordt beschreven gewoon een security bug. Wat er ook lokaal wordt opgevraagt, en in welke vorm dan ook, als dat gebeurt op een pagina die niet lokaal is geopend (http:// dus), _mag_ dat gewoon nooit worden toegestaan. (of het wel mag vanaf een html op je desktop die je opent door er dubbel op te klikken) valt over te discusseren maar vanaf een website wat mij betreft nooit.

Het enige echte risico is dat belangrijke systeembestanden geopend worden, en geedit worden door de gebruiker.
De oplossing daarvoor ligt niet zozeer bij IE, maar bij het OS, waarbij readonly rechten voor de user op de belangrijke bestanden gezet moeten worden by default...

Dat voorkomt idd dat de gebruiker wijzigingen kan opslaan, maar waarom (even on topic...) is het de gebruiker zijn probleem dat IE het toestaat om vanaf een website een lokale file te laten openen? Imho is dat sowieso al een slechte zaak. Systeembestanden read-only is een ander 'probleem' wat dieper gaat dan deze bug/lek.

god, nog meer reclame

Kan MS gewoon niet die hele file:// uit zetten in IE. dan maar wat minder functionaliteit.

je klinkt me als een persoon die alleen text-only browsed, al die overbodige functionaliteit....

Alles maar in je RAM cachen dan?

En de windows explorer dan? Is dat niet ook half IE?

Nee. Da's helemaal IE

wil jij dan ff onze intranetapplicatie herschrijven die nogal intensief hiervan gebruik maakt... het is nu eenmaal een functie die aanwezig is, geen lek, zie mijn volgende post

Er zou wel een setting kunnen zijn om dit aan/uit te zetten (en die default uit staat)

dan kan jij op je intranet die aanzetten voor je prog omdat je het hard nodig hebt bv

naa, zal ik eerste stevig aan C en C++ moeten leren enzo
Maar zeg zelf, wordt je niet van al die "bugs" ?

Functionaliteit is leuk enzo maar ik als gebruiker zit er niet echt op te wachten dat websites dingen op mijn pc kunnen aanspreken.

ik ga me voor de rest niet druk over maken ben toch van plan om over te stappen naar linux.

Tja, en straks staat hierboven een nieuwspost met het bericht dat er een lek in Internet Explorer zit waarmee reclameboodschappen in MP3 verspreid kunnen worden....

Dit is een functie, geen bug.

het is trouwens perfect mogelijk te zorgen dat dit niet meer mogelijk is, in tegenstelling tot bugs/lekken waarbij je op een patch van MS moet wachten

9 kansen op de 10 draait dit weer uit op een flame tgo MS / IE...
EDIT: 'k vind het jammer dat Tweakers met dergelijke nieuwsberichten die tot niets anders dienen dan het uitlokken van veel reacties zijn nivo naar beneden haalt, wat overigens voor de rest zeer hoog is

offtopic:
Dat lijkt mij overdreven.

[quote]
9 kansen op de 10 draait dit weer uit op een flame tgo MS / IE...
[/quote]
1. Flames worden meestal weg-gemodereerd door gebruikers

[quote]
'k vind het jammer dat Tweakers met dergelijke nieuwsberichten die tot niets anders dienen dan het uitlokken van veel reacties
[/quote]
2. Onzinnig, het gaat om een mogelijkheid die IE biedt, maar die eventueel gebruikt zou kunnen worden voor andere doeleinden

[quote]
nivo naar beneden haalt, wat overigens voor de rest zeer hoog is
[/quote]
3. Dat slaat ook nergens op, het is een prima objectief stukje van Harm. Tweakers maakt ook melding van bugs in andere browsers. Er is dus geen sprake van (extra beschadiging) van Microsoft, laat staan van opzet om Microsoft te beschadigen.
[quote]
wil jij dan ff onze intranetapplicatie herschrijven die nogal intensief hiervan gebruik maakt...
[/quote]

Ik wil niet vervelend doen, maar jullie ondersteunen maar één browser? Lekker ontworpen

ontopic:
Ik ben het met je eens dat deze "mogelijkheid" van IE waarschijnlijk niet zo snel zal worden uitgebuit. Desondanks kan het geen kwaad om er nog even kritisch naar te kijken.

k wil niet vervelend doen, maar jullie ondersteunen maar één browser?

En dat is wel een browser die door 95.4% van de markt wordt gebruikt. Dus waarom voor die 4% enorm veel moeite doen om een website/applicatie geschikt te maken voor 3 browsers?

Richting blouweKip

Kwestie van gewoon goede code opleveren, iets wat ik ook zou willen als men iets ontwikkeld voor alleen IE (vaak wordt dat laatste echter als excuus aangevoerd vanwege het ontbreken van de kennis bij de developers)

Er bestaat een spreekwoord "de beste stuurlui...."

Je moet niet zo dom blaaten, door het te gooien op gebrek aan kennis bij de developers, je zet jezelf daarmee gewoon voor schut.

Bij professionele developers is de kennis wel aanwezig, alleen is de klant altijd degene die bepaalt wat hij wilt ontvangen voor zijn geld, en niet de developer. Sterker nog, de uiteindelijk beslissingen liggen nog altijd bij het management, en niet bij developers.

Er zijn genoeg features die Msie only zijn, en dagelijks worden gewaardeerd. Features die zelf doen besluiten tot het achterwege laten van crossbrowser support zoals bijv. contentEditable velden, die enorm veel gebruikt worden, en waarvoor nog geen enkele andere browser een vergelijkende oplossing heeft die zich kan meten met deze feature.

Zo is er op de Mac nog steeds geen XML support. Dat alleen zou al een belangrijke reden kunnen zijn om een interface met een on demand treeview puur alleen voor Msie geschikt te maken.

Verder speelt ook altijd geld mee. De meeste professioneel ontwikkelde websites zijn aan de presentatiekant afdoende crossbrowser. Achterkanten zie je vaak Msie only (welke Account Manager, Marketing Manager zie jij werken met FireBird op de werkvloer?) en het is vaak bekijken wat de investering oplevert voor het ondersteunen van minder als 4% aan exotische browsers.

@Little Penguin

Grappig dat somige browsers *cough* mozilla *cough* ook niet altijd 100% omgaan met de standaard... (misschien nu opgelost, maar er waren eerst wel degelijk problemen)

Ik heb aan behoorlijk wat websites gewerkt... En het grootste probleem is niet invalide html... Maar dat elke browser het net even anders op het beeld tovert... Zelfs verschillende versies van dezelfde browser hebben daar last van (maar vaak is dat een klein iets wat makkelijk op te lossen is)...

Die display problemen kosten een klant *erg* veel geld om op te lossen en nog meer test tijd... En is het dus de beslissing van een klant om alleen IE support te geven snel gemaakt...

Kwestie van gewoon goede code opleveren, iets wat ik ook zou willen als men iets ontwikkeld voor alleen IE (vaak wordt dat laatste echter als excuus aangevoerd vanwege het ontbreken van de kennis bij de developers)

zoals hij al zei, het gaat niet om het marktaandeel van IE maar over de meerprijs van het compatible maken van een site voor andere browsers. Alles pixelperfect in elke browser krijgen kost tijd, tijd kost geld en een klant heeft dat er erg vaak niet voor over.

En kom niet aan met de kwaliteiten van een developer, dat als hij goede code oplevert dat meteen compatible is met alle browsers want dan heb jij nog niet een gedesignde site afgeleverd

Gordijnstok:

En jij hebt het nu over sites die nog minder dan 4% uitmaken van het web/intranet.

Vind ik nog steeds geen reden om slechte html (Lees: niet valide) te schrijven.

@Gordijnstok:
Ik zal niet ontkennen dat de diverse browsers bepaalde features hebben die de concurrentie niet heeft. Maar dat geld voor alle browsers!

Het is echter altijd verstandig om zo veel mogelijk de standaarden (HTML/CSS/DOM) te volgen, ook al vraagt de klant om IE support. Uiteraard zul je dan voor IE (of Mozilla) specifieke features een uitzondering moeten maken.

Zeker voor een internet site is dat belangrijk omdat je nu eenmaal geen controle over de browser van de gebruikers hebt.

sab.loempia.com

Oh jawel, af en toe is het gewoon nodig om slechte html te schrijven. Ik noem een voorbeeld, de immer missende (werkende!) ondersteuning van vertical-align in msie. Of de renderbugs die optreden bij gebruik van images in een span (waarbij de image over de span heenvalt).

Doet overigens niet af, aan mijn betoog, over waarom er voor bepaalde browsers simpelweg niet ontwikkeld wordt.

Even iets rechtzetten:

Firbebird / Mozilla heeft contentEditable velden, veel
cleaner dan MSIE met dat MSHTML

Mac geen XML? Wat is dat voor onzin?

@Da_Teach.

Grappig dat somige browsers *cough* mozilla *cough* ook niet altijd 100% omgaan met de standaard...

Reken jij dan W3C of IE tot de standaard? Ik ben in het gebruik
van Mozilla nog nooit tegengekomen dat deze van de standaard afweek die door het W3C is vastgelegd. Tenminste voor zover men niet NS4 probeerte te emuleren in de zogenaamde 'Quirks' mode.

Overigens hoeft een klant helemaal niet te weten dat jij op Mozilla ontwikkeld. Door altijd een laatste controle op IE te doen zie je al snel genoeg of het wel of niet goed is. - Overigens is het wel zo dat IE (ook versie 6) CSS1/2 nog steeds niet volledig beheerst...

En altijd (tenzij het om een specifieke feature van de gebruikte browser gaat) de pagina opzetten volgens de W3C standaarden. Daar heb je uiteindelijk (dus ook over een paar jaar) meer plezier van dan nu alleen maar te testen op IE.

Alles pixelperfect in elke browser krijgen kost tijd, tijd kost geld en een klant heeft dat er erg vaak niet voor over.

Dat boeit ook niet. Als een site in ieder geval _werkt_ in andere browsers is dat al heel wat (en dus niet van die www.mp3shopper.nl code)

k wil niet vervelend doen, maar jullie ondersteunen maar één browser?

En dat is wel een browser die door 95.4% van de markt wordt gebruikt. Dus waarom voor die 4% enorm veel moeite doen om een website/applicatie geschikt te maken voor 3 browsers?

Je gewoon aan de W3C standaarden houden. btw als je wel de klok hebt horen luiden maar niet weet waar de klepel hangt dan kun je beter niet meer reageren.

Ik wil niet vervelend doen, maar jullie ondersteunen maar één browser? Lekker ontworpen

Het gaat om een INTRAnet applicatie, waarom zouden we rekening met netscape en consoorten gaan houden als die in het bedrijf nergens geinstalleerd zijn?

heel ff off-topic:

Dat slaat ook nergens op, het is een prima objectief stukje van Harm

Ik zeg ook niet dat het subjectief is. Ik zeg alleen dat ik naast de zeer kwalitatieve nieuwsposts hier, soms dingen zie opduiken waarvan ik me afvraag wat nu de eigenlijke nieuwswaarde is hiervan. Meestal gaat het dan om onderwerpen die gegarandeerd heel wat reacties opleveren, dat het meestal MS related is, heb ik express niet vermeld, daar gaat het ook niet om.

off-topic-reactie-op-off-topic-flame

ik heb zelf niets met de ontwikkeling en beheer van het intranet te maken, maar hoe ga je via streaming verwijzen naar een document op een share, dat eventueel moet aangepast kunnen worden?

dat zie ik nog niet direct gebeuren, dat je een Word-file via http opent, en er zomaar ff iets in aanpast en opslaat...

is mogelijk; noemen ze webdav....mooie technologie

lol, je zou es moeten weten hoeveel hacks daarop zitten... erger dan file:// bugjes die alleen maar op de clients effect hebben, via webdav loopt heel je server gevaar

Als ik dat orginele bericht lees, en het goed begrijp, met een lek dat zo direkt met functionaliteit / de mogelijkheden van de windows verkenner verband houdt, dan zie ik toch weer duidelijk het nut / het voordeel van een losse browser (eentje die niet geintegreerd is in je besturingssysteem).

(in navolging van het mooie plaatje voor je website powered by notepad kunnen we dus in de toekomst een plaatje infected by notepad verwachten? :d)

Het is een slordige veiligheids-fout imho.

Het is imho niet erg dat een browser file:// ondersteunt, alleen niet als dat wordt gebruikt in een niet-lokale (html)file.

Als je file:///c:\windows\win.ini in je adresbalk zet (en je ramt op enter...) opent notepad. Zet je dat in een link in een lokale test.html, is het een download-link en opent ie niet automatisch (vraag of je wilt downloaden of openen)).

Als je file:///c:\windows\win.ini in de Mozilla Firebird adresbalk zet, toont ie 'gewoon' de ini file. Alleen doet Mozilla niks met view-source:. En Mozilla checkt dus wel of de verwijzing op een pagina van een site staat, of lokaal. Als je lokaal een test.html aanmaakt met een link naar de win.ini is dat prima. Alleen zodra die html vanaf http:// komt ben je niet meer lokaal bezig, en dan krijg je een security error (zoals Asylum al zei hierboven).

Als ik het me goed herinner (geen zin om na te zoeken...) heeft IE al vaker last gehad van beveiligingslekken, dat een html file als lokaal werd gezien (want stond in de temp inetfiles, en dat is lokaal...) terwijl die van een website kwam. Het zal me niks verbazen als dit ook zoiets is (al is dat natuurlijk puur gokwerk).
Het is imho dan ook niet zozeer een bug in de "windows verkenner" functionaliteit, maar in een controle waar vandaan iets wordt opgevraagt.

ASCII art

kleine bug maar kan enorm irritant zijn, link naar een iso file op een random server en die notepad loopt vast, met een beetje pech kan je hem niet sluiten en neemt hij explorer mee.

Of je opent een 1000tal van deze bestanden met een js loopje ... manieren genoeg om dit te misbruiken. En dat het kan is gewoon erg, eigenlijk moet wat het src attribuut is gecontroleerd worden op de browser op het correcte mime-type zodat zo'n dingen heel wat moeilijker worden.

kleine bug maar kan enorm irritant zijn, link naar een iso file op een random server en die notepad loopt vast, met een beetje pech kan je hem niet sluiten en neemt hij explorer mee.

Op wat van sites kom jij dan waar dit zou gebeuren ?? Op "normale" sites zul je dit niet aantreffen.

Is http://www.linuxiso.org/ geen "normale" site dan?

mijn windows staat op D
Voor de rest vind ik dit niet echt een bug

[url="view-source:file://%windir%/win.ini"]view-source:file://%windir%/win.ini[/url]
[url="view-source:file://%20localhost/admin$/win.ini"]view-source:file://%20localhost/admin$/win.ini[/url]
/edit
Euhm . variabele werkt niet denk ik.
Wie kan er de spatie uit de onderste URL halen terwijl dan wel de 2e slash blijft ?

Deze werkt wel !! (WindowsXP)
[url="view-source:file://%3127.0.0.1/admin$/win.ini"]view-source:file://%3127.0.0.1/admin$/win.ini[/url]

Microsoft popup
[url="view-source:file://%3127.0.0.1/admin$/System32\Eula.txt"]view-source:file://%3127.0.0.1/admin$/System32/Eula.txt[/url]

Via de admin$-share werkt het natuurlijk alleen maar als je daar toegang toe hebt. Op een goed geconfigureerde (bedrijfs)PC zal dat hopelijk niet het geval zijn.

Helaas heeft een "gewone" user onder XP administrator-rechten en kan dus wel de administrative share gebruiken.

En dan probeer je de link uit met Mozilla Firebird browser

Bugfix kun je hier halen:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.4/mozilla-win32-1 .4-installer.exe

Ik wil niet lullig doen hoor, maar mijn nieuwste Firebird (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030803 Mozilla Firebird/0.6.1) opent ook gewoon bestanden hoor !!!
Wat is dit toch een nieuws zeg! je kunt er weinig mee! Mozilla open zelfs viewsource:javascript:blaaterdeblaat (bug already filed offcource )

ik vind dit eigenlijk maar niets.

Banners: OK;
popups: word wat minder;
Notepad (of iets anders) voor reclame: kan echt niet.

Ik ben een gelukkig gebruiker van Firebird win32 en ik ben er nu van overtuigd dat ik IE alleen nog maar gebruik voor windowsupdate.

dat klopt dus niet wat je zegt,
"Notepad (of iets anders) voor reclame: kan echt niet. "
dit scriptje laat je notepad openen met een bestandje op je hd, dus niet een bestandje.
tenzij je die notpad link naar een server kunt sturen waar een txtje op staat ach . het kan allemaal .. en het zal wel

tenzij je die notpad link naar een server kunt sturen waar een txtje

Dat kan ook, [url="view-source:http://www.tweakers.net/"]probeer deze link maar eens in IE aan te klikken[/url]

Overigens is het wel zo dat ook in Mozilla de source van het bestand getoond wordt. Alleen wordt deze niet in een apart programma cq venster geopend EN is deze niet te editten....

Edit: Na het goed doorlezen van alle reacties zag ik dat Mozilla de popup van lokale bestanden WEL tegenhoudt. Toch weer een pluspunt voor Mozilla tov IE. Alleen jammer dat de meeste mensen dit niet zien...

phat krijgen we dadelijk ascii-art popups van porno dat wordt nog lachuh

Zie je zo een animatie, hoor je opeens 'Ooh ja, ja, JA!'

Ik vind dit geen bug, het zit gewoon in de verkenner.
Je kan de bestanden toch alleen maar openen, niet aanpassen.
Hopen dat in Longhorn op de systeembestanden een beveiliging zet, zodat je alleen via een speciale account (niet via de Administrator account, maar via een andere admin account dus) die bestanden aan kunt passen.
Met 'die bestanden' bedoel ik dus win.ini, system.ini, boot.ini en nog wat van die bestanden.

in Win XP home edition kan de hoofd-gebruiker ze dus wel wijzigen, want die is administrator (al zal de gemiddelde thuisgebruiker dat niet eens weten). Het is dus zeker wel een probleem voor een meerderheid van de gebruikers.

Ik heb Microsoft er al een half jaar geleden over gemaild dat dit mogelijk was, inclusief img src = mailto:email@host en src = telnet:lol maar nooit een reactie gehad.

Misschien hebben ze dit wel gelezen maar houden ze de eer aan zichzelf en aan de developers. Doen ze wel vaker...