Microsoft: lek in IE gebruikt bij aanvallen op Gmail

Reacties

« 1 2 3 »

Door 140398, vrijdag 15 januari 2010 14:53

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)

Door Cedrix9000, vrijdag 15 januari 2010 14:57

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 vrijdag 15 januari 2010 15:12]

Door 140398, vrijdag 15 januari 2010 14:58

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

Door airell, vrijdag 15 januari 2010 15:08

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 zaterdag 16 januari 2010 13:45]

Door teek2, vrijdag 15 januari 2010 15:35

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

Door musiman, vrijdag 15 januari 2010 15:44

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 vrijdag 15 januari 2010 15:45]

Door OddesE, vrijdag 15 januari 2010 21:10

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.

Door HoeZoWie, maandag 18 januari 2010 00:28

Alle bugs zitten in IE6, IE6 is één grote BUG

(grapje)

[Reactie gewijzigd door HoeZoWie op maandag 18 januari 2010 00:28]

Door Xirt, vrijdag 15 januari 2010 21:01

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.

Door musiman, vrijdag 15 januari 2010 15:43

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.

Door Nickname55, vrijdag 15 januari 2010 18:18

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

Door OddesE, vrijdag 15 januari 2010 21:21

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.

Door xzaz, vrijdag 15 januari 2010 22:34

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.

Door Tomba, zaterdag 16 januari 2010 10:06

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

Door kiersie, zaterdag 16 januari 2010 19:11

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

Door AHBdV, zondag 17 januari 2010 09:48

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.

Door BeosBeing, dinsdag 19 januari 2010 10:51

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.

Door chime, vrijdag 15 januari 2010 15:14

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.

Door OddesE, vrijdag 15 januari 2010 21:39

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.

Door Goderic, vrijdag 15 januari 2010 23:26

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?

Door Haan, zaterdag 16 januari 2010 00:04

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

Door Grijze Vos, zaterdag 16 januari 2010 11:28

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.

Door Rhapsody, vrijdag 15 januari 2010 15:22

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

Bugvrije software bestaat niet.

Door elmuerte, vrijdag 15 januari 2010 15:46

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

Door BeosBeing, dinsdag 19 januari 2010 11:13

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.

Door IoorLTD, vrijdag 15 januari 2010 17:23

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

het kan al jaren spelen....

Door OddesE, vrijdag 15 januari 2010 21:43

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.

Door Distael, zaterdag 16 januari 2010 10:06

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.

Door berend_engelbrecht, zaterdag 16 januari 2010 19:53

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.

Door BeosBeing, dinsdag 19 januari 2010 11:22

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.

Door BeosBeing, dinsdag 19 januari 2010 11:17

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.

Door Tinctorius, vrijdag 15 januari 2010 15:35

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.

Door johnbetonschaar, vrijdag 15 januari 2010 16:19

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.

Door Tinctorius, vrijdag 15 januari 2010 21:50

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.

Door Xeon_vl, vrijdag 15 januari 2010 16:20

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)

Door johnbetonschaar, vrijdag 15 januari 2010 16:44

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.

Door BlackHawkDesign, vrijdag 15 januari 2010 15:59

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..

Door EdwinSchaap, vrijdag 15 januari 2010 22:05

Door dukegoryan, vrijdag 15 januari 2010 14:59

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?

Door scorpie, vrijdag 15 januari 2010 15:21

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.)

Door BeosBeing, dinsdag 19 januari 2010 07:41

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.

Door snek, vrijdag 15 januari 2010 14:54

Door Eonfge, vrijdag 15 januari 2010 17:28

Dacht ik ook meteen: "Daar gaan we weer"

Nu zullen er meteen weer enkele groepen Tweakers ontstaan, zoals altijd gebeurt bij een IE bug. Groep A: Het gebeurt nu eenmaal, geen browser is perfect. Ze proberen er tenminste wat aan te doen. Groep B: Gebruik geen IE. Groep C: Technische 'diedeliedoe', zonder specifiek antwoord. Ik zeg: laat ons superieur en nurdig wezen met Firefox/Chrome/Opera e.d. en laat de andere mensen het lekker zelf uitzoeken.

De meeste computer problemen ontstaan door de hardware tussen het toetsenbord en de stoel. Daar komt ook nog bij dat de drivers van deze hardware meestal snel verouderen en niet in staat is om fatsoenlijk om te gaan met andere pakketten waardoor nog meer fouten ontstaan.

_{EN KONQUEROR IS HET BESTE!}

Door pe1dnn, vrijdag 15 januari 2010 20:10

_{EN KONQUEROR IS HET BESTE!}

Op lynx na natuurlijk...

Door OddesE, vrijdag 15 januari 2010 21:51

De meeste computer problemen ontstaan door de hardware tussen het toetsenbord en de stoel.

Kom op zeg. Door dit te blijven zeggen hou je gebruikers dom. Je zegt: "De software is prima, u snapt het gewoon niet". De werkelijkheid is wel anders. Vaak is de software helemaal niet prima.

De hierboven beschreven bug kan je treffen als gebruiker door op een pagina te belanden waarop de bug wordt geexploiteerd. Dit kan een hyves profiel zijn, een blogpost of noem maar op. Je kunt als gebruiker nooit weten dat/of zoiets op de pagina staat totdat het te laat is. Wat moeten die gebruikers lezen dan volgens jou? Welke cursussen moeten ze volgen? Waarom geef je (impliciet) hun de schuld van een fout in Internet Explorer??

Hele PC weer naar de gort? Dat komt zeker door die domme gebruiker. Moet hij ook maar niet naar die rare sites surfen. Alsof het acceptabel is dat gewoon op een link klikken je PC aan gort kan helpen.

Door BeosBeing, dinsdag 19 januari 2010 11:36

De gebruiker is fout, hij had gewoon nooit IE moeten gebruiken, en zelfs Windows niet want dat is ook absoluut onveilig.

Typte hij vanachter Vista 400 met IE8 omdat ...

P.S ik gebruik ook nog altijd Afga Vista 400 film in mijn fotocamera's (ja die andere, niet de D-slr, die volledig mechanische dus batterijonafhankelijke, altijd werkende slr

Door tehsojiro, vrijdag 15 januari 2010 14:54

Door snek, vrijdag 15 januari 2010 14:56

vanaf IE6, dus als ik het goed begrijp zijn ook 7 en 8 ervoor vatbaar, mitst deze niet in "beveiligde modus" draaien (whatever that might be)..

Door Gepetto, zaterdag 16 januari 2010 15:19

De beveiligde modus van Internet Explorer is een functie waarmee de installatie van schadelijke software op je computer moeilijker wordt.

Naast het bijdragen aan de beveiliging van je computer tegen schadelijke software, biedt de beveiligde modus je de mogelijkheid om gewenste ActiveX-besturingselementen of invoegtoepassingen te installeren wanneer je bent aangemeld als beheerder.

De beveiligde modus is standaard ingeschakeld in de beveiligingszones voor internet, intranet en websites met beperkte toegang. Op de statusbalk wordt een pictogram weergegeven, zodat je weet dat de modus is geactiveerd.

Door retepvosnul, zaterdag 16 januari 2010 20:06

"De beveiligde modus van Internet Explorer is een functie waarmee de installatie van schadelijke software op je computer moeilijker wordt."

hoezo ? Internet Exploder staat er dan toch al op ?

Of gaat het erom dat er dan 1 schadelijk pakket minder geinstallerd kan worden.. omdat Internetniet Exploiter normaliter maar een keer geinstaleerd kan worden ?

Door BreezahBoy, vrijdag 15 januari 2010 14:56

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

niet alleen in IE6 dus...

Door Gamebuster, vrijdag 15 januari 2010 14:56

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

Nog erger...

Vraag me af aan wat voor bug ik dan moet denken.

Door hAl, vrijdag 15 januari 2010 16:15

Een bug die overflows of memory pointer adressen gebruikt.
In IE6 op windows XP verwijzen die naar relatief vaste locaties in memory maar Windows Vista en Windows 7 met IE7 en IE8 gebruiken address space layout randomization waardoor dergelijke bugs veel moeilijker te epxloiteren zijn.

Door Gamebuster, vrijdag 15 januari 2010 18:09

Even 3 keer lezen....

Dus als ik het goed begrijp:
Windows XP heeft een "lineare" manier om geheugen te reserveren voor programma's. D.w.z., dat als internet explorer 6 2 (32bit) integers aanmaakt, dat deze respectievelijk bijv. adres 0x12345678 en 0x1234567B krijgen, waardoor de locatie van deze 2 integers te voorspellen is.
Windows Vista/7 wijst alle variablen een random locatie toe, waardoor de gebruikte locatie niet te voorspellen is. Dezelfde 2 integers kunnen dus aangemaakt worden op 0x18765432 en 0x12436587

Is dat een beetje goed begrepen?

Dan nog vraag ik me wel af wat je met de kennis van de locatie van zulke variablen kan, maar dat heeft denk een aardig lange uitleg nodig, wat ik wel een keer ga googlen als ik me eens verveel.

Door OddesE, vrijdag 15 januari 2010 22:01

Valt mee met die langere uitleg.

Je wil een buffer overflow misbruiken ja? Dus teveel data naar een buffer schrijven zodat je eruit loopt en het stack-frame in. Daar overschrijf je de return instructie-pointer naar een locatie waar je je eigen code hebt klaargezet. De code loopt af, hij wil returnen en springt dan mooi naar jouw code. Vanaf daar kun je dan de hele PC overnemen als de gebruiker (net zoals iedereen) als Administrator is ingelogd.

Eerst even een rootkitje installeren zodat het virus niet zo makkelijk er af gegooid kan worden... Symantec/Norton even uit zetten... een servertje installeren zodat hij op het netwerk gaat luisteren naar instructies naar jou... Een key-loggertje zodat je alle passwords kunt onderscheppen die hij gaat intypen... Webcam en microfoon aanzetten en een beetje afluisteren... De mogelijkheden zijn eindeloos. Maar ach ja het is maar een bug in IE he.

Die domme gebruikers moeten ook niet op die linkjes klikken.. Alsof het niet heel makkelijk is om die op betrouwbare sites te laten verschijnen...

Door Gepetto, zaterdag 16 januari 2010 15:31

Daar overschrijf je de return instructie-pointer naar een locatie waar je je eigen code hebt klaargezet.

En dat is voor iedereen die weet hoe je een telefoonnummer moet draaien natuurlijk ook te doen he.

Zoals vaak is de gebruiker weer de zwakste schakel. Mensen die ik ken die netjes alle Windows updates installeren en niet altijd maar als administrator inloggen hebben namelijk nooit problemen met virussen. Waarom zou je iets anders doen? Je roept nu tegen mensen dat ze een ander slot in hun voordeur moeten zetten, terwijl je weet dat een bepaalde groep mensen hun voordeur toch altijd open laat staan. Beetje kansloos.

Ik heb trouwens maar niet op een van jouw linkjes geklikt, ik weet niet wie je bent en voor hetzelfde geld probeer je iets met phising. (Logisch nadenken kan ook een hoop ellende besparen

)

[Reactie gewijzigd door Gepetto op zaterdag 16 januari 2010 15:32]

Door BeosBeing, dinsdag 19 januari 2010 11:52

True, maar omdat veel apps altijd alleen werkten onder administrator-modus blijven mensen dat gewoon doen en leren ze het nooit af. Enkel het principe van Ubuntu (root disabled, altijd sudo gebruiken of terminal-venster met su, en gelimiteerde lijst van sudo-ers) helpt een beetje.

De realiteit is dus dat vijwel iedereen werkt als Administrator, sommige mensen noodgedwongen automatische updates uitschakelen (bij xp wordt een oude pc al ontzettend veel trager daarvan, bij vista functioneert dan opeens hardware niet meer) en virusscanners ook niet alle troep tegenhouden, maar wel alles vertragen.

Met logisch nadenken kun je daar allemaal mee weg komen. Echter als er acties gebeuren waarover je geen controle hebt (bv automatisch downloaden en openen van een html-e-mail of onveilige bijlagen in bv Outlook, Outlook express (preview window) maakt je wel kwetsbaarder.

Door BeosBeing, dinsdag 19 januari 2010 11:39

En IE7 (of

op XP dan?

Door dutchonline, vrijdag 15 januari 2010 14:56

Of je gebruikt gewoon firefox (of chrome of opera)
..........................................................

Ja en die zijn wel veilig,???? moet ik nog zien.

Door 140398, vrijdag 15 januari 2010 15:01

wel voor deze exploit dus , maar als je echt veilig wilt zijn moet je nu op alt+f4 drukken

Door PiepPiep, vrijdag 15 januari 2010 15:33

Dat doet niet veel op mijn mac, hoe moet ik nu veilig surfen?

Door itarix, vrijdag 15 januari 2010 15:43

Stekker uit het stop contact.
In geval van laptop de accu er ook uithalen.

Als je gebruik maakt van een bedraade verbinding volstaat een condoom tussen de netwerk port en de netwerk kabel ook.

Door Ventieldopje, vrijdag 15 januari 2010 17:00

Ctrl+Q

Door Gamebuster, vrijdag 15 januari 2010 18:10

CMD+Q

Door lenny_z, vrijdag 15 januari 2010 15:56

Chrome is behoorlijk veilig vanwege het sandbox concept per tab.

Door Rizon, vrijdag 15 januari 2010 16:14

Door IoorLTD, vrijdag 15 januari 2010 17:24

Door 140398, vrijdag 15 januari 2010 18:26

het maakt geen donder uit of het in een sandbox draait of niet. Het is een aanval op je google account, niet een poging je pc te besmetten.

Door OddesE, vrijdag 15 januari 2010 22:05

Nee zo lees ik het niet.

De bug in Internet Explorer maakt het injecteren van code mogelijk

Dit suggereert dat men wel degelijk de PC van de gerbuiker kan besmetten. En dat is natuurlijk ook een hele makkelijke manier om de gmail account te hacken. Eén sessie cookie onderscheppen of één password loggen en je bent er. Lijkt me heel wat makkelijker dan de servers van Gmail hacken, dat is zeker!

Door OddesE, vrijdag 15 januari 2010 22:16

Chrome is behoorlijk veilig vanwege het sandbox concept per tab.

Nee dat is onzin. Veiligheid en stabiliteit zijn niet hetzelfde. Als een tabje crashed blijft de rest draaien, ok. Maar de aanvaller heeft maar één crashend tabje nodig. Met één geschikte exploiteerbare fout kan hij forse schade aanrichten, tot aan het overnemen van de hele computer aan toe. Dat de rest van de tabs dan netjes doordraait heb je als gebruiker dan niks aan.

Door BeosBeing, dinsdag 19 januari 2010 11:59

Bij een echte sandbox niet, maar dan werkt het dus echt in een eigen stukje space, en dat is niet zo gebruikersvriendelijk (niets downloaden, niets opslaan, niets printen) maar heeft dan ook geen weet op wat voor OS het daadwerkelijk draait.

Dan nog, kan een fout in de emulatielaag ge-exploiteerd worden.
Browser-sandbox-app-limited_user-os maakt het wel al moeilijker.

Door roller12358, vrijdag 15 januari 2010 18:11

Als je de plugin "Noscript" gebruikt is Firefox wel aardig veilig, standaard wordt er dan geen enkel script uitgevoerd, zelfs geen flash of andere plugins. Bevat ook een goede bescherming tegen XSS.

Je moet dit voor elke pagina activeren of een vertrouwd domein eenmalig whitelisten. Is iets meer werk om een pagina met allerlei scripting ellende op het scherm te krijgen (soms moet je toestemming op 5 domeinen geven om een simpele pagina op het scherm te laten zien) maar ik ben er zeer tevreden over.

http://noscript.net/

Door OddesE, vrijdag 15 januari 2010 22:08

Als je de plugin "Noscript" gebruikt is Firefox wel aardig veilig, standaard wordt er dan geen enkel script uitgevoerd, zelfs geen flash of andere plugins.

En aardig saai!! Vrijwel geen enkele site zal het goed doen.

Als je het dan toch niet erg vindt om het kind met het badwater weg te gooien, volg dan gewoon het advies dat hierboven wordt gegeven: Stekker er uit! Gegarandeerd 100% veilig!

Door BeosBeing, dinsdag 19 januari 2010 12:02

En aardig saai!! Vrijwel geen enkele site zal het goed doen.

Fout van die site dan, is die eigenlijk ook de moeite van het bekijken meestal niet waard. Moeten de makers maar een goed ontworpen site maken wil hij bezoekers trekken en reclame-inkomsten verkrijgen.

Door sundace, zaterdag 16 januari 2010 00:14

dat kun je ook instellen in msie.. sterker nog, dat zit er al wat jaren in.
Alleen zet ms dat standaard niet aan, omdat het nogal wat gevolgen heeft en de hele tijd irritante popups geeft (en daar houdt niemand van)

Door MieJuul, vrijdag 15 januari 2010 15:00

wat is je punt?

er staat : vanaf IE6.0, dus ook de versies erna, tot de meest recente aan toe

Door rbtje1, vrijdag 15 januari 2010 15:01

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

Door xbm360, vrijdag 15 januari 2010 15:19

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.

Door Little Penguin, vrijdag 15 januari 2010 16:41

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.

Door YopY, vrijdag 15 januari 2010 16:00

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).

Door Nowad, vrijdag 15 januari 2010 15:01

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 vrijdag 15 januari 2010 15:04]

Door 140398, vrijdag 15 januari 2010 15:06

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.

Door sys64738, vrijdag 15 januari 2010 15:07

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 vrijdag 15 januari 2010 15:09]

Door degener, vrijdag 15 januari 2010 15:09

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.

Door jan_va, vrijdag 15 januari 2010 15:24

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.

Door Rizon, vrijdag 15 januari 2010 16:18

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.

Door berend_engelbrecht, zaterdag 16 januari 2010 06:06

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 zaterdag 16 januari 2010 06:34]

Door EdwinSchaap, vrijdag 15 januari 2010 22:12

Door PPie, vrijdag 15 januari 2010 15:19

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

Door Brantje, vrijdag 15 januari 2010 15:02

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

Door Flowmo, vrijdag 15 januari 2010 15:14

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.

Door Little Penguin, vrijdag 15 januari 2010 15:19

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.

Door OddesE, vrijdag 15 januari 2010 22:36

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.

Door berend_engelbrecht, zaterdag 16 januari 2010 07:04

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 zaterdag 16 januari 2010 07:06]

Door Phoenix1337, vrijdag 15 januari 2010 15:22

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.

Door geniusboxen, vrijdag 15 januari 2010 16:37

Wel waneer je ingelogt bent in GMail.

Door Rhapsody, vrijdag 15 januari 2010 15:25

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 vrijdag 15 januari 2010 15:25]

Door durian, vrijdag 15 januari 2010 15:11

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...

Door snek, vrijdag 15 januari 2010 15:13

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

Door Psychnosiz, vrijdag 15 januari 2010 15:23

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.

Door Little Penguin, vrijdag 15 januari 2010 15:23

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.

Door hAl, vrijdag 15 januari 2010 16:19

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

Door Little Penguin, vrijdag 15 januari 2010 19:26

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?

Door YopY, vrijdag 15 januari 2010 16:04

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.

Door tiranofice, vrijdag 15 januari 2010 15:33

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 ^^

Door arjankoole, vrijdag 15 januari 2010 15:54

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.

Door BeosBeing, dinsdag 19 januari 2010 12:23

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.

« 1 2 3 »

Op dit item kan niet meer gereageerd worden.

15:18	'Mismanagement Rockstar is oorzaak uitstel Max Payne 3'
14:15	Gran Turismo 5 krijgt gps-functionaliteit

Nieuws I/O

Shortcuts

Categorieën

Lees meer over

Gerelateerde content

Gerelateerde jobs

Reacties

21:35 Nieuws

15:30 Productreviews

23:33 Vraag & Aanbod

16:40 Jobs

22:19 Etc.

23:33 Reacties

23:34 Forum

14:31 Gesponsorde acties

16:05 Tweakblogs

17:40 Computable headlines

13:29 CRN headlines