Audit van populaire cryptobibliotheek legt geen grote kwetsbaarheden bloot

Een audit van de populaire cryptografische softwarebibliotheek libsodium heeft geen grote kwetsbaarheden aan het licht gebracht. Het onderzoek van de code werd op verzoek van vpn-provider Private Internet Access uitgevoerd door cryptograaf Matthew Green.

De vpn-provider heeft bij de presentatie van de resultaten van de audit gemeld dat het de softwarebibliotheek zelf gebruikt voor zijn interne software. Het onderzoek richtte zich in eerste instantie op versie 1.0.12 van libsodium en na enkele nieuwe commits werd ook versie 1.0.13 meegenomen. Green schrijft bij de resultaten van de audit: "Onze algemene bevinding is dat libsodium inderdaad een veilige bibliotheek van hoge kwaliteit is, die zijn doelen op het gebied van gebruiksvriendelijkheid en efficiëntie waarmaakt."

Er zijn wel twee problemen met de inschatting 'laag' gevonden. Het eerste heeft ermee te maken dat libsodium op Windows alleen van een onofficiële api gebruikmaakt. Daardoor ontstaat het risico dat er geen back-upoptie is als Microsoft besluit de api te verwijderen. Het tweede probleem heeft te maken met een null pointer dereference, die de stabiliteit van de software kan beïnvloeden.

Libsodium is een opensource-fork van de in C geschreven NaCl-blibliotheek. Ontwikkelaars kunnen de bibliotheek op verschillende platforms gebruiken om cryptografische functies in hun projecten te implementeren, zoals hashing van wachtwoorden, encryptie, decryptie, random number generators en ondertekening. Het libsodium-team wil hiertoe een makkelijk te gebruiken api ter beschikking stellen.

Naast Private Internet Access zijn er nog meer bedrijven en projecten die libsodium gebruiken. Bijvoorbeeld Facebook, hosters Digital Ocean en OVH, en de cryptochatapp Wire. De code komt verder terug in projecten als Discord, PowerDNS, de cryptocurrency Zcash en collaboratiesoftware Peerio. Matthew Green, die eveneens hoogleraar is aan de Amerikaanse Johns Hopkins-universiteit, was eerder betrokken bij audits van TrueCrypt en OpenVPN.

Reacties (14)

[InfoTracer]

Misschien ook leuk om te weten dat
libsodium wordt opgenomen in PHP7.2.

https://dev.to/paragonie/...y-to-its-standard-library

[PrivacyMind]

Mooi dat PIA geld stopt in het auditen van Open Source software die zoveel verschilden bedrijven gebruiken.

Offtopic:
Wel een side noot in het artikel over Wire die jullie linken wordt gezegd.

Totdat er een audit van de software heeft plaatsgevonden, blijft Wire echter een twijfelgeval, maar dankzij de veelzijdigheid aan functies en de aanwezigheid op verschillende platforms, waaronder Windows, is het interessant om het project in de gaten te houden.

Nu heeft Wire wel een Audit gehad zie: https://medium.com/@wirea...urity-review-61f37a1762a8

[Reactie gewijzigd door PrivacyMind op 25 juli 2024 08:52]

[Bongoarnhem]

Wat ik uit het stuk haal is het volgende:

Het onderzoek richtte zich in eerste instantie op versie 1.0.12 van libsodium en na enkele nieuwe commits werd ook versie 10.0.13 meegenomen.

Zijn er in de tussentijd dan zoveel versie updates geweest of is er een typ fout gemaakt?
In mijn ogen ga je dan namelijk van versie 1 een hele hoop versies later naar versie 10, een redelijke wereld van verschil.

Betreft een typo, gemeld in het forum.

[Reactie gewijzigd door Bongoarnhem op 25 juli 2024 08:52]

[Arjant2]

Als je even de link aanklikt zie je dat het een typefout is en het versie 1.0.13 betreft.

[Stokpop]

Ik vermoed een typo, want op hun website geven ze aan dat versie 1.0.13 de laatste betreft die uitgebracht is op 14 juli 2017.

[duqu]

Dank, die nul hoorde daar idd niet!

[0x76]

Dat blijkt inderdaad een typfout te zijn het hoort namelijk 1.0.13 te zijn zoals te zien op de github pagina van libsodium

[freburgje]

Als veel grote bedrijven van deze lib gebruikmaken, waarom zou MS dan de API verwijderen?
Is het mogelijk om bij MS een verzoek te doen om een bepaalde API te behouden/officieel te maken?

[CAPSLOCK2000]

Als veel grote bedrijven van deze lib gebruikmaken, waarom zou MS dan de API verwijderen?
Is het mogelijk om bij MS een verzoek te doen om een bepaalde API te behouden/officieel te maken?

Ik zou er niet op rekenen. Dat is nu net het verschil tussen officiele en niet-officiele API's. Die API is niet officieel omdat MS niet wil/kan beloven dat die API stabiel blijft. Er kunnen talloze redenen zijn om een API af te willen schaffen omdat het op een andere manier de verdere ontwikkeling van je product in de weg zit, of het onderhouden/ondersteunen te duur of te lastig is.
Dat is natuurlijk ook geen garantie dat die API zal verdwijnen. Veel API's worden eerst experimenteel ingevoerd en pas als blijkt dat ze goed gebruikt worden krijgen ze de upgrade naar "officieel".

[Niels1985]

@freburgje
Het is een onofficiele API, wanneer die nieuwe of bestaande functionaliteit in de weg zit zou het een logische keuze zijn om de onofficiele API te schrappen.

[Reactie gewijzigd door Niels1985 op 25 juli 2024 08:52]

[CAPSLOCK2000]

Goed werk, hier hebben we meer van nodig. Dit soort API's staan aan de basis van talloze applicaties; een onveiligheid op API niveau zou grote gevolgen kunnen hebben.
Deel van het probleem is dat we van veel API's/libraries gewoon niet weten wat de kwaliteit is. Als gebruiker moet je dus of je eigen onderzoek doen (als je dat kan) of maar gewoon eentje kiezen en hopen dat het goed zit.
Nu weten programmeurs in ieder geval dat dit een goede keuze is voor hun software.

[wica]

Wat ik mij afvraag bij dit soort lib, is hoe het geregeld is voor de toekomst?
Krijgt Libsodium voldoende, geld binnen om dit nog jaren te onder steunen en met dan de zelfde kwaliteit aan code.

We hebben libssl (openssl) welke ook door de grote bedrijven gebruikt wordt/werdt maar toch te weinig geld binnen kreeg om goede code op te leveren.

[DShadow]

Wat ik me nu eigenlijk afvraag is er ergens een overzicht van welke software of libraries allemaal een security audit heeft ontvangen en wat de resulaten hiervan zijn.
Als je veilige (zover mogelijk) libraries wil gebruiken lijkt mij zo'n overzicht erg makkelijk.