Patch voor ernstig lek in encryptiebibliotheek libotr komt beschikbaar

In versie 4.1.0 en eerder van het off-the-record-encryptieprotocol OTR is het mogelijk om willekeurige code uit te voeren, door het versturen van een zeer groot bericht. Vooral gebruikers met snelle verbindingen zijn kwetsbaar. Versie 4.1.1 van de libotr-bibliotheek dicht het lek.

Het Duitse bedrijf X41 D-Sec laat weten dat het de kwetsbaarheid ontdekte via een code review. Volgens de beschrijving is het niet eenvoudig voor een aanvaller om van de kwetsbaarheid, bekend onder cve-2016-2851, gebruik te maken. Deze vereist namelijk dat er een bericht met een grootte van 5,5GB wordt verstuurd.

De onderzoekers hebben een proof of concept opgesteld, waarbij zij 275 berichten van elk 20MB verstuurden. Dat leidde uiteindelijk tot een heap overflow op 64bit-systemen, waarmee willekeurige code uitgevoerd kon worden. De onderzoekers maakten gebruik van een testsysteem met 8GB ram en 15GB swap-ruimte. Met een snelle netwerkverbinding kon de aanval daarop uitgevoerd worden zonder dat dit voor het slachtoffer merkbaar was.

Libotr wordt onder andere gebruikt in chatprogramma's als Pidgin en Adium, waardoor deze ook kwetsbaar zijn. Libotr is een implementatie van het off-the-record-encryptieprotocol, dat authenticatie en encryptie verzorgt in onlinecommunicatie. Over het algemeen wordt het protocol als zeer veilig beschouwd. Deze week werd ook bekendgemaakt dat Tor Messenger OTR-ondersteuning voor Twitter-privéberichten implementeert. De update naar de gepatchte 4.1.1 versie is inmiddels beschikbaar.

Reacties (30)

[Kalief]

Heeft nou eerst iemand in theorie bedacht dat zoiets mogelijk moest zijn, of kwam dit toevallig aan het licht toen iemand per abuis een groot bestand verstuurde, of heeft iemand zitten uittesten wat er zou gebeuren als je een steeds groter bestand verstuurde?

[Devilfish]

Het Duitse bedrijf X41 D-Sec laat weten dat het de kwetsbaarheid ontdekte via een code review. Ik denk dus dat iemand de code las en dacht, hmm, hier zou het wel eens fout kunnen gaan want dit wordt niet gechecked of het boven de n uitkomt.

[Ravefiend]

Meer details met referencies naar de broncode kan je hier terug vinden:

http://seclists.org/fulldisclosure/2016/Mar/21

[Sysosmaster]

Dit soort opmerkingen komen (imho) enkel van mensen die geen kennis van zaken hebben. De taal die gebruikt word in een applicatie heeft niets te maken met hoe vatbaar deze is voor misbruik. Namelijk :

• Geen enkele garage collection is 100% veilig en betrouwbaar.
• Hoe highlevel een taal is heeft 0 impact op Security (binnen het Security theater)
• Ook met C++ en STL is deze type fout Mogenlijk

De manier om deze dingen te voorkomen is met - code audits (welke de fout naar boven haalde bij deze)

• pen testing (ook wel Security testing, oftewel in simpele woorden, iemand vragen om jouw systeem te kraken)
• automatische testen, maar enkel als deze goed geschreven worden.

[Reactie gewijzigd door Sysosmaster op 27 juli 2024 04:36]

[Ceaus]

Je verliest de realiteit overduidelijk uit het oog. Zeggen dat het niet uitmaakt is slechts een academische / theoretische afweging. In de praktijk kiezen *mensen* voor een programmeertaal. En dat betekent dat ze kiezen voor een taal die het ze het meeste ligt. En dat betekent weer dat een taal die jou dwingt om zonder zijwieltjes goed goede code af te leveren, veiliger software code oplevert. En nu komt dus de truuk: dat komt niet door de taal, maar door de persoon. En daarom zijn talen die jou het meest ondersteunen (in de vorm van templates, libraries en ander development gemak) in die zin het gevaarlijkst. Ze leveren een schijnveiligheid op. Ik ben zelf Java architect, en ik zou me op dit terrein niet durven meten met een C architect. Juist omdat de C architect gedwongen wordt veel beter zijn best te doen.

[Sysosmaster]

Het maakt niet uit omdat het bij security niet draait om de code, of hoe deze tot stand is gekomen. het gaat om het resultaat.
Of een bepaalde fout makkelijker of moeilijker is om te maken is daarvoor niet relevant. Of deze gemaakt is wel. En de kans dat deze gemaakt word heeft invloed op wat je tetst. maar niet op de impact vanuit security.

Dit alles betekend samengevat dat de taal geen ene moer uitmaakt als het op security aankomt. Je kunt namelijk gen enkele taal vertrouwen in dat ze alles 100% doen zoals de intentie is. Dit is waar voor zowel assembly als Javascript. Zodra je iets kunt doen wat niet de bedoeling is door welke reden dan ook, dan is dit een onderdeel van een security issue.

Taal keuze is net zo vaak een 'legacy' ding als persoonlijke voorkeur. En ja Iedere taal heeft zijn eigen dingen om op te letten als het gaat om security fouten en risico's, maar dat is enkel vanuit de programeur gekeken en verliest alle waarden zodra je er als security-expert er naar kijkt.

[CAPSLOCK2000]

Dit alles betekend samengevat dat de taal geen ene moer uitmaakt als het op security aankomt. Je kunt namelijk gen enkele taal vertrouwen in dat ze alles 100% doen zoals de intentie is. Dit is waar voor zowel assembly als Javascript. Zodra je iets kunt doen wat niet de bedoeling is door welke reden dan ook, dan is dit een onderdeel van een security issue.

Ik vind je standpunt nogal extreem, als die motorrijder die geen helm draagt omdat geen enkele helm 100% veiligheid biedt. Er zijn wel degelijk grote verschillen tussen programmeertalen die veilig werken makkelijker of moeilijker kunnen maken. De buffer-overflows van C zijn bijvoorbeeld heel berucht. Andere talen hebben de controles toegevoegd die beschermen tegen de meest voorkomende bufferoverflows, sindsdien hebben we daar een stuk minder last van.
Een meer recent voorbeeld zijn de SQL-libraries voor scriptalen als PHP. Een paar jaar gelden was het nog standaard om je queries op te bouwen doo met de hand stringetjes en variabelen aan elkaar te plakken. Tegenwoordig gebruiken we steeds vaker libraries die dit niet meer toe staan, daarmee is een hele categorie aan makkelijke SQL-injecties praktisch onmogelijk geworden.

Als je een taal gebruikt die het makkelijk maakt om veilig te werken dan kunnen de programmeur en de auditor hun beperkte aandacht richten op de moeilijke problemen.

[Sysosmaster]

het Key concept dat ik mis in jouw reactie en dat ik wel gebruik is "in de context van het security theater". Hierin werken dingen anders dan als je er naar kijkt als programmeur. Een van de gevolgen van deze benaderings verandering is dat je gewoonweg 0 vertrouwen kunt hebben in de software zoals opgeleverd door programmeurs, zodat je op zoek kunt gaan naar de exploits en lekken en andere nasty bits die met security te maken hebben.

De veiligheid waar jij het nu over hebt helpt inderdaad om minder vaak het wiel opnieuw uit te vinden en om beter en veiligere code te schrijven. (Yaay minder werk voor de programmeur) maar als je naar de security kijkt dan ga je opzoek naar de zwskste plek. en mag je er niet meer vanguitgaan dat (bijvoorbeeld) de library die je SQL injectie onmogelijk maakt ook echt altijd werkt. Je gaat proberen om de beveiliging te omzeilen. Met weer als gevolg dat de taal geen weerslag heeft op de security. Programmeurs die daarentegen veilige software opleveren hebben wel weerslag, foor simpelweg het onmogelijk te maken voor een pen tester om de software te breken.

[CAPSLOCK2000]

het Key concept dat ik mis in jouw reactie en dat ik wel gebruik is "in de context van het security theater". Hierin werken dingen anders dan als je er naar kijkt als programmeur. Een van de gevolgen van deze benaderings verandering is dat je gewoonweg 0 vertrouwen kunt hebben in de software zoals opgeleverd door programmeurs, zodat je op zoek kunt gaan naar de exploits en lekken en andere nasty bits die met security te maken hebben.
ter om de software te breken.

Ik kan je niet volgen. In mijn boekje gaat "security theater" over schijnveiligheid die niet echt iets toevoegt. Het gebruik van talen of libraries die zijn ontwikkeld met security in het achterhoofd voegt wel iets toe.

Het gebruik van zo'n taal of library is geen garantie voor veiligheid, dat bestaat gewoon niet, maar het vermijden van bekende zwakke plekken helpt een hoop.

Het is heel goed dat je er niet blind op wil vertrouwen dat een bepaald onderdeel veilig is maar daarmee is het nog niet onveilig. Daar staat tegenover dat er bepaalde talen, libraries en technieken zijn waarbij je er op kan vertrouwen dat het /niet/ veilig is omdat de kans op fouten erg groot is.

Al met al ben ik het dus niet met je eens dat "de taal geen ene moer uitmaakt als het op security aankomt". Hoewel niemand ooit 100% zekerheid kan bieden bestaan er in praktijk wel grote verschillen.

[Sysosmaster]

Security theater is Zoiets als de ideale wereld vanuit de beveiliging kijkend. Schijnveiligheid komt daar als het goed is niet voor.

Het is een middel om Security te beschrijven zonder echte wereldse beperkingen mee rekening te houden.

Bijvoorbeeld in de Security theater is er onbeperkte computer kracht beschikbaar, en kan het zijn dat tijd onbeperkt is.

Verder blijf je je eigen werk en het werk van andere controleren wat als gevolg heeft dat je geen aanname maakt over een begin veiligheid.

[Voutloos]

Praktisch iedereen hanteert de term security theater om schijnveiligheid aan te duiden, dus ik ben bang dat je de verkeerde term noemt danwel een paar artikelen verkeerd begrepen hebt. Google de term anders eens.

[Reactie gewijzigd door Voutloos op 27 juli 2024 04:36]

[Ceaus]

+1, ik vind het ook maar een vreemd verhaal.

[Rafe]

Toch zijn er wel talen die bepaalde soorten fouten zoveel mogelijk trachten te voorkomen, bijv. https://www.rust-lang.org/ - maar daar kan je jezelf nog steeds mee in de voet schieten als je niet oppast

[Sysosmaster]

Klopt, op beide punten. Dit heet echter 0 invloed op de 'security' binnen het 'security theater'.

[svenslootweg]

Waar heb je het nu eigenlijk over? "'Security' binnen het 'security theater'" is m.i. een betekenisloze term.

[Sysosmaster]

Kijk een op https://security.stackexchange.com
Het gaat om Security en de speelverbod waarbinnen je je gedachten experimenten uitvoert.

[RoestVrijStaal]

Als je vrolijk C-dingen als macro's en malloc & alloc in je C++ code gebruikt dan is het inderdaad mogelijk.

Maar dan schrijf je erg archaïsch C++.
Gebruik new en delete (en smart pointers) en zet je macro's om in functies. Het is niet moeilijk.

Eigenlijk zou iedere goede C++ compiler meteen de middelvinger moeten geven als het malloc of alloc tegen komt dat niet in een "extern "C"{}"-blok staat.

[Reactie gewijzigd door RoestVrijStaal op 27 juli 2024 04:36]

[lrietveld]

Mwah, onzinning is een sterk woord. Er zijn een aantal (zowel sociale and technische) argumenten voor C boven C++. Of zie hoe Linus dit verwoord

[Nathilion]

En ondertussen zijn we 9 jaar verder en heeft C++ een gigantische verbetering ondergaan in de vorm van C++11, onderhand is ook al C++14 uit en ligt er al een draft voor C++17 klaar waar iedereen zijn zegje over kan doen. C++ is een taal waar nog volop gewerkt wordt aan de tekortkomingen die waar men in het verleden tegen aan liep. En ja, de eerste versies van de taal waren slecht. Maar dat argument gaat nu niet meer op.

Om een schroef in te draaien gebruik ik een schroevendraaier. Voor een spijker een hamer. Je gebruikt het gereedschap wat je nodig hebt op de manier die je het nodig hebt. Mensen die C++ haten vergeten dat het slechts een stuk gereedschap is. Net zoals C, en Haskell en Python. En zij gebruiken hun C hamer om alles te doen waar een Python of een Haskell of (insert whatever) een stuk beter is.

[BBM]

If the only tool in your toolbox is a hammer, everything starts to look like a nail...

[.oisyn]

Of zie hoe Linus dit verwoord

En zich meteen diskwalificeert:

It's made more horrible by the fact that a lot of substandard programmers use it

No, that's not how any of this works... . Linus Torvalds is een azijnpisser die niets accepteert wat in zijn straatje valt, en als zodanig heeft zijn mening over een willekeurig onderwerp dan ook weinig waarde.

[Reactie gewijzigd door .oisyn op 27 juli 2024 04:36]

[Verwijderd]

Ik vraag mij ook al sinds de eerste les C++ in 2006 af waarom ik die taal en dan nog 'object georiënteerd' zou moeten programmeren. Mijn docent C (betere school, betere docent) en gcc gaven mij ook gelijk... Die docent zijn C++ code was verschrikkelijk.

Ik volg Linus zijn redenering wel een beetje, ik heb toch ook altijd de indruk dat C programmeurs en mensen die spontaan nog wel eens assembler gebruiken meestal netter werk afleveren dan mensen die bij 'hogere' talen zweren en met hopen exotische bibliotheken komen aanleuren...

Maar wie ben ik

[Freee!!]

[...]
ik heb toch ook altijd de indruk dat C programmeurs en mensen die spontaan nog wel eens assembler gebruiken meestal netter werk afleveren dan mensen die bij 'hogere' talen zweren en met hopen exotische bibliotheken komen aanleuren...

Ach, definiëer 'hogere' talen. Ik ben opgeleid in COBOL en codeer tegenwoordig meestal in RPGLE. Die ene keer dat ik iets in C deed, kreeg ik als commentaar dat het te leesbaar en netjes gestructureerd was

[.oisyn]

Die docent zijn C++ code was verschrikkelijk.

Wat natuurlijk in z'n geheel niets zegt. Verschikkelijke code is in elke taal te produceren.

C is leuk voor low-level efficiency, en als zodanig natuurlijk uitstekend voor embedded applicaties en kernels. Het is ook meer binary portable, daar C++ in de praktijk geen eenduidige ABI heeft. Maar het grote probleem van C is het gemis aan genericiteit. Je kunt niet een algoritme schrijven dat werkt met verschillende datatypes, en dus zit je al snel te prutsen met macro's of gewoon maar allemaal void pointers in een container te stoppen. C is absoluut geen taal om productief in te zijn en is als zodanig links en rechts ingehaald door talen met moderne constructies zoals templates/generics, lambdas en closures.

Fun fact: we hebben een dure sort in Tomb Raider een keer weten te optimizen door de aanroep naar qsort() (van C) te vervangen door std::sort (van C++), wat vele malen sneller performde omdat std::sort een template functie is en de compiler dus gewoon weet wat je erin stopt, ipv dat het een precompiled black box functie is die je een functie pointer mee moet geven als comparator, wat resulteert in dure branches.

ik heb toch ook altijd de indruk dat C programmeurs en mensen die spontaan nog wel eens assembler gebruiken meestal netter werk afleveren dan mensen die bij 'hogere' talen zweren en met hopen exotische bibliotheken komen aanleuren...

Maar nogmaals, dat ligt voornamelijk aan de programmeur. Ik zit als C++ ontwikkelaar regelmatig met mijn neus in assembly. En het gebruik van bibliotheken zie je in C net zo goed - en dat wordt behoorlijk duidelijk wanneer je denkt een open source project wel eventjes voor Windows denkt te kunnen compilen, want dan blijkt ineens dat dat project tienduizend dependencies heeft op andere libraries, en die ook weer. Ik heb de indruk dat C programmeurs voornamelijk verstokte masochisten zijn die slechts twee type containers kennen: arrays en linked lists

[Reactie gewijzigd door .oisyn op 27 juli 2024 04:36]

[Verwijderd]

Ik heb niet gezegd dat het een object georiënteerde taal is ik vraag mij gewoon af waarom je object georiënteerd moet programmeren, wat KAN in C++

[Laurens-R]

Uhm... Met alle respect, maar in C++ is dit net zo goed mogelijk. Het is niet zo dat de ++ in C++ staat voor automatische security protection oid. Dit soort zaken zijn alleen maar op te vangen door oplettendheid van de ontwikkelaar.

Een garbage collector helpt alleen memory leaks te voorkomen, maar het helpt je niet bij een overflow als deze. En STL is een library waar ook genoeg fout in kan gaan.

Het is erg makkelijk om over het werk van anderen te praten, maar een Library als deze is complex en het getuigd juist van professionalisme als ze naar een externe review partij luisteren.

[Reactie gewijzigd door Laurens-R op 27 juli 2024 04:36]

[Verwijderd]

Klopt, maar je hebt de mogelijkheid om b.v. met STL, encapsulation en GC vrijwel alle geheugen management problemen op te lossen. En vaak zijn dit soort fouten waar code execution mogelijk is toch gewoon geheugen management problemen omdat er verkeerd met pointers wordt opgegaan.

In C kan je trouwens ook Garbage Collection gebruiken maar men doet dit vaak gewoon niet uit koppigheid.

[svenslootweg]

Ik zou nu niet zeggen dat C++ zo'n goede keuze zou zijn (ook deze maakt het immers op bepaalde punten gewoon te makkelijk om fouten te maken), maar dat de 'standaard veiligheid' van je stack veel invloed heeft op de veiligheid van het resultaat is absoluut waar.