Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 143 reacties

De NSA zou al tenminste twee jaar bekend zijn met de Heartbleed-bug en hier actief misbruik van hebben gemaakt. De organisatie zou de ontdekking van het beveiligingslek echter stil hebben gehouden omwille van de 'nationale veiligheid'.

Dat zegt Bloomberg op basis van twee niet nader genoemde bronnen. De Amerikaanse inlichtingendienst zou al zeker twee jaar geleden hebben ontdekt dat OpenSSL de kritieke Heartbleed-bug bevat. In plaats van de vondst te melden zou de NSA gebruik hebben gemaakt van de kwetsbaarheid en via de bug 'op regelmatige basis' data vergaren. Er zou zijn gekozen voor het stilhouden van de bug vanwege de belangen voor de nationale veiligheid, aldus Bloomberg. De NSA ontkent echter iets van de bug af te hebben geweten.

Het mogelijk gebruik van de Heartbleed-bug door inlichtingendiensten werd eerder geopperd. Daarbij hintte de Electronic Frontier Foundation, die opkomt voor digitale burgerrechten, naar betrokkenheid van organisaties als de NSA. Volgens Ars Technica werd de bug al zeker twee maanden misbruikt, maar Bloomberg meldt dus nu dat dit aanzienlijk langer zou zijn. Daarbij wordt niet uitgesloten dat inlichtingendiensten van andere landen ook op de hoogte waren van de bug.

Heartbleed is een kwetsbaarheid in OpenSSL die kortgeleden aan het licht kwam nadat een Google-medewerker de vondst meldde. De bug maakt het mogelijk om van buitenaf het interne geheugen van een webserver uit te lezen en daardoor private keys en ontsleutelde data te zien. Vele websites maken gebruik van OpenSSL om private keys te genereren, maar hebben in de afgelopen dagen maatregelen genomen om het door Heartbleed veroorzaakte beveiligingslek te dichten.

Moderatie-faq Wijzig weergave

Reacties (143)

Het had de redactie gesierd als ze in elk geval een update had gemaakt naar het officiële standpunt van de NSA:
The Federal government relies on OpenSSL to protect the privacy of users of government websites and other online services. This Administration takes seriously its responsibility to help maintain an open, interoperable, secure and reliable Internet. If the Federal government, including the intelligence community, had discovered this vulnerability prior to last week, it would have been disclosed to the community responsible for OpenSSL.
Na de discussie hierboven en de officiële statement, blijft voor mij de vraag of we deze statement nou moeten vertrouwen of niet.

Maar ja, hoe bewijs je zoiets?
Ze kunnen het ook voor hun eigen systemen en die van de roverheid aldaar gepatched hebben en voor de rest van 't internet de exploit lekker hebben zitten misbruiken natuurlijk :P
Lekker aluhoedje, en ik zeg niet DAT het zo is, enkel dat het met groot gemak kan.
Viel te verwachten natuurlijk. Wie weet hoeveel security holes er in het wild rondvaren waar de NSA al lang van af weet...

Wat zo triest is aan de hele Heartbleed bug is dat het feit dat de eigenlijke bug te exploiten is met desastreuze gevolgen uiteindelijk wordt veroorzaakt door het feit dat OpenSSL een eigen memory pool implementatie heeft, die vrijgegeven geheugen (wat vaak gevoelige gegevens zal bevatten) vanwege performance-overwegingen niet overschrijft met nullen o.i.d., iets wat je bij security-critical code wel zou verwachten.
Dat geheugen is niet per se vrijgegeven. Triester is dat er schijnbaar geen check zit op de grootte van het verstuurde pakketje data, en dus geen check op de inhoud ervan: http://xkcd.com/1354/

ik weet inmiddels totaal niet meer wat of wie ik nog kan vertrouwen, of moet geloven, misschien werkte Robin Seggelmann wel in het geheim voor de NSA, en was het geen bug maar een NSA-feature.

Wél is duidelijk dat we inmiddels zo afhankelijk zijn van computers en internet, dat er daardoor een zeer kwetsbaar netwerk en systeem is ontstaan, wat misschien op deze manier totaal niet meer in de hand te houden is, of te controleren. "We've created a monster!"

Edit: en dan net als ik dit wil posten vliegt mijn internet eruit, ik ben niet paranoďde ik ben een vliegtuig!

[Reactie gewijzigd door Benno de Bruin op 12 april 2014 00:57]

Wat jij beschrijft is standaard amateur-programmeur boundschecking fuck-up. Waar ik op doelde, namelijk waarom de bug catastrofaal is i.p.v. slechts zeer problematisch, is dat dat de malloc wrapper ervoor zorgt dat het probleem vele malen kwalijker is.

Meer informatie hiero: http://article.gmane.org/gmane.os.openbsd.misc/211963
Er bestaat een indicatie dat de hartbleed-bug mogelijk werd geexploiteerd, zoals Terrence Koeman heeft beschreven (zie: eff.org). Het betreffende artikel concludeert dat als deze bug daadwerkelijk actief wordt misbruikt er voldoende bewijs moet liggen in de logs van netwerkoperators voor een bepaald patroon (bijv. TCP Payload van 18 03 02 00 03 01 of 18 03 01 00 03 01).
Wat ik mij afvraag, de bug is er 2 jaar geleden in gekomen.

Wie heeft deze commit gedaan? Wat is die persoon zijn achtergrond? Hiervoor zat het er namelijk "niet" in. Is het er niet bewust in geplaatst en kan je de commit in de history tree terug vinden? Is deze bug er niet bewust in gemaakt?

[Reactie gewijzigd door Texamicz op 12 april 2014 12:05]

De commit is gedaan door Robin Seggelmann. Hij werkte destijds voor T-systems, een dochteronderneming van T-mobile (duitsland).
Het is zeer moeilijk te beoordelen of dit bewust is gedaan. Menselijke fouten zijn niet uit te sluiten. Daarnaast zijn er uitzonderingen waarin een variable length heartbeat packet nut heeft, zie: news.ycombinator.com.
Dat deze bug zover heeft kunnen komen is deels te wijten aan gebrekkige code in een ander deel van openssl, zoals te lezen is in de analyse van de bug.

(bron: github.com).

[Reactie gewijzigd door hieper op 12 april 2014 13:00]

Bedankt voor deze info. Dit soort zaken zijn interessant.
Ik hoop dat de opensource-gemeenschap haar review-proces blijft verbeteren.

Edit: Persoonlijk vind ik het veel interessanter onder welke condities de bug gevonden is:
- Is dit onderdeel van Google's nieuwe security-audit beleid?
- Is de google-onderzoeker getipt van buitenaf op deze bug (door bijv. de NSA)?
-etc.

[Reactie gewijzigd door hieper op 12 april 2014 13:47]

De optie is heel groot dat het een NSA feature geweest is.......Wat het hele verhaal alleen nog maar erger zou maken.....
Nee, de NSA feature is juist dat nu jan en alleman nieuwe certificaten loopt aan te vragen bij de 300+ CA vendors van deze wereld - inclusief die waar inlichtingendiensten een vinger in de pap hebben. Niks geen gehack nodig, ze hebben je PK toch al.
De nationale veiligheid? Dat is toch juist het fixen van deze bug? 8)7
Dat dacht ik ook, zeker gelet op vitale infrastructuur. Maar als niemand er weet van heeft, hoef je ook niet bang te zijn dat het misbruikt wordt, zal de gedachte erachter wel zijn.
Vitale infrastructuur draait meestal op 'hardened' systemen; en als de NSA op de hoogte was, dan waren die systemen van hun ongetwijfeld gepatched.

En dat niemand er weet van heeft dat is een onzinnig argument. Als jij erachter kan komen, dan kan iemand anders dat net zo makkelijk.
Dus ... meldingsplicht...
Feit is als ze het wisten hadden ze het moeten melden. Heel veel bedrijven/particulieren zijn hierdoor kwetsbaar geweest (of nog steeds).
En wie weet hoeveel geld is afgetroggeld.
Dus jouw argument @TheBigB86 is nogal schokkend. Blijkbaar geef je niks om de veiligheid en privacy van anderen want je bagatelliseert het.
Ik begrijp jouw reactie niet helemaal.

Het was een reactie op "Maar als niemand er weet van heeft, hoef je ook niet bang te zijn dat het misbruikt wordt, zal de gedachte erachter wel zijn." (quote MrRobin). Ik ontkracht alleen het argument, moge MrRobin dat argument geloven of het juist cynisch bedoeld hebben.

Ik geef in mijn reactie ook verder geen standpunt. Ik ben het er volledig mee eens dat de NSA het had moeten melden. Het enige wat ik daarbij zeg is dat de realiteit is dat vitale systemen in de VS hoogst waarschijnlijk beschermd waren voor dit lek. De NSA heeft onethische activiteiten, dat wil niet zeggen dat ze dom zijn.
Jawel want de macht van de NSA komt juist uit lekken als de Heartbleed bug. Als lekken als dit juist gedicht worden heeft de NSA weer minder macht.
Voor ethiek moet je absoluut niet bij de NSA aankloppen en dat was al bekend voordat Snowden begon te praten.
Tja, als jij je werk goed en efficient wilt doen heb je toch goede tools nodig, en dit soort lekken zijn voor geheime diensten hun 'goede tools'.. En doe niet net alsof Snowden zo'n ethisch mannetje is, want imho is hij dat verre van, maarja, ethiek is in the eye of the beholder natuurlijk....
Het gaat dan ook niet om Snowden als persoon, maar om de informatie die hij naar buiten brengt.
NSA beheerd niet die vitale infra. NSA beheerd helemaal niks, behalve hun eige infra.
Maar de NSA is niet dom. Als zij van dit lek van deze proportie wisten, dan zouden ze er alles aan doen om de infrastructuur in hun eigen land te beschermen.

Nu weet ik niet of het daadwerkelijk zo is, maar het zou mij niks verbazen als de NSA in een besloten kring vroegtijdig security patches voorziet.
Al de berichten sinds Snowden duiden er op dat de gehele nationale veiligheid van de US afhangt van data dus deze bug was natuurlijk een heerlijke mogelijkheid tot (schijn) veiligheid voor de NSA.
Misschien heeft snowdon die bug zelf tegen de NSA gexploiteerd. ;)
De nationale veiligheid? Dat is toch juist het fixen van deze bug? 8)7
Het is maar hoe je het bekijkt. De bug is geen probleem voor de nationale veiligheid als niemand anders ervan weet. Het wordt pas een probleem als het tegen hen gebruikt wordt.

Anderzijds zolang niemand ervan weet kan de NSA er gebruik van maken om gegevens te vergaren van servers die door vermoedelijke terroristen of dergelijke worden gebruikt. En je kan ervan uitgaan dat de NSA de middelen en mogelijkheid heeft om deze bug uit te buiten. Er is allicht een schat aan informatie vergaart. Denk bijvoorbeeld aan de configuratie van de Cisco en andere routers die ook kwetsbaar bleken (zie ander artikel op tweakers). Met de info die zo'n router prijsgeeft kan je veel afleiden van de opstelling van het netwerk. Dus zelfs als de bug nu opgelost wordt, nieuwe kwetsbaarheden zijn omwille van de vergaarde voorkennis gemakkelijker te identificeren en uit te buiten. Men heeft een voet tussen de deur.
Maar je weet niet of iemand anders ervan weet. Als hackers erachter komen en servers van Google gaan hacken, zijn allerlei Americanen potentieel de dupe, en de NSA heeft dan dus niets gedaan om Google en haar burgers te bershermen. En de NSA kan nooit weten of hackers de kwetsbaarheid al kennen en gebruiken.
is vertaalfout, het gaat om "nationale belangen"... maar wees gerust er zijn nog een pak bugs die ze zonder problemen liggen hebben.
Haha wat je zegt. Maar aan de andere kant, wat niet weet wat niet deert.. zal hun redenatie wel zijn geweest.
dat is geen bug maar een achterdeur!
niet als het nationaal belang de veiligheid van de overheid zelf is, tegen de eigen bevolking...
Bloomberg heeft een reputatie op te houden, maar tot op heden staan de journalisten die voor Bloomberg schrijven niet bekend voor het brengen van primeurs over de NSA, inlichtingen, veiligheid etc. Waarom zouden we dan zo graag geloven dat die anonieme bronnen van de journalisten zo betrouwbaar zijn? Er is geen context, er is geen onderbouwing, ze doen alleen een bewering en komen met wat informatie die op iedere 'gerespecteerde' geheimedienst van toepassing is. Er had net zo goed 'geschreven door Kuifje' onder kunnen staan.
Dat is zeker waar, goed dat dit genoemd wordt.

Ik denk echter dat ik dit toch in de categorie "zo ernstig, dat zelfs anonieme informatie nader onderzoek rechtvaardigt" wil plaatsen. Ongeveer zoals anonieme bommeldingen ook serieus worden genomen. Dit des te meer omdat er op basis van twee bronnen wordt gesproken.
Het gaat er volgens mij in de eerste plaats niet om wie het misbruikt heeft maar of het misbruikt is. En daarbij gaat het dus niet alleen om een NSA, FSB, GCHQ, Chinesen of noem een willekeurig land met zo'n organisatie, of om criminelen die het om flink geld te verdienen gaat.

Dat het twee jaar misbruikt kon worden is duidelijk en welke organisaties of personen daar graag in het geheim misbruik van maken eveneens. En er achter komen wie het waren kom je niet, hooguit van een of twee organisaties - zonder bewijs heb je weinig houvast.

Het zou interessant zijn als bijvoorbeeld Snowden dit soort informatie nog achter de hand hield.

[Reactie gewijzigd door kodak op 11 april 2014 23:52]

De bronnen van Bloomberg in dit geval weten dat ze niet naar de Snowden / NSA verslaggevers kunnen stappen, die worden veel te goed in de gaten gehouden. Daarom stappen ze naar Bloomberg, veel veiliger voor de bron.
Ik heb het zelfde artikel net op Engadget gelezen. Daar citeren ze tevens het volgende:
Update: The NSA insists that it only became aware of Heartbleed at the same time as everyone else. This answer isn't going to satisfy everyone given the many contradictory claims about the agency's activities, but hey -- at least it's on top of the situation.
Statement: NSA was not aware of the recently identified Heartbleed vulnerability until it was made public.
Ik heb het zelfde artikel net op Engadget gelezen. Daar citeren ze tevens het volgende:

"Update: The NSA insists that it only became aware of Heartbleed at the same time as everyone else.
En de beweringen van de NSA zijn betrouwbaar?
Net zo betrouwbaar als de beweringen van de CIA, dat ze door waterboarding belangrijke informatie hebben opgedaan waarmee ze terroristen hebben kunnen oppakken en aanslagen kunnen voorkomen.

(Voor zij die hem niet snappen: kort geleden werd bekend dat dat gelogen is)
En de beweringen van 2 anonieme bronnen zijn betrouwbaar?

Dit nieuwsbericht geeft mij weer een hoog alu-hoedje gehalte. Dat de NSA zijn boekje meer dan eens serieus te buiten gaat staat vast maar als we nu al anonieme bronnen voor waar gaan aannemen als het maar in lijn is met de "NSA is Always evil" doctrine en het tegenwoord automatisch als leugen bestempelen zijn we niet meer zo goed bezig denk ik.

Ik ga absoluut niet ontkennen dat de NSA niet goed bezig is (understatement) maar alle nieuwsberichten die ook al maar iets te maken hebben met privacy is het meteen NSA dit NSA dat en hier springen die anonieme bronnen natuurlijk graag op in. Sensatiemakerij alom.
Wat de schade voor mijn privé gegevens is van deze bug maakt mij niet zo uit.

Ik maak me meer zorgen over wat de schade is van deze spionage mogelijkheid, die actief door de VS werd gebruikt, voor bedrijven.
Een van de drie hoofdpijlers van de Amerikaanse Patriot act, is namenlijk het verzamelen van Zakelijke informatie, ter behoeve van de verenigde staten.

Vanuit het verleden is al aangetoond dat Europese bedrijven miljarden orders (duizenden banen) hebben misgelopen door deze Amerikaanse spionage, alleen tegenwoordig wordt het steeds moeilijker aan te tonen, dat we een aanbesteding of race om innovatie door spionage verliezen.

[Reactie gewijzigd door kastjes op 11 april 2014 23:19]

Dit is waarom ik pleit voor onafhankelijke software ontwikkeling binnen de EU wat ook voor ons tot meer banen zal gaan leiden. Ik vind het ook frappant dat sommige mensen hier klakkeloos achter Amerikaanse software bedrijven staan alsof het hun God is. O.a. Microsoft, Google en Apple.

Waarom niet onze eigen Microsoft / Google / Apple ?? Wat meer onafhankelijkheid van Amerikaanse software zal heel goed zijn voor onze economie.
Waarom verrast mij dat niet?
Mooi dat dit nu opgelost is en verholpen kan worden.. maar ik ben wel bang dat ze heus nog wel andere exploits/bugs hebben die ze achterhouden voor het geval dat.
Tja mooi... Als de NSA al 2 jaar toegang had tot deze exploit, hebben zij waarschijnlijk nu een groot deel van alle private keys in handen. Met deze private keys kunnen zij dus nu al het (eerder) opgeslagen dataverkeer uit het verleden decrypten..

Kortom, alles wat je de afgelopen 2 jaar achter interessante SSL verbindingen hebt uitgespookt is dus nu ook (decrypted) aanwezig in het datacenter van de NSA

[Reactie gewijzigd door basvd op 11 april 2014 23:36]

Er zijn gelukkig wel wat hoopvolle geluiden van CloudFlare, die na wat onderzoek hebben geconcludeerd dat het verkrijgen van private keys via Heartbleed erg moeilijk kan zijn in de praktijk. Ze hebben zelfs een challenge pagina opgezet waarin ze hackers uitdagen om de private keys van een met opzet kwetsbaar gemaakte server te pakken te krijgen. Maar goed, als de NSA 2 jaar de tijd heeft gehad... wie weet wat ze uit hebben kunnen spoken.
Die challenge is intussen completed... 2 partijen hebben de key :(
Inderdaad, ik las dat Indutny het met 700requests/s in 3u tijd voor elkaar had. Zorgwekkend dus...
Mogelijk hebben die gasten al vaker misbruik gemaakt en hebben ze daar dus wat meer handigheid in?
CloudFlare heeft hooguit onderzocht of private keys van hun eigen systeem konden worden geplukt. Kan dat ook gezegd worden voor vanilla Nginx, Apache, Postfix, etc.?

Edit: vanilla Nginx lijkt kwetsbaar op basis van hun eigen challange.

[Reactie gewijzigd door hieper op 12 april 2014 10:25]

Met deze private keys kunnen zij dus nu al het (eerder) opgeslagen dataverkeer uit het verleden decrypten..
Op zich kon OpenSSL natuurlijk wel iets aan forward secrecy doen vanaf versie 1 , dus het is niet noodzakelijk het geval dat ze al het eerder opgeslagen verkeer kunnen decrypten als ze een key hebben verkregen.

@ basvd hieronder: men mag forward secrecy inderdaad wel wat vaker implementeren, vandaar dat ik de aandacht er even op wilde vestigen.

[Reactie gewijzigd door begintmeta op 12 april 2014 15:26]

Inderdaad, niet al het verkeer ;)
As of April 2014, 6.3% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to web browsers.
https://www.trustworthyinternet.org/ssl-pulse/

[Reactie gewijzigd door basvd op 12 april 2014 00:24]

Kortom, alles wat je de afgelopen 2 jaar achter interessante SSL verbindingen hebt uitgespookt is dus nu ook (decrypted) aanwezig in het datacenter van de NSA
Om dat te kunnen doen, zou de NSA ook alle servers moeten hebben aangevallen, en alle private keys eraf hebben getrokken...
ja dus? met al die DDOS'en de laatste tijd valt een paar honderd request per uur nou ook niet meer zo heel veel op. WS hebben die gasten ook genoeg apparatuur om vanaf meerdere locaties met honderden IP-adressen tegelijk te werken. anti-DDOS apparatuur/services (Zoals Akamai aanbied bv.) zal daar dus ook minder gevoelig voor zijn.

700 requests/uur vanaf 1 IP valt nogal op, maar 2 Requests/uur vanaf 350 IP-adressen niet,
700 requests / s is wel een factor 3600 groter dan 700 requests/uur. Maar ik snap je punt, en natuurlijk heeft de NSA andere mogelijkheden. Zorgwekkend.
Sorry net ff te snel overheen gelezen. Maar dan nog. Dat moet voor de NSA toch zo te rochelen zijn?
Ik vind het vooral verbazingwekkend dat een groot beveiligingsrisico als deze niet eerder aan het licht is gekomen. Zoveel mensen die zoveel dagen met deze technieken bezig zijn en dan is er zo'n gigantisch gat wat enorm misbruikt kan worden.
Simpelweg omdat de 'open source' te ingewikkeld is. Veel mensen doen stoer over open source omdat je dan de bron code kan lezen en dan bugs eruit halen, en dat wordt soms dan ook wel gedaan hoor. Maar ik vraag mij af hoeveel 'ingewikkelde' open source code wordt gechecked door 'de community'. Het is niet per sé beter omdat men het kán lezen. Men moet het dan ook wel -goed- én daadwerkelijk kunnen...

Edit:
Voordat de pro-open source community hier gaan minnen, dit is meer mijn mening dan ondersteund door feiten.

[Reactie gewijzigd door Triblade_8472 op 12 april 2014 08:16]

Het probleem met OpenSSL is dat ze allerlei meuk inbouwen om er zeker van te zijn dat een kleine bug als deze hele grote nare gevolgen heeft.
OpenSSL heeft eigen geheugenallocatiefuncties omdat ze ooit hebben getest op een bepaald platform dat die van het systeem traag zijn. De functies van openssl geven geen geheugen vrij, maar wijzen het intern steeds opnieuw toe.
Met de beschermingen en detectie die de afgelopen 5 jaar in compilers en glibc waren gebouwd zou de eerste poging tot exploiten een assertion met backtrace opgeleverd hebben ipv stilletjes 2 jaar lang private keys lezen.
Je haalt wel heel veel dingen door elkaar...

Bugs worden niet bewust ingebouwd, tenzij dat er machten achter de schermen invloed hebben. Ik heb zelf vaker met OpenSSL gewerkt, bugs gemeld etc en ga even niet vanuit dat je van een complottheorie uit moet gaan.

Als je van te voren niet bewust bugs inbouwt, weet je ook niet of ze grote of kleine impact hebben. 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.

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.

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.

Kortom: OpenSSL als meuk classificeren lijkt me ongefundeerd, onterecht en onvoldoende kennis van zaken.
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]

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.
Wat heeft dit met Liskov substitution te maken?
ik denk dat R4gnax bedoelt dat je nooit 100% zeker weet dat je niet toevallig een dezelfde instance terugkrijgt. Op het moment dat ik twee instances heb van het type auto (waarvan een bv. VW golf en de ander S. Fabia) en van een geef ik pointer door naar een andere class, die er wat ongein mee uithaalt door bv het type motorblok op te vragen, maar voordat ik dat doe heb ik die geheugen positie al weer vrij gegeven, dan kan het voorkomen dat mijn systeem door memory relocation bijvoorbeeld de boel net een positie doorschuift zodat daar bijvoorbeeld ineens de Skoda staat in plaats van de golf. Voor het programma maakt het niet uit, want deze kan nog steeds exact dezelfde dingen op vragen als bij de golf (het zijn immers beiden instances van hetzelfde type). Dat de uitvoer heel anders is dan oorspronkelijk bedoelt weet het programma niet en omdat er vrij weinig te zien is voor de eindgebruiker (of het is vrij complex voor een leek) zal deze het ook niet zo snel opvallen. Ook kunnen er meerdere instances zijn die bijvoorbeeld hetzelfde type blok hebben. dit soort grappen zijn dus vrij lastig te zien (omdat ze vrij weinig voorkomen), maar ik kan me voorstellen dat als het gebeurt er onverwachte dingen kunnen gebeuren die niet heel positief zijn voor de veiligheid.

vziw heeft de OS X Mavericks met de nieuwe memcompress methode ook de mogelijkheid om bepaalde geheugenposities door te zetten. Zo heb ik momenteel 118,8MB RAM gecomprimeerd weggeschreven. die adressen zijn dus als het goed is veranderd ten opzichte van het origineel en er kan nu dus iets heel anders staan.
[...]

Wat heeft dit met Liskov substitution te maken?
Als je 2 implementatie A en B van dezelfde interface hebt, dan moet je implementatie A en B transparant uit kunnen wisselen zonder dat dat tot extern zichtbaar gewijzigd gedrag verandert.

OpenSSL leunt op randeigenschappen van hun eigen implementatie B van malloc() en aanverwanten, die in de implementatie A in de systeem libraries niet gelden.

(Dit is dus ook waarom OpenSSL al jaren niet meer zonder die custom memory manager te gebruiken is.)

[Reactie gewijzigd door R4gnax op 13 april 2014 17:50]

Heb je de openssl code bekeken? Er zit geen C++ in. Dus template extractie en zo is niet relevant in dit verhaal.

Als je een stack array hebt in C van 10 elementen (bijv. int a[10]) en daarna nog een rijtje variabelen, dan zal a[11] een stukje stack verknallen. En als het heap geheugen was (malloc) dan een stukje heap. Dat soort fouten is erg lastig te vinden. Met sommige compilers kun je dit afvangen ja, maar niet alle (of misschien beter: de meeste niet). Heap stukken worden doorgaans beschermd met guardbytes, maar de stack heeft vaak alleen een begin en eind marker als bescherming.

Daarmee is C wel een taal waarmee je makkelijk fouten kunt maken, en er zijn ook andere talen, maar ook daar kun je nog steeds fouten maken, memory corruptie, stack corruptie tot zelfs core dumps toe. En zelfs met de veiligste, managed code, eigen perfecte garbage collector etc kun je security lekken maken. Een open TCP/IP poortje met een pseudo file handler volstaat. Of een taal als C/C++ op zich al onveiliger als Java, Pascal weet ik niet. Ik weet niet of dit ooit onderzocht is.

Je kunt niet in z'n algemeenheid stellen dat een eigen allocater fout is. Al schrijf jij de mooiste code van het heelal, als het niet presteert zal geen klant je voor die code betalen.

Het feit dat OpenSSL bij grote namen (Cisco etc) gebruikt wordt betekent of dat zei de code goed genoeg vinden, of dat zij er niet meer voor willen betalen. En of het laatste gebeurd omdat ze te weinig ontvangen voor hun eigen producten, of voor winstmaximalisatie voor zichzelf gaan kan ik niet beoordelen.

Er zijn voor openSSL een beperkt aantal security alerts per jaar. De regels code in OpenSSL kun je zelf tellen. Van closed source weet je doorgaans al minder vaak of er security alerts zijn (dat soort problemen worden vaak eerst direct gemeld) en al helemaal niet de verhouding tot het aantal source code regels.

En fini: elke taal mondt uiteindelijk uit in CPU instructies. Ik ken geen taal waar niet uiteindelijk een interpreter, compiler of VM tussen zit die in C/C++ geschreven is. Een CPU snapt niet zoiets als een programmeertaal :-).
Ja , maar met een ssl backtrace zou je eerder verwachten dat de community opgemerkt zou hebben. Uiteraard is het verwerpelijk van de NSA dat zij deze exploit maar dat kan je verwachten van een geheime dienst die geen verantwoording af te leggen.
Door die assertion met backtrace zou je programma crashen waardoor je een DoS lek hebt. Persoonlijk heb ik liever een programma dat crasht dan een programma dat stilletjes prive data laat lezen.
Simpelweg omdat de 'open source' te ingewikkeld is. Veel mensen doen stoer over open source omdat je dan de bron code kan lezen en dan bugs eruit halen, en dat wordt soms dan ook wel gedaan hoor. Maar ik vraag mij af hoeveel 'ingewikkelde' open source code wordt gechecked door 'de community'. Het is niet per sé beter omdat men het kán lezen. Men moet het dan ook wel -goed- én daadwerkelijk kunnen...

Edit:
Voordat de pro-open source community hier gaan minnen, dit is meer mijn mening dan ondersteund door feiten.
De vraag is niet "is open source perfect?", want niets is perfect. De vraag is "is het alternatief beter?".

Het alternatief is closed source en met closed source was de bug misschien wel helemaal nooit ontdekt en had de NSA deze nog jaren kunnen misbruiken.

Dus nee, open source is niet perfect, maar het is wel beter dan closed source. Mocht je een beter alternatief weten, vertel het ons! Code controleren kost nu eenmaal tijd en iemand zal het ook moeten doen en zelfs dan nog kunnen bugs over het hoofd gezien worden. Such is life.
Het is niet 'de' vraag. Het is 'een' vraag.

Ik wil geen discussie open of closed source, maar meer een normalisering van deze discussie. Misschien moet het geen eens een discussie zijn. Beide heeft zo z'n voor- en nadelen.

Wat ik wilde aangeven is dat heel veel mensen die ik ken (en ook zie op deze forums) erg te spreken zijn over open source, maar zelf zeer waarschijnlijk geen idee hebben waar ze het over hebben omdat ze de 'open' code zelf niet lezen en/of verbeteren. Laat staan de zeer ingewikkelde software.

Bij de openbaring van deze bug zijn (gelukkig!!) weinig negatieve reacties geweest naar mijn weten. Ik ben hier erg blij om, omdat geen enkele software 100% veilig is en kan zijn. Maar als dit Microsoft overkomen was, hoe zouden dan de reacties zijn geweest? En dat door mensen die zelf geen code nakijken...

Misschien is juist omdat het open source is, is het twee jaar geleden door de NSA ontdekt, maar dat stel je weer niet omdat het je goed uit komt. Het is een oneindige discussie. (en ik ga er hierna ook niet meer verder op in, hier. Je mag me pmmen als je erg graag wilt)
Ik zie geen reden om zo'n discussie in PM te voeren.

Ja, tuurlijk. Als deze bug in closed source zou zitten dan had de NSA hem allicht ook niet ontdekt. Kan. Maar dan ben je bezig met security through obscurity en dat moet je eigenlijk niet willen.

Zolang je er vanuit gaat dat het merendeel van de mensen goedaardig is ben je wat dit betreft met open source beter af dan met closed source. Dat maakt open source niet perfect, maar het wil al helemaal niet zeggen dat closed source de oplossing zou zijn.

Je zei "Het is niet per sé beter omdat men het kán lezen.". Dat is het wel. Het is beter omdat men het kan lezen. Dat we dat dan misschien onvoldoende doen is spijtig, maar het is nog steeds beter dan het helemaal niet kunnen lezen. Dit geeft ons nog altijd de ruimte om later te beslissen het alsnog te lezen, om geld in te zamelen om het te lezen, om het te lezen bij verdenking of voor een bedrijf dat meer zekerheid wil om er mensen op te zetten om het te lezen. Mogelijkheden die bij closed source allemaal ontbreken.

[Reactie gewijzigd door W3ird_N3rd op 14 april 2014 07:25]

Crypto is van nature complexe materie. Nu ben ik geen programmeur, maar ik kan me goed voorstellen dat code die complexe operaties uitvoert bijna onleesbaar is voor lieden anders dan de auteur. Met documentatie kom je dan nog wel een eind maar zelfs dan....

VZIW was de "fout" triviaal, dus makkelijk over het hoofd te zien. Dat de consequenties zo groot zijn is wel interessant, op zn zachtst gezegd o_O
er gebruiken vooral heel veel mensen het, maar daadwerkelijk naar de code kijken is zo weinig in verhouding...
Ik vind het vooral verbazingwekkend dat een groot beveiligingsrisico als deze niet eerder aan het licht is gekomen. Zoveel mensen die zoveel dagen met deze technieken bezig zijn en dan is er zo'n gigantisch gat wat enorm misbruikt kan worden.
Daarom zijn er mensen die alles open source willen hebben, want dan hadden dit soort zaken eerder ontdekt kunnen worden............

Zo ziet men maar weer, Open Source is dus net zo kwetsbaar...
Omdat je zoals de meesten hier de standaard Pavlov reactie vertoony van "security bug"= NSA = Evil America...

Ik word er een beetje moe van om bij elk security leak weer een tweede bericht te moeten lezen dat zegt dat de hele wereld het gemist heeft maar de supermensen van de NSA het al jaaaaren wisten en gebruiken..
"Ik word er een beetje moe van om bij elk security leak weer een tweede bericht te moeten lezen dat zegt dat de hele wereld het gemist heeft maar de supermensen van de NSA het al jaaaaren wisten en gebruiken.."

Ik ook, maar om een legitieme reden en niet omdat ik het nieuws van de NSA maar over me heen laat komen van "zucht, alweer iets over de NSA"... *doorgaat met niets om eigen privacy geven doet*.

Nee, ik walg van deze berichten omdat keer op keer duidelijk wordt dat de NSA zoveel macht heeft in de digitale wereld, zo corrupt is tot op het bot, en echte veiligheid op het spel zet voor hun eigen gruwelijke belangen van schijnveiligheid.
het is natuurlijk maar wat je 'corrupt' noemt, er zullen bij de NSA wel heel wat meer bugs bekend zijn, maar het is natuurlijk niet aan hun om ze te onthullen immers is het hun 'job' om informatie te vergaren om daarmee ook echt de zogenaamde staatsveiligheid te beschermen. En tuurlijk zullen er ook mensen in die organisatie zitten die er voor persoonlijk gewin gebruik van maken, en dat zijn degene die ze moeten opsporen en eruit knikkeren. Diensten als de NSA en onze eigen 'geheime'diensten zijn helaas ook een bittere noodzaak.
"het is natuurlijk maar wat je 'corrupt' noemt, er zullen bij de NSA wel heel wat meer bugs bekend zijn, maar het is natuurlijk niet aan hun om ze te onthullen immers is het hun 'job' om informatie te vergaren om daarmee ook echt de zogenaamde staatsveiligheid te beschermen."

De gehele organisatie is een corrupte tak van de regering. Het gaat niet om corruptie binnen de NSA, het gaat om het corrupt zijn van de NSA als geheel. De wet aan hun laars lappen, wereldwijd mensen bespioneren, om nog maar te zwijgen over moraliteit.

"Diensten als de NSA en onze eigen 'geheime'diensten zijn helaas ook een bittere noodzaak."

Citation needed. Hoeveel heeft de NSA daadwerkelijk in positieve zin voor de wereld betekend? Hoezo hebben ze vooraf aangekondigde aanslagen niet voorkomen? Er is juist ophef over en als ik het me goed herinner, zelfs bevestiging van een hoge pief, dat de NSA totaal niet efficiënt is met hun vangnetprincipe. Maar het gaat natuurlijk niet om terroristische aanslagen tegen te gaan. Het gaat om macht. Walgelijk.
Precies wat ik dacht toen heartbleed bekend werd
OpenSSL maakt gebruik van Github, dan moet toch terug te zien zijn wie de code heeft toegevoegd?
Het maakt niet uit wie deze bug erin heeft gezet. Wat wil je ermee bereiken? Die man/vrouw zijn leven kapot maken omdat hij een fout heeft gemaakt die iedere andere persoon ook had kunnen maken? Het is jammer dat dit is gebeurd, maar het heeft geen zin om die ontwikkelaar nu of straks aan te vallen.
Ik vind het wel uitmaken. Als een bekende programmeur de fout heeft gemaakt, prima, niets aan de hand. Iedereen maakt fouten. Maar als het iemand is die amper iets bij heeft gedragen aan het project en dan ineens zulke code opvoert, dan zou er meer achter kunnen zitten, zoals een overheid die bewust deze bug er in heeft gezet.
Als deze bug er dan bijvoorbeeld bewust is in gezet, is de exploitatie er van natuurlijk genoeg geld waard om diegene commits te laten blijven maken. Dus dat verhaal gaat niet helemaal op.
Klopt, want we weten wel wie het is. Maar niet de intentie. Mensen blijven fouten maken... tot in de eeuwigheid. Dat moeten we accepteren.

Om er gelijk een complot aan te hangen is niet eerlijk voor die man.
Als de schrijver van deze bug zwaar in de publiciteit komt en zijn leven daardoor kapot gaat, dan zal er niemand meer zijn die aan open source mee durft te werken. Dat zou de open source wereld wel eens kapot kunnen maken.
Op Ad.nl staat een artikel wat gaat over de man achter de code , incl een foto
Volgens mij is hij al bekend: Robin Seggelman. Ff googlen en je leest zijn verhaal
Ik snap niet dat ze dit 2 jaar hebben kunnen doen, argument nr een als het over opensource gaat: "het is veiliger want je kan de code in kijken". Als ik dan het lijstje afloop van bedrijven die zich bezighouden met netwerksecurity, dan is zowat iedereen geimpacteert . Wat hebben die bedrijven zo allemaal gedaan de laatste 2 jaar?
open source maakt het alleen makkelijker voor whitehackers om te zoeken naar zwakheden maar is geen garantie voor veiligheid
Het zou het ook makkelijk moeten maken voor security bedrijven zoals juniper, bluecoat, fortinet, etc.
whitehacking en een security bedrijf is een beetje hetzelfde maar je hebt inderdaad gelijk
De veiligheid van open source is een illusie.
D'r is slechts een beperkt aantal mensen slim genoeg om dit soort code te doorgronden.
En die mensen hebben allemaal wel wat beters te doen dan anderman's code napluizen
Nou ja, als je die experts betaalt, dan kijken ze ook open source code wel na. De Linux kernel wordt intussen onderhouden door betaalde experts van Google, IBM, Oracle, Red Hat, etc. Die bedrijven hadden een paar van die experts ook op het OpenSSL project kunnen zetten.

Voor de rest moet je met open source idd maar hopen dat de "many eyeballs" die bugs spotten, die ook daadwerkelijk fixen ipv misbruiken.

[Reactie gewijzigd door Dreamvoid op 12 april 2014 10:00]

Ik denk dat het met deze bug in OpenSSL nog niet klaar is, ik denk dat er nu wel meer op komst gaat zijn. Denk ook dat het hele SSL een beetje zn idee van veiligheid wel kwijt is. Het word tijd voor wat nieuws. Maar wat kun je nog aan "nieuws' maken voor die NSA idioten erachteraan komen.....
Aan zulke verwachtingen hebben we weinig in de wereld van beveiliging. Het gaat om het risico wat je loopt. En dit is een beetje als een loterij: dat er nu een fiks gat in de beveiliging is gevonden zegt nog niets over de rest van de code zonder dat iemand er met een frisse blik naar kijkt. Net zo min als het jaren lang niet merken ook niets zegt over toekomstig risico. Het gaat om bewijs.

Er zijn overigens allang alternatieven. Dat is waarom er ook behoorlijk wat producten en diensten niet direct kwetsbaar zijn. De wereld maakt er allang gebruik van. Maar voor hetzelfde geld zit daar net zo'n zwaar ander gat is.
Lampuhkap, je kijkt er niet juist tegen aan.

Software bevat bugs. ALLE software. Het feit dat niemand bugs heeft gevonden, betekent niet dat er geen bugs in zitten.

Software met voor-de-hand liggende bugs, bevatten zowel voor-de-hand liggend bugs als niet-voor-de-hand liggende bugs.

Software die 'geen' bugs bevat, bevat alleen nog maar niet-voor-de-hand liggende bugs.

Dus software die 'geen' bugs bevat, maar waar soms nog een niet-voor-de-hand liggende bug uit gehaald wordt, is altijd nog beter dan andere software.

En bugvrije software bestaat gewoon niet. We zien altijd zo'n beetje de statische bugs, de bugs waarbij als je A doet, je bug B krijgt.

Maar software zit complexer in elkaar. Er zitten ook ontelbare bugs in waarbij als je A doet, dan B, maar dan C overslaat, dan wel D en E doet, maar dan F ook overslaat, je bug G krijgt. Terwijl als je C niet overslaat, je bug G niet krijgt. Of dat als je de tijd tussen A en B langer dan 2 seconden maakt, je wel bug G krijgt, en anders niet.

Of zelfs dat een bug pas te reproduceren is als je 10 minuten geleden A deed, en nu B. Of erger. Te reproduceren doordat jij A doet, terwijl iemand exact 20 seconden later B moet doen, en jij binnen een 10e van een seconde daarna C moet doen om bug D te krijgen.

Ga al dat soort bugs maar eens vinden en oplossen...

[Reactie gewijzigd door RetepV op 12 april 2014 08:32]

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True