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.
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Cyber Security Trainer
"You know that feeling after you have been to the cinema and seen an exciting movie? It's the same after this training. I can only say that this is probably the BEST TRAINING that I've ever done!!!”
Are you ready for a challenge?
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.