OpenVPN repareert door Nederlander gevonden kwetsbaarheden

De ontwikkelaars van OpenVPN hebben verschillende kwetsbaarheden in hun vpn-software verholpen. Deze zijn ontdekt door beveiligingsonderzoeker Guido Vranken, nadat er al audits van de software hadden plaatsgevonden.

Volgens Vranken gaat het om vier kwetsbaarheden, die hij ondanks de twee audits heeft weten te ontdekken. Hij maakte daarvoor gebruik van fuzzing, waarbij een programma geautomatiseerd van willekeurige data of gedeeltelijk geldige inputs wordt voorzien. Daardoor is het mogelijk om vast te stellen of het programma op een onverwachte manier reageert, bijvoorbeeld door te crashen.

Vranken zegt daarover: "Het handmatig uitvoeren van een audit om geheugenlekken te vinden in een C-programma is hetzelfde als het wassen van een auto met een make-upborsteltje." Daarmee bedoelt hij dat in bepaalde gevallen een geautomatiseerde aanpak het beste werkt.

De kwetsbaarheden maken het onder meer mogelijk om een dos-aanval uit te voeren op een OpenVPN-server of -client. Een ander lek maakt het voor een aanvaller in een man-in-the-middlepositie mogelijk om gevoelige gegevens te onderscheppen, bijvoorbeeld een wachtwoord. Dit geldt echter alleen als er verbinding wordt gemaakt met een ntlm-proxy.

De lekken doen zich voor in versie 2.4.2 van OpenVPN, aldus de organisatie. Er zijn inmiddels patches beschikbaar in de vorm van versies 2.4.3 en 2.3.17. Bij de kwetsbaarheden gaat het om CVE-2017-7521, CVE-2017-7520, CVE-2017-7508 en CVE-2017-7522. Het is dan ook aan te raden een update uit te voeren.

Reacties (27)

Wat ik mij nu afvraag is of ze dit niet hadden op kunnen vangen met unit tests? Het gaat immers om foutieve data in bepaalde functies invullen.

Dat lijkt mij best een belangrijk onderwerp gezien de populariteit van OpenVPN.

[Reactie gewijzigd door WK100 op 22 juni 2017 17:16]

Unit tests zijn ook heel erg specifiek met een specifieke input en output (juist omdat ze automatisch uitgevoerd kunnen worden). Het is juist om te zorgen dat het systeem in bekende van tevoren bedachte situaties (de normale werking) goed functioneert.

Fuzzing is wel iets heel anders, het is het bestoken van een programma met random shit Daarmee introduceer je juist onbekende situaties. Je zou wel unit tests kunnen maken voor elke mogelijke foute invoer maar dan kom je weer in het gebied 'auto schoonmaken met een tandenborstel' dat in het artikel genoemd wordt.

Goed werk in elk geval, super dat deze bugs ook weer geplet zijn. Daarmee heeft deze Guido het internet weer een stuk veiliger gemaakt

[Reactie gewijzigd door GekkePrutser op 22 juni 2017 17:36]

Je zou wel unit tests kunnen maken voor elke mogelijke foute invoer maar dan kom je weer in het gebied 'auto schoonmaken met een tandenborstel' dat in het artikel genoemd wordt.

Ben ik het niet mee eens. Unittests met waarden die je uiteindelijk ook verwacht zijn heel leuk, maar juist de unittests waarbij je fouten verwacht zijn belangrijk. Zodoende shrijf ik vaker scenarios waarbij het fout gaat dan scenarios waarbij het goed gaat. Foutieve invoer door users komt namelijk vaker voor dan dat een gautomatiseerd systeem kan testen. Handmatig fuzzen is dan ook een hele goede methode om unittests uit te kunnen breiden met foutieve input.

Ik mag dan ook aannemen dat hier een aantal bekende scenarios aan de test cases zijn toegevoegd.

Maar zelfs die foute input is iets dat jij kiest, en waarvan je na één test weet of het systeem reageert zoals je verwacht. Je kan echter niet een oneindige hoeveelheid inputs proberen in je unit tests. Je kiest iets goeds, een paar corner cases, iets fouts, en dat is het meestal wel. De problemen ontstaan als er cases zijn die je niet had bedacht (en dus getest) en die een ander dan normaal gedrag veroorzaken om welke reden dan ook, bijvoorbeeld omdat je er niet aan gedacht had dat je input zou kunnen krijgen die bizar lang is, of die bepaalde karakters bevat die je normaal niet tegen komt, of die veel sneller komt dan normaal, of...

Dat zijn nu juist de dingen die je met fuzzing in feite aan het proberen bent.

Input die bizar lang is vang je hoop ik direct af toch? Dat kan bijna niet goed zijn namelijk.

Nou snap ik natuurlijk het idee dat random van alles proberen meer oplevert dan vooraf allerlei scenario's bedenken, maar ik mag toch aannemen dat je er niet vanuit gaat dat een andere unit altijd de correcte data doorgeeft?

Zeker met externe systemen doe je altijd eerst een korte validatie toch? Ik controleer ook altijd even of m'n input goed is zelfs al heb ik het zelf gegenereerd.

Ja maar check je bijvoorbeeld oook wat er gebeurt met je systeem als je er 16mb aan random karakters in stopt? Misschien vang je de te lange string wel af, maar 16mb aan data kan bv je regex bibliotheek omzeep helpen. En als je dan op dat moment nog een connect maakt met een pylod van 16mb zodat je server dan trager wordt. En op dat moment doe je er nog een. Tot je een DOS te pakken hebt waarbij bv maar 10 connects per seconde voor nodig zijn. Ik noem maar iets, maar Aan zulk soort dingen moet je denken.

[Reactie gewijzigd door DeuTeRiuM op 22 juni 2017 22:39]

Er bestaat ook een fuzzing-methodiek die probeert te snappen hoe de software werkt. Door te kijken wanneer de uitvoering van de software op nieuwe code-gedeeltes of -patronen komt. Door die variatie in de input te bewaren als 'bouwlok' kan er effectiever worden getest dan met random bitcombinaties.

En natuurlijk kent een fuzzer ook het protocol, zodat niet bijvoorbeeld alle input wegens een CRC-error wordt tegengehouden.

Unit-tests om te controleren of bepaalde code reageert zoals je verwacht zijn de meest obvious unit-tests en de meeste devvers schrijven die ook, maar de beste unit-tests zijn degene die je maakt met de gedachte "hoe zou ik dit stuk kunnen maken".

Had gekund maar moet je alsnog een goede test schrijven wat soms best lastig kan zijn.

Het maken van goede test scripts is vrij lastig

bij grote software implementaties, zoals een SAP HANA uitrol, loop je gedurende een project door een aantal fases heen:
*1 het definiëren van een ontwerp specificatie - een set van eisen waaraan de software moet voldoen inclusief een aantal unit tests (set van cases) waaraan de oplossing moet voldoen
*2 de developer(s!) bouwen aan de hand van de specificaties de oplossing. Als het ontwerp voldoet dan wordt het overgedragen aan de key users voor validatie
*3 de key users hebben een aparte (!) set van scenarios en data waarmee de oplossing separaat wordt getest
*4 bij fouten/aanvullingen/correcties wordt het ontwerp (*1) bijgewerkt totdat het voldoet.
*5 een grotere groep van key users zal dan end-to-end (E2E) testen of de aanpassing in het grote geheel goed werkt.

Nu klinkt dit leuk maar het blijft een kunst om goed te testen. Het gaat op de volgende punten vaak mis:
*0 zowel de key users als de developers leven in hun eigen wereldje en snappen elkaar niet erg goed. Dit is vooral een probleem als externe partijen voor de implementatie zorgen.
*1 de eisen zijn te vaag of te specifiek opgesteld. Ook werkt men vaak niet samen met andere gebruikers om een specificatie te controleren. Hierdoor veroorzaakt de oplossing voor een een probleem voor een ander.
*2 de ontwikkelaars bouwen naar de specificatie toe maar missen vaak het overzicht.
*3 als de key users genoeg tijd hebben en weten hoe ze moeten testen dan zoekt men ook naar manieren om de oplossing te breken.
*4 verbeteren mits er genoeg prioriteit/tijd/geld/mensen zijn
*5 E2E tests vragen om een grote groep (cross afdeling) samen te werken en tientallen tests door te voeren.

Het komt er eigenlijk op neer dat de developers/ITers geen gebruikers zijn en de gebruikers geen ITers zijn. Dat wil zeggen ze snappen elkaars wereldje maar matig. Daarom is automatisch testen belangrijk, nu kan je een grote data set (zeg: alle orders van afgelopen december) door het test systeem gooien en kijken of het allemaal werkt.

Mooi verhaal en zeker een aantal punten benoemd welke eigenlijk taboe zijn. Met name dat programmeurs/ITers geen representatieve key users zijn.

Daarop gaat ook zo veel fout. Omdat ITers vaak anders denken dan niet ITers. Je zag dat vroeger met de GUI van diverse Open Source projecten, sloot perfect aan bij de makers, maar totaal niet bij de mainstream gebruiker die geen kennis had van IT. Wat overigens nog steeds is met veel Software.

De manier van denken van ITers vs gebruikers is vaak fundamenteel verschillend. Dit kun je enigszins oplossen door een ITers een tijdje laten meedraaien in een werk omgeving, zoals een callcenter, order intake, magazijn enz. Daarmee verhoog je het begrip van de ITer in gebruiksvriendelijkheid van de oplossing.
Omgekeerd is een stuk moeilijker. Om aan een gebruiker uit te leggen dat hard afsluiten (ALT+F4) voor problemen zorgt en dat je beter kan wachten tot het trage programma verder gaat, is een stuk lastiger uit te leggen -zonder- technisch te worden.

Een mooi verbeeld is het gebruiken van een zacht vs hard popup scherm met een fout melding. Ik zie gebruikers vaak een zachte-popup (eentje die alleen informatie toon en gelijk kan sluiten) gelijk weg klikken als het te vaak voorkomt (systematische oorzaak?). Bij een harde-popup (het probleem moet eerst opgelost worden voor men verder kan) is de irritatie snel groter, zeker als het oplossen door anderen moet worden gedaan (voorbeeld: materiaal gelocked gedurende aanpassing vs materiaal toekennen aan een bestelling/levering).
Bij een zachte-popup zal men mogelijk foute/incomplete data invoeren en verder gaan. Andere afdelingen (+IT?) kunnen dan achteraf gaan opruimen.

De keuze van dit soort popups gedurende grote projecten worden vaak gemaakt door managers/key users - mensen die verantwoordelijk zijn voor een deel van de operatie.

Klopt totaal, maar ik zie ook vaak dat key-users een andere mening hebben dan de manager, of dat een groep key-users een deelnemer hebben welke nog in oude procedures en werkwijze denkt, waardoor het uiteindelijke resultaat zowel technisch een gedrocht is, als bedrijfsmatig een nachtmerrie is, en werkzaam een hel is.

Ja, een ITer mee laten draaien is ok. Maar vlak de beslissers niet uit. Hoe vaak ik gezien heb dat een oude DOS, OS/400, VMS ga baseerde applicatie met hangen en wurgen ia geconverteerd naar een moderne toepassing waarin moderne methodieken en bedrijfsprocessen totaal vernaggeld zijn omdat een handvol bejaarden er anders niks meer van kunnen snappen. En zich afvragen waarom het bedrijf na het IT project opeens over de kop gaat.

Ik heb ooit een OS/400 BPCS systeem naar SAP migratie project geleid. Precies een oud systeem dat zover was "verbeterd" dat er niets meer standaard was. Een grote nachtmerrie.

We hebben heel veel tijd gestoken in het vooraf trainen in vanille SAP gebruik en daarna in het mappen van bestaande processen naar SAP best practices. Elke afdeling/manager kreeg een "budget voor aanpassingen weg van standaard" waardoor discussies over "zo doen we het al jaren" een discussie werd over "verbeteren van SAP".

Drie maanden na go-live bleek uit een enquete dat zelfs de grootste hardliners tegen migratie over waren. Het "oude proces" werkte maar zorgde ook voor veel extra werk dat nu automatisch gebeurde.

Change management wordt vaak sterk onderschat. Belangrijk is dat je naar iedereen luistert maar ook dat iedereen luistert naar jou. En vergeet maar dat je iedereen kan overtuigen, een sterke ruggengraat van de PM en van management is soms heel belangrijk.

[Reactie gewijzigd door _Zedd_ op 22 juni 2017 22:23]

Ja, leuk verhaal, maar dat is hoe we 20 jaar geleden software bouwden (ook wel bekend als de waterval-methode). Tegenwoordig bouwt ieder degelijk ontwikkelteam met een agile methode (kanban, scrum, etc), waarin je niet meer vooraf alle eisen definieert maar het grote geheel in kleine stapjes bouwt.

1. Bepaal welk stukje er gebouwd gaat worden en werk alleen van dat stukje de specificaties uit.
2. Bouw het stukje. Afhankelijk van je methode schrijf je de tests ervoor (tdd), erna of tijdens de ontwikkeling.
3. Verzamel feedback van alle betrokkenen (PO, gebruikers, ...).
4. Neem deze feedback mee en maak een nieuw plan voor het bouwen van een ander klein stukje (zie 1). Ofwel het gebouwde stukje verfijnen (of zelfs helemaal schrappen), ofwel aan iets nieuws beginnen.

Het verschil met jouw geschetste situatie is dat je geen grote IT-projecten meer krijgt die aan het eind voor geen enkele partij voldoen (gebruikers kunnen er niet mee werken, management vind de featureset niet goed, IT heeft moeite met beheer), omdat eventuele problemen tijdig worden gevonden voordat ze te ver in het systeem verankerd zitten om er nog wat aan te kunnen doen.

Waar je iets hoort over gefaalde IT projecten gaat het meestal om waterval projecten. De overheid staat er bekend om. Hun manier van aanbesteden wekt een waterval model in de hand, aangezien ze vóór de implementatie al een contract afsluiten en zich daarmee vast zetten op een bepaalde oplossing.

Tests zijn niet de universele oplossing voor al je problemen. Een test controleert alleen gevallen die je er zelf in bouwt en zal dus geen problemen vinden die buiten het bereik van de test liggen. Als je bv een functie test die een integer als input neemt en je test op 100, 1, 0 en -1 vind je geen bug die zich pas voordoet bij bv 1025. Ik denk niet dat iemand tests gaat schrijven die alle mogelijke inputs testen. Zo'n suite zou dagen duren om te draaien.

Als je bv een functie test die een integer als input neemt en je test op 100, 1, 0 en -1 vind je geen bug die zich pas voordoet bij bv 1025. Ik denk niet dat iemand tests gaat schrijven die alle mogelijke inputs testen. Zo'n suite zou dagen duren om te draaien.

Dat is dus nou net wat men tegenwoordig wel doet, aangezien men tot het inzicht is gekomen dat unittests alleen niet zaligmakend zijn. Kortom dat is wat in het artikel staat "Fuzzing". Wordt tevens al een tijdje losgelaten op de Linux kernel en andere OSS projecten (of ze zijn er mee bezig), Google heeft er bijvb een framework voor geschreven. Het duurt inderdaad potentieel wel lang voor er bugs gevonden worden, dus je kunt de techniek inderdaad niet als test in de "push-gate" gebruiken van een project, dat werkt alleen met unittests. Kortom unittests en fuzzing vullen elkaar aan.

Ja, ik heb het artikel gelezen, en ik weet wat fuzzing is. Dat was m'n punt niet. En aan jouw reactie te zien ben jij het dus met mij eens.

Mijn reactie ging over WK100 die met een opmerking kwam als "dan schrijf je toch gewoon een test?", terwijl ik juist aan wilde geven dat dat helemaal niet hetzelfde is, en het genoemde probleem niet oplost. Fuzzing en tests zijn 2 verschillende dingen. Tests controleren een beperkte set aan input op voorspelbare waardes, terwijl fuzzing naar onverwacht gedrag zoekt.

Als je slechts test met de door jouw genoemde input heb je dus niet getest. Dan heb je geprobeerd of het werkt.

Dat was een simpel voorbeeld natuurlijk. Bij een test moet je al weten wat er als resultaat uit hoort te komen. Je kunt dus niet in de test zelf de berekening opnieuw uitvoeren met random input aangezien je dan geen test maar een tweede implementatie hebt geschreven. Dan zou je een test nodig hebben om de test te controleren.

Iedereen heeft een andere kijk. Of misschien heeft iemand oogkleppen op. Vandaar ook een audit.

Of misschien moesten die lekken er in zijn by design...

Conspiracy theory, #CIA :-)

Dan werkt het principe van open source dus niet als het nu pas gevonden is. Dan had het al veel eerder gevonden kunnen zijn.

Dat principe wordt ook schromelijk overdreven... Bij oss _kan_ de source ingezien worden, niets zegt dat dat ook echt gebeurt en al helemaal niet op een niveau zoals deze bugs zijn gevonden.

Ik weet dat MS zo'n systeem heeft, en heeft daar al tientallen jaren en miljarden aan ontwikkeling in heeft zitten. Elk stukje code van MS wat naar klanten gaat, gaat hier doorheen.

En nog overkomt het MS met regelmaat dat er links en rechts gaten in de software zit.

Als de grootste software ontwikkelaar dat al niet af weet te vangen, dan gaat een FOSS project als OpenVPN, hier ook weinig mee beginnen.

Je kunt namelijk niet meer afvangen dan wat bekend is en de kennis van de developers.

Heeft dit ook invloed op de OpenVPN app die ik op mijn iPhone gebruik om verbinding te maken met Private Internet Access?

Ja inderdaad, en die openVPN server die is ingebakken op mijn router?
Als Netgear die voorlopig niet update blijf ik gevaar lopen.

Maw: de OpenVPN organisatie kan het lek wel dichten in de source, maar nu alle implementaties op alle verschillende hardware nog?