Ik heb de PDF doorgenomen, maar ik snapte er niet veel van. Is er een serieuze kans dat dit lek misbruikt gaat worden? Ik ben benieuwd wat de softwarespecialisten hier er van vinden.

En niet alleen een achterdeur, alle deuren en ramen eigenlijk. Maar dit geldt voor elke browser, ook al zijn alle gaten niet (publiek) bekend.

Ik geloof niet dat jij in staat bent om alle code die van Browsers openbaar is door te lopen en te beoordelen op validiteit. Wat je doet is reageren op en met fud voor eigen voorkeur en afkeur.

Als je de pdf kan uitleggen wat die onderzoekers niet gelukt is dan zou dat beter staan. Met fud moet je in het geheel buiten de ICT blijven omdat de gangbare politiek leidt tot onveilige sotware die niet af is. Dat is ongeacht de bron en type closed/open van de software

Het beschreven probleem van hp is iets fundamenteels met browsers en scripting. De basis is:
- een browser handelt bekende code (html) en onbekende code (scripting) van onbekende bronnen af.
- het apart valideren van code voordat het prod is gaat niet op wegens het toestaan van die onbekende bronnen. De kracht van Internet is ook het nadeel.
- met al die fraaie script functies moet de brosser memory voor die script talen gaan beheren.
- het memory management in een adres space zoals een browser is een plat model. Je kan Door handig te Scripten in andermans memory pages binnen dat process komen..
Dat is een gangbaar OS en multiuser muliproces probleem dat al bekend is zolang er multiuser multiproces uitdagingen in gebruik zijn.

De isolatie is alleen volledig betrouwbaar te krijgen als alles geïsoleerd in eigen memory beheer mechanismen gaan lopen. Het nadeel is dat alles veel omslachtiger en trager wordt.

Een goede aanpak kan zijn alleen bepaalde pagina's via een browser proces te doen die op zich weer weinig op jouw machine kan doen. Html en web gaat er vanuit dat alles naar jouw machine gedownload wordt en op jouw machine wordt uitgevoerd. Dat is Hoe het is... Zij zo.

Microsoft besluit even om een browser lek niet te repareren,Google besluit om een lek in oudere android versies niet te verhelpen..hallo!!? Dit is software waar miljoenen mensen gebruik van maken! Dit op apparaten die al gauw een paar honderd euro per stuk kosten (windows pc,samsung galaxy s6,i-phone,wat dacht je van een mac book a 2000 euro, enz)! Hier moeten dus de nationale en evt.internationale overheden eens gaan optreden als belangenbehartiger/beschermer van de consumenten,in dit geval de internetgebruiker/pc gebruiker/smartphone-gebruikers.Vooral de Amerikaanse overheid mag weleens in actie komen.Dit zijn Amerikaanse bedrijven die niet alleen de consumenten-belangen aan de laars lappen,maar ook hun (digitale) veiligheid en daarmee ondermijnen ze de algehele internet-veiligheid.Laat de regeringen nu eens komen met miljoenen-boetes,dwangsommen,voor mijn part van een miljoen dollar per dag om deze bedrijven te dwingen om deze ernstige lekken eens heel snel te gaan verhelpen!

Beste karma4,

Ik kan mij volledig vinden in uw kritiek op Krakatau, die een gebrek aan kennis en kunde verbergt door FUD.

Echter...
U gaat er volledig aan voorbij dat dit probleem toch echt typisch voor IE is.

UAF (Use After Free) problemen zien we overal, maar waar dat bij Google en Firefox (over heel 2013) ongeveer,
het wisselt per jaar, per seizoen en per versienummer, een kwart van alle problemen uitmaakt, was dat bij IE een ruime meerderheid.

Dat is gewoon slordig programmeerwerk en heeft niets met de belasting door het internet te maken.

In plaats van de code eens goed tegen het licht te houden, komt MS in 2014 met een andere,
op zich heel slimme oplossing, namelijk een geïsoleerde heap.

Dit werkt dan in combinatie met een nieuwe ProtectedFree() functie, die naast de originele HeapFree()
functie komt.
ProtectedFree() zet gedealloceerde, dus vrijgegeven geheugenblokken in een wachtlijst en vult deze blokken
vervolgens met een 'null character'.
In die wachtlijst staan een aantal gegevens (descriptor) waaronder ook alle allocatie gegevens
van de betreffende geheugenblokken.
Voor een aanvaller is het dan in principe mogelijk om aan de hand van zo'n adres te 'raden' op
welke plaats in het geheugen een nieuwe module wordt geladen.
Op dit adres zet je dan een pointer naar je eigen code welke dan vervolgens wordt uitgevoerd.

De kans dat je het juiste adres te pakken krijgt is volgens mij zeer klein, maar niet onmogelijk.

Raar en onverklaarbaar is dat MS niets doet met de richtlijnen die gegeven worden om dit probleem op te lossen.

Het hele punt is dat Microsoft een zeer goede beveiliging heeft met ASLR, maar daar vervolgens
ZELF een gat in schiet met hun nieuwe "MemoryProtection" (dus de ProtectedFree() functie).
.

Ah anoniem 20:19 dat is is commentaar met kennis van zaken.
Zoals je inderdaad stelt er is een kans dat het adres van een nog te laden module geraden zou kunnen worden. Ik weet niet hoe het risico versus impact in geval van het ms probleem uitpakt. In ieder geval zou die informatie meer helderheid verschaffen. Dat mag ms best wat aan doen en dan is de kritiek terecht.

Wat ik mis is memory protection voor processen op threads nivo zodat er geen escalation kan plaatsvinden. Dat de browser sessie corrupt kan raken zie ik als iets wat in de basis met http web gekomen is.
Je moet geen onnodige functies op koppelvlakken hebben omdat het zo makkelijk te coderen is. Vroeg of laat gaat het gemis va security met het ontwerp pijn doen.