Ja leuk maar als je van Java 6 naar Java 7 upgrade dan word je toch juist weer kwetsbaar voor de nog niet gepatchte bugs in Java 7?

Klopt, maar je moet je afvragen of dat risico groter of kleiner is dan het risico wat je nu loopt...

En wel altijd de laatste versie installeren...

Voor de Java 7 bugs heb ik al diverse keren exploits gezien in de logfiles van de proxy. Ze lukken niet door de setup van het netwerk en de rules in de proxy, maar ze zijn er wel.
Voor de IE bug heb ik nog geen enkele exploit gezien.

Ik denk dus dat het wel klopt wat MS schrijft (dat deze bug maar bij een beperkt aantal organisaties ingezet wordt), maar dat Java een veel groter risico vormt.
Zeker voor degenen die met een default install werken, als Administrator, en zonder proxy enzo.

Vannacht nog was er een mail "van Empaco B.V." met zogenaamd een factuur, die probeert je via het aanklikken van een link te infecteren als je Java 7 hebt.
(jammer dat de verzender hiervan nog steeds niet gepakt is, deze heeft al diverse van dit soort spamruns op zijn geweten)

Dit is op te lossen door een upgrade naar Java 8... ^^

Het probleem is niet zozeer Java, maar het feit dat Java 6 het bestand C:\Program Files\Java\jre6\bin\msvcr71.dll en C:\Program Files\Java\jre6\bin\plugin2\msvcr71.dll zal installeren. Dat bestand is de "Microsoft® C Runtime Library" versie 7.10.3052.4.

Het probleem is dat dit bestand geen ASLR protectie biedt en via een Java applet in de context van MSIE geladen kan worden (zie bijv. https://www.corelan.be/index.php/2011/07/03/universal-depaslr-bypass-with-msvcr71-dll-and-mona-py/).

Maar lang niet alleen Java installeert deze DLL; er zijn ook PC's waar je in andere mappen (zoals C:\Windows\System32\ en verschillende submappen onder C:\Program Files\) een "kwetsbare" msvcr71.dll kunt tegenkomen. Als er een MSIE plugin/ActiveX module is die hiervan gebruik maakt is je systeem waarschijnlijk kwetsbaar. Dat geldt vermoedelijk ook voor andere code bevattende bestanden (waaronder DLL's) die geen ASLR gebruiken en in de context van MSIE worden geladen.

Kortom Java 6 is een veel voorkomende exploit factor, maar reken je niet rijk als je geen Java 6 op je systeem hebt.

Aanvulling: C:\Program Files\Java\jre6\bin\plugin2\msvcr71.dll toegevoegd.

Meermaals merk ik dat Java ter sprake komt in de reacties.
Nu vraag ik mij nog steeds af of je dat java echt nodig hebt op je PC (als thuisgebruiker dan wel)
Ik heb zelfs niet de indruk dat dat ding op één van de pc's staat hier toch zeker geen gedownloade versie van Java.
Java blijkt zoals Adobe in de meeste gevallen ook bug stuff te zijn.
PC toch nog eens afspeuren op die zooi ...

Yep,
Ik vind 'm onder C:\Windows\System32 (als Microsoft Visual Studio .NET bestand)
en onder C:\Program Files\GRETECH\GomPlayer (eveneens als Microsoft Visual Studio .NET bestand).

Alleen wanneer je programma's gebruikt die afhankelijk zijn van Java,
en/of wanneer je per se internetapplicaties wilt gebruiken waarvoor Java benodigd is.

Is Java aanwezig op je computer, maar weet je niet of je programma's gebruikt die werkelijk afhankelijk zijn van Java, en/of je internetapplicaties gebruikt waarvoor Java benodigd is, dan zou je bij wijze van test Java kunnen verwijderen.
Mis je het niet, dan is dat mooi, merk je op een gegeven moment dat je Java wel mist voor iets dat je als essentieel beschouwt, dan kun je opnieuw Java installeren.

Is dit niet wat misleidend van MS? Zodra men ipv de Java dll een alternatief gebruikt ben je als Windows7 gebruiker zonder Java toch nog steeds de klos? Als ik me niet vergis had Peter aka WTFuzz al een andere manier gevonden.

Betekent dit nu dat het bestand msvcr71.dll, in welke directory die ook staat, gewist kan/moet worden ??

Ik heb een aantal files msvcr71.dll gevonden, in verschillende directories.
Ze zijn van verschillende datums en omvang.

Is er een veilige versie, die in al de verschillende directories de "oude" versies kan vervangen ?

Via een site van MS wordt verwezen naar http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71 voor een vervangende/ontbrekende versie (de zip-file kiezen lijkt mij het beste, bij de andere optie wordt er een tijdelijk gratis hulpprogramma geinstalleerd) !

@ Anoniem vr.21-9, 21:42 uur,
@ Anoniem vr.21-9, 22:42 uur,

Um, doe nou geen al te gekke dingen en installeer gewoon de patch die gisteravond is uitgebracht, zie:
http://www.security.nl/artikel/43198/1/Microsoft_noodpatch_dicht_ernstig_IE-lek.html

Ik hoop dat Bitwiper of iemand anders me corrigeert wanneer ik me vergis,
maar als ik me niet vergis zijn die msvcr71.dll in essentie 'onschuldige' reguliere bestanden behorend bij reguliere programma-installaties, het probleem ermee was slechts dat ze benut konden worden als onderdeel van het mechanisme van de aanval via de beschreven kwetsbaarheid in IE.
Door msvcr71.dll bestanden te wissen tast je mogelijk/wellicht(?) functionaliteit aan van de programma-installaties waarbij ze behoren,
en vervangen lijkt me niet zinvol gezien het feit dat er in principe niet iets mis is met die bestanden, maar dat het probleem ermee 'slechts' was dat ze benut konden worden als onderdeel van het aanvalsmechanisme.
Nogmaals: gewoon IE patchen lijkt me verstandiger.

Mocht ik me onjuist of onvolledig uitdrukken,
ik hoop dat iemand me dan even wil corrigeren of aanvullen.

Dat hangt ervan af!

Het primaire probleem is een bug in MSIE waar ondertussen een patch voor is.

DEP en ASLR in executable code kunnen helpen verhinderen dat een exploit voor zo'n bug ertoe leidt dat kwaadaardige code wordt uitgevoerd (DEP en ASLR lossen geen bugs op, de browser kan nog steeds crashen of zich raar gaan gedragen). DEP en ASLR zijn dus geen fix, hooguit een vangnet!

En heel belangrijk: als er binnen de "context" (het geheugengebied zeg maar) van het buggy programma (MSIE in dit geval) een stukje code aanwezig is (of, in opdracht van de aanvaller, nageladen wordt) dat geen DEP en/of ASLR ondersteunt, dan is de exploit toch vaak mogelijk. En dat blijkt het geval indien jij Java 6 op je PC hebt en deze niet in je webbrowser hebt uitgeschakeld: de aanvaller kan je dan een Java applet laten uitvoeren waardoor de Java Virtual Machine het bestand msvcr71.dll in het geheugengebied van MSIE zal laden, waardoor de feitelijke exploit niet gehinderd wordt door ASLR en/of DEP.

Omdat security bugs zich regelmatig voordoen, en in zo'n geval DEP en ASLR de bijbehorende code-uitvoerende exploits blokkeren, zijn hackers met hoeden in alle grijstinten voortdurend op zoek naar DEP en ASLR bypasses. Vooral sinds Windows 7 is dit een enorme uitdaging, omdat de meeste bestanden met uitvoerbare code DEP en ASLR ondersteunen (doe geen moeite onder XP). Zowel kwaadaardige als goedaardige hackers beschouwen het als een uitdaging om elk lek te vinden (goedaardige in de hoop dat zij dit eerder doen dan de kwaadaardige en er snel een oplossing voor komt).

Maar eigenlijk is dit allemaal waardeloos. De aandacht (vooral van softwaremakers, maar ook van white hat hackers) zou m.i. moeten uitgaan naar het voorkomen (en lukt dat niet: vinden en fixen) van bugs, niet het verspillen van tijd aan vangnetten. Wat we nu zien is collateral damage: mensen die msvcr71.dll denken te moeten verwijderen omdat deze geen DEP en ASLR ondersteunt...

Ik heb persoonlijk dan ook nog niks met EMET gedaan en draai gewoon XP. Het risico dat zaken niet meer werken na het draaien van EMET is levensgroot, en zie dan maar eens uit te vinden wat daar de oorzaak van is. Microsoft wentelt met hun EMET advies hun problemen op gebruikers af. Bovendien suggereert Microsoft dat er sprake is van een bug in Oracle Java (dat komt regelmatig voor, maar deze keer klopt het niet, en Microsoft maakt hier misbruik van). Het einge dat Oracle "fout" doet is het verspreiden van Java 6 met een door Microsoft gemaakte DLL uit de tijd dat Microsoft nog niet met de wanhoopsdaad genaamd DEP en ALSR bezig waren.

Mijn advies voor redelijke veiligheid: zorg dat Java niet werkt in je webbrowser; met Java applicaties op je PC is niks mis. Minimaliseer het aantal plugins in je webbrowser tot het strikt noodzakelijke, dan is de kans dat er code zonder DEP en ALSR door plugins of door hen gebruikte DLL's in jouw webbrowser geladen wordt, minimaal.

@Spiff: wat jij schrijft klopt helemaal!

En zorg ervoor dat je gebruikers GEEN beheerders rechten op hun werkplek PC hebben..
Dat maakt dit soort lekken pas echt gevaarlijk, mijn enige conclusie is dat grote organisaties (UvA, Volkswagen, Duitse overheid?) dit nog in grote getale doen....

Dankjewel voor de bevestiging, Bitwiper :-)

Nadat ik eerder vanmiddag zag dat je daar versie 7.10.6030.0 zou kunnen downloaden, lukte mij dat niet. Momenteel krijg ik van http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71 alleen nog maar "Service Temporarily Unavailable" meldingen.

Ik heb zelf vanaf verschillende PC's de volgende versies van msvcr71.dll verzameld en zelf (voor het gemak) de bestandsnaam aangevuld met het versienummer:
Geen van deze bestanden ondersteunt DEP of ASLR!

Ik verwacht dan ook niet dat de laatste versie vanaf http://www.dll-files.com/ dat doet. Het heeft dan ook geen zin om op je PC deze DLL's te vervangen door de laatste versie, in elk geval niet om exploits voor MSIE te helpen blokkeren. Of oudere versies van msvcr71.dll zelf security vulnerabilities bevatten weet ik niet (heb ik niet onderzocht). De kans bestaat dat oudere programma's niet goed werken met nieuwere versies van die DLL, dus tenzij je zin hebt in een uitgebreide testsessie, zou ik het allemaal lekker zo laten staan.

Dat genoemde bestanden geen ASLR en DEP ondersteunen zie ik door ze 1 voor 1 in CFF Explorer (http://www.ntcore.com/exsuite.php) te laden: onder File -> Nt Headers -> Optional Header heeft DllCharacteristics de waarde 0.

Andere gratis tools waar je dit mee kunt checken zijn PeExplorer v4.00 (http://www.winitor.com/) en FileInsight van McAfee (http://www.mcafee.com/us/downloads/free-tools/fileinsight.aspx).

Lastig is dat je de termen DEP en ASRL niet terugvindt in dat soort tools. Volgens http://secunia.com/gfx/pdf/DEP_ASLR_2010_paper.pdf geldt:
- DEP is enabled als de NX_COMPAT (0x100) vlag opgezet is in DllCharacteristics;
- ASLR is enabled als de DYNAMIC_BASE (0x40) opgezet is in DllCharacteristics.

Als ik met één van genoemde tools recente DLL's in C:\Windows\System32\ open, zie ik dat DllCharacteristics steeds de waarde 0x0140 heeft. Dat is een hexadecimaal getal met 0x40 en 0x100 bijelkaar opgeteld, met andere woorden, die bestanden ondersteunen zowel DEP als ASLR.

Meer info over ASLR en DEP vind je in http://msdn.microsoft.com/en-us/library/bb430720.aspx (of Google ernaar).

Dank voor de uitleg.

Ik dacht al dat mijn simpele logische benadering te mooi was om waar te zijn.

Ik heb de .dll van dll-files.com als vervanging gebruikt ( het is de .6030.0). De betreffende applicaties leken wel te werken, echter toch merkte ik bij enkele een iets ander (slechter) gedrag.
Mogelijk toch maar weer de oude versies aktief zetten.

Groeten en fijn dat er mensen zijn die op code-niveau af en toe uitleg willen/kunnen geven.