Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 144 reacties

Microsoft heeft toegegeven dat een gevaarlijk beveiligingslek niet alleen in Internet Explorer 7 voorkomt, maar in vrijwel alle versies van zijn browser. Kwaadwillenden misbruiken inmiddels de bug om malware te installeren.

Het lek kwam vorige week onverwacht bovendrijven, toen een team van Chinese beveiligingsonderzoekers per ongeluk code publiceerde waarmee Internet Explorer 7 kan worden aangevallen. De exploit zou al sinds november op de zwarte markten tegen betaling verkrijgbaar zijn. Daarbij zouden bedragen tot 15.000 dollar zijn geboden.

De kwetsbaarheid wordt veroorzaakt door een fout in de zogeheten data binding-functionaliteit van Internet Explorer, en niet zoals eerder werd gedacht in de rendering van xml-tags. Door de bug ontstaat een heap-overflow, waardoor kwaadaardige code gestart kan worden. Met behulp van javascript installeren aanvallers aanvullende downloadcode. Vervolgens kan de aanvaller malware naar het getroffen systeem overhevelen.

Aanvankelijk werd de exploit op relatief bescheiden schaal gebruikt om inloggevens van Chinese gamers te stelen, maar inmiddels duikt de aanvalscode op steeds meer plekken op. Hackers maken daarbij onder andere gebruik van sql-injecties, waardoor ook ogenschijnlijk veilige websites de gebruiker ongemerkt kunnen besmetten met malware.

Microsoft heeft inmiddels in een revised security report laten weten dat niet alleen Internet Explorer 7 kwetsbaar is, maar ook IE5.01, IE6 en IE8 bèta 2 het lek hebben. De gebruikte Windows-versie speelt verder geen rol. Aangezien de bug nog niet met een update is verholpen, stelt Microsoft een aantal noodoplossingen voor. Zo kan de dep-beveiliging in IE7 ingeschakeld worden. Ook kan active scripting in IE worden uitgeschakeld of toegang tot oledb32.dll worden ontzegd. Beveiligingsbedrijf Secunia laat echter weten dat uitsluitend de laatste maatregel effectief is en de eindgebruiker voorlopig beter kan uitwijken naar een alternatieve browser. Of Microsoft met een tussentijdse patch uitkomt om het gat te dichten, is nog onbekend.

Moderatie-faq Wijzig weergave

Reacties (144)

Dit is al de zoveelste - dit keer is het IE op Windows, maar eerder al Chrome, Firefox, Safari, Opera op Linux, OS X, Solaris. De ene keer is het JavaScript, de andere keer de jpeg library, de volgende keer SSH, het houdt niet op. Maar elke keer wel weer hetzelfde concept: een heap of stack overflow waardoor de aanvaller dwars door de user rechten structuur heen banjert richting geheugenruimte met admin/root rechten.

Misschien moeten we maar eens stoppen met het schrijven van browsers in unmanaged code. Maar ja, dan ga je letterlijk weer vanaf nul beginnen met coden en heb je de komende 7, 8 jaar geen bruikbare browser...

[Reactie gewijzigd door Dreamvoid op 13 december 2008 19:46]

Wat ook alle problemen zou oplossen is het verbieden van het uitvoeren van heap of stack data (volle hardwarematige DEP). De plugins (java, flash) en mogelijk de javascript-interpreter zouden daarvoor echter herschreven moeten worden en aangezien dat veel tijd en moeite kost, gebeurt het niet.

Het zou het beste zijn als elk java/flash applet in een apart proces zou draaien met minimale rechten, waarin de heap en stack wel uitgevoerd zouden kunnen voeren. Daar zie je Google naartoe gaan met Chrome, maar ik geloof dat Chrome hardwarematige DEP nog niet aan heeft staan.

Echter, in Amerika is er alweer iemand die heeft uitgevonden dat je al bestaande code zonder additionele code nog steeds Turing complete is. Met de goede data zou een aanvaller dus alsnog willekeurige code kunnen uitvoeren, maar dat is in ieder geval veel moeilijker dan het nu is.

Het probleem met managed code is dat er alsnog een bug in de virtual machine zou kunnen zitten, waardoor er alsnog code zou kunnen worden uitgevoerd.
Maar elke keer wel weer hetzelfde concept: een heap of stack overflow waardoor de aanvaller dwars door de user rechten structuur heen banjert richting geheugenruimte met admin/root rechten.
Alleen als het betreffende proces admin/root rechten heeft. En les 1 in het dichttimmeren van je computer is dat dat nooit het geval mag zijn.
Misschien moeten we maar eens stoppen met het schrijven van browsers in unmanaged code.
En zelfs dan nog is het mogelijk om code te schrijven die vatbaar is voor lekken. Zo'n goed idee is het nu ook weer niet - zeker als je bedenkt dat je zo weer 4+ jaar bezig bent met implementatie, zoals je zelf al aangeeft.

Overigens is veel van de UI van Firefox in managed code geschreven, omdat de UI gebruik maakt van JavaScript en XUL. Het render-process is overigens wel weer native code...
Da's mooi voor het marketing verhaal maar al die gevaarlijke remote code op webpagina's wordt niet door het UI framework uitgevoerd, dat doet die native renderer.

Managed code is inderdaad ook maar 1 stap - dat zou ook nog eens verifiable code moeten zijn. Dan ben je van het hele overflow probleem af. Maar ja, dan krijg je weer bakken met social engineering malware. It will never stop...

[Reactie gewijzigd door Dreamvoid op 14 december 2008 00:14]

DEP stel je (voor alle programma's) in door met de rechtermuisknop op "Mijn computer" te klikken en dan in het contextmenu op "eigenschappen" te klikken. Ga daar naar tab "geavanceerd". Klik daar op "prestaties", en klik dan op tab "Data Execution Prevention". Er staan 2 keuzerondjes, klik de tweede aan: "Schakel DEP in voor alle programma's en services, behalve...". Dit is vertaald van de WinXP64bit Engelse versie, dus misschien heb ik niet de juiste woorden gebruikt.
Dit zou moeten zijn wat MS voorstelt, al is de tekst die in het artikel hier staat...
Zo kan de dep-beveiliging in IE7 ingeschakeld worden.
... niet echt helder. Die zegt alsof het in te stellen is via Internet Explorer 7, maar ik ben die optie daar nog niet tegengekomen.

Als bekende programma's of services gaan klagen of niet meer werken, voeg dan het programma toe op hetzelfde scherm als waar je DEP voor alle programma's en services instelde.

[Reactie gewijzigd door Grrmbl op 13 december 2008 14:55]

Er wordt in die zin eigenlijk naar Protected Mode verwezen, dit is de DEP-modus van IE.
Hm, even gezocht naar je uitleg. Maar ik kom geen artikel tegen dat je antwoord staaft. Wat het is waarom ik het niet zie, is omdat die optie in IE7 alleen voor Vista gebruikers is te zien. En met protected mode alleen ben je er dus nog niet.
Hier kun je lezen hoe je IE de toegang tot oledb32.dll ontzegt
<vleugje offtopic>

"Door de bug ontstaat een heap-overflow, waardoor kwaadaardige code gestart kan worden"

hoe is dat eigenlijk mogelijk, technisch gezien? ik verwacht bij iets als een 'overflow' eerder een crash ofzo :p
Ondanks dat je vraag (een vleugje) offtopic is, is het toch wel een interessant verhaal. De precieze gegevens heb ik (nog) niet bekeken van deze bug, maar over het algemeen komt het neer op het volgende.

Je hebt je geheugen, dit geheugen wordt ingedeeld in stukken (pages / stacks) en daarin wordt data opgeslagen. In managed code (vb. C#) kan je direct hiernaartoe schrijven, omdat de bijbehorende libraries (in de virtuele machine) voor de juiste addressering zorgen.

Bij unmanaged code moet je echter helemaal zelf de ruimte aanroepen waar je het wilt opslaan. In je programma kan dit heel eenvoudig een stukje tekst zijn dat je opslaat in een 'string' / 'charater' variabele. Met andere woorden je registreerd een stukje ruimte en stopt er data in.

Stel (bron: wikipedia) dat je twee programma's hebt, die beide een stuk ruimte registreren en die direct naast elkaar liggen:

Programma 1: vak 1 tot en met vak 11
Programma 2: vak 12 en 13

Nu heeft programma 2 een simpel stukje data daar opgeslagen, bijvoorbeeld een getal (wikipedia neemt 3). Dan wordt dat over de vakken verdeeld door middel van het opslaan van '03', vak 12 heeft waarde 0 en vak 13 heeft waarde 3.

Als nu programma 1 een stukje tekst opslaat, laten we bijvoorbeeld nemen 'tweakers.net' en dit opslaat in zijn geregisteerde geheugen zonder te kijken hoeveel ruimte dat gaat innemen, dan krijg je het volgende:

vak 1 t/m 11 => tweakers.ne
vak 12 => t
vak 13 => 0 (de data schuift een stukje op, dus de oude waarde van vak 12 wordt 13)

Hierdoor heeft programma 2 niet meer de waarde 3 in zijn geheugen zitten maar 't0', wat de waarde (in decimalen) 1150 zou hebben. Als dit de score van je spel is wat je aan het spelen is ben je super blij, maar als dit het aantal euros is wat je overschrijft naar een rekening van een bedrijf ben je minder vrolijk.

Dit is de technische benadering van een buffer offerflow, waarvan een heap-overflow een bepaald type is. De hele truc is jouw geheugen aanroepen op die plek waar je data kan injecteren in een draaiend process (bijvoorbeeld winlogon.exe of iexplore.exe), waardoor die programma's jouw code uitvoeren en dus iets kunnen uitrichten.
Voor de volledigheid (lees: "voor niet-programmeurs") is het misschien nog even handig om te verklaren waar die 0 in vakje 13 vandaan komt.

Omdat een stuk tekst een variabele lengte heeft zul je op de een of andere manier moeten opslaan hoe lang dit specifieke stuk tekst is. Hier zijn twee mogelijkheden voor: je schrijft er een getal voor, of je schrijft er een speciale waarde achter (deze einde-markering moet natuurlijk een waarde zijn die onmogelijk onderdeel van de tekst kan zijn).
In veel programmeertalen (waaronder C) wordt gekozen voor de tweede oplossing, waarbij voor de markering wordt gekozen voor de waarde nul. De technische benaming is eigenlijk gewoon een omschrijving: "zero-terminated string".
Omdat je buiten het door het programma gemanagede geheugen treedt.

http://en.wikipedia.org/wiki/Buffer_overflow

Daarom is die DEP (Data Execution Preventenion) ook zo nuttig. Zelfs al heb je een overflow en kun je schrijven buiten het geheugen van het programma, dan nog is die data als non-executable aangemerkt, en kun je hem dus niet (laten) uitvoeren.

[Reactie gewijzigd door Keypunchie op 13 december 2008 17:38]

Je plaats enkele dingen meer op de heap zonder die er terug af te halen, en zo kom je buiten de toegewezen ruimte terecht. Zo kan je er uitvoerbare code plaatsen en op magische wijze ook nog uitvoeren. Hoe dit nu precies in zijn werking gaat weet ik ook niet exact, maar ik geloof dat het op dit neerkomt.
Ik denk toch dat veel mensen die enkel achter de PC zitten om hun mail te checken zulke dingen niet lezen en uiteindelijk toch wel getroffen worden. Hoeveel oudjes kennen nou Firefox? Volgens mij wel heel weinig.
No offence maar FF is ook niet heilig en heeft zo ook haar beveiligings problemen gekend in het verleden. Het lijkt er zelfs nogal op dat de FF crew veiligheids lekken grotendeels voor zichzelf houdt, stel je voor dat dit naar buiten komt dan valt plotseling het woord 'veiliger' af waardoor mensen misschien wel weer terug stappen naar MSIE.
Het verschil is dat FireFox meestal binnen enkele dagen (uren?) met een patch komt en dat automatisch geinstalleerd wordt bij de gebruiker. Bij Internet Explorer moeten de patches binnengehaald worden via Windows Update en daarbij moet kan de gebruiker zelfs aangeven dat hij de patch niet wil hebben (nogal domme optie lijkt mij). Het updaten bij Internet Explorer is dus veel omslachtiger en langzamer, waardoor dit soort exploits zeer waardevol zijn voor misbruikers (en die worden nog exrta blij als ze kijken naar het - gelukkig afnemende - marktaandeel).

Zie ook klik

[Reactie gewijzigd door Xirt op 14 december 2008 02:40]

Het verschil is dat FireFox meestal binnen enkele dagen (uren?) met een patch komt en dat automatisch geinstalleerd wordt bij de gebruiker.
Behalve wanneer je de"Stop bugging me" optie neemt door op de knop [cancel] te drukken.
Bij Internet Explorer moeten de patches binnengehaald worden via Windows Update en daarbij kan de gebruiker zelfs aangeven dat hij de patch niet wil hebben (nogal domme optie lijkt mij)
Ja zeg :) Stel je eens voor dat je die keuze niet zou krijgen. Ev0l MS toch, zomaar die hotfix door je strot douwen.
. Het updaten bij Internet Explorer is dus veel omslachtiger en langzamer, waardoor dit soort exploits zeer waardevol zijn voor misbruikers (en die worden nog exrta blij als ze kijken naar het - gelukkig afnemende - marktaandeel).
Dat marktaandeel zal de eerstkomende vijf jaar echt niet onder de 75% komen denk ik zo.

[Reactie gewijzigd door alt-92 op 13 december 2008 16:20]

Security fixes zouden wat mij betreft zonder toestemming geinstalleerd mogen worden. Dit zou zeker het geval moeten zijn in de 'Home' editions van Windows, aangezien het merendeel van de gebruikers niet goed weet welke updates belangrijk zijn en welke niet. Daarbij moet natuurlijk wel de kanttekening gemaakt worden dat de fix alleen het beveiligingprobleem oplost en niet nog extra taken uitvoert op het systeem.

Het aantal van Internet Explorer is (gelukkig?) al lager dan 75% wereldwijd. In Nederland ligt het gebruik iets hoger (naief of onwetendheid?), maar Mozilla is hard aan het werk om het aandeel van FireFox te laten groeien (zie ook het andere artikel van vandaag).

Bron marktaandelen: klik
Dat marktaandeel zal de eerstkomende vijf jaar echt niet onder de 75% komen denk ik zo.
Boven de 75% bedoel je?
@ZeroSixZero
Das niet zo. Je kunt instellen in IE dat de updates voor IE automatisch gedownload en geinstalleerd worden. Bij "extra" --> "internetopties" --> "geavanceerd" kun je dat instellen.

[Reactie gewijzigd door marquis op 13 december 2008 17:35]

Maar het is dus niet de standaardinstelling en ik denk niet dat veel 'standaard'-gebruikers in de 'geavanceerde' instellingen kijken.
Deze post vind ik geen meerwaarde hebben, dit hangt er gewoon af van hoeveel je update met beide applicaties. Verder toont dit niets aan over hoe snel er door de developers dingen gepatcht worden.
Verder toont dit niets aan over hoe snel er door de developers dingen gepatcht worden.
Los van hoe snel de developers hun patch klaar hebben staan worden deze door microsoft doorgaans alleen de eerste dinsdag dinsdag van de maand vrijgegeven. Alleen in extreme gevallen (zoals deze) komt de patch eventueel eerder.
daarbij moet kan de gebruiker zelfs aangeven dat hij de patch niet wil hebben (nogal domme optie lijkt mij
al een aantal keren gehad, dat 1 specifieke update heel de windows update liet vastlopen, niets qua windows update werkt dan nog, tot je de patch er terug afdoet.
in enkele van deze gevallen keert het probleem terug bij het herinstalleren van deze patch.
vandaar de (nuttige en slimme) optie om deze NIET te installeren (om te voorkomen dat je die andere 20 updates niet binnen kunt halen).
Dat zegt meer iets over het update-systeem van Microsoft of de integratie (hierboven al gediscussieerd) van Internet Explorer binnen Windows. Ik heb zelf overigens nog nooit problemen gehad met updates van IE6 en 7.
Het verschil is dat ik bepaalde "hack" sites altijd bezocht met mijn virtuele machine (windows xp) en IE en niets opliep, en met ff direct een exploit te pakken had op de zelfde vage sites.

Gezien de sites bezocht worden vanuit een virtuele machine en allemaal even wazig zijn is er altijd een risico maar het blijkt dat ik met FF net zo veel of soms zelfs meer problemen heb dan met IE. Alleen Opera is een stuk veiliger heb ik gemerkt.
No offence maar FF is ook niet heilig en heeft zo ook haar beveiligings problemen gekend in het verleden. Het lijkt er zelfs nogal op dat de FF crew veiligheids lekken grotendeels voor zichzelf houdt
Heb je ook een bewijs voor deze, enigszins onzinnige, stelling? Of loop je maar wat te kletsen?

In tegenstelling tot het ontwikkelproces van Internet Explorer, is Mozilla 100% open in het aangeven welke bugs er gefixed zijn. Het enige dat men eventueel nog achter houdt, dat is de detail-informatie rond de bug (in bugzilla) - hoewel je deze *altijd* kan achterhalen als deze eenmaal ingecheckt is, door in de changelog van het versiebeheersysteem van Mozilla te kijken. Dat achterhouden heeft dan vooral te maken met de toepasbaarheid van de exploit op andere browsers...

Bij Microsoft is er geen enkele controle mogelijk, en zou het zo kunnen zijn dat men dingen fixed en hier niets over meldt...
Liever dat er dingen bij MS bekend zijn die gefixed worden zonder melding dan dat alle beveiligingslekken op de website van de developer worden beschreven. Openheid is leuk maar in het geval van beveiliging mogen ze van mij wachten tot ze het probleem ook daadwerkelijk opgelost hebben.
Maar in dit geval ging de code kennelijk al enkele weken rond en kwam MS pas een paar dagen geleden met een melding. Dan heb ik toch liever dat het meteen gemeld wordt zodat ik maatregelen kan nemen wat me weer de nodige helpdesk telefoontjes scheelt.
Het lijkt er zelfs nogal op dat de FF crew veiligheids lekken grotendeels voor zichzelf houdt
Als dat waar is (heb je er een bron van?) is dat fout en kortzichtig. Er zijn exploits in omloop die door de ontdekkers bewust niet openbaar gemaakt worden maar voor veel geld verkocht worden aan mensen die geld kunnen verdienen met misbruik, net als in het artikel voor deze exploit genoemd wordt.

Ik ben het overigens eens met je opmerking over FF: als je naar een "vage" website gaat zie je zowel bij Firefox als bij IE dat er code uitgevoerd wordt die effectief de popup blocker omzeilt. Ook heb ik meegemaakt dat een bekend lek in de flash-plugin misbruikt werd om vanuit Firefox malicious code uit te voeren zonder andere user-interactie dan het bezoeken van een website. In dit geval worden de problemen niet geheim gehouden, maar het duurt wel erg lang voordat Firefox met een oplossing komt. Ik liep hier zelf begin augustus voor het eerst tegenaan en voor zover ik kan zien is het nog altijd niet in alle situaties opgelost (bron dd. 28 november 2008, beschrijft een kwetsbaarheid in FF zelf en niet in de flash plugin).

[Reactie gewijzigd door berend_engelbrecht op 13 december 2008 15:42]

Het gros van de echte issues is gerelateerd aan het platform waarop FF draait, als dat onveilig is (windows) dan maakt het totaal niet uit hoe veilig de browser is.
Ik denk toch echt dat het MS is die zoveel mogelijk bugs probeerd geheim te houden, bij Fx worden de meeste bugs en lekken door de community gemeld en komen ze ook gewoon in de publieke bugtracker terecht.
The problem in Internet Explorer 7 means a computer could be infected with malicious software merely by visiting a Web site
Aangezien de malware zonder tussenkomst van de gebruiker wordt geinstalleerd denk ik dat een heleboel andere mensen er ook last van kunnen hebben. Zo blijkt maar weer dat er nog een hoop te verbeteren valt aan de beveiliging in Windows (ook in de varianten die volgens Microsoft veilig zijn (Vista!)).
Aangezien de malware zonder tussenkomst van de gebruiker wordt geinstalleerd denk ik dat een heleboel andere mensen er ook last van kunnen hebben
Dat moet je natuurlijk ook nog wel naar een malware verspreidende site toegaan waar de bug actief geexploiteerd wordt.
Wat denk je van gehackte servers waar dit soort code opgezet kan worden? Een lange tijd terug zijn er nog adservers gehackt van een grote advertentieprovider waardoor sites als nu.nl malware installeerden. Denk je even veilig alleen maar nu.nl of startpagina.nl te bezoeken wat totaal geen kwaad kan, heb je ineens een virus op je PC.
het is wel lastig surfen, als je daarover moet nadenken, ik ga ergens naartoe waar ik iets interessants vindt, ik zou niet weten hoe ik dit moet uitzoeken.

Misschien heb je wat tips, die, en het internet leuk houden, en het internet veilig houden,
Wat heeft Windows Vista hier mee te maken, dit artikel doelt enkel op Windows XP gebruikers en diegenen die DEP uitgeschakeld hebben staan in Windows Vista.
Op Tweakers:
De gebruikte Windows-versie speelt verder geen rol.
Op PCWorld:
It affects computers running IE7 on Windows XP regardless of the service pack version, Windows Server 2003 running Service Pack 1 or 2, Windows Vista and Windows Vista with Service Pack 1 as well as Windows Server 2008.
Bovendien staat in het artikel dat volgens Secunia DEP niet effectief is tegen deze aanval.
Bovendien staat in het artikel dat volgens Secunia DEP niet effectief is tegen deze aanval.
Lezen: volgens Secunia is uitsluitend DEP inschakelen effectief, en niet de andere lapmiddellen die Microsoft voorstelt.
Nee! Volgens secunia is uitsluitend het instellen va n de securitysettings in IE op "hoog" in combinatie met het unregisteren van oledb32.dll effectief.

bron: http://secunia.com/blog/38/

[Reactie gewijzigd door de Rochebrune op 13 december 2008 18:04]

Ach ja alweer :! Dat krijg je als je Browser zo diep in het Systeem zit! Je kan je systeem nog zo veilig proberen te maken als je een browser hebt die als een anker diep in het systeem zit...wel.
Dat heeft er helemaal niks mee te maken. Zolang het geen lek in de kernel betreft is een lek in een geinstalleerde applicatie net zo erg als een lek in een user-mode onderdeel van het operating system.

Daarnaast is IE helemaal niet zo geïntegreerd met het OS als vele anti-MIcrosoft lobbyisten iedereen willen doen geloven. IE is feitelijk opgebouwd uit een verzameling van objecten met een flinterdunne user interface schil (IExplore.exe is slechts +/- 600 kb groot).
Die objecten kun je zonder problemen (handmatig) deinstalleren. Je hebt dan alleen beperkte functionaliteit in bepaalde onderdelen van de shell (Desktop) en geen help functie meer binnen Windows omdat deze ook gebruik maken van deze objecten. Ook diverse 3rd party software maakt gebruik van deze objecten omdat ze nou eenmaal erg handig zijn en veel functionaliteit bevatten die je zo niet zelf hoeft te implementeren.
Nu wil ik niet lullig doen, maar je zegt eerst dat het niet heel erg diep in je systeem zit, maar komt vervolgens wel met een hele lange lijst met dingen die gek gaan doen als je het deinstalleerd.
Ik weet wel dat je IE kan deinstalleren, maar ik weet ook dat je dat eigenlijk gewoon niet moet doen wil je een normaal systeem houden.
Echter als ik firefox deinstalleer in zeg ubuntu, verandert er verder aan het systeem helemaal niets.
Op Webwereld zegt de bekende MS: "hAl" expert dat DEP wel werkt tegen dit exploit. Dus ik neem aan dat Secunia ernaast zit
DEP werkt tegen de gepubliceerde exploit.
Het lost niet de onderliggende vunerability op in oledb32.exe.
http://www.microsoft.com/...rity/advisory/961051.mspx

Op deze link staat dat het niet het geval is wat jij zegt.:

Recently, proof of concept code was published that demonstrates methods to bypass DEP.
Het wordt wel vernoemd, dus het zal op zich wel effect hebben, zeker als je 64 bit draait.
En wat is het verschil?

IE7 draait pas vanaf XP (niet op bijvoorbeeld w2k), dus in feite is "alle Windows-versies" precies hetzelfde als de lijst bij PCWorld...
Lees wat er staat:
Zo kan de DEP-beveiliging in IE7 ingeschakeld worden.
want er staat niet:
Zo kan de Windows-DEP-beveiliging ingeschakeld worden om IE7 te beveiligen.
Meer dat iets zoals Vista niet zo veilig zal zijn als ze doen voorkomen. Je kunt veiligheid immers niet garanderen. Jammer dat bedrijven dat menen te kunnen roepen. Het is praktisch gezien geen goed verkoopargument omdat alles te kraken is.
"Kijk, we hebben weer iets gefixt, Windows, nu nog veiliger!"
"Zo blijkt maar weer dat er nog een hoop te verbeteren valt aan de beveiliging in Windows (ook in de varianten die volgens Microsoft veilig zijn (Vista!))."

kots. bugs gebeuren. er zijn ook constant critical bugs in de linux kernel bijvoorbeeld. het verschil is dat deze niet gemeld is aan MS, maar gelijk wordt geexploiteerd.

shit happens. een paar security researchers die ik ken hebben ook een 0day voor sendmail op het moment, maar die misbruiken hem niet. Daar gaan ze een fijn artikel over schrijven en over een tijdje eens contact opnemen met de devs.
Als je goed leest is het een lek in IE en niet in Windows.

Maar gelukkig hebben de MS-flamers weer een leuk weekend op deze manier.

Er staat ook niet bij dat er een heleboel mensen last van hebben.

Er staat iets van op bescheiden schaal, maar dat hij nu op steeds meer plaatsen opduikt.

Wat is op steeds meer plaatsen?
En als je ook begrijpt wat er staat: Je kan door een bug in IE alle beveiliging van Windows doorbreken. Windows is dus nog steeds een single user OS. Ondanks alle beloftes de afgelopen 10 jaar. Een bug mag voorkomen. Maar zodra mensen bugs in ALLE lagen van je OS aan elkaar kunnen schakelen heb je niet het recht om E 100,- te vragen voot je software (mijn mening, geen feit).

De reden waarom mensen als ik MS-flamers zijn is eenvoudig: MS is een OS uit de jaren 80 en is blijkbaar nog steeds gebaseeerd op achterhaalde technieken. Als Windows een redelijk OS was hadden de mensen die nu Windows aan het patchen zijn Windows kunnen uitbreiden tot een prachtig OS. Dan haddden de mailservers 90% minder e-mail in de spambox hoeven zetten. Dan had de wereld met 90% minder systeembeheerders af gekundt.

Een vergissing (bug) mag. Voor een verzameling bugs E100,- vragen mag. Maar dan mag ik zeggen dat een PC-liefhebber een keer nadenkt voodat ie veel geld naar Redmond overmaakt.

En: Proost!
Deze bug doorbreekt helemaal niet niet alle beveiligingslagen van Windows. Een exploit krijgt dezelfde rechten als waaronder IE draait en onder goede omstandigheden zou dat een user account moeten zijn met beperkte rechten. Dan zijn er overigens nog genoeg vervelende dingen mogelijk maar dat geld voor ieder OS.
Wat een prachtig staaltje MS-bashing weer. hierboven, IE heeft echt niet meer lekken dan een browser als netscape, safari, opera of wat dan ook. Firefox is gewoon voorbereid om de bekende issues met IE preventief af te vangen.

Windows is niet het lekste, maar het meest gebruikt, als je exploits in firefox of conquerer gaat zoeken vind je ze ook wel, net als in MacOS of linux.

Ik benieuwd of er mensen microsoft nog gaan afzeiken voor de antieke drop, pong, yankee doodle en flip virussen, of award of ami voor nog altijd vatbaar te zijn voor tsjernobyl.

Gaat er straks nog iemand schreeuwen dat hij op zijn amiga, c64, atariST of amstrad nooit virussen had en dat veel betrouwbaarder platformen waren om die reden?
"Hooge bomen vangen veel wind"
Geld zeker voor de marktleider,deze zal 1000 maal beter zijn best moeten doen dan
de volgers.
Dus ja,elke lek is er een te veel.
MS zal meer tijd en geld moeten investeren om fouten te voorkomen.
Hoe kan men in het algemeen alle versies van IE in alle platforms van Windows de-installeren. Ze vertellen altijd maar van die bugs maar ze verwijderen ze niet. Ik gebruik nu reeds andere internet browser, maar blijf opgescheept met die "VERPLICHTE" installetie van van eender welke versie van Internet Explorer.
Hoe ge het ook bekijkt "IE" is enorm traag geworden, en hangt veel (blokkeerd)

blauwvin@hotmail.com
Microsoft Security Advisory (961051)
Vulnerability in Internet Explorer Could Allow Remote Code Execution
Published: December 10, 2008 | Updated: December 13, 2008

Which of the workarounds should I apply to my system in order to be protected?
• Disable XML Island functionality
• Restrict Internet Explorer from using OLEDB32.dll with an Integrity Level ACL
• Disable Row Position functionality of OLEDB32.dll
• Unregister OLEDB32.dll
• Use ACL to disable OLEDB32.dll

Hoe?
Hieronder:
____BATCH-TEXT_______________________________________________________
:: Uiteindelijk heeft ontzeggen van SQL/Acces op de OleDb32.dll zin,
:: in deze volgorde, open CMD bij Run (Uitvoeren):

:: Eerst Eigenaar (Owner) worden van het bestand 'oledb32.dll';
cd %SystemRoot%\system32\
takeown /f "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"
:: Uitvoer hiervan ::
:: SUCCESS: The file (or folder): "C:\Program Files\Common Files\System\Ole DB\oledb32.dll" now owned by user "%ComputerName%\%UserName%".

:: Ten tweede; UnRegister oledb32.dll;
cd %SystemRoot%\system32\
regsvr32.exe /u "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

:: Undo :: Te niet doen van deze actie :: (register oledb32.dll) ::
:: cd %SystemRoot%\system32\
:: regsvr32.exe /i "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

:: Daarna ontzie de Windows-Security-Group 'Everyone' access van dit bestand:
cd %SystemRoot%\system32\
cacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll" /E /P everyone:N

:: Uitvoer wordt:
:: processed file: C:\Program Files\Common Files\System\Ole DB\oledb32.dll

:: Undo :: Te niet doen van deze actie ::
:: cd %SystemRoot%\system32\
:: cacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll" /E /P everyone:R
____END-OF-BATCH_____________________________________________________

(Zorg ervoor dat de uitvoer regels (hierboven in Batch) idd één regel zijn, anders werkt het natuutlijk niet, btw: Graag gadaan hoor...! ;)

Controle uiteindelijk, via CMD:
cd %SystemRoot%\system32\
icacls "%ProgramFiles%\Common Files\System\Ole DB\oledb32.dll"

Uitvoer:
C:\Program Files\Common Files\System\Ole DB\oledb32.dll: Access is denied.
Successfully processed 0 files; Failed processing 1 files

Dat is Positief, u bent beveiligd tegen Access-/SQL-Injectie van OleDB32.DLL !!!!

Verder heeft het zin om deze te downloaden....:
(Deze ZIP uitpakken en de Bestanden lezen, INF-installeren (rechter-muis-knop), het gebruik spreekt voor zich, dacht ik zo...: BlockAccess_x86.inf / UnBlockAccess_x86.inf ):
http://blogs.technet.com/swi/attachment/3167803.ashx

[Reactie gewijzigd door HoeZoWie op 14 december 2008 13:09]

Dat is het grote probleem he. IE wordt voorgeinstalleerd op alle windows computers.

Hopelijk kan google met z'n chrome browser iets aan doen zodanig dat er enkele merken hun OEM windows versies met Chrome erop gaan brengen. Het zou een hele evolutie zijn.
Helaas gaat het niet zozeer om ene bug in Internet Explorer - het deel dat de gebruikers zien, maar de in Windows geïntegreerde Trident-engine.

Het meeleveren van een andere browser (Google Chrome, Firefox, Opera,...) lost niets op omdat Microsoft haar OS zodanig ingericht heeft dat er tig afhankelijkheden zijn op deze Trident-engine. Verder maken veel programma's gebruik van deze engine (denk bijvoorbeeld aan Outlook Express/Windows Mail) en het instellen van een andere browser als standaard-browser helpt dus slechts ten dele.

(Dat het installeren van een modernere browser als IE een vooruitgang zou zijn voor 't web bestrijd ik overigens niet)
De trident engine is echter zelden de oorzaak van security issues.
De issues zitten bijna altijd in het ondersteunen van allerlei fileformaten op het internet of in de scripting gerelateerde zaken.
De bovenstaande bug is zit bijvoorbeeld in de OLE databinding
@Little Penguin:

Zowel Gnome als KDE hebben ook gewoon een ingebakken HTML render engine, dat is op zich niets bijzonders en is ook niets mis mee.

Het lijkt me dan niet logisch om te zeggen dat deze bugs komen doordat de engine geintegreerd is of dat het integreren de bugs op een of andere manier erger maakt. Dergelijke overflow bugs kunnen ieder gewenst stukje code opstarten, het maakt dan niets uit in welk programma origineel de bug zat.
Dat wil je ook niet, want wat we nu al aantreffen op nieuwe asus notebooks is dat Google desktop standaard is geinstalleerd. Samen met de windows search functie die standaard in vista zit staan er dan dus al vaak 2 programma's nutteloos te indexeren.....wat een traag systeem oplevert.

Wat ik wel vind is dat IE gewoon niet in het OS moet zitten. Zorg maar dat het los beschikbaar komt als update. Dan kan de eindgebruiker namelijk zelf kiezen wat ze willen.
Een gebruiker wil niet eerst uitzoeken hoe hij op het internet geraakt, hij wil gewoon een icoon op de achtergrond waar dat hij direct op kan klikken en hem ook duidelijk maakt dat hij daar mee kan surfen. 'Internet Explorer' maakt al heel wat duidelijker dan 'Google Chrome', 'Firefox' of iets anders met zijn naam, dit het is direct duidelijk dat de gebruiker met dat icoon op het internet kan.

Weet je als gebruiker wat meer er over dan kan je een alternatieve browser gaan installeren, maar hier heb je reeds een browser voor nodig. Daarnaast is het verwijderen van Internet Explorer dom, het neemt haast geen plaats in en op de componenten ervan zijn sommige andere dingen afhankelijk.

Twee programma's die indexeren is inderdaad overbodig, als je haast niet zoekt is zelfs een verbodig, maar als je af en toe eens iets moet opzoeken zou ik het zeker niet nutteloos vinden. Je kan aanpassen wat hij indexeert.
Daarnaast is het verwijderen van Internet Explorer dom, het neemt haast geen plaats in en op de componenten ervan zijn sommige andere dingen afhankelijk.
Internet Explorer zelf (dat wil zeggen een paar executables en wat desktop links) kun je volgens mij ongestraft verwijderen.

De door Internet Explorer gebruikte HTML-engine (Trident) kun je inderdaad (beter) niet verwijderen. Delen van Verkenner maken al gebruik van Trident en dat geldt ook voor sommige delen van het configuratie scherm...
Desktop links tot daar toe, maar die executables nemen haast geen ruimte in naar mijn mening. Ik had het eerder over het geheel te verwijderen.
In Vista (en volgens mij ook XP) zit er gewoon een snelkoppeling in je startmenu met als titel "Internet" ongeacht van welke browser erachter steekt, lijkt me makkelijk genoeg.
Klopt, hier op mijn xp-installatie staat bovenin mijn startmenu "Opera Internet Browser".

(Geldt ook voor mail trouwens, thunderbird wordt aangegeven ipv outlook)
Maar niet op het bureaublad, en vroeger waren dit soort dingen er niet.
Standaard staat IE niet op het bureablad
Ik heb vaak Windows XP moeten installeren dus als je op bureablad firefox snelkoppeling aanmaakt en zegt dat men alleen die moeten gebruiken dan zullen ze het ook doen desnoods haal je IE uit start menu
Wie zegt dat Chrome en andere niet-IE browsers geen onbekende bugs hebben. Je houdt jezelf alleen maar voor de gek.
Chrome en Firefox zijn gewoon open source. Dus achter bugs kan de community zelf komen.
Die "dus" in je statement klopt niet echt, ook zonder de source kun je prima achter bugs komen. Ofwel het een heeft niets met het ander te maken, hoe hard open source fanboys dat ook roepen.

Daarnaast is voor 99% van de wereldbevolking die source complete hocus pocus.
Het is alleen een stuk lastiger om zonder broncode achter de bugs te komen, omdat je niet de code hebt. Een stuk slecht geschreven code kan ik dan zo zien. In plaats van dat ik zo maar wat probeer. En of er nou 1 of 10 mensen de software na kijkt dat maakt opzich niet uit.
Natuurlijk hebben andere browsers ook bugs. En ook heel ernstige.

Het voordeel van meerdere browsers en heh miet automatisch installeren van Internet explorer heeft een aantal voordelen.
1) Bij exploits worden niet alle gebruikers getroffen dus het effect op het internet is kleiner.
2) Web programmeurs hoeven niet meer tot in den treure te testen want alle browser fabrikanten zullen zich aan een standaard moeten houden, anders zullen ze buiten de boot vallen.
Het lijkt mij logisch dat als je gebruikers wilt afsnoepen van Microsoft, je dan zoveel mogelijk zal proberen veiligheidslekken voor jezelf te houden. Vooral als bijna 99,9% van de gebruikers zeggen dat de concurrent van MS veelal veiliger is.

Ik denk ook niet dat Ferarri zal zeggen dat een VW Beatle beter is dan hun auto, net zo min als dat de Hema zegt dat Unox rookworsten lekkerder zijn etc. etc. etc.
Ik sta niet zo te springen voor de Chrome browser van Google zelf, eerder voor een 'verbetering' daarvan:

Chrome vs Iron
Chroom ziet er mooi uit
IJzer is sterker
of maak ik een denk fout?
wat ben jij toch naive... denk je nou werkelijk dat Chrome of welke andere browser dan ook zo veel veiliger is? nee dus, elke browser heeft zo zijn lekken die minstens zo erg zijn, het feit dat dit dus blijkbaar een lek is die al sinds IE5 er in zit geeft al aan hoe moeilijk het is en lang kan duren voordat een lek pas naar boven komt... Als je bv met Chrome al ziet hoeveel beveiligingslekken er naar boven zijn gekomen in die korte tijd dat het publiekelijk is, dan heb ik ook niet zo'n vertrouwen in chrome bv..
"Zo kan de dep-beveiliging in IE7 ingeschakeld worden."

Als je Windows Vista gebruikt zou je dit probleem dus niet moeten hebben.

Verder is dit goed nieuws want zo kunnen ze het verhelpen naar IE8 toe en fixen in de bestaande versies, vraag me af of dit probleem nog in de overlaatst privaat vrijgegeven IE8 RC1 zit.
Het probleem geldt voor alle Windows versies dus ook Vista.

Lijkt me wel dat het ook in IE8 RC1 zit want als ze die al gepatcht hadden was er ook wel snel een patch voor IE7.

[Reactie gewijzigd door Amorax op 13 december 2008 14:42]

  • Protected Mode in Internet Explorer 7 and Internet Explorer 8 in Windows Vista limits the impact of the vulnerability.
  • An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.
Windows Vista speelt hier zwaar een rol in beveiliging, zeker omwille van het draaien van DEP en UAC, verder ben je niet goed bezig als je als lokale administrator aanmeldt.
En mocht een programma toch admin rechten willen hebben dan krijg je een wachtwoord scherm voor je neus en als je wachtwoord invult dan ben je verkeerd bezig geweest

Ik gebruik vista, uac, dep en ben een beperkte gebruiker
Als je Windows Vista gebruikt zou je dit probleem dus niet moeten hebben
Alleen op de 64 bits versie van Vista staat DEP voor alle applicaties aan.
Verder staat DEP ook standaard aan bij de nieuwe browserversie IE8 op Vista en W2k8 server.
Volgens de Rochebrune en secunia: http://secunia.com/blog/38/
maken DEP niets uit, geeft het dit keer geen bescherming, wat is jouw mening daarover?
Ik zie geen melding van DEP op het secunia blog
De gepubliceerde exploit was gebaseerd op een heapoverflow. Dat is iets waartegen DEP bescherming biedt.
Op zich is DEP aanzetten dus verstandig.
Er zit echter een onderliggendevunerability in oledb32.exe. Deze moet gepatched worden. Het is misschien mogelijk om op andere wijze deze vunerability te misbruiken.
Het kunnen misbruiken van een heapoverflow is echter ernstig omdat er dan geen gebruikersactie vereist is maar alleen het surfen naar een gecompromiteerde website. Dus DEP aanzetten is zeker verstandig en maar garandeert niet dat er geen andere minder ernstige manieren mogelijk zijn om de vunerability te misbruiken.
Dus DEP aanzetten is zeker verstandig en maar garandeert niet dat er geen andere minder ernstige manieren mogelijk zijn om de vunerability te misbruiken.
Dat kan wel zijn maar is blijkbaar off topic in samenhang met deze vulnerability

Ook op de Microsoft advisory wordt niet gezegd dat DEP zou beschermen.
http://www.microsoft.com/...rity/advisory/961051.mspx

Er wordt zelfs gezegd dat proof of concept code DEP passeert. Er staat dat:
Recently, proof of concept code was published that demonstrates methods to bypass DEP. However, the workarounds included in this advisory, of setting the security slider to High as well as applying one of the OLEDB32.dll workarounds, are still effective in blocking current attack

Dus het secunia-advisory zegt hetzelfde.

In het Microsoft advisory wordt ook gezegd dat ALLE Windows-versies vulnerable zijn in combinatie met ALLE IE versies (dus ook IE8, dus ook W2k8)
Er is wel discussie over methodes om DEP te omzeilen maar effectief is het zover ik weet nog niet iemand in de real world gelukt er een zinvolle aanvalmethode van te bakken. Het is echt wel zo dat DEP beschermt tegen momenteel bekende aanvalsmethode ten aanzien van deze vunerability.
Echter het volledig uitzetten van de toegang tot executable die de vunerability bevat is sowieso de meest effectieve methode.
DEP wordt in deze aanval omzeild, sterker nog, het speelt geen rol, lees het MS advisory, het staar er expliciet in
Lees jij nog maar eens de advisory.
Jij haalt vermoedelijk twee set van proof of concept code door elkaar. ER is weliswaar proof of concept code bekend voor het omzeilen van DEP maar die was niet zinvol toepasbaar in malwareverspreiding.
De 'per ongeluk ' gelekte code met de proof of concept code om de hier besproken vunerability te misbruiken is echter weer heel wat anders en is heel geschikt voor malware verspreiding maar maakt dus juist ook gebruik van een heap overflow en omzeilt DEP niet.
maar er staat toch, additioneel, in de advisory dat W2k8 en alle andere Windows versies, IE8 beta2 en alle Iandere IE versies vulnerable zijn?
Dat betekent toch dat DEP in dit geval niet voldoet, anders zouden ze toch niet vulnerable zijn? (vulnerable=kwetsbaar)

Ik zou daar toch graag een eenduidig antwoord op volgende vraag hebben, want wel vulnerable zijn maar geen exploit kunnen uitvoeren, daar snapt een gewone leek zoals ik niets van.

Leg dat maar niet uit. Dat soort ingewikkeldheden, daar raadpleeg ik experts voor die eht voor mij naar mij toe vertalen. Dus als je volgende vraag eenduidig wil beantwoorden, ben ik heel blij.

Ben jij, hAl, als bekend Windows-expert, van mening dat niemand die DEP heeft aanstaan gevaar loopt voor deze, in dit artikel, besproken vulnerability?

En als dat zo is, waarom zegt MS dat dat niet in hun advisory, dat soort geruststellende feitjes staan er anders altijd heel uitdrukkelijk bij onder het kopje mitigating factors
DE vunerability wordt niet afgedekt door het aanzetten van DEP.
Het misbruiken van de 'per ongeluk' gelekte exploit die nu op een aantal plaatsen op het internet wordt gebruikt wordt wel wel voorkomen door DEP.
Misschien ontstaan er nog wel amdere manieren om de vunerability op andere wijze te misbruiken maar ik vermoed dat deze dan wel gepatched zal zijn.
Wat is het verschil tussen misbruik van een exploit en misbruik van een vulnerability?

Als misbruik wordt voorkomen, ben je toch je niet meer vulnerable, toch? ook als DEP aanstaat, wat in verschillende omgevingen default het geval is.

Ik bedoel er is een advisory van MS, deze dus, waarin staat dat ALLE Windows versies en in combinatie met ALLE IE versies, inclusief IE8 een vulnerability hebben, maar ik kan die gerust negeren? Omdat ik DEP default heb aanstaan?
Dat is jouw advies?

Ik snap niet waarom dat dan niet in de advisory staat, want nu lijkt het alsof ze mensen voor niks bang maken,

[Reactie gewijzigd door nieuwstip op 14 december 2008 22:24]

Een exploit is een bekende manier op een vunerability te misbruiken.
Een exploit misbruik je dus niet maar is een methode om een vunerability te misbruiken.
maar ik kan die gerust negeren? Omdat ik DEP default heb aanstaan?
Dat is jouw advies?
Ik zou sowieso niet op mijn advies afgaan aangezien ik geen security expert ben.
In dit geval zal het aan hebben staan van DEP je bescherming verhogen. Dat is dus sowieso verstandig. Er kunnen echter op den duur nieuwe exploits onstaan. (dat is afhankelijk van op hoeveel manieren de vunerability gebruikt kan worden) die niet gebaseerd zijn op een via DEP detecteerbare en af te vangen methode. De beste manieren om de vunerability helemaal 100% af te dekken is het onbeschikbaar/onbereikbaar maken van de executable waarin de vunerability zich bevind. En dat wordt ook zo verwoord in de advisories.
Dan had je je vergist, want je schreef enkele dagen geleden:
Het misbruiken van de 'per ongeluk' gelekte exploit die nu op een aantal plaatsen op het internet wordt gebruikt wordt wel wel voorkomen door DEP.

Maar goed, vergissen is menselijk.

Weer komt de advisory ter sprake:
http://www.microsoft.com/...rity/advisory/961051.mspx

Natuurlijk moet je DEP hebben aanstaan, bijna ieder OS heeft een DEP mechanisme en Windows in de latere versies toch ook.
De MS advisory zegt niet expliciet dat DEP hier helpt, dus is toch een teken dat het niet helpt, anders had het er vast bij gestaan. Integendeel, het zegt, dat de gebruikers van zelfs W2k8-server ook vulnerable zijn, met IE8 beta2 (meer DEP is toch niet denkbaar?).

Het gaat hier ook om oledb32.dll, deze is voor sommige machines moeilijk buiten gebruik te zetten omdat er nogal wat services hier van afhangen, maar het kan. Dat klopt. Er staan nog wat tips, ze helpen om bepaalde aanval vectoren buiten werking te zetten. let op het woordje "helpen".
Er staat niet dat de tips de aanvalsvectoren buiten werking zetten, maar dat het helpt.

We moeten er gewoon vanuit gaan dat er geen 100% remedie is voordat dit gerepareerd is. Op zich geen slechte conclusie, beter een bekende zwakheid dan een onbekende zwakheid.

Misschien kan het ook helpen om Windows-servers die oledb32.dll moeten gebruiken tijdelijk van het Internet af te sluiten, dat lijkt mij de veiligste manier.
Dit is alleen moeilijk acceptabel op Windows-terminal-servers, omdat de terminal-gebruikers dan ook van het Internet worden afgesloten (dit stond ook ergens in de advisory)

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True