Bijna 10.000 regels code pEp-privacymachine gecontroleerd
Onderzoekers hebben de bijna 10.000 regels code van de pEp-privacymachine gecontroleerd, de software die volgens de gelijknamige stichting alle geschreven communicatie op internet moet versleutelen. De pEp (pretty Easy privacy) stichting wil encryptie zo gebruiksvriendelijk mogelijk maken.
Dit moet ervoor zorgen dat straks de geschreven communicatie van iedereen standaard is versleuteld. Om dit doel te bereiken ontwikkelt de stichting verschillende tools, zoals encryptietools voor Android en Outlook. Deze software draait op de pEp-engine. Zowel voor transparantie als veiligheid is er vorig jaar augustus een audit van de code gestart, bestaande uit bijna 10.000 regels van de programmeertaal C. Het Duitse Sektion Eins voerde de audit uit, waarbij regel voor regel werd gecontroleerd.
In totaal werden er zeven kwetsbaarheden met de beoordeling "medium" gevonden en vier die als "high" werden aangeduid, alsmede verschillende andere zaken. De beveiligingslekken zijn inmiddels in de software verholpen. Tevens legde de audit verschillende ontwerpbeslissingen bloot. Niet per definitie fouten, maar wel zaken die tot verwarring of toekomstige problemen konden leiden.
De ontwikkelaars van de pEp-stichting merken op dat het hier om een proces gaat, waarbij de audits continu zullen worden herhaald. "Dit biedt geen 100% garantie op code zonder fouten, maar het houdt wel in dat onafhankelijke specialisten en wijzelf alles zullen doen dat menselijk mogelijk is om dat doel te bereiken", zegt Hernani Marques van de pEp-stichting. Het auditrapport en aanvullende documenten zijn nu te downloaden.
[...]
assert(key);
[...]
pair->key = strdup(key);
[...]
Die strdup(key) aanroep crasht wanneer key een null pointer is (waarop niet afdoende wordt gecontroleerd want alleen assert statement).
Checken of de parameter "key" een null-pointer bevat is leuk, maar wat als "key" ongelijk nul is maar naar een vrijgegeven of ander ongeïnitialiseerd stuk geheugen wijst? Het risico daarvan is meestal groter dan van een null-pointer dereference.
In dit soort situaties is het gebruikelijk om de aanroepende functie (of eerder) ervoor verantwoordelijk te maken dat "key" fatsoenlijk is geïnitaliseerd (user supplied input in een zo vroeg mogelijk stadium valideren). Ik heb overigens niet naar andere sources gekeken, d.w.z. waar deze functie wordt, of kan worden, aangeroepen, en weet dus niet of die controles plaatsvinden en "waterdicht" zijn.
Dus je moet dan verder gaan zoeken naar de aanroepers van die functie.
[...]
assert(key);
[...]
pair->key = strdup(key);
[...]
Die strdup(key) aanroep crasht wanneer key een null pointer is (waarop niet afdoende wordt gecontroleerd want alleen assert statement).
Checken of de parameter "key" een null-pointer bevat is leuk, maar wat als "key" ongelijk nul is maar naar een vrijgegeven of ander ongeïnitialiseerd stuk geheugen wijst? Het risico daarvan is meestal groter dan van een null-pointer dereference.
In dit soort situaties is het gebruikelijk om de aanroepende functie (of eerder) ervoor verantwoordelijk te maken dat "key" fatsoenlijk is geïnitaliseerd (user supplied input in een zo vroeg mogelijk stadium valideren). Ik heb overigens niet naar andere sources gekeken, d.w.z. waar deze functie wordt, of kan worden, aangeroepen, en weet dus niet of die controles plaatsvinden en "waterdicht" zijn.
Natuurlijk - we zijn voorzichtig met dit soort input-checking respectievelijk initialisatie; anders zijn null checks waardeloos :) The assert-without-if slipped through here, though, so small or not, it's a good catch. We appreciate it.
https://twitter.com/pEpCouncil/status/787972918177329152
new_ functions in pEp engine are considered constructors. They have to deliver a pointer to the constructed object, or NULL on out of memory.
Unfortunately, the constructor new_stringpair() is designed to take non-optional parameters (practically all other constructors are taking optional parameters only). This is, because a stringpair of less than two strings does not make sense semantically.
And here we go: it is impossible to find a correct implementation, which keeps the original assumptions, and additionally delivers a parameter error if parameters are missing (are NULL).
The “fix” we have now is changing the behaviour of the function. It's not any more delivering NULL on out of memory, but NULL on any error (which includes parameters missing).
This is generating a bug in pgp_gpg.c:1289 for example.
I think, we have to revert that for good reasons.
In het Nederlands: het is wellicht geen goed idee om potentiële beveiligingskwetsbaarheden te bespreken op een open site als deze, omdat kwaadwillenden mogelijk meelezen en het tijd kost voordat geteste fixes gebruikt worden door (security serieus nemende) eindgebruikers.
@krista_g: thanks for your answer! I'm going to find time (no idea how yet ;-) to look at pEp! The world definitely needs signed e-mails to help prevent phishing, while end-to-end encryption is important in some cases (encrypted mail also poses new security risks).
De software is al in gebruik? Oeps, sorry. Dat had ik me niet gerealiseerd...
Helaas is dit, vermoed ik, ook een van de redenen dat maar weinig mensen de moeite nemen om open source code te auditten: vaak twijfel je of iets echt een kwetsbaarheid is, en wilt dat met anderen overleggen zonder de auteurs lastig te vallen met zaken waar zij mogelijk al aan gedacht hebben. Het is dan heel prettig als je dit eerst met anderen kunt bespreken, maar juist bij security issues introduceer je mogelijk risico's - want die anderen kunnen heel andere bedoelingen hebben dan jij.
In het Nederlands: het is wellicht geen goed idee om potentiële beveiligingskwetsbaarheden te bespreken op een open site als deze, omdat kwaadwillenden mogelijk meelezen en het tijd kost voordat geteste fixes gebruikt worden door (security serieus nemende) eindgebruikers.
@krista_g: thanks for your answer! I'm going to find time (no idea how yet ;-) to look at pEp! The world definitely needs signed e-mails to help prevent phishing, while end-to-end encryption is important in some cases (encrypted mail also poses new security risks).
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
