VU-onderzoekers omzeilen geheugenbescherming aslr via javascript

De onderzoeksgroep softwarebeveiliging van de VU, die onder leiding staat van professor Herbert Bos, heeft een aanval gepresenteerd waarmee de beveiligingsmaatregel aslr omzeild kan worden. Bescherming is vooralsnog niet mogelijk, omdat de aanval gebruikmaakt van een fundamentele eigenschap van processors.

De onderzoekers Ben Gras en Kaveh Razavi hebben de aanval de naam AnC gegeven. De side-channelaanval maakt gebruik van een fundamentele eigenschap van AMD-, Intel- en ARM-processors en vereist daarom geen lekken in software. De methode maakt gebruik van het feit dat de mmu van deze processors de cpu-cache gebruikt om page table walks uit te voeren, waarbij virtuele geheugenadressen worden omgezet in fysieke.

Gras legt aan Tweakers uit: "Dit onderzoek toont aan dat de resultaten van deze page table walks in de cpu-cache terechtkomen en daarom 'afgeluisterd' kunnen worden door, na de cache te manipuleren, te meten wanneer het opzoeken langzamer gaat. Denk aan een stethoscoop die je tegen een kluis aanduwt om te horen wat er binnen gebeurt." Deze aanval is zowel mogelijk vanuit Chrome als vanuit Firefox, toonden de onderzoekers aan.

Gras vervolgt: "Daardoor kan uitgerekend worden wat het adres is dat de mmu aan het opzoeken is, ook als dat in een domein gebeurt waarin die informatie beveiligingsgevoelig is en je het niet hoort te kunnen weten. We demonstreren dit in javascript in twee browsers en laten zien dat het verschijnsel op alle moderne Intel-, AMD- en ARM-modellen bestaat." De onderzoekers hebben de aanval op 22 verschillende processors getest en kwamen geen model tegen waarbij de methode niet werkte.

Door de methode toe te passen kan een aanvaller achter geheugenadressen komen, die normaal gesproken door aslr beschermd zouden moeten zijn. Deze techniek moet aanvallen op het systeemgeheugen, bijvoorbeeld stack overflows, moeilijker uitvoerbaar maken door willekeurige locaties in het virtuele geheugen aan te wijzen waar programma's belangrijke componenten kwijt kunnen. Volgens Gras is daarmee bijvoorbeeld aan de sandbox van javascript te ontkomen en zo code uit te voeren op het systeem van een slachtoffer, maar is er wel een tweede bug nodig om van een exploit te kunnen spreken. Deze methode gaat ervan uit dat de aanvaller javascriptcode kan uitvoeren in de browser, bijvoorbeeld door gebruik te maken van een kwaadaardige website.

Omdat de methode gebruikmaakt van een fundamentele processoreigenschap, is het vooralsnog niet mogelijk tegenmaatregelen te nemen. Het uitvoeren van javascriptcode kan wel worden tegengegaan, bijvoorbeeld door de Noscript-add-on te gebruiken, aldus de onderzoekers. Ze zijn in gesprek met zowel cpu-fabrikanten als browsermakers. Volgens Gras hebben de fabrikanten geen plannen bekendgemaakt om het probleem aan te pakken. Gras zegt dat het probleem op cpu-niveau op te lossen zou zijn door bijvoorbeeld een aparte mmu-cache te gebruiken. De onderzoekers hebben wel met Apple samengewerkt om WebKit van aanvullende beveiliging te voorzien.

De onderzoeksgroep heeft het disclosure-proces, dat gecoördineerd wordt door het NCSC, in oktober in gang gezet. Er zijn verschillende kenmerken in het leven geroepen. Zo geldt CVE-2017-5925 voor Intel-processors, CVE-2017-5926 voor AMD en CVE-2017-5927 voor ARM. De benaderde browsermakers, Apple, Mozilla, Google en Microsoft, maken gebruik van CVE-2017-5928. De presentatie van de methode vindt plaats op het NDSS-symposium, dat eind deze maand in de VS plaatsvindt.

Demonstratie van de aanval in Firefox

Reacties (62)

Dit is misschien wel het ergste lek van het afgelopen jaar. Juist doordat het hardwarematig is. Ook de houding van fabrikanten om geen datum of iets over de oplossing te communiceren toen dit aangetoond werd is bizar! Openbaring van het VU is enerzijds te snappen maar aan de andere kant roekeloos. Dit kan gigantisch worden uitgebuit, en zonder twijfel zal dat ook worden gedaan. Javascript staat bij Jan Modaal aan, en de volgende CPU komt binnen 4 tot 8 jaar pas in huis. Browserfabrikanten kunnen hier een grote rol spelen en ik hoop dat andere net als Apple snel reageren met een pleister tot CPU fabrikanten de hardware permanent verbeteren.

Kan iemand even in Jip en Janneke taal uitleggen wat het gevaar van dit is? Is het puur dat ze iets kunnen uitlezen of kunnen er ook dingen door aangepast worden?

Een direct gevaar is er niet, maar het is makkelijker om adressen te achterhalen van functies en dus makkelijk exploits te maken voor systemen met aslr. Bij systemen zonder aslr kon dit gewoon altijd al. Stel de functie voor het starten van een command prompt staat normaalgeproken op 0x123456 maar als je aslr gebruikt kan het overal staan. Je kan in dat geval niet zeggen start de functie op 0x123456 omdat je niet weet waar het staat. Met deze methode kan je het adres achterhalen en alsnog de functie starten. Je hebt uiteraard wel een andere exploit nodig om de functie te starten.

Dit is puur aslr omzeilen en niets anders, het is dus niet zo dat alle machines in 1x kwetsbaar zijn. Je kan er geen code mee uitvoeren of data aanpassen wat je normaalgesproken niet mag. Het is een beetje zoals het zonder aslr was, waarmee we al jaren hebben gedraaid zonder dat iemand zich hier druk over maakte. Wat ik eerder bizar vind is dat dit werkt via javascript

Wat ik eerder bizar vind is dat dit werkt via javascript

Precies dat is dan ook het meest nieuwswaardige. Imers zo vinden de meeste besmettingen van PC's plaats.

Maar de onderzoekers geven zelf al wat tegenmiddelen. Zo melden ze dat het bewust invoegen van ruis in de JavaScript timer hun aanval al moeilijker maakt.

Verder vraag ik me persoonlijk af, waarom Javascript toegang moet hebben tot eigenschappen van het cache (al dan niet direct of indirect via uitlezen van CPU type) zoals associativiteit en soort instructie-cache. Zonder die data wordt het moeilijker om aan de hand van cache timings, te weten welke instructies wel niet gecached worden en zo indirect adresinformatie te verzamelen.

Het verlagen van de nauwkeurigheid is door de onderzoekers zelf al omzeild door het ontwikkelen van eigen timers in javascript. Zie deel IV. A en IV. B uit hun
paper. In de mitigations section zeggen ze over timers:

"Reducing the accuracy of the timers [35], [43],
[58] makes it harder for attackers to tell the difference between
cached and memory accesses, but this option is often costly
to implement. Further, there are many other possible sources
to craft a new timer. Prior work [11] shows it is hard if not
impossible to remove all of them even in the context of simple
microkernels"

Je hebt gelijk, ik leg mijn punt dan ook slordig uit. Wat ik bedoelde is dat afleidend uit hun onderzoek je wat tegenmiddelen kunt geven. Zelf spreken ze van reductie van nauwkeurigheid. Ik dacht zelf aan het invoegen van ruis in de JavaScript timer. Liefst non-random ruis, en eentje met een kleine bias. Specifiek IV.A wordt hiermee namelijk voorkomen

"We, however, believe that TTT can also be used in performance.now() with
jitter as long as it does not drift, but it will require a higher
number of measurements to combat jitter."

Mijn doel was om bewuste drif te introduceren. Maar zelfs als dat niet kan om compatibiliteitsredenen, het gaat uiteindelijk om de tijdsduur waarin een aanval mogelijk is. Mijn hoop is dat het lang genoeg gemaakt kan worden.

Het grootste zwakke punt van deze aanval is echter dat het behoorlijk gedetaileerde info over het cache moet hebben, welke normaal niet te krijgen is. Toch is dat natuurlijk niet helemaal geruststellend.

Maar met die methode haal je dus 1 van de 2 ontwikkelde timers weg en los je het probleem dus eigenlijk niet op. In IV. B staat namelijk: "SMC is agnostic to the quality of performance.now()
since it only relies on a separate observer core for its measure-
ments".

[Reactie gewijzigd door Vedette. op 16 februari 2017 08:08]

Klopt, als je je eigen timer ontwikkeld werkt mijn verdediging niet.

Maar de eigen timer is gebaserd op een aantal speciieke implementatie keuzes van SMC. Het idee dat je een eigen core krijgt is bijvoorbeeld geen garantie. Ook kan de core wijzigen - zeker in ARM big.LITTLE systemen of PC hypterthreads. En SMC is nog experimenteel en dus niet uitontwikkeld. Of de SMC timer zoals ontwikkeld dus ook zal blijven werken is maar de vraag. Standaard staat die feature bovendien niet aan op browsers, dus vandaag de dag is men wel degelijk afhankelijk van de performance.now().

Maar mijn punt was meer, dat de bedenkers zelf een zwak punt al aangeven. Ze moet een een timer hebben met weinig ruis, en geen drift. Daar kun je als browsermaker best op inhaken. Browser Javasctipt heeft namelijk normaal geen timer zonder drift nodig, en ook geen microseconde nauwkeurigheid.

Dit is dus precies wat ik dacht. We laten toe dat JavaScript via de browser zoveel kan, maar zonder dit soort low level toegang zou JS nog steeds prima functioneren maar wel veel veiliger zijn.

Natuurlijk zou het goed zijn om het probleem in de hardware aan te pakken, maar dan nog blijft low level toegang gevaarlijk.

Er is bijzonder veel gevaar. Er zijn genoeg exploits binnen een systeem. De uitdaging is altijd de entry. En deze wijze maakt de entry dood eenvoudig en bijzonder makkelijk doordat elke internetgebruiker potentieel risico loopt. Daarnaast is de oplossing lastig tenzij browsers snel een pleister plakken tot de CPU verbeterd wordt. Bagatelliseer ook niet de impact, het uitbreken uit een sandbox en het kunnen veroorzaken van een buffer overflow, waarbij extra code kan worden geïnjecteerd is een natte droom voor menig cracker. (Ja cracker, hackers testen veiligheid, crackers zijn de criminelen. De media doet het al jaren fout)

Maar dat is het dus... Met deze exploit heb je geen entry. Het enige wat je hebt is een lijst van adressen waar functies staan die kunnen worden aangeroepen.

Vervolgens dien je via een andere manier toegang tot het systeem te krijgen, om zo die adressen aan te roepen.


Mocht je die toegang dan toch al hebben, kan je de nieuwe javascript exploit ook op een andere wijze uitvoeren, en heb je m.i. niks aan de afzonderlijke exploit.

Dus ik met m'n domme boerenverstand zie geen extreme beveiligingsproblemen, tot een 2e exploit wordt vrijgegeven, om daadwerkelijk iets met de informatie van deze exploit te doen.

Als je toegang hebt heb je niks aan deze javascript exploit.

Deze javascript exploit is een "tool" om die toegang te krijgen met je huidige exploit.

Ik kan niet geloven dat ik op Tweakers zie hoe zwaar deze bug onderschat wordt. Dat je een +3 hebt voor deze reactie vind ik echt zeer zorgwekkend.
Niks persoonlijks, trouwens.

Maar er zijn nu technieken om DEP te omzeilen, sandboxes te omzeilen en nu aslr die je b.v. "ff" de return address voor je BOF exploit stuurt terwijl dit voor veel exploits onmogelijk/moeilijk was.

Om even op erwin80 te reageren:

Ik vind het vertrouwen van de vendor van de software die we gebruiken "zoals in de goede oude dagen" geen goed idee en we hebben genoeg voorbeelden van hoe gevaarlijk deze situatie is. (Adobe Flash Player anyone?) .

We hadden vroeger ook de CLSID-bug waarmee je even een clsid kon plakken als extensie en je heel makkelijk van je virus een "jpeg-bestand" of "mp3-bestand" te maken die dan uitvoerbaar was.

Of de Ping of Death op Windows 95.

Ik snap niet dat we bijna juichen dat we terug in de tijd gaan met onze beveiliging. Vooral niet wanneer er nu al zoveel gevaar is voor besmettingen van b.v. ransomware en wanneer malware / spyware steeds hardnekkiger en ingewikkelder wordt.

Dat je een +3 hebt voor deze reactie vind ik echt zeer zorgwekkend.

Volgens mij is het niet de bedoeling van de moderatiescore om aan te geven hoe gelijk je hebt, maar eerder hoe relevant de post is voor de discussie.

Het feit dat hij totaal het gevaar niet inziet lijkt me juist zeer relevant voor de discussie (het is duidelijk een mening die andere ook toebedeeld is) en geeft jou de mogelijkheid om nog beter uit te leggen waarom het juist wel gevaarlijk is.

Ik snap jullie punt. Vanochtend denk ik iets te vluchtig dit artikel doorgenomen.

Na even iets meer tijd ervoor te hebben genomen snap ik hoe gevaarlijk de exploit eigenlijk is. Door een verkeerde aanname die ik gedaan heb, dacht ik inderdaad dat het wel meeviel.

Bedankt dat jullie me toch nog even aan het denken hebben gezet

+1 Eric S. Raymond, CatB.

"There is another group of people who loudly call themselves hackers, but aren't. These are people (mainly adolescent males) who get a kick out of breaking into computers and phreaking the phone system. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security doesn't make you a hacker any more than being able to hotwire cars makes you an automotive engineer."

Nog meer Jip-en-Janneke taal:

Om code uit te voeren waartoe je geen rechten hebt, moet je drie dingen doen:

1) Zorg dat de code ergens in het geheugen staat
2) Weet waar het in het geheugen staat
3) Zorg dat de processor naar de plek in het geheugen springt waar de code staat

1) Is het makkelijkst, dat kan met JavaScript. 3) Is moeilijk, maar in het verleden zijn vaak beveiligingsgaten gevonden waarmee het mogelijk is. Blijft 2) over, waar bovenstaande techniek over gaat.

Er kunnen ook dingen aangepast worden. Als een website succesvol van deze methode gebruikmaakt, kan ze dingen doen op je computer die ze normaal niet kan:

... code uit te voeren op het systeem van een slachtoffer

Maar ze moeten als ik het goed lees wel daarnaast nog gebruik maken van een andere zwakheid in je systeem; het is slechts 1 (belangrijke) stap.

Voor sommige "aanvallen", die kwaadwillenden op je computer kunnen doen, moet bekend zijn waar bepaalde zaken in het geheugen van de computer staan. ASLR is een techniek die bedoeld is om het moeilijker te maken om die plaatsen in het geheugen te bepalen.

Maar blijkbaar is de manier waarop momenteel ASLR is uitgevoerd niet zo goed. Op zich was eerder ook wel bekend dat er wat aan te merken viel op de huidige stand van zaken rondom ASLR. Bijvoorbeeld http://www.cs.ucr.edu/~nael/pubs/micro16.pdf

Het gevaar is dus dat sommige types aanvallen toch weer makkelijker blijken dan gehoopt.

Dit is misschien wel het ergste lek van het afgelopen jaar. Juist doordat het hardwarematig is.

Valt wel mee, want het "lek" is niet nieuw, maar al eerder aangetoond. Nieuwe hier is dat het in Javascript gebeurde.

Maar het is ook geen lek in zichzelf. Het is een methode om informatie over te ontdekken waar bepaalde bibliotheekcode geladen is, die je zelf ook kunt aanroepen.

Het gevaar zit hem erin dat je het physieke adres kunt ontdekken, hetgeen mogelijk bruikbaar is in een andere aanval, zoals een use-after-free, waarbij een ander hoger gepriviliceerd process (buiten de Javascript sandbox) nu weet waar deze handige bibliotheekfuncties zitten. Dat maakt het voor die andere aanvallen aanzienlijk makkelijker.

Er zitten echter nog wel wat haken en ogen aan een echte end-to-end aanval, maar het is wel een knappe doorontwikkeling van hun onderzoek van vorig jaar.

Snap het ergens wel van die fabrikanten, die rammen al verschrikkelijk veel elektronica in een minatuurvorm en dat heb je, lijkt mij, niet met een knip in de vingers of twee keer de hielen tegen elkaar klikken opgelost Zal echt wel naar gekeken worden.

Openbaring van het VU is enerzijds te snappen maar aan de andere kant roekeloos. Dit kan gigantisch worden uitgebuit, en zonder twijfel zal dat ook worden gedaan.

Ik snap je reactie, maar als je dit niet op een gegeven moment meldt, wordt het nooit opgelost. En uiteindelijk kan een crimineel dit ook uitvogelen, dus dit onder de pet houden lost het probleem ook niet op. Blijkbaar heeft de industrie tot nu toe nog geen urgentie gevoeld om het probleem aan te pakken. Dan maar op deze manier.

Javascript staat bij Jan Modaal aan, Javascript staat bij de meeste gebruikers aan.

Lekker overdreven.
Dit kan alleen maar helpen om een exploit wat makkelijker uit te buiten.

Dus de enigste manier om je hier tegen te wapen is, de noscript-add-on te gebruiken in je browser?

Je browser up-to-date houden is waarschijnlijk al voldoende. De browser is op beveiligingsgebied waarschijnlijk het meest onderzochte stuk software op je pc, dus de kans dat je via javascript aan code-injectie kunt doen lijkt me klein, en zonder deze tweede zwakheid kan je met het gevonden adres alsnog niets.

Browser in een virtuele machine/omgeving (bv VirtualBox) draaien? Is dat een oplossing?

[Reactie gewijzigd door juanita op 15 februari 2017 09:19]

Nee, gewoon noscript en wachten op een bugfix.
Tenzij je een super-slome browser wilt.

[Reactie gewijzigd door Soldaatje op 15 februari 2017 06:15]

Hoezo zou dat een slome browser opleveren? De VM's van tegenwoordig zijn retesnel.

Virtual machines hebben meestal geen toegang tot hardwareversnelling voor het decoderen van video en het versnellen van graphics. Daarom moet alles op de CPU gebeuren. Als je PC op de achtergrond ergens mee bezig is of als je een video bekijkt dan kan dit voor traagheid zorgen. Hardwareversnelling in virtual machines komt wel steeds vaker voor maar de meeste consumentenoplossingen kunnen dit vaak niet zo goed.

NoScript is best oké, maar ik gebruik liever ScriptBlock voor Google Chrome, geen idee af deze addon er ook is voor Firefox en/of Edge.

[Reactie gewijzigd door xippie op 15 februari 2017 00:16]

Waarom is die beter dan Noscript?

Deze addon kan je veel makkelijker aan/uit zetten per gebruik, en is ook op oudere computers lichter in gebruik.

Hoe bedoel je precies, aan- en uitzetten "per gebruik"? Noscript kun je heel makkelijk aan- en uitzetten?

Ik heb nooit echt gemerkt dat Noscript veel processorkracht gebruikt, althans niet in Firefox? Mijn computer is 9 jaar oud.

een 9 jaar oude high end game pc heeft toch iets meer power dan een moderne atom

Dat is zo, maar ik heb 'm toen gebouwd voor ca. €600.

Lijkt mij dat NoScript er juist voor zorgt dat de browser een stuk sneller wordt, want je hoeft 1. heel veel niet in te laden 2. heel veel niet uit te voeren.

Elke keer als ik javascript en geheugen in de zelfde zin lees dan vraag ik me elke keer weer af waarom? Is het niet veel makkelijker om te zeggen dat je niet direct bij het geheugen kunt vanuit code die cliënt side draait in het hedendaagse web omgeving

[Reactie gewijzigd door ocwil op 15 februari 2017 00:48]

Als je wilt programmeren zul je toch gebruik moeten maken van variabelen en functies. Als je bedoelt dat Javascript niet direct toegang zou moeten bieden tot de geheugen adressen waar variabelen en functies staan: dat is normaal ook niet zo, dat is juist wat deze aanval mogelijk maakt. In het filmpje zie je ook dat het 'geraden' adres bevestigd wordt met behulp van gdb.

Volgens mij gaat het er om dat je voor al dit soort hacks directe controle over de cpu moet hebben en dat zou eigenlijk niet moeten kunnen.

Nee hoor, dat is nergens voor nodig. Door het slim lezen van variabelen op specifieke punten kunnen de onderzoekers ervoor zorgen dat bepaalde cachelines verdwijnen uit de cache. Hiervoor zijn geen specifieke instructies vereist, maar een hoop kennis van de werking van CPU caches.

Ja, en dus is de vraag waarom je vanuit die taal 'slim' variabelen kan lezen. Volgens mij kan dat alleen door bepaalde 'features' in js uit te buiten.
Zo lijkt het erop dat vanuit JS de resultaten van de MMU operaties benaderbaar zijn en dat had nooit gemogen.
Ik bedoel, jij hebt het over cachelines die verdwijnen, maar hoezo kan je vanuit JS bij die informatie komen?

Volgens mij kan dit niet als je hitmanpro.alert gebruikt..
downloads: HitmanPro.Alert 3.5.0 build 546

"Hardware-Assisted Control-Flow Integrity (CFI) mitigation
ROP mitigation
CallerCheck mitigation
Heap Spray mitigation"

Of Microsoft EMET, iets minder geavanceerd.
downloads: Enhanced Mitigation Experience Toolkit 5.51
Of Malwarebytes Anti Exploit
downloads: Malwarebytes Anti-Exploit 1.09.1.1291

Of komen ze al voor de ROP en Heapspray migitation in het cpu-cache?

Wanneer een aanvaller de locatie van code in het geheugen weet, is CFI een methode om een ROP attack tegen te gaan. In hoeverre CFI beschermt is afhankelijk van de implementatie, echter hebben goede implementaties een enorme overhead. Maar ook van CFI is al bewezen dat het te omzeilen is in bijvoorbeeld dit paper.
CallerCheck mitigation ben ik niet echt bekend mee, maar als ik het even zoek lijkt het op een vergelijkbare bescherming als CFI, correct me if I'm wrong.

[Reactie gewijzigd door Vedette. op 15 februari 2017 09:58]

Misschien moet je nogmaals het artikel lezen.

Wat is hier nu concreet het risico van? En als er geen risico is, waarom wordt hier dan zoveel tijd in gestoken? Ik ziet het nut van dit soort onderzoek niet in gezien het 'lek' schijnbaar nauwelijks te misbruiken is.

Nauwelijks is hier het sleutelwoord.

Er wordt zoveel tijd en geld in gestoken omdat kwaadwillende partijen dit ook doen. Liever komt de VU erachter dan iemand met minder goede bedoelingen. Hoe moeilijk ook, als iets kan zal het ook gebruikt worden.

Nee, het is een van de manieren
"Het uitvoeren van javascript-code kan wel worden tegengegaan, bijvoorbeeld door de Noscript-add-on te gebruiken"

Weet je wat ik me wel eens afvraag, al geld dit niet direct voor dit lek, aangezien hier geen code mee kan uitgevoerd worden.
Maar waarom worden lekken in software & hardware bijna altijd gemeld.
Aangezien er zo een grote groep in een keer vanaf weet.
Nu snap ik natuurlijk ook wel dat ze vaak gemeld worden, zodat er wat aan gedaan kan worden.
En dat is natuurlijk een goeie zaak.

Off-topic:
Maar soms heb ik er een beetje hetzelfde mee als toen gemeld werd op het nieuws, dat het oranje stoplicht een halve seconde langer op oranje zal gaan blijven staan.
Toen dacht ik namelijk gelijk van, waarom melden jullie dit nu aan de massa.
Aangezien er op deze manier waarschijnlijk vaker nog even lekker op het gas getrapt gaat worden wanneer er een stoplicht op oranje staat.
Waar als ze het niet hadden gemeld, de burgers zich niks anders in het verkeer waren gaan gedragen, waar dit op deze manier (het wel melden) wel het geval kan gaan zijn.
Maar goed, misschien zijn ze dit nou eenmaal verplicht te melden natuurlijk, dat zal ik niet zo weten namelijk.

[Reactie gewijzigd door SSDtje op 15 februari 2017 12:02]

Zoals het artikel aangeeft: de bevindingen zijn in oktober bekend gemaakt aan de hardware fabrikanten en browsermakers.

Het is dus niet zo dat ze dit gisteren gevonden hebben en vandaag met de wereld delen.

De redenen dat dit openbaar gemaakt zullen te maken hebben met

• druk zetten op de betrokken partijen omdat de onderzoekers vinden dat dit zo snel mogelijk verholpen moet worden
• gebruikers inlichten, zodat mensen zich bewust zijn van, niet alleen dat het probleem bestaat, maar ook dat de aanval gemakkelijk reproduceerbaar is.

Vaak wordt in zo'n disclosure besproken wat het termijn is waarin de onderzoekers het probleem geheimhouden. Openbaarmaking van deze informatie gebeurt over het algemeen achteraf, nadat het probleem verholpen is, of wanneer de onderzoekers het idee hebben dat ze niet serieus genomen worden.

[Reactie gewijzigd door Laloeka op 15 februari 2017 13:36]

"de bevindingen zijn in oktober bekend gemaakt aan de hardware fabrikanten en browsermakers.

Het is dus niet zo dat ze dit gisteren gevonden hebben en vandaag met de wereld delen."

Goed punt, en thx voor de aanvullende informatie hierover natuurlijk, altijd welkom.
Maar ze kunnen ze dit ook prima aan de partijen melden die hier wat aan mogen/kunnen gaan doen, en er zo zelf ook baat bij hebben, en het verder zolang stil houden, tot dat het is verholpen, en het dan pas aan het grote publiek melden.
Maar zoals het nu gaat, wordt het vaak eerst gemeld, en na de tijd pas opgelost.
Niet de meest slimme tactiek dus zeg maar (althans naar mijn idee dan)

Edit: Typo's

[Reactie gewijzigd door SSDtje op 15 februari 2017 15:19]

Ze maken het bekend om prestige te winnen, kijk eens hoe goed onze faculteit is. En op die manier (mogelijk) ook aan meer fondsen en sponsering te komen.

Kijk, en dat wist ik dan weer niet.
Dus dat verklaart een hoop.
Thx voor het melden

Hoe kan Javascript, een script-taal met garbage collection en zonder directe toegang tot pointers, zoiets doen?