Cookies op Tweakers

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

Meer informatie

Door , , 66 reacties
Bron: SecurityFocus

M35 wees ons op een artikel van SecurityFocus waarin geschreven wordt over een grote bug in Microsofts Internet Explorer. Vooral versies 5.0 en 5.5 zijn kwetsbaar, versie 6.0 niet altijd. Kortgezegd stelt deze bug mensen in staat om al je beveiligde gegevens gewoon uit te lezen, wat erg vervelend is als toevallig je creditcardnummer voorbij komt zeilen. Nog vervelender is het dat er nog geen patch beschikbaar is...

Het torretje heeft zich genesteld in de implementatie van de Secure Socket Layer (kortweg: SSL). Dit stukje code zorgt voor beveiligde verbindingen met websites. Deze verbinding wordt tot stand gebracht met behulp van een certificaat dat door een webmaster wordt aangemaakt. Onder dit certificaat wordt een electronische handtekening gezet door een "Certificate Authority". Bij het binnenkomen van het certificaat worden de handtekening en de hostname gecontroleerd. De combinatie van de hostname en de handtekening zou het systeem veilig moeten maken. Echter, in sommige gevallen wordt de hostname niet gecontroleerd, wat dus elk certificaat met een goede handtekening geldig maakt.:

BugAls de browser dit ontvangt zou het moeten controleren dat het domein waarmee hij een verbinding legt gesigneerd is door de Tussenkomst CA en dat de Tussenkomst CA is gesigneerd door een bekend CA certificaat. Tevens moet de web browser nagaan dat alle tussenkomst certificaten een correcte structuur hebben, de zogenaamde Basic Constraints". Internet Explorer doet dat niet. Dit betekent dat iedereen met een correcte gesigneerd certificaat voor WELK domein dan ook een gesigneerd certificaat kan genegeren voor ELK ander domein.

In het artikel wordt de bug en de exploit duidelijk uitgelegd, op een manier dat ook nieuwkomers het verhaal na een keer goed lezen snappen. Aangezien Microsoft ook pas sinds vanochtend van de bug op de hoogte is, is er nog geen patch uit.

Moderatie-faq Wijzig weergave

Reacties (66)

quote:
Aangezien Microsoft ook pas sinds vanochtend van de bug op de hoogte is, is er nog geen patch uit
/quote

Misschien toch beter om MS van te voren in te lichten, voor het wereldkundig gemaakt wordt.
Ook al zijn ze dan misschien niet zo snel met patches...
De bug kwam dinsdag trouwens al op security-focus' bugtraq voorbij en ruim daarvoor was al een andere SSL-bug genoemd die, volgens mij, gerelateerd is.

MS zal dus al wat langer op de hoogte (moeten?) zijn en zo niet dan doen ze toch zelf wat fout.
Waar haal je dat vandaan? Die bug was in OpenSSL ja:

*) Add various sanity checks to asn1_get_length() to reject
the ASN1 length bytes if they exceed sizeof(long), will appear
negative or the content length exceeds the length of the
supplied buffer.
[Steve Henson, Adi Stav <stav@mercury.co.il>, James Yonan <jim@ntlp.com>]

*) Assertions for various potential buffer overflows, not known to
happen in practice.
[Ben Laurie (CHATS)]

*) Various temporary buffers to hold ASCII versions of integers were
too small for 64 bit platforms. (CAN-2002-0655)
[Matthew Byng-Maddick <mbm@aldigital.co.uk> and Ben Laurie (CHATS)>

*) Remote buffer overflow in SSL3 protocol - an attacker could
supply an oversized session ID to a client. (CAN-2002-0656)
[Ben Laurie (CHATS)]

*) Remote buffer overflow in SSL2 protocol - an attacker could
supply an oversized client master key. (CAN-2002-0656)
[Ben Laurie (CHATS)]


Heeft totaal niks te maken met een man-in-the-middle attack.

Het is vandaag vrijdag. Dat is slechts 3 dagen. Sure, het kan veel sneller maar het is vakantietijd. Gun een bedrijf even de tijd dit nauwkeurig te fixen en te testen. Of wil je soms 2x updaten en/of een brakke bugfix aangesmeerd krijgen? Nee heh?
Misschien toch beter om MS van te voren in te lichten, voor het wereldkundig gemaakt wordt.
Dit is ook iets dat ondermeer Microsoft aanraad. Nu dit nieuws wereldwijd bekend wordt, zullen de certificaten zonder goede host snel meer gebruikt gaan worden.

Nadeel is dat er toch voldoende gebruikers blijven die deze patch (als deze uit is) niet installeren, zodat deze toch ongepatch blijven surfen.
Misschien, heel misschien helpt het nu wel dat Microsoft sneller een fix maakt. Zolang niemand iets weet kunnen ze rustig aan doen, nu moeten ze, als we geluk hebben, sneller werken.
Dit heeft niets te maken met sneller of rustiger werken, alleen maar testen of heel goed testen. Op het moment dat 'het publiek' nog niet op de hoogte is van de bug is er meer tijd om grondig te testen op allerlei combinaties van OS/Service packs, etc.

Als dit niet goed genoeg gebeurt krijg je dat gedoe net als met de media player patches, een aantal achter elkaar voor dezelfde bug, omdat de patch weer een bug bevatte etc.

Dus niet meteen publiek maken zou beter zijn
Nadeel is dat er toch voldoende gebruikers blijven die deze patch (als deze uit is) niet installeren, zodat deze toch ongepatch blijven surfen.
Daarom is het misschien nog niet eens zo'n gek idee dat MS volgens hun nieuwe license automatisch en ongevraagd alle updates er doorheen mogen drukken...
Ik denk dat het goed is dat mensen zelf controle over hun PC hebben het moet zeker een functie blijven die uit te schakelen is want ik installeer pas iets wanneer ik dat zelf nodig vindt. Een patch voor bijvoorbeeld msn-messenger of mediaplayer om het reclamemakers interessant te maken heb ik zeker niet nodig, daarom ben ik zeker tegen de automatische updates.
dat is dan ook de reden dat ms de patches automatisch wilt laten downloaden, zolang ms er geen misbruik van maakt zou het zelf goed zijn
Geloof je het zelf? Automatisch update betekend automatisch andere prut erop zetten. Ze kunnen het net zo goed melden dat er een update is en dan meer informatie over de update en dan vragen ja of nee downloaden en installeren.
zolang ms er geen misbruik van maakt zou het zelf goed zijn
1 woord: WMP
1 datum: 26 juni 2002

Rest mag je zelf invullen
dat ze die patch dan niet installeren is dan hun eigen schuld hoor!
Moeten ze maar regelmatig windows update draaien :Y)
Dat is al heel veel keren gebeurd. Echter wordt er dan vaak niet ingegrepen. Het is al vaker voorgekomen dat microsoft (en dit is niet als flame bedoeld) al bijna EEN JAAR op de hoogte was van sommige security bugs en er simpelweg niets aan heeft gedaan totdat het wereldwijd bekend werd gemaakt.
"Ook al zijn ze dan misschien niet zo snel met patches..."

huh? Niet zo snel? Waar basseer jij deze uitspraak op?

Dit is namelijk complete onzin. Je kan veel dingen zeggen over Microsoft, maar ik ken geen enkel bedrijf dat zo snel met patches uitkomt zoals MS
Je kan veel dingen zeggen over Microsoft, maar ik ken geen enkel bedrijf dat zo snel met patches uitkomt zoals MS
Sorry, maar nou praat je toch echt onzin.

Vanwege de grote hoeveelheden ongepatchte exploits in MSIE is er een pagina opgericht die deze exploits telt en bijhoudt: www.pivx.com/larholm/unpatched/.

Op dit moment zitten er 22 ongepatchte exploits in MSIE, waarvan 18 ouder dan een maand. Noem jij dat snel met patches uitkomen?

En dan heb ik het dus *alleen* nog maar over IE, nog niet over Outlook (express), IIS, Windows zelf en andere MS software.
Op dit moment zitten er 22 ongepatchte exploits in MSIE, waarvan 18 ouder dan een maand. Noem jij dat snel met patches uitkomen?
Onzin. Je patcht pas iets als het gepatched moet worden. Als de bedreiging laag is hoeft het niet direct en prop je alles in een SP.

Je auto krijgt toch ook een grote beurt als het nodig is, of ga je voor elk wissewasje de garage in?
Ja, als je remleiding stuk is (lees: grote exploit/bedreiging) dan ga je dat direct repareren.
Wauw, hoe erg kun je security negeren?
Er wordt misschien niet uitgebreid gebruik gemaakt van die exploits, maar het zijn wel stuk voor stuk vulnerabilities, waarmee kwaadwillende sites best vervelende dingen kunnen doen.

Het "och, dat stoppen we wel in een SP" houding is een erg gevaarlijke houding. Exploits moeten gefixt worden, en zo snel mogelijk ook. Ik zie niet in waarom je daarmee zou wachten op een SP.

En je vergelijking met auto's gaat helemaal mank. Met een "wissewasje aan de auto" bedoel je waarschijnlijk iets dat alleen comfort of luxe beinvloedt. Als er iets raars is met de motor, de remmen of de signaallichten (om maar wat te noemen), dan ga je daar wel onmiddelijk mee naar de garage.

Bovendien doet het niks af aan de reden van mijn reply: Stefan Wiersma beweerde dat Microsoft snel was met haar patches, en ik beweer dat dat absoluut niet zo is. Jij *verdedigt* het laat uitgeven van patches zelfs, wat mijn punt alleen maar bevestigt.
Veel mensen doen dat ook, maar in een geval van dit vind ik dat niet de juiste handeling. Het is voor de gebruiker echt niet zo moeilijk (evt. tijdelijk) een andere browser te gebruiken. Bij een webserver of operating system is dat minder makkelijk. De impact van deze bug moet je trouwens niet onderschatten, in de handel van SSL certificaten gaat best veel geld rond, alle certificaten voor websites (waar normaal gesproken de meerderheid met IE naartoe gaat) zijn dus onveilig geweest. Als dat zo is waarom zou je dan in hemelsnaam nog zo'n certificaat willen kopen?
Tja, leuk bedacht, maar de stelling dat het je als end user vrij staat een andere browser te gebruiken gaat in de praktijk niet altijd op.

Ik kan je zo al twee voorbeelden geven van een Web-based omgeving die niet in andere browsers als IE werkt door de integratie met Office-applicaties (online Xcelsheets e.d.) die onder IE nou eenmaal veel sneller en beter werken dan onder Mozilla.
Dan heb ik het nog niet eens over de gebruikte certs die niet in Mozilla gebruikt kunnen worden dus inloggen is al niet mogelijk.

Ik kon tot voor een maand geleden niet eens telebankieren met Mozilla omdat de bank hun site nog niet compatible had gemaakt (werkt nu nog steeds niet goed in Opera overigens).
Ach, misschien dat ze nu wel de hete adem van de (beveiligings)wereld in hun nek voelen en er snel een patch voor uitbrengen.
Inderdaad, full disclosure is het beste vind ik. Het alleen op de hoogte brengen van de ontwikkelaar nodigt alleen maar uit tot de "doofpot" aanpak. Dat is nu al zo vaak bewezen.
Zijn zat concepten voor. Je geeft een vendor een bepaalde tijd om het probleem op te lossen. Bijv. 7 dagen is een redelijk standaard voor beide partijen. Als er na 7 dagen geen patch is ga je over op full-disclosure en zet je druk achter de ketel. Vendor doet er alles aan om niet op deze manier in een kwaad daglicht gesteld te worden en heeft toch een redelijk tijdsbestek om een patch te voorzien. Et voila.
Dammed :( , de laatste tijd altijd problemen met SSL, is het de ene keer OpenSSL niet, dan weer Microsoft.

Ze zouden de sourcecode van de SSL implentatie door 1 bedrijf moeten laten ontwikkelen. En die dan weer vrijgeven aan alle browser "fabriekanten" om zo de veiligheid te waarborgen.
mmm,

Iets door 1 fabrikant laten ontwikkelen zou veiliger zijn?

Ik zie geen reden waarom. Dan zou ieder bedrijf het nu toch ook goed kunnen doen. Bugs horen bij software.

Daarom wordt in de ruimtevaart een systeem juist door drie verschillende fabrikanten op 3 verschillende systemen ontwikkeld zodat identieke bugs uitgesloten zijn.
Iets door 1 fabrikant laten ontwikkelen
En als we wel iets geleerd hebben is dat voortaan geen enkel bedrijf een standaard in handen mag hebben omdat er later of vroegen een commercieel tintje aan komt te zitten. (jpg bijvoorbeeld)
Dat waren geen problemen met OpenSSL (dat bij mijn weten helemaal niet bestaat), maar met OpenSSH. Dat is een implementatie van een protocol voor beveiligde shellverbindingen, iets heel anders dan het vooral bij websites gebruikte SSL. Deze problemen zijn dus absoluut niet gerelateerd aan elkaar.
OpenSSL bestaat wel degelijk: http://www.tweakers.net/meuktracker/2454
en www.openssl.org
dat stukje software zorgt ervoor dat apache bv een ssl connectie met een browser kan maken...
Klok & klepel opmerking. Als je OpenSSH wil compilen dan heb je de OpenSSL libs nodig.
Ze zouden de sourcecode van de SSL implentatie door 1 bedrijf moeten laten ontwikkelen.
Zodat heel de wereld afhankelijk is van dat ene bedrijf? Zodat als er een bug zit in de code van dat ene bedrijf je niet eens meer een alternatief hebt (Mozilla in dit geval)? Zodat de NSA of the CIA alleen maar hoeft te infiltreren bij dat ene bedrijf bij iedereen ter wereld binnen te komen? |:(

* 786562 olivier
Daar zie ik geen voordeel in. Als dat bedrijf nog een bug in de code heeft zitten dan is meteen alles de pineut. IE, Mozilla, Netscape en de rest wat SSL gebruikt. SSL wordt op veel plaatsen gebruikt en kan niet door 1 bedrijf worden ontwikkeld. Dat ene bedrijf heeft dan alle macht (en al het geld) over SSL en kunnen zomaar backdoors maken e.d.
Dit is ook erg fijn voor mensen die internetbankieren zoals via de rabobank.

Als ik het goed begrijp is er niets met ssl ofzo maar heeft ms het een en ander (niet) geimplementeerd waardoor deze exploit mogelijk is.
Nee hoor daar hoef je je niet druk over te maken..
Het is namelijk nog steets zo dat het een beveiligde verbinding is.. Het gaat er alleen om dat iemand op de website van de rabobank bijvoorbeeld een banner plaatst van een andere website.. en die zig net voor laten doen alof het door de rabo gehost is.. meer niet..
De bug is niet erg gevaarlijk voor SSL verbindingen..

Als je een SSL (secure) vebinding heb gemaakt kan er niet door 3e wat gegevens worden geleeched..
Het enige wat een poptensieele crimineel kan doen is facken dat hij/zij een SSL sertificaat heeft, en zo CreditCard gegevens vragen..

Maar ik ben van menig dat je altijd moet opletten naar wie je dat soort gegevens stuurd, ongeacht dat dit via SSL gebeurd ja of nee..

PS: Elke Hans Worst kan een SSL certificaad krijgen van die stichting mits je maar genoeg dokt ;{
Moet je toch beter lezen. Wel degelijk een gevaar! Kijk:
Kortgezegd stelt deze bug mensen in staat om al je beveiligde gegevens gewoon uit te lezen, wat erg vervelend is als toevallig je creditcardnummer voorbij komt zeilen.
Het is niet zo gemakkelijk maar alsnog...
check deze link maar en dan spreken we je nog wel (8>
https://www.thoughtcrime.org
SSL connection met fout certificate
IE6 ziet het gewoon bij mij..
Is er iemand met IE5 die dit even kan testen?

PS: Deze site heeft het Amazone verisign certificate
Auch, net met mozilla geprobeert...... en die detecteer wel dat hij een verkeerde certificaat heeft, maar voor de gein op mijn linux bak met LYNX geprobeert en die heeft er ook last van!

Ben ik de enige of heeft lynx ook last van deze bug? (ik heb versie 2.8.4rel.1, SSL-MM 1.4.1 OpenSSL 0.9.6d
De ontdekker van deze bug, ene Mike Benham vond het niet nodig om vooraf deze bug aan Microsoft te melden.
Microsoft moet dus nog beginnen met een patch te maken tegen deze grote bug.
Hoe lang kan het maken van een patch duren?

ACM: Dat maakt het inderdaad een stuk begrijpelijker. Maar misschien had hij eerst toch, tegen beter weten in, MS in kunnen lichten met een ultimatum en dan pas bug wereldkundig maken?
Die SSL bug is misschien moeilijk exploiteerbaar, maar geeft mij toch geen veilig gevoel. ;)
Daar had ie wel een reden voor:
=========================================
Vendor Notification Status

Last week I saw Microsoft downplay and obfuscate the severity of the IE vulnerability that Adam Megacz reported. After seeing that, I don't feel like wasting time with the Microsoft PR department.
En DAT kan ik me dan ook wel weer heeel goed voorstellen.
Als MS geen zin heeft het te fixen/te reageren op een vergelijkbare issue, dan kan ie het net zo goed wereldkundig maken en het op die manier afdwingen.
Bovendien is een browser typisch een stukje software dat je gemakkelijk kunt vervangen door een produkt van een andere leverancier, of niet soms?

Even een andere browser er op en je loopt in ieder geval niet tegen dit probleem aan, toch? MS heeft al een poging gedaan om het principe van full disclosure de nek om te draaien en dit soort dingen drukt de jongens in Redmond weer eens met de neus op de feiten.

Fouten maken is niet goed, maar iedereen weet dat het gebeurt. Neem dan ook de verantwoordelijkheid voor je produkt en breng zo snel mogelijk een fix uit.

Wat meneer Benham hier gedaan heeft is niet erg netjes, maar wel begrijpelijk gezien de houding van Micorsoft. Bovendien is dit blijkbaar de enige manier om MS te laten luisteren naar bevindingen van mensen die (beveiligings)fouten ontdekken.
Bovendien is een browser typisch een stukje software dat je gemakkelijk kunt vervangen door een produkt van een andere leverancier, of niet soms?
Hier geef ik je gedeektelijk gelijk in. Natuurlijk, je kunt zo een andere browser gebruiken. Ben je echter wel je instellingen kwijt (en dat kan irritant zijn cq. tijd kosten. Bijv: ga jij voor je hele bedrijf even overal Mozilla op installeren + instellen; gaat niet overal even gemakklijk.)
Wat meneer Benham hier gedaan heeft is niet erg netjes, maar wel begrijpelijk gezien de houding van Micorsoft.
Niet erg netjes? Het is asociaal. Evil. Blackhat-styled. Satanistisch! Dit doe je gewoon niet, het is totaal onethisch.
Bovendien is dit blijkbaar de enige manier om MS te laten luisteren naar bevindingen van mensen die (beveiligings)fouten ontdekken.
Nee. Je kunt ook MS mailen: over een week full-discolusure. Iig een redelijk tijdsbestek. Dat is m.i. het meest eerlijkst voor alle partijen en daarmee ga je dat probleem dat ooit MS een jaar een bug voor zich heeft gehouden uit de weg.

(satanistisch is niet serieus bedoeld btw)
Ach. met een man-in-the-middle attack kom je ook een heel eind. En daar hebben ALLE SSL applicaties last van. (als er eenzijdige certificaten gebruikt worden)
Nee, dat is juist het leuke van SSL...
Die horen er juist _geen_ last van te hebben. Maar als IE dan de certificaten niet goed controleert is het natuurlijk niet echt handig werkzaam meer.

Door deze bug IS een man-in-the-middle attack juist mogelijk die niet mogelijk hoort te/mag zijn.
Volgens mij constateer ik hier een OpenSource probleem...
[theorie]
Je hebt de IE source code...
Zoekt de verandwoordelijke code op veranerd deze zodat er geen sheck is en compilen -> run -> atack
[/theorie]
Can iemand mij vertellen hoe dit bij Mozilla zit?
Zou je dit daar kunnen toepassen..
Ik ben geen opensource programmer dus het is een vraag?
Je kan op deze manier je eigen browser exploitable kunnen maken en jezelf laten hacken. }>

Zolang je deze niet aan duizenden mensen weet te distribueren is daar geen probleem mee. Anders wordt het als zo'n versie op de cd bij de ComputerIdee komt...
Kortom de eind-gebruiker weet niet meer welke soft te vertrouwen.. En word dus zo het slachtoffer van een soort trojans...
Dat lijkt me lastig onder controle te houden door de virus boeren omdat elke code anders is.. moeilijk optesporen dus
Je begrijpt me niet goed...
Ik bedoel dat iemand doormiddel van een programming verandering in bijvoorbeeld Mozilla deze fout er ook kan inbouwen...
Als dit namelijk wel kan (ik denk van wel) dan kun je dit exlpoit browsertje distribueren en klaar is de atacker.
Een gebruiker kan alleen SSL encrypted op die manier zien alsof het plaintext is. Aangezien dat meestal vertrouwelijke data is kunnen daardoor idd gevoelige info als passwords gesniffed worden. Maar jouw schets is zeer onwaarschijnlijk om te gebeuren en dus vrij 'out of the line'.
Ik vraag dit omdat er laatst ook een probleem was met OpenBSD source met een exploit http://www.tweakers.net/nieuws/22773
dat bedoel ik...
Da's iets totaal anders. Hierbij is een FTP server geroot en is opzettelijk door een blackhat code getrojaned.

1) MS is niet geroot (het onderzoek loopt idd nog maar de kans is miniem)
2) MS heeft dit niet opzettelijk erin gezet onder het mom van laat ik users rooten (het onderzoek loopt idd nog en hiervan zul je de waarheid niet kunnen achterhalen vrees ik. Ik denk dat je hierbij nuchter moet zijn en MS het voordeel van de twijfel behoort te geben)
3) Het is door MS zelf gedaan, niet door iemand anders, ie. een blackhat (ook dit valt niet met zekerheid te zeggen maar nogmaals dit kun je wel aannemen IMHO)
4) Het gaat hier om een programmeerfout niet om backdoored code (geldt weer hetzelfde).

Al met al, wanneer je dit alles rationeel bekijkt zal het kloppen en is de kans dat er opzet in het spel is vrij miniem.

PS: ik reageer niet flamend ik reageer kritisch, misschien af en toe wat fel. LA je klachten hebt mail je maar of open je een draadje op GoT :)
[dubbelpost]
Je hebt de IE source code...
Zoekt de verandwoordelijke code op veranerd deze zodat er geen sheck is en compilen -> run -> atack
Uit een recent onderzoek is gebleken dat open-source software niet persee meer secure is tov. closed-source software OF vice versa. Bron heb ik niet 1-2-3, ik dacht SecurityFocus. 't Is vast wel Googable.
Can iemand mij vertellen hoe dit bij Mozilla zit?
Zou je dit daar kunnen toepassen..
Ik ben geen opensource programmer dus het is een vraag?
And I quote:
Affected Browsers

Netscape 4.x and Mozilla are NOT vulnerable.

IE 5 and 5.5 are vulnerable straight-up, and IE 6 is mostly vulnerable.
staat gewoon in de link van het artikeltje hierboven. Read it, my friend..
Je begrijpt me niet goed...
Ik bedoel dat iemand doormiddel van een programming verandering in bijvoorbeeld Mozilla deze fout er ook kan inbouwen...
Als dit namelijk wel kan (ik denk van wel) dan kun je dit exlpoit browsertje distribueren en klaar is de atacker..

Ik vraag dit omdat er laatst ook een probleem was met OpenBSD source met een exploit http://www.tweakers.net/nieuws/22773
dat bedoel ik...

PS het is gewenst om volgende keer iets minder flamend te reageren
dan mogen ze wel opschieten met de nieuwe patch.
maar als het net zolang duurd als alle andere patches.. dan kunnnen we lang wachten.

en dan vragen groote webwinkels zich af waarom er niet zoveel online word gekocht via creditcards..

eeeh om dit soort redenen..
en dan maar stellig volhouden dat `t veilig is om online te bestellen..

ben blij dat er vaak nog iets bestaat als bestellen onder rembours.
Het is wel een ernstige bug, maar niet zo heel simpel te exploiten als hier beschreven staat hoor :)

Je moet nog steeds een 'gewone' spoofing/hijacking-actie uitvoeren ervoor.
Maar als je dat succesvol hebt gedaan is de SSL-encryptie geen probleem meer om te kraken...
Niet iedereen is zeker van het feit dat het een security leak is:

http://online.securityfocus.com/archive/1/286313/2002-08-05/2002-08-11 /2

Newsposters: wat op het SecurityFocus forum wordt gepost is lang niet altijd een 'official vulnerability'.
Het probleem zit hem erin dat je zelf certificates kan signen, als je over een certificate beschikt dat gesigned is door een erkende CA (rsa, verisign etc). Internet Explorer ziet een chain of trust

CA - jouw cert - mitm cert

IE checkt alleen de CA en gaat er van uit dat het goed is.
M.a.w. je kan voor niks zelf certificates signen zonder dat IE erover zeurt :) (zoals bij de self-signed certificates wel gebeurt).
Wat zal er eerst zijn, de exploit of de patch..
De exploit is er al.

De ontdekker heeft een werkende exploit opgezet, maar deze niet wereldwijd verspreid.
Waarschijnlijk de exploit, MS moet nl. eerst nog allemaal spyware in gaan bouwen in de patch :)
Ben zo wie zo "nog" niet kapot van prive en creditcard gegevens versturen via internet.

Bankieren OK maar dan met bv 2400 bps (traag) bij de postbank inbellen. :Z

Wat heeft IE nog meer voor ons in petto ??

Er zijn toch vast en zeker hackerz die iets hebben gevonden en het niet openbaar maken...
offtopic:
Leer het nou eens, het is 'sowieso'. 'zo wie zo' slaat echt nergens op :'(

Ontopic vind ik dat alles eigenlijk al gezegd is; daar heb ik niets meer aan toe te voegen.

Op dit item kan niet meer gereageerd worden.



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

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