image

Beveiligingslek in pdf-lezer Chrome "per ongeluk" verholpen

maandag 16 juli 2018, 12:04 door Redactie, 3 reacties

Een beveiligingslek in de pdf-lezer van Google Chrome is eind juni "per ongeluk" verholpen, zo meldt onderzoeker Zhou Aiting van het Qihoo 360 Vulcan Team. Aiting had op 17 april een kwetsbaarheid in de pdf-lezer van Chrome gevonden waardoor een aanvaller willekeurige code had kunnen uitvoeren.

De kwetsbaarheid alleen was niet voldoende om uit de sandbox van Chrome te beveiligen, waardoor een aanvaller in het ergste geval data van andere websites had kunnen stelen of aanpassen. Twee dagen nadat Google door de onderzoeker was ingelicht werd er een patch voor het probleem ontwikkeld. Deze patch werd op 10 mei onder Chrome-gebruikers uitgerold. Voor zijn bugmelding ontving Aiting 5.000 dollar.

De onderzoeker ontdekte dat de patch niet volledig was en het nog steeds mogelijk bleek om het beveiligingslek aan te vallen. Eind juni kwam er echter een onverwachte oplossing voor het probleem. Google besloot namelijk het datatype waardoor de aanval mogelijk was in de pdf-lezer te verwijderen en door het gebruik van een vector te vervangen. Daardoor werd ook de kwetsbaarheid "per ongeluk" verholpen, aldus Aiting.

Reacties (3)
16-07-2018, 22:50 door Anoniem
Security by design of met andere woorden “Foutloos programmeren” blijft een probleem. De programmeur ziet te weinig van de bijverschijnselen die zijn creaties met zich meebrengen. De testers onderzoeken vaak alleen de gewenste functionaliteit en richten zich niet op de beveiliging, daar hebben ze nauwelijks of geen verstand van. Het gevolg is dat er kwetsbaarheden in de productionele omgeving worden geïmplementeerd.
17-07-2018, 09:02 door Anoniem
unit testing zou dit wellicht beter kunnen voorkomen (dat het ten eerste fout gaat dan),. maar dat kost wel heel veel extra ontwikkeltijd.
17-07-2018, 23:57 door Anoniem
Neen, dat kost niet meer ontwikkeltijd. Het kost je alleen maar tijd aan security bewust maken van de programmeurs van de toekomst. En dan ben je er ook nog niet, want ook bij de configuratie aan de server en client (browser) kant, dient het veiligheid bewustzijn aardig opgekrikt te worden. Een algemeen INF & TINF educatief en bewustwordingsprobleem dus (INF =informatica en TINF= technische informatica).

Als de gemiddelde website nog zo'n tussen de 40 en 80 kleinere tot stevige veiligheidsissues kent en een heleboel bibliotheken met kwetsbare code, verouderde code of niet meer onderhouden code niet op tijd afgevoerd worden, verandert er niets in de feitelijke situatie. Het blijft dan dweilen met de kraan open, cheat sheets of geen cheat sheets. Degene die knipt en plakt, knipt en plakt andermans ellende mee.

Een endless loop stuck event laten beslissen of iemand zijn graadje development 4 toets haalt, OK, maar ook onvoldoende veilig coderen moet dan betekenen dat je dat papiertje missen moet.

Oh, ja en mensen met relevante kennis in het beslissing-circuit opnemen en geen outsider beslissers, die kiezen voor een mooie 1-click-solution out of the box, zoals het helaas nog te vaak gebeurt. Zij die kennis hebben, doen er niet toe en zij, die er toe doen, bezitten meestal de noodzakelijke kennis niet. Of spelen er steeds nog weer andere belangen mee? (gratis? en product en zo?). Nog steeds geen omslag van de algemene situatie gezien.

Velen van ons op deze site blijven roependen in de woestijn, helaas pindakaas! Bitwiper, ik voel met je mee, keep up the good work.

luntrus
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.