Microsoft: lek in IE gebruikt bij aanvallen op Gmail

Een bug in Internet Explorer is gebruikt voor de recente aanvallen op Gmail-accounts en systemen van andere bedrijven. Dat heeft Microsoft bekendgemaakt. Het gaat om een tot nu toe onbekend lek waar nog geen patch voor is ontwikkeld.

Momenteel wordt er gewerkt aan een software-update die de bug moet pletten. Tegenover Ars Technica heeft Microsoft bevestigd dat de bug is gebruikt voor de aanvallen op systemen van Google en andere bedrijven. Deze hack, die aan de Chinese overheid wordt toegeschreven, leidde ertoe dat Google overweegt om zich uit China terug te trekken. De IE-exploit is volgens Microsoft echter niet de enige gebruikte aanvalstactiek.

De bug in Internet Explorer maakt het injecteren van code mogelijk wanneer een object uit het geheugen wordt verwijderd, terwijl er nog wel verwijzingen naar bestaan. De bug kan met speciaal vervaardigde html-code worden misbruikt; Microsoft heeft logischerwijs niet uit de doeken gedaan hoe dit precies in zijn werk gaat. Hoewel de bug in alle Internet Explorer-versies vanaf 6.0 aanwezig is, werd alleen misbruik van de 6.0-versie vastgesteld.

Vooralsnog is het gebruik van de beveiligde modus van IE onder Windows Vista of Windows 7 de enige manier om de kans op misbruik te minimaliseren. Uiteraard kan ook een andere browser worden gebruikt. De beveiligde modus wordt standaard gebruikt voor html-mails in de mailprogramma's van Microsoft op Vista en Windows 7; wel zijn gebruikers dan nog kwetsbaar als ze op een link klikken die naar een website met exploitcode verwijst.

De door Google ontdekte hack leidde tot de nodige commotie. De Amerikaanse regering sprak haar bezorgdheid over het nieuws uit. Eurocommissaris Neelie Kroes, die in de nieuwe commissie de portefeuille Digitalisering toebedeeld moet krijgen, zei achter Google te staan. Intussen heeft Google de beveiliging van Gmail aangescherpt; gebruikers hebben nu standaard een beveiligde verbinding via https. De https-verbinding was al langer optioneel beschikbaar, maar stond standaard uit. Hoewel het voor de hand ligt, heeft de zoekgigant niet bevestigd dat de verscherpte beveiliging een gevolg van de Gmail-hack is.

Reacties (143)

[Nowad]

is het echt gebeurd of maakt google een verhaal (of zelf opgezet door G) op om Internet Explorer in het negatieve daglicht te krijgen en daardoor meer gebruikers te zien overstappen naar Google Chrome?
zelf gebruik ik Chrome
zelf vind ik het raar dat ze dan precies gmail aanvallen...

[Reactie gewijzigd door Nowad op 23 juli 2024 21:31]

[Verwijderd]

Tuurlijk ze willen iedereen vertellen dat Gmail niet veilig is?

Dat is niet erg voor de hand liggend

Het imago van de veiligheid van hun diensten als Gmail is voor google toch belangrijker dan het zwart maken van de concurrent.

Ik heb dat Google ook nimmer zien doen. het is juist MS die bakken met stront aan het uitstorten is over Google. Zoals Steve Balmer heeft gezegd: hij zal Google vermoorden. Van MS weten we dat ze weinig scrupules hebben. Een bedrijf dat stelselmatig de wet aan de laars lapt, schrikt ook niet terug voor smeer campagnes.

Ik vind het daarom nog voor de handliggender dat MS opzettelijk deze mogelijkheid heeft ingebouwd. MS is er in het verleden ook niet voor teruggeschrokken om fouten in haar producten te gebruiken om concurrende producten slechter te laten functioneren.

Dbase en WordPerdect kunnen er over mee praten.

[jan_va]

Het gaat hier totaal niet over in dit artikel. Heb je het eigenlijk wel gelezen? MS zegt dan een voorheen onbekende bug in IE (aanwezig vanaf versie 6.0 en later) aan de basis lag (samen met nog andere niet nader vernoemde methodes) van de hackpogingen gericht op gmail gebruikers (vredesactivisten etc die tegen de schenen van Communistisch China schoppen).

Dit zegt niets over de veiligheid van gmail en nog minder over de bedoelingen van MS. Zoals ik het hier zie proberen MS en Google juist zo snel mogelijk allerlei soorten hack pogingen van de Chinezen onmogelijk te maken of toch zo sterk mogelijk te beperken. Zwart maken van elkaar zit hier totaal niet bij en dat is zelfs niet de toon van het artikel. Het gaat om een oude bug (zoals er zoveel zijn), die enkel bekend was bij de Chinese overheid waar ze gebruik van gemaakt hebben.

Ontopic: Goed dat Gmail nu standaard met HTTPS draait, ikzelf gebruik het al meer dan een jaar op die manier, goed dat alle gebruikers nu minder risico lopen op een gehackte email account.

[Verwijderd]

Niemand spreekt van de Chinese overheid, das enkel een vermoeden waarme Amerika de Chinese republiek wil zwart maken (communism is bad).
Als de zoveelste Rusissche hackgroep hetzelfde doet (wat ook dagelijks gebeurd), hoor je niemand mekkeren omdat Rusland toch geen slachkracht heeft. Rusland heeft ook geen vingers rond de Amerikaanse nekjes zoals China op dit moment.

Ergens bij de bron ging het om ICT maar daarna is het gewoon politiek geworden.

[berend_engelbrecht]

Het "Chinese overheid"-verhaal is door Ars Technica afgeleid uit de felle aanklacht tegen China die Google eerder deze week deed.
Ars Technica: Furious Google throws down gauntlet to China over censorship

who else would come out swinging against the entire Chinese government [...] Google has had it with China's pervasive web of censorship and spying, and the company is done censoring its search results in China. The decision wasn't made in a vacuum, but rather came after years of increasing cyberattacks from the Chinese mainland. A recent, massive infiltration attempt that targeted Google and 20 other tech companies was the final straw. Though Google stops short of naming the Chinese government as the party behind the attacks, the implication is clear.

Google bron: Official Google Blog: A new approach to China
Google zegt nergens expliciet dat de Chinese overheid verantwoordelijk is, maar het wordt wel tussen de regels door gesuggereerd en Ars Technica heeft dat er uit gelezen. Lees Google's verhaal zelf maar, de toon is heel fel en Google stelt weldegelijk dat de aanval specifiek gericht is tegen tegenstanders van het Chinese bewind. De Google accounts van deze mensen werden ook al een tijd in de gaten gehouden vanuit China (gesuggereerd maar niet gezegd wordt: door dezelfde mensen die de aanval uitgevoerd hebben). Als je ziet wie dit geschreven heeft is het duidelijk waarom er geen expliciete beschuldiging in staat:

Posted by David Drummond, SVP, Corporate Development and Chief Legal Officer

Deze man is jurist en weet dus hoe ver hij kan gaan in zijn aanklacht zonder dat het laster wordt.

De primaire maatregel van Google wijst ook op verdenking van overheidsinmenging: ze stimuleren hun klanten https te gebruiken, dit moet het moeilijker maken het verkeer over de verbinding af te luisteren. Dat soort afluisteren wordt bij een openbare internetverbinding primair gedaan door overheidsinstellingen, het is moeilijk te doen zonder dat je toegang hebt tot het netwerksegment waar een van de eindpunten toe behoort. Aan de kant van de eindgebruiker zijn dat alleen mensen die toegang hebben tot de apparatuur van de provider: de provider zelf of de overheid in het land van de provider.

Tenslotte over het opzettelijk inbouwen van bugs: ik vind dat als programmeur erg vergezocht. In een ingewikkeld stuk software heb je al last genoeg van niet opzettelijke bugs. Bovendien klinkt deze exploit erg ingewikkeld en moeilijk toe te passen, en als je met opzet een backdoor inbouwt zou je het de hacker wel gemakkelijker maken. Microsoft valt Google ook helemaal niet aan in deze zaak maar bedankt ze netjes in hun security advisory:

Acknowledgments
Microsoft thanks the following companies for working with us and for providing details of the attack:
• Google Inc. and MANDIANT
• Adobe
• McAfee

[Reactie gewijzigd door berend_engelbrecht op 23 juli 2024 21:31]

[Verwijderd]

Tegenover Ars Technica heeft Microsoft bevestigd dat de bug is gebruikt voor de aanvallen op systemen van Google en andere bedrijven.

Microsoft komt er dus zelf mee....... wellicht dat google ze heeft geïnfiltreerd om ze zich zelf zwart te laten maken maken.

[sys64738]

Een bug in Internet Explorer is gebruikt voor de recente aanvallen op Gmail-accounts en systemen van andere bedrijven. Dat heeft Microsoft bekendgemaakt

Oftewel: MS zegt het zelf dus is het echt waar. En "MS heeft niet uit de doeken gedaan hoe de bug geexploit kan worden" dus ze weten hoe (en waarschijnlijk ook waar) ie werkt.

[Reactie gewijzigd door sys64738 op 23 juli 2024 21:31]

[PPie]

In het artikel staat dat Microsoft dit bekend heeft gemaakt, niet Google.

[durian]

De bug in Internet Explorer maakt het injecteren van code mogelijk wanneer een een object uit het geheugen wordt verwijderd, terwijl er nog wel verwijzingen naar bestaan. De bug kan met speciaal vervaardigde html-code worden misbruikt; Microsoft heeft logischerwijs niet uit de doeken gedaan hoe dit precies in zijn werk gaat.

Dat is helemaal niet logisch. Security door obscurity werkt niet, en als ze uitleggen hoe het werkt kan je misschien zelf ook stappen ondernemen, of zien mensen andere potentieel gevaarlijke websites, enz. Nu is het maar afwachten of het goed gerepareerd wordt, en omdat we niet te horen krijgen wat het originele probleem precies was kunnen we er ook niet op testen...

[Little Penguin]

Dat is helemaal niet logisch. Security door obscurity werkt niet, en als ze uitleggen hoe het werkt kan je misschien zelf ook stappen ondernemen, of zien mensen andere potentieel gevaarlijke websites, enz.

Toch wordt, op korte termijn, ook door (bijvoorbeeld) Mozilla gebruik gemaakt van security through obscurity. Op het moment dat een "bug" (in bugzilla) namelijk een veiligheids-issue betreft kunnen alleen een select groepje mensen die bug inzien.

Op het moment dat een issue goed gexifed is in de actuele versies van Firefox, dan worden die bugs wel openbaar gemaakt (dat gebeurt vaak ook als de informatie via andere kanalen reeds publiek is en de bug nog niet gefixed is overigens).


Op het moment dat de patch al weer 2+ weken uitgebracht is, dan kan men eventueel openbaar maken wat er precies misging en hoe je zoiets kon bouwen in een lekke versie van de browser.

[Verwijderd]

Die obscurrity methode van Mozilla wordt wel gevaarlijker naarmate je oudere versie niet meer update.
Als Mozilla nu Firefox 3.5 patched wordt versie 3.0 vanaf komende maand niet meer geupdate ook al zit datzelfde lek ook in versie 3.0. Een gemakkelijke prooi voor malwaremakers

Microsoft patched veel meer versies tot veel langer terug

[Little Penguin]

Het feit dat Mozilla Firefox 3.0 niet meer update een half jaar nadat een volgende versie uitgebracht is, dat is bekend. Met de diverse upgrade-opties wordt het gebruik van een vorige versie tot een absoluut minimum teruggebracht en is de impact van het mogelijke lek minimaal.

Over ongeveer 2-3 maanden zal het aandeel van Fx 3.0 dan ook zo ver teruggelopen zijn dat het ook voor malware-makers geen interessant target meer is. Het marktaandeel van Fx 3.0 is de afgelopen maanden met procentpunten gedaald en als men een volgende 'major update' aanbiedt zal het marktaandeel van Fx 3.0 alleen maar verder dalen en dit jaar zal het marktaandeel van Fx 3.0 ook nog op afgerond 0% uitkomen...

In hoeverre het beleid om slechts een half jaar na het uitbrengen van een nieuwe versie, de oude versie nog de supporten dat is een goede vraag. Mogelijk zou men dit tot een jaar uit moeten breiden, maar het is ook goed mogelijk dat het probleem dat je nu een half jaar na de relase hebt (namelijk dat gebruikers op stel-en-sprong over moeten als ze nog een gesupporte browser willen gebruiken) alleen maar met 6 maanden uitgesteld wordt.

Dat Microsoft de browsers langer ondersteund, dat is ook gewoon noodzaak - ze beloven dat ze een OS een bepaalde tijd ondersteunen en moeten dan ook alle software die er toen in zat ondersteunen. Als ze dat niet doen komen ze hun eigen belofte niet na. Misschien had 't toch een goed idee geweest om het een en ander niet als één geheel te zien?

[Verwijderd]

Ik begrijp wel dat ze dit niet zomaar openbaar maken. Dat zou heel wat meer mensen in staat stellen om de bug te misbruiken.
Waarschijnlijk zijn de "belangrijke" partijen hier wel over ingelicht, maar niet Jan Alleman

[Verwijderd]

Jan en alleman kunnen dit toch niet exploiten, je dient er wel een basiskennis voor te hebben. De mensen die het misbruiken weten dit al een tijdje hoe men dit manipuleert.

Is dus eerder om hun eigen incompetentie te verbergen. Want is letterlijk lachwekkend hoeveel security bugs er al zijn ontdekt (en dit zal ongetwijfeld niet de laatste zijn) en zulke producten zouden dan ook niet op de markt mogen worden losgelaten.

Stel je voor dat een autofabrikant morgen een auto op de markt brengt met security risico's waardoor de autodeuren niet sluiten maar je wel een klik hoort of je airbag 'soms' kan falen.

[YopY]

Dus, als het slot van je deur stuk is, ga je briefjes ophangen waarop je zegt 'Kijk, m'n slot is stuk, zo kom je binnen'? Lijkt me sterk. Natuurlijk doen ze dat niet, en het is ook geen 'security through obscurity', daar het just niet veilig is. Ze voorkomen een wildgroei van aanvallen op alles en iedereen hun PC's juist door niet precies te vertellen hoe de bug werkt, net zoals jij voorkomt dat iedereen je huis binnenkomt om je zooi te jatten door niet te laten merken dat je deur los staat. Dit doen ze net zolang tot er een fix is, en deze fix verspreid is. Daarnaa kunnen ze mogelijk, voor de geïnterreseerden de bug bekend maken.

[Verwijderd]

Vooralsnog is het gebruik van de beveiligde modus van IE onder Windows Vista of Windows 7 de enige manier om de kans op misbruik te minimaliseren. Uiteraard kan ook een andere browser worden gebruikt. De beveiligde modus wordt standaard gebruikt voor html-mails in de mailprogramma's van Microsoft op Vista en Windows 7; wel zijn gebruikers dan nog kwetsbaar als ze op een link klikken die naar een website met exploitcode verwijst.

Of je gebruikt gewoon firefox (of chrome of opera)

[Cedrix9000]

Dat zeggen ze toch : ^{Uiteraard kan ook een andere browser worden gebruikt.}

Hoe heeft MS deze lek kunnen missen, vanaf versie 6! Dat er maar snel een patch komt, want dit is onverantwoordelijk.

Gebruik zelf gewoon firefox.

[Reactie gewijzigd door Cedrix9000 op 23 juli 2024 21:31]

[Verwijderd]

Ter verduidelijking van in hoeverre MS heeft gefaald:

De bug in Internet Explorer maakt het injecteren van code mogelijk wanneer een een object uit het geheugen wordt verwijderd, terwijl er nog wel verwijzingen naar bestaan.

Technische term: dangling pointers.

Normaal worden de verwijzingen weer teruggezet op een adres wat nooit geldig kan zijn (meestal "null"), zodat het gebruik van de verwijzing een crash oplevert in plaats van onvoorspelbare effecten. Iemand is dit dus ergens vergeten te doen.

Dangling pointers kunnen relatief eenvoudig opgespoord worden, vooral als je de beschikking hebt over de debugging symbols van IE6 (een slap aftreksel van de broncode ervan). Driemaal raden wat Microsoft gratis en voor niets ter download aanbiedt, en dus ook aan hackers.

De reden dat het waarschijnlijk niet is opgelost, is omdat het misbruiken van dangling pointers op het eerste gezicht niet triviaal lijkt te zijn.

[johnbetonschaar]

Ik heb niet echt een hoge pet op van de IE broncode, maar met deze summiere informatie concluderen dat ergens een dangling pointer wordt achtergelaten naar een stuk geheugen dat je via een HTML document kunt beschrijven met uitvoerbare code, dat is wel erg kort door de bocht. Het zou in theorie best kunnen maar er zou in theorie ook prima iets volkomen anders aan de hand kunnen zijn hier. Sowieso is het veel te makkelijk gesteld dat iemand vergeten is een pointer te NULL-en bij het vrijgeven van een object (wat trouwens ook helemaal niet gebruikelijk is in C/C++ code, hoewel het wel netter is om het te doen). Het kan prima dat een volkomen ander stuk IE code of van mijn part code uit een compleet andere DLL of module nog een pointer naar een gedelete object heeft, C/C++ pointers werken maar 1 kant op dus het is vaak helemaal niet mogelijk om vast te stellen of ergens nog verwijzingen naar een object staan voordat je het delete.

Wat ik ook niet helemaal snap is hoe de debug symbols kunnen helpen om dangling pointer exploits te vinden. De debug symbols bevatten alleen maar de namen en locaties van functies en variabelen die globaal of static zijn, niet van alle variabelen, objecten en klasses die op runtime worden aangemaakt.

[Verwijderd]

Het geciteerde stuk van het artikel is bij mijn weten precies de beschrijving van een dangling pointer, en ik denk dat dat stuk weer een vertaling is van een bericht van Microsoft zelf.

Het is niet minder dan verstandig om relevante pointers zo snel mogelijk op een sentinelwaarde te zetten zodra er iets gedelete is. Je kunt tijdens het ontwikkelen van software soms rare bugs tegenkomen, die je pas gaat snappen zodra je dangling pointers gaat NULLen of er nog zelfs een Monitor pattern tegenaan gooit. Dangling pointers zijn acceptabel als je zeker weet dat je ze nooit aanraakt, maar die aanname kun je in sommige gevallen gewoon niet maken. Vooral als de aanname bugvrijheid van andere delen van je code vereist. Ze overschrijven is nuttig, ze niet overschrijven is vroegtijdige optimalisatie.

Verder moet je niet onderschatten hoeveel informatie er in een PDB (Program Database, het formaat voor debug symbols van MS) past. Als je user-defined types erin kunt passen én je hebt informatie over lokale variabelen op de stack, dan mag ik toch aannemen dat je een hoop introspectie kunt verrichten met deze informatie. Uiteraard ligt het er natuurlijk aan welke opties MS heeft meegegeven bij het maken van de debug symbol-bestanden -- dat zou ik dan weer niet weten.

En daarbij, ik heb het nooit over beschrijven gehad, en het artikel ook niet. Ze kunnen het verwijderde stuk geheugen wellicht ook gelezen hebben; niet alle implementaties van free() trashen het (complete) stuk verwijderde geheugen.

[Xeon_vl]

Het is niet zo eenvoudig als jij het hier stelt. In het ideale geval waar je slechts één pointer hebt naar en stuk geheugen is het inderdaad piece of cake, helaas worden vaak pointers doorgegeven aan functies en sinds de opkomst van OO blijven die vaak ook zitten in objecten. Als je dan ergens in object A dat geheugen terug vrij geeft zijn er misschien nog 10 objecten ergens anders in je programmatuur waarin pointers zitten die ondertussen dangling zijn geworden en die objecten weten dat niet, tenzij je ze het verteld. Vaak geeft dit aanleiding tot "random crashes" (want een dangling pointer dereferen gaat nu eenmaal fout) omdat meestal maar een bepaalde situatie aanleiding geeft tot een fatale afloop en het lijkt erop dat dat ook hier zo is als ik lees dat er "speciaal vervaardigde html" voor nodig is.

De vraag: wie beheert welk geheugen is bij het programmeren cruciaal. Een simpel antwoord als "diegene die het alloceert" bestaat gewoonweg niet. Soms is het zelfs bijzonder moeilijk om een correcte verantwoordelijke aan te duiden voor veilige delete operaties.

Het is niet voor niks dat sinds TR1 er voor C++ een nieuwe template shared_ptr is opgedoken. Die houdt zelf het aantal pointers dat nog bestaat naar een bepaald object bij en kuist op voor jou. Een vorm van garbage collecting dus.

(ps ik ben verre van een ms fan maar de problematiek van dangling pointers is er nu eenmaal voor iedereen)

[johnbetonschaar]

Het is niet voor niks dat sinds TR1 er voor C++ een nieuwe template shared_ptr is opgedoken.

Kleine correctie: shared_ptr is niet zomaar opgedoken, maar een verbetering van de reeds bestaande STL auto_ptr, die eigenlijk voor hetzelfde bedoeld was maar helaas niet zo goed ontworpen waardoor je hem heel makkelijk verkeerd kon gebruiken. De Boost C++ libraries hebben ook al jarenlang dezelfde shared_ptr als dat nu in TR1 terecht zou komen.

[chime]

Zoals veel bugs gemist blijven in alle programmacode.

Als niemand de code aanroept of er misbruik van maakt, dan gaat niemand ervan af weten hé.

In alle programmatuur zit fouten.

[OddesE]

In alle programmatuur zit fouten.

Niet waar. Door dat maar te blijven zeggen blijven we excuses maken voor rotzooi producten. Het is wel degelijk mogelijk om 100% foutvrije code te schrijven. Het krijgt gewoon nog geen prioriteit.

Toegegeven het is ook heel erg duur. Zo waren de mensen van het L4.verified project 4 jaar bezig om 8,700 regels C code plus 600 regels ARM assembly code te verifiëren (wiskundig bewijzen dat het correct is). Ter vergelijking, een product waar ik op mijn werk aan ontwikkel bevat iets meer dan 600.000 regels Delphi code (vergelijkbaar met C, maar dan iets hoger abstractie niveau).

Maar het werk aan L4.verified is af en die 8.700 regels C code zijn dus echt helemaal foutvrij. Het kan dus wel.

Voor de geïnteresseerden, L4 is de naam van een operating system kernel. Net zoiets als Linux dus. Aan alleen een kernel heb je niets, maar het is wel de belangrijkste code in een OS. Als in de kernel een dikke fout zit kan in principe geen enkel programma op het systeem nog betrouwbaar draaien. Vandaar dat ze daarmee zijn begonnen dus.

[Haan]

Je spreek jezelf tegen. Als het al vier jaar kost om van 8700 regels code te bewijzen dat deze bugvrij is, dan zou het (600.000 / 8700) * 4 = 275 jaar kosten voor jouw project (en dan ga je er nog vanuit dat de complexiteit lineair is, terwijl dat eerder exponentiëel zal zijn). Met andere woorden, onmogelijk om te garanderen dat het bugvrij is

[Grijze Vos]

Daarnaast bewijs je dan nog steeds alleen maar dat die code volgens de specificatie correct is. De specificatie zelf kan dan nog steeds fout zijn.

[Goderic]

Natuurlijk kun je bugvrije code schrijven, "Hello world" is ook bugvrij.

Als je complexe programma's schrijft is het onmogelijk om 100% zeker te zijn dat het bugvrij is, of zou jij 400 jaar willen wachten om zeker te zijn dat jouw product bugvrij was?

[BlackHawkDesign]

Er zitten nog heel veel lekken die nog niet bekend zijn en ook dus door Microsoft gemist worden Zo gek is het dus niet. P.s: Ook in andere software zitten lekker, je kan als programmeur gewoon niet zien..

[Rhapsody]

Als deze bug er al vanaf IE6 in zit en NU pas misbruikt wordt....

Bugvrije software bestaat niet.

[elmuerte]

De bug is nu pas ontdekt nadat het recentlijk veel misbruikt is bij de verkeerde personen/sites.

[BeosBeing]

Die bug wordt mischien wel al sinds september 2001 misbruikt, maar is bij malafide personen bekender geworden en wordt pas recentelijk veel misbruikt, en dan komen er ook meer mensen die het merken enzovoorts.

En bugvrije software bestaat wel, echter zoals OddessE schrijft is het heel duur en tijdrovend om wiskundig te bewijzen dat een stuk software gegarandeerd bugvrij is.
(en dan heb je het nog niet over de specificatie)
Zou men de moeite steken in het verifieren van de GNU tools, dan zouden waarschijnlijk veel, voornamelijk oudere, uitontwikkelde programma's, ook kwalificeren. Aan die tools is echter voor een programmeur/ontwikkelaar heel weinig eer te behalen.

Bugvrij op praktisch niveau is echter een stuk haalbaarder, echter dan moet het wel een prioriteit zijn, en niet, zoals in de praktijk, onder druk van commercie, nieuwe features, deadlines, en behoefte aan winstgevendheid opzij gezet worden.

Op een gegeven moment is de grootste foutenbron de gebruiker zelf en merk je van eventuele bugs in het programma niets meer, of is de bug dusdanig bekend dat deze ten alle tijde elders wordt afgevangen.

[Verwijderd]

nee, er is nu pas ONTDEKT dat er misbruik van is gemaakt....

het kan al jaren spelen....

[OddesE]

Bugvrije software bestaat niet.

Zoals meestal met misverstanden en mythen zijn ze hardnekkig.

Bugvrije software bestaat wel! Zie mijn comment hierboven en check het L4.verified project.

De OS kernel is pas stap één. Deze mensen zijn bezig om stukje bij beetje een volledig foutvrij besturingssysteem te bouwen. Jij zegt dat het niet kan, zij doen het gewoon.

[Distael]

Leuk voor ze. Echter in de echte wereld bestaat een programma als IE uit wel wat meer dan 8600 regels. Door nieuwe technieken en mogelijkheden zijn die 8600 regels code na 4 jaar al weer verouderd. Hoeveel jaar wil je wachten voordat een nieuwe versie van IE uitkomt? Dat is toch gewoon niet werkbaar.

Windows bestaat uit miljoenen regels code, over hoeveel jaar is jouw project zover dat het dezelfde functionaliteit heeft als windows? Het blijft een afweging tussen een werkbaar OS wat we nu kunnen gebruiken en veiligheid. We hebben niets aan een 100% veilig OS wat we pas over 100 jaar kunnen gaan gebruiken en wat dan allang is achterhaald.

[berend_engelbrecht]

Nog iets: ook in technisch "bugvrije" code kan zeker functionaliteit zitten die niet naar de zin van elke gebruiker is. De gebruiker ziet functionaliteit die werkt zoals bedoeld vaak als een bug, terwijl de programmeur van mening is dat het een feature is. Je kan het nooit iedereen naar de zin maken, dus er zullen ook als het "echt bugvrij" is nog steeds mensen zijn die je code als buggy zien. Als je naar de optieslijst van een ouder programma als MS Word kijkt zie je hoe commerciële programmeurs daar omheen werken - je bent gedwongen om tientallen obscure opties te maken om dat soort assertieve klanten te plezieren.

[BeosBeing]

Ik denk dat je niet dezelfde functionaliteit als windows moet willen bieden. Beter is om die functionaliteit te bieden die zinvol is binnen de context waarin het gebruikt gaat worden.

Een 100% bugvrij/veilig OS is mischien dan zinvol in embedded toepassingen, dat is iets dat we nu nog niet kunnen overzien, feit is wel dat de chips dan veel krachtiger zullen zijn en met dit os weinig moeite zullen hebben.

Echter nu hebben we nog niets aan iets dat over 100 jaar pas klaar is, dat is waar.

[BeosBeing]

Alleen kost het ontzettend veel tijd (en geld) en willen de meesten daar niet op wachten en verder gaan met nieuwe features en nieuwe versies waaraan meer eer is te behalen en (naar men denkt) meer geld mee te verdienen.

[Verwijderd]

tja dat had ik al niet meer gelezen, ik ging al af op de omslachtige methode om het dan maar in safemode te draaien.

[airell]

Ik denk dat men het over UAC heeft... aanzetten dus.

Edit: @teek2: uiteraard heeft XP geen UAC, maar dan is 'safemode' in XP net zo lek.

[Reactie gewijzigd door airell op 23 juli 2024 21:31]

[teek2]

Bestaat ie6 op vista? Volgens mijn niet en XP heeft geen uac...

[musiman]

quote: teek2

Bestaat ie6 op vista? Volgens mijn niet en XP heeft geen uac...

Het lek bestaat VANAF versie 6 van IE...

[Reactie gewijzigd door musiman op 23 juli 2024 21:31]

[OddesE]

Hoewel de bug in alle Internet Explorer-versies vanaf 6.0 aanwezig is, werd alleen misbruik van de 6.0-versie vastgesteld.

De bug zit dus ook in IE6.

[HoeZoWie]

Alle bugs zitten in IE6, IE6 is één grote BUG (grapje)

[Reactie gewijzigd door HoeZoWie op 23 juli 2024 21:31]

[Xirt]

Volgens mij kan je IE6 gebruiken door virtueel een versie van Windows XP te draaien onder Windows Vista (die wordt door MS zelf aangeboden om ontwikkelen van IE6 mogelijk te maken). Maargoed, de bug zit blijkbaar ook in nieuwere versies van IE (dus ook onder Vista en 7), maar is nog niet misbruikt daarin.

[musiman]

wanneer UAC uitgezet wordt, gaat ook de IE browser niet meer in protected mode draaien, wat betekent dat hij niet meer op het laagste securitylevel opereert waar hij bijna geen rechten in het systeem had. In plaats daarvan draait IE dan in hetzelfde securitylevel als die van standaard gebruikers, met alle gevaren van dien.

Wanneer je een hekel hebt aan UAC, maar toch die protected mode van IE aan wilt laten staan, dan kun je middels een group policy aangeven dat je de UAC meldingen niet meer wilt zien. UAC werkt dan nog wel, maar je krijgt de toestemmingsverzoeken niet meer. Natuurlijk is dit minder veilig dan wanneer je de meldingen aan liet staan, maar IE kan in ieder geval in protected mode blijven draaien.

[OddesE]

Fuck IE en zijn protected mode. Door hoeveel hoepels wil je springen om maar de slechtste browser te blijven gebruiken??

Download gewoon Opera, Safari, Chrome of Firefox en be done with it. Veel meer security doordat er geen ActiveX wordt gebruikt voor plug-ins en het niet verweven is met het OS.

En doordat je niet meer met de n00b-browser werkt nooit problemen. Zelfs als Firefox en IE allebei 50% marktaandeel zouden hebben zou IE nog meer aangevallen worden, puur omdat alle beginnende gebruikers daarmee werken. Die zijn toch net iets geneigder om "plaatje.jpg.exe" te dubbelklikken, of OK te klikken bij security waarschuwingen.

Ik wacht geduldig op de dag dat de rem van het WWW af gaat. Dat de webstandaarden zich hebben bevrijd van de ketenen van IE en de vooruitgang zoals we die een paar jaar geleden zagen weer terug komt. Aan de andere browsers zal het niet liggen, die staan te trappelen van ongeduld. Maar IE is geen beweging in te krijgen. IE8 haalt nog steeds niet de Acid2 test?!? Laat staan Acid3!

Niet blijven trekken aan een dood paard. Move on.

[xzaz]

Niemand is verplicht om 100% te halen bij de Acid tests, ook Microsoft niet. Maar inderdaad het blijft verdomd makkelijk wanneer ze zich in ieder geval richten op het halen van hoge scores.

[Tomba]

Nou nou nou, relax Max, euhm OdessE
Dat velen ^{(waaronder ik)} IE8 goed genoeg vinden voor 'normaal' surfen maakt het echt geen n00b browser hoor !.
Ik heb persoonlijk ^{(en naar mijn bescheiden mening is een browser voorkeur ook precies dat; persoonlijk)} meer problemen gehad met Firefox dan met IE8. Firefox komt er bij mij dus nooit meer op. (als ik een alternatieve browser wil gebruik ik veel liever Opera )

Daarnaast; hoe je er bij komt dat IE8 de Acid2 test niet haalt is mij overigens een raadsel

[Verwijderd]

Bij voorkeur zou ik toch ook aantal lekken in een browser meenemen.

[Verwijderd]

UAC en de protected mode zijn juist hét middel tegen browser problemen. exploits zijn altijd mogelijk, en komen ook wel degelijk voor in Opera, safari, chrome en firefox. Een andere browser is dus geen serieus alternatief, het verplaatst alleen het probleem.

Het mooie van UAC en protected mode is juist, dan zo'n exploit in browser dan nog steeds niets gevaarlijks kan doen. Dat is dus precies de manier waarop je security wilt opbouwen. Alleen vertrouwen op de browser is gewoon dom, je wilt een dubbele security laag.

[BeosBeing]

Nou dat betekend een goede browser zonder active-X én een goede security-laag (dus apps draaien niet in su-mode) en waar vind je dat, onder andere
- Unix, inclusief Linux, xBSD, waarschijnlijk ook bij OS-X alhoewel Apple daar consessies gedaan zou kunnen hebben.
- Windows NT-family mits je als beperkte gebruiker werkt én de apps ook met beperkte rechten werken. Helaas zijn er nog steeds apps die dan niet goed werken, inclusief MS-apps. Ook draaien heel veel services met te veel rechten (ondanks dat pas opgestart worden bij inloggen. Veel security-apps zoals firewalls worden ook pas opgestart na inloggen zodat een opgestarte machine waar niet ingelogd is soms volledig ter beschikking staat van eventueel aanwezige malware.

Kortom, met een andere browser is de beste keus, al moet die net zo goed met beperkte rechten werken als IE. Helaas voor IE is dat met beperkte rechten werken, door de verwevenheid in het OS niet goed mogelijk, waardoor er lapmiddelen moeten worden toegevoegd als UAC. UAC en protected mode (heeft firefox ook) kunnen uiteraard ook een andere browser veiliger maken. Dan pas heb je een dubbele security-laag, ahoewel, als je het systeem van UAC+IE+protected mode al als dubbele security-laag aanmerkt, dan is beperkte-rechten+UAC+andere browser al een driedubbele, en met als andere browser firefox en diens protected mode vierdubbel.

[Nickname55]

Je hoort wel eens zeggen dat Linux moeilijk is ...

[Verwijderd]

uit het artikel: De IE-exploit is volgens Microsoft echter niet de enige gebruikte aanvalstactiek.

Misschien heeft de chinese overheid ook wel exploits voor firefox, chrome en opera, wie zal het zeggen?

[scorpie]

Als Microsoft dat zou weten, zouden ze niet alleen zichzelf in de vingers snijden dat hun browser gebruikt werd voor de hack, maar ook andere browsers.

(Dat de Chinese overheid wellicht ook exploits gebruikt die icm andere browsers werken kan natuurlijk alsnog, denk alleen niet dat Microsoft dat dan zou weten.)

[BeosBeing]

En voor wie geen Win7 of Vista heeft, en dus geen beveiligde modus...

Hoewel de bug in alle Internet Explorer-versies vanaf 6.0 aanwezig is, werd alleen misbruik van de 6.0-versie vastgesteld.

en toch per sé IE wilt gebruiken moet dan toch maar terug naar een nog oudere versie: IE5.5 Dat wordt WINE of virtualisatie (W98/NT4) gebruiken.

[rbtje1]

Wel wrang voor Microsoft dat een fout in hun software gebruikt is om een concurrent schade toe te brengen

[Verwijderd]

Wat dat betreft wel netjes van MS om hun fout toe te geven, ze hadden ook met 'n vingertje naar Google kunnen wijzen dat hun security niet goed is.

[Little Penguin]

Op het moment dat een derde het (ook) beweert, dan kun je maar beter toegeven ipv voor jezelf een nog grotere schade aan te richten door het te ontkennen.

[YopY]

Reken er maar op dat ze daar ondertussen in getraind zijn. Maar ze moeten wel - ze hebben miljarden gebruikers, en niemand kan bugvrije software garanderen (of, niet zonder dat de kosten buitenproportioneel worden), zelfs als ze aan de hoogste kwaliteitseisen voldoen (zoals raketten, die soms nog stuk gaan door programmeerbugs).

[Brantje]

Hoewel de bug in alle Internet Explorer-versies vanaf 6.0 aanwezig is, werd alleen misbruik van de 6.0-versie vastgesteld.

Vanaf versie 6?!?!?!?
Volgens mij moeten de beta testers + developers een goede keuring krijgen.
Maar iedereen weet tegenwoordig wel dat IE zo lek als een rietenmand is.

Mooi dat Gmail nu standaard https gebruikt.

Geef mij maar liever Firefox dan IE

offtopic:
Dat is ook een reden waarom ik firefox portable altijd bij me heb

[Flowmo]

https in Gmail moet je zelf handmatig aanzetten, wat ik dus zelf van de week ook heb gedaan.

Zou het sowieso aanraden aan iedereen die het nog niet gedaan heeft.

[Little Penguin]

De vraag is of het helpt als je lokale gegevens uitgelezen worden. HTTPS versleuteld namelijk alleen het verkeer tussen de server en de browser op jouw computer.

Op het moment dat je het lokaal gaat renderen moet de browser de boel decoderen en als je gegevens dan via een lokale exploit gelezen worden helpt ook HTTPS-verkeer niet meer.

[OddesE]

De vraag is of het helpt als je lokale gegevens uitgelezen worden.

Bingo! Dat helpt dus inderdaad niet. Het artikel spreekt over code injectie. Dus de lokale machine van de gebruiker wordt gecompromitteerd. Daarna kunnen ze het password uitlezen dat je hebt opgeslagen, of het password live uitlezen terwijl je het intoetst als je inlogt, of na inloggen je sessie cookie stelen zodat ze vanaf een andere machine je sessie kunnen overnemen, of gewoon de responses van al je pagina's doorsturen.. de mogelijkheden zijn eindeloos. Https heeft daar niets mee te maken, want jouw machine heeft natuurlijk gewoon de key.

[berend_engelbrecht]

De https-verbinding helpt niet tegen deze hack, maar wel tegen het routinematig afluisteren van het verkeer van klanten van Google. Google gelooft dat klanten in China daar ook slachtoffer van zijn geworden (lees Official Google Blog: A new approach to China), en heeft daarom besloten tot de https-maatregel. Overigens helpt het ook niet tegen de primaire manier van afluisteren die ze noemen:

we have discovered that the accounts of dozens of U.S.-, China- and Europe-based Gmail users who are advocates of human rights in China appear to have been routinely accessed by third parties. These accounts have not been accessed through any security breach at Google, but most likely via phishing scams or malware placed on the users' computers.

[Reactie gewijzigd door berend_engelbrecht op 23 juli 2024 21:31]

[Phoenix1337]

Volgens het artikel zou dit nu standaard aan moeten staan, hoewel dat mij niet het geval is. Als ik gmail.com intyp krijg ik een niet beveiligde http verbinding.

[geniusboxen]

Wel waneer je ingelogt bent in GMail.

[Rhapsody]

Intussen heeft Google de beveiliging van Gmail aangescherpt; gebruikers hebben nu standaard een beveiligde verbinding via https. De https-verbinding was al langer optioneel beschikbaar, maar stond standaard uit. Hoewel het voor de hand ligt, heeft de zoekgigant niet bevestigd dat de verscherpte beveiliging een gevolg van de Gmail-hack is.

Staat dus nu voor iedereen aan.

[Reactie gewijzigd door Rhapsody op 23 juli 2024 21:31]

[SunnieNL]

Even niet over msie en de bug...

Ik vind het verdomd slecht dat Google niet standaard op https zat en dus blijkbaar hiervoor altijd standaard de onbeveiligde http gebruikte. Maarja, daar hoor je ze dan natuurlijk niet al te hard over schreeuwen, dat de informatie van gebruikers (mail, wachtwoord) eigenlijk standaard onbeveiligd over het lijntje heen ging....

[mmjjb]

Inderdaad, daar hoor je niemand over.

Hoezo onveilig.
En bovendien ie8 staat standaar in niet admin modus dus kan geen systeem weizigingen aanbrengen (tenzij je zo dom bent om hem met admin uac te runnen)

Dus kan wel bug in zitten maar invloed voor je eigen pc kan het niet hebben

[Verwijderd]

Overigens... Veel MUA's hebben ook niet standaard POP over SSL aanstaan. (terwijl 9 van de 10 POP servers het wel ondersteunen)

[Reactie gewijzigd door Verwijderd op 23 juli 2024 21:31]

[Verwijderd]

ach ja, al dit gebash op IE,

IE heeft gewoon al jaren een extreem groot marktaandeel, dus ideale favoriet voor exploitzoekers en dergelijke. Daardoor worden immens veel exploits effectief ook gevonden, waardoor het lijkt dat IE zo lek is als een zeef.

echter, firefox en dergelijke zijn ook maar gemaakt door mensen en zullen bijgevolg ook een massa aan onvoorspelbare en exploiteerbare code bevatten. Gewoon doordat firefox minder lang bestaat zijn er nog niet zo veel gevonden, wat de illusie wekt dat er veel minder gaten in zitten.

Pas op, ik zeg niet dat firefox zo lek is als een zeef, ik zeg gewoon dat de kans reeel is dat het zo lek is als een zeef, net als alle, inderdaad ALLE, internetbrowsers. Het veiligste lijkt mij gewoon een browser te gebruiken die relatief weinig marktaandeel heeft en dus geen aantrekklijk doelwit is voor hackers,( chrome, safari, ...) alhoewel, als iedereen dit begint te doen zitten we natuurlijk met de paradox dat dit juist weer wel gevaarlijk gaat worden...

Draai en keer het hoe je wilt, gezond verstand blijft nog altijd primeren ^^

[arjankoole]

ik zeg gewoon dat de kans reeel is dat het zo lek is als een zeef

Hoewel je zeer zeker een (zeer logisch) punt hebt: het hoeft niet zo te zijn.

Firefox, doordat het opensource is en er veel ontwikkelaars bij betrokken zijn, kan best scherp hierop gelet hebben. Bij Microsoft vrees ik dat je toch een te maken hebt bij een typisch Amerikaanse corporate culture, waarbij de ontdekker van een exploit z'n bevinding indient, maar dat om bedrijfs economische redenen (budget, tijd, etc) geen fix ontwikkeld wordt, of gereleased wordt.

Het is niet de eerste keer dat Microsoft (en met Microsoft vele, vele andere bedrijven) al lang weet van een exploit, en pas een fix ontwikkeld en released bij actief gebruik in 'het wild'. Mede daarom releasen sommige ontdekkers soms de proof-of-concept code na verloop van tijd, om het bedrijf in kwestie (en wederom, echt niet alleen Microsoft zit zo in elkaar) te dwingen wat te doen.

[BeosBeing]

Als er maar genoeg browsers zijn is er geen een nog interessant genoeg om een exploit voor te maken, simpelweg omdat deze niet wijd genoeg versprijd kan worden om voldoende opbrengsten te genereren.

Wel moeten websites dan ook goed met alle browsers werken, maar die houden zich allemaal aan de standaard, dus dat is dan ook geen probleem, tenzij er een exploit vanuit de standaard is opgelegd.

[blorf]

Ik snap het niet helemaal. Was het nou een ddos-aanval op Google die door die exploit mogelijk gemaakt word? Dan moet er al een flink zombie-netwerk zijn van IE6-machines die een script oid draaien. Voordat Google daar last van heeft...
En als het geen ddos-aanval is, hoe kan het dan Google lastig vallen? Die hebben de beveiliging van hun domeinen wel aardig in orde dacht ik.
Dus wat is er nou echt aan de hand?

[BeosBeing]

Er is helemaal geen sprake van ddos. Men heeft gepoogd gmail-accounts te benaderen en deels is dat gelukt. Men heeft daarbij blijkbaar gebruik gemaakt van informatie verkregen door lokale pc's te hacken door gebruik te maken van deze bug in IE.

Ik hoop dat ik het zo goed samenvat.

[blorf]

Ok, maar waarom is er dan nog sprake van een aanval op Gmail? Als je de login gegevens hebt, gejat of niet, hoef je niks meer aan te vallen.
IE 6 is dus gewoon misbruikt om in te breken en gegevens te jatten. Doordat de dader via de zelfde verbinding waar hij de hack mee deed ook inlogde op Gmail met de verkregen login gegevens viel hij door de mand?. Komt nogal amateuristisch over.

[Reactie gewijzigd door blorf op 23 juli 2024 21:31]

[shadow1967]

Deze mini browser oorlog die mensen denken te voeren over de welke browser het beste is, is er echt over. Het getuigd van weinig zin voor realiteit om te denken dat er een browser ontsnapt aan buggy code en exploits. Het is bovendien algemeen geweten dat de zwaktste schakel van een browser zijn plug-ins zijn. Ik zie hier niemand schieten op de ontwikkelaars hiervan. Mensen kiezen vooral hun browser zoals het hen uitkomt. De techneuten hebben een sterke voorkeur, degene die ontbreken aan enige technische kennis kiezen voor het gemak zonder zich te druk te maken over welke browser nu de 'beste' is.

De beste software bestaat niet, enkel de minst slechte. Het is oeilijk een objectieve keuze te maken want iedereen gebruikt zijn eigen criteria.

Men kan enkel voorzichtig zijn en zijn gezond verstand gebruiken bij het installeren van plugins en het bezoeken van websites. Boven alles: Blijf patchen !

[shadow1967]

Ruben314
99% vd eindgebruikers uit deze statistieken hebben niet de kennis om te gaan 'isoleren' en degene die het wel kennen gebruiken het niet. Zolang er geen gebruiksvriendelijke (lees tranparant) opzet komt van deze methode is er weinig kan op slagen.