'NSA maakte al twee jaar misbruik van Heartbleed-bug'

Assers inbouwen is een prima praktijk, maar in release/optimized versies zijn asserts doorgaans nul operaties. Alleen debug releases hebben asserts, voornamelijk voor de ontwikkelaar. Een assert is een bewijs een aanname.

Als OpenSSL gewoon de standaard implementatie gebruikt had voor malloc et al. dan zou het in debug mode een assertion opleveren vanuit de library en in release/optimized versies ronduit crashen met een segmentation fault.
Dat is dus echt 1000en keren beter dan stilletjes privé data lekken.

Zie o.a. : http://article.gmane.org/gmane.os.openbsd.misc/211963

Eigen alloc functies zijn op z'n best een wrapper rondom systeem alloc functies. Geheugenbeheer gaat altijd via systeem libraries/kernel. Er zijn nog steeds goede redenen om zelf geheugenbeheer te doen. Domweg omdat allocatiepatronen per applicatie verschillen, en de systeem alloc vaak van bepaalde patronen uitgaat.

En als je dat dan doet in een applicatie die security-technisch heel zwaar leunt op correctheid, dan neem je de verantwoordelijkheid om je eigen implementatie rigoreus op problemen te controleren en zorg je er dus ook voor dat je een eigen seg-fault mechanisme implementeert zodat je dezelfde mate van bescherming en detectie kunt bieden als in de systeem libraries aangebracht is.
En dat is dus bij OpenSSL niet gedaan; 'want performance'.

In een security-gevoelige applicatie is het daarnaast ook bespottelijk dat je een geheugen allocator implementeert die geheugenblokken niet terug op 0 zet, maar ze enkel opnieuw toekent aan andere functionaliteit binnen de applicatie. Dat is vragen om een buffer overflow die allerlei recent in het geheugen aanwezig geweeste data kan opvragen.

Overigens zit er ook een dikke vette valse aanname in de eigen allocator van OpenSSL waardoor je de library niet kunt compilen zonder gebruik te maken van die eigen allocator:
Geheugen dat vrijgegeven wordt met wordt klaarblijkelijk direct daarop volgend opnieuw gealloceerd voor verder uitlezen, waarbij aangenomen wordt dat je exact het oude geheugenblok terug krijgt.
En dat is bij zo ongeveer elke systeem implementatie absoluut niet gegarandeerd. Misschien moeten de mensen die dit geschreven hebben even terug naar school om te leren wat Liskov substitution en zo inhouden.

Zie o.a. http://www.tedunangst.com...of-openssl-freelist-reuse

OpenSSL verschijnt met enkele versies per jaar en wordt door een brede groep gebruikers en platformen gebruikt. Die gebruikers gebruiken ook gewoon actuele compilers. Ook de meest moderne bewaart je niet voor het maken van bugs. En buffer overflows, stack corruptie (waar compilers soms een beetje bescherming voor bieden) voorkom je er niet (volledig) mee. Daarbij heb je bij multi-platform niet alleen met gcc/glibc te maken, maar met veel meer compilers en platformen.

Side comment: dat is dus waarom C/C++ klote zijn. In het bijzonder als je alles onder een saus van template abstractie begraaft maar vervolgens nog steeds op bepaalde punten al dan niet gedwongen met pointers aan het werken gaat. Je bent dan mogelijk de grootste leaky abstraction van de afgelopen decennia in stand aan het houden.

Kortom: OpenSSL als meuk classificeren lijkt me ongefundeerd, onterecht en onvoldoende kennis van zaken.

Gezien het feit dat er al meermalen bug reports omtrend de custom geheugen allocatie en security implicaties geweest zijn (al zeker 4 jaar terug komen ze voorbij!) en daar nooit eerder iets aan gedaan is, kan je mijns inziens wel zeker stellen dat OpenSSL op het vlak van secure software compleet meuk is.

[Reactie gewijzigd door R4gnax op 12 april 2014 11:26]