Veel Linux-distributies blijken kwetsbaar door kritieke GnuTLS-bug

Veel opensourcesoftware, waaronder de Linux-distributies van Red Hat, Debian en Ubuntu blijkt kwetsbaar door een bug in de GnuTLS-bibliotheek waardoor ssl en tls te omzeilen is en internetverkeer af te vangen is. De bug doet denken aan een recent Apple-lek.

GnuTLS is een bibliotheek die voor ssl/tls-implementatie zorgt en veel opensourcesoftware, waaronder besturingssystemen en honderden programma's, maakt er gebruik van. Er blijkt echter een bug in de GnuTLS-code te zitten, waardoor de ssl/tls-beveiliging te omzeilen is. Ssl en tls zijn de belangrijkste encryptieprotocollen voor internetverkeer en ze voorkomen dat belangrijke communicatie als internetbankieren en webmail te onderscheppen zijn.

De fout in de code zorgt ervoor dat bepaalde verificatie-checks niet uitgevoerd worden. Daarmee vindt geen goede authenticatie van de tls-, of X509-certificaten plaats en kunnen ongeldige certificaten geaccepteerd worden als geldig, beschrijft Existentialize. De bug zit mogelijk al jaren in de code en de reden dat het niet opgemerkt is, zou zijn omdat het moeilijk is tls-implementaties grondig te testen.

Daar kwam ook Apple onlangs achter: zowel iOS als OS X bleken vatbaar voor het omzeilen van ssl en tls door een fout in de code die inmiddels de 'goto fail' is gaan heten, naar de dubbele invoer van die coderegel die de bug veroorzaakte. Apple heeft de kwetsbaarheid in beide besturingssystemen opgelost. De GnuTLS-bug is ontdekt tijdens een audit voor Red Hat. Een GnuTLS-ontwikkelaar noemt de bug 'beschamend'. GnuTLS raadt aan te upgraden naar versie 3.2.12. Omdat de bibliotheek in zoveel software verweven zit, gaat het waarschijnlijk lang duren voordat alle programma's en besturingssystemen bijgewerkt zijn.

Reacties (145)

[Verwijderd]

sudo apt-get update
sudo apt-get upgrade
zo fixed...

edit: dit is het probleem uit link van "The Zep Man" hierboven:

A vulnerability was discovered that affects the certificate verification functions of all gnutls versions. A specially crafted certificate could bypass certificate validation checks. The vulnerability was discovered during an audit of GnuTLS for Red Hat.

Who is affected by this attack?

Anyone using certificate authentication in any version of GnuTLS.
How to mitigate the attack?

Upgrade to the latest GnuTLS version (3.2.12 or 3.1.22), or apply the patch for GnuTLS 2.12.x.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 22:28]

[zwik]

Wat misschien het melden wel waard is, Android, wat ook op Linux draait heeft hier default geen last van omdat het gebruik maakt van OpenSSL, een andere SSL/TLS library. Het is overigens wel mogelijk dat bepaalde apps tegen deze library aanlinken en dus daarmee je device kwetsbaar maakt.

[Loller1]

Dat dit eens duidelijk die denkwijze de kop in drukt dat open source geen garantie is voor veiligheid, nooit was en nooit zal zijn. Hoeveel mensen er ook maar toegang hebben tot de broncode.

[Milmoor]

Natuurlijk is open source geen garantie op veiligheid. Elk stuk code van meer dan een A4'tje heeft fouten. Maar een audit kan deze tenminste vinden, zoals nu bijv. gebeurd is. Bij closed souce is toegang krijgen t.b.v. een audit een stuk moeilijker. Naast bugs heb je ook nog bewust toegevoegde malavide code (achterdeurtjes). Dat is moeilijker te regelen met open source. Het is zichtbaar als er een blok code bijgekomen is (mits daar iemand op let).

Een voorbeeld: er waren al jaren vragen over Truecrypt. Zitten daar achterdeurtjes in, is de gecompileerde code wel passend bij de broncode. Er is nu een audit voor gestart en dat kan omdat het open source is.

[curumir]

Het zou best kunnen dat deze audit is gedaan vanwege de bug die bij Apple is gevonden. Het is wel heel toevallig dat juist deze code nu specifiek wordt getest. Het is ook een zeer vergelijkbare fout:
http://arstechnica.com/se...ps-open-to-eavesdropping/

This time, instead of a single misplaced "goto fail" command, the mistakes involve errors with several "goto cleanup" calls. The GnuTLS program, in turn, prematurely terminates code sections that are supposed to establish secure TLS connections only after the other side presents a valid X509 certificate signed by a trusted source. Attackers can exploit the error by presenting vulnerable systems with a fraudulent certificate that is never rejected, despite its failure to pass routine security checks. The failure may allow attackers using a self-signed certificate to pose as the cryptographically authenticated operator of a vulnerable website and to decrypt protected communications. It's significant that no one managed to notice such glaring errors, particularly since they were contained in code that anyone can review.

Voor elke software kan een audit worden gestart, alleen voor Open Source kan een publieke audit worden gestart. Het grote voordeel van een publieke audit is dat je de leverancier niet hoeft te vertrouwen. Maar ja, aangezien de meeste mensen ook voor OS hun code niet zelf compileren, blijft ook daar een stukje vertrouwen hangen bij degene die de binary aanlevert.

[Blokker_1999]

Ja en nee. Maar OSS heeft in deze wel voordelen. Stel je even voor dat de TLS implementatie gesloten was. Dat zou betekenen dat je ineens afhankelijk bent van de ontwikkelaar om deze fout eruit te halen. En als het pakket dan niet meer actief ontwikkeld word heb je nog een veel groter porbleem, moet je ineens op zoek gaan naar een alternatief en dat in zowat alle software gaan vervangen.

Wat voor audit werd uitgevoerd is niet bekend. Maar dankzij het OSS karakter kan men wel zeer snel de kernoorzaak van het probleem opsporen en kan iedereen met voldoende kennis de fout ook zelf oplossen.

De enige zekerheid die je hebt met OSS is dat het een heel stuk moeilijker is om er backdoors in te verwerken. En in dat opzicht is OSS wel een stuk veiliger.

[curumir]

Zou jij zelf de bug willen fixen? Je bent ook afhankelijk van de ontwikkelaars, alleen zijn ze nu gedistribueerd over de (in geval van Linux) meerdere mensen die erbij betrokken zijn. In geval van een binairy Ubuntu install ben je nog steeds afhankelijk van Canonical dat ze een update sturen. Een deel van de bevolking kan inderdaad zelf de update draaien. Een kleine minderheid zou ik willen zeggen.

Dat je deze zekerheid niet hebt bewijst deze bug gewoon omdat ze er minstens sinds 2006 in zat, en alle kwalificaties heeft van een subtiele backdoor heeft. Jouw aanname heeft dus al minstens 8 jaar gefaald.

[Gropah]

Ik ben het hier niet mee eens. Er zullen altijd bugs in zoftware zitten en degene die dat ontkend weet niet waar hij / zij hetvover heeft. Daarnaast betekend 1 bug in 1 project niet meteen dat alle open source projecten vol met bugs zitten of onveilig zijn.

Buga worden op verschillende manieren. De 2 manieren die het meeste bugs vinden zijn gebruik en code review (gewoon de tekst doorkijken op zoek naar bugs) . Gebruik is bij dit soort dingen erg moeilijk omdat door de encryptie het niet makkelijk te controleren is. Dan blijft codereview over en bij open source kan iedereen dat doen, terwijl bij closed source alleen het bedrijf wat het ontwikkeld.

Over het algemeen geld dat meer review meer beter is, maar bij bedrijven is er vaak geen geld voor degelijke code review en al helemaal niet voor alle code. Bij open source kan iedereen het doen en dit gebeurd dan ook regelmatig. Waarschijnlijk een stuk vaker dan code bij een bedrijf.

[emnich]

Hij zegt ook niet dat alle open source projecten vol met bug zitten en doet ook geen uitspraak over open vs closed source.

Hij maakt alleen een terechte opmerking dat open source geen garantie is voor veiligheid. Dit argument wordt erg vaak wel gebruikt. `Het is open source dus het is veilig` en dat is gewoon onjuist.

Ik gebruik vrijwel alleen open source en help ook mee in diverse projecten en ben dus erg pro open source maar gegarandeerd veilig(er) is het gewoon niet.

[Verwijderd]

En Gropah beweert ook helemaal niet dat Loller1 beweert dat alle open source software vol met bugs zitten. Gropah maakt een terechte opmerking dat je niet een generaliserende uitspraak kan doen over alle open source software op basis van een bug gevonden in 1 pakket.

Verder zijn het vooral tegenstanders van open source software / voorstanders van closed source software, die het argument gebruiken dat voorstanders van open source software altijd beweren dat open source software een garantie biedt dat het dan veilig is. Dat is niet waar namelijk. Dat dat beweerd wordt.

[curumir]

Volgens Gropah:

Dan blijft codereview over en bij open source kan iedereen dat doen, terwijl bij closed source alleen het bedrijf wat het ontwikkeld.

Lijkt toch precies wat jij zegt dat niet gebeurt: een review is makkelijker bij Open Source.

Voor een klein project ben ik het hier nog wel mee eens, maar wat deze bug aantoont is dat het voor enorme projecten zeker niet vanzelfsprekend is. Er is niemand die een zo groot overzicht heeft om maar even een persoonlijke audit te starten op een Linux implementatie. Ik zeg niet dat het niet kan, maar betwijfel of het gebeurd.

Deze bug zat er ruim 8 jaar in, en was van hetzelfde banale niveau als de bug die 1,5 jaar in de Apple code zat. Het was dan wel geen goto-fail, maar als ik het ars technici artikel kan geloven ging het over een aantal 'goto cleanup'-calls.
http://arstechnica.com/se...ps-open-to-eavesdropping/

[hardwareaddict]

Waar linux testen al hoegenaamd niet gebeurt in dit opzicht is het bij security code nog veel lastiger.

Mensen hebben 't dan over openssh oid, maar toen ik de TLS server hier controleerde werd de daadwerkelijke encryptie niet via openssh gedaan maar via een systeemlibrary, waar ik dus NIET de code van heb

[RGAT]

De GnuTLS-bug is ontdekt tijdens een audit voor Red Hat

Het is dus gevonden omdat het open-source is, maar inderdaad, open-source moet niet betekenen dat het veilig is, enkel dat het toegankelijk is.

[Maurits van Baerle]

De bug heeft negen jaar in de open source code gezeten voordat hij gefixt is. De Apple bug heeft vier maanden in de open source code gezeten voordat hij gefixt is. Bovendien worden dit soort dingen regelmatig ontdekt in gecompileerde code die een test faalt en waarbij de source er dus niet toe doet. Beide bugs zijn niet gevonden door externe partijen maar door Red Hat (die ook als het closed source was die source wel hadden gehad) en Apple (die ook als het closed source was die source wel hadden gehad).

Het open source zijn heeft in deze twee gevallen dus niet bepaald bijgedragen aan het vinden, anders had je toch wel gehoopt dat ze het negen jaar geleden al hadden gevonden.

[blouweKip]

De vraag is hoeveel van dit soort kwetsbaarheden er in closed source software zitten, zonder cijfers daarover is het moeilijk te stellen dat open source gemiddeld geen positief effect heeft op de kwaliteit van de code.

[Maurits van Baerle]

Klopt, je kunt met dit incident inderdaad niet closed en open source met elkaar vergelijken.

Wat je wel kunt doen is concluderen dat het feit dat iets open source is geen garantie is dat ernstige kwetsbaarheden niet jarenlang ongefixt blijven. In dit geval kostte het drie jaar om te ontdekken en daarna nog zes jaar om het te fixen. Ondanks dat iedereen de source code (en de discussie er over) kon inzien.

[woutertje]

Dat de code beschikbaar is gesteld aan de auditor betekent niet dat die code open source is.

Edit: inderdaad bedoel ik wat Maurits van Baerle zegt, dat code geaudit wordt staat los van het feit of de code open source is of niet. Dat dat in dit geval toevallig wel zo is doet daar niets aan af.

[Reactie gewijzigd door woutertje op 22 juli 2024 22:28]

[sfc1971]

De GNUtls code is volgens jouw niet opensource?

[Maurits van Baerle]

Wat woutertje bedoelt is dat ook closed source software beschikbaar gesteld kan worden aan interne of externe auditors. Het heeft niets met open of closed te maken.

[i-chat]

dat mogen allemaal waar zijn, maar ik kan geen onderdelen van windows auditeren, bij delen van bijv debian kan ik dat wel (even aangenomen dat ik hiervoor de kennis zou bezitten). nu is gnutls een beest geavanceerd stukje oftware, en daarmee zie je dus dat er relatief weinig mensen genoeg kennis hebben van de materie om een goede audit uit te voeren. en zie daar: waarom het zo lang heeft geduurd.

ik zou niet te lang in de waan verblijven, dat dit soort fouten niet in windows zitten, het betekend gewoon dat er soms hele domme fouten in zeer kritische software zitten. maar zo'n beetje elke goede sysadmin zou dat al lang hebben moeten weten, en hebben moeten voorzien in zijn software-installaties... (hoewel je daar in dit geval wellicht weinig tegen kunt beginnen).

[Dreamvoid]

maar ik kan geen onderdelen van windows auditeren,

Als je als grote klant de code wilt auditen kan dat - diverse overheden hebben bv toegang tot de Windows source.

Microsoft geeft zijn software niet vrij onder een GPL ofzo, maar dat wil niet zeggen dat de source code niet inzichtelijk is.

[elmuerte]

En het voordeel van opensource is dat een ook niet-grote-bedrijven en overheden een kunnen audit kunnen uitvoeren.

[Brahiewahiewa]

Alsof ze daar de kennis voor hebben...

[curumir]

Een audit wordt over het algemeen door een externe partij gedaan, maar kan ook prima intern gebeuren door een aparte groep/afdeling/whatever. Zo zal de Apple-goto-fail vast ook door een interne audit gevonden zijn. Ik kan me zelfs voorstellen dat deze specifieke wellicht getriggert zijn door de claims van Snowden over waar de NSA overal bijkan.

Sterker nog, er was al een tin-foil theorie over de bug bij Apple en er een wel heel erg overeenkomstige bug gevonden is op deze plek... Ik ben benieuwd of getraced kan worden wie deze bug heeft veroorzaakt.

[thegve]

Als het goed is zou je dit uit een revisiesysteem moeten kunnen achterhalen. 'svn blame' of vergelijkbaar voor andere systemen.

[Verwijderd]

De bug zat er eerst ook niet in. Pas na een grote commit was deze bug ineens verschenen.

[MetalfanBlackness]

Niet elke audit is op de source code, het kan ook zijn dat een audit is gedaan op de binaries om te kijken of er lekken te vinden zijn.

[curumir]

Loller1 heeft helemaal gelijk!

De bug zat er al waarschijnlijk in sinds 2006! Dat zijn 8 volle jaren in code die voor iedereen open is. De schaalgrootte van OS projecten als Linux is gewoon veel te groot om dit soort bugs structureel te vinden doordat het nu eenmaal Open Source is en iemand het wel vind en oplost.
Ter vergelijk, de Apple bug zat er sinds October 2012 in.

Niks ten nadele van OS, er worden veel zeer toffe, grote en kleine projecten gemaakt maar vooral de grote projecten zijn te groot en te complex om er vanuit te gaan dat bug en exploits wel gevonden worden.

[Blokker_1999]

Neen, hij heeft niet helemaal gelijk slechts ten dele. Ja, men moet er naar kijken, maar bij OSS heb je die mogelijkheid wel. Bij closed source kan je er nooit naar kijken, zelfs al zou je willen. Je weet bij closed source ook niet of de software meer doet dan jij verwacht (lees backdoors), iets wat bij OSS veel eenvoudiger is na te gaan.

[hardwareaddict]

OSS is veel te groot om zelf te bekijken meestal.

Heb je wel eens je TLS server goed bekeken?

[curumir]

Theoretisch heb je helemaal gelijk. Dat zal ik zeker niet ontkennen.

In de praktijk zal 99% van de mensen ook niet weten wat hun Open Source software doet (en dan heb ik het over de grote systemen als Linux installs) omdat ze simpelweg binaries en libraries downloaden. Daar zit zeer zeker ook een (wellicht kleinere) trust-factor in.

Ook kunnen er mensen kijken naar de source-code van Linux om te checken of er backdoors in zitten, maar in de praktijk is dat best ondoenlijk omdat er veel te veel code is om maar wat in te gaan checken. Dat is een aanname van mij, maar wel eentje die voor een deel ondersteund wordt door deze bug die er al 8 jaar+ in zat.

http://en.wikipedia.org/wiki/Source_lines_of_code#Example
Debian: 419 miljoen in 2012
Linux kernel: 16 miljoen in 2012.

Happy hunting...

[HerrPino]

Backdoors zijn echt niet zo erg eenvoudig te herkennen. Ja als je een backdoor inbouwd op de manier van:

if (authorized || userName == 'NSA_USER') ...

Maar als jij een backdoor inbouwd dat gebruik maakt van bugs of bepaalde limitaties in bijvoorbeeld de standaard C/C++ libraries dan ga je die echt niet zo makkelijk vinden.

[Freee!!]

Het is inderdaad geen garantie, maar zonder toegang tot de broncode was het nog veel moeilijker geweest om het te vinden.

Het grootste probleem bij open source is overigens de compiler. Er is allang aangetoond dat daar allerlei rotzooi in verborgen kan zitten die ook weer doorgegeven kan worden aan nieuwe compilers die vanuit schone sources worden gecompileerd.

[Verwijderd]

Interessante statement, heb je misschien wat links voor me?

Ik heb er meerdere keren van gehoord, maar ook van manieren waarop attacks op de compiler juist weer omzeild kunnen worden, zoals bijvoorbeeld door DDC (Diverse Double Compiling). Zie https://en.wikipedia.org/wiki/Backdoor_(computing) laatste alinea

[Freee!!]

Sorry, op dit moment geen links (zit op mijn werk), uit blote hoofd gedaan. Ik was niet op de hoogte van mogelijkheden dit weer te omzeilen.

[hardwareaddict]

Het klopt alleen wel.

Veel compilers voegen tegenwoordig allerlei troep toe die in 't verleden er niet was. Denk aan microsoft visual c++ compiler die hele XML manifesten toevoegt, waardoor je systeempje ook op die manier te hacken valt

[Freee!!]

Gelukkig codeer ik niet voor Windows machines.

[_Pussycat_]

Daar gaat het hier dus helemaal niet om.

Wat Freee!! bedoelt is bv. op http://cm.bell-labs.com/who/ken/trust.html uitgelegd.

[Verwijderd]

DDC werkt natuurlijk alleen als je diff tool niet al besmet is.

[djiwie]

Hetzelfde kan gezegd worden voor closed-source, overigens.

[Ultraman]

Dat dit eens duidelijk die denkwijze de kop in drukt dat open source geen garantie is voor veiligheid,

Fijn dat het het ontwikkelmodel dat ook niet claimt, laat staan kan claimen. Wie dit beweert slaat, net als jij, een flink aantal hordes over waarom open source software veiliger kan zijn dan closed source software.

nooit was

die bewering kan ik niet volgen.

en nooit zal zijn.

Daar ben ik het niet mee eens. Er worden genoeg bugs gevonden doordat er meer mensen uit verschillende standen van de maatschappij naar kijken.
Met het gebruik van closed source software is dit een grote onbekende en heb je nooit de mogelijkheid om inzicht te krijgen in wat er wel gevonden wordt en wat er doorheen glipt. Dergelijk nieuws zul je ook minder lezen omdat dit soort grotere fouten mogelijk intern worden gehouden in plaats van dat de discussie in het open gebeurd. Zoals het geval is met open source software en iedereen alles mee kan krijgen.

[Reactie gewijzigd door Ultraman op 22 juli 2024 22:28]

[twiFight]

Beschamend dat jij een +2 krijgt. Het is één groot pot verwijt de ketel verhaal zo.

Fijn dat het het ontwikkelmodel dat ook niet claimt, laat staan kan claimen. Wie dit beweert slaat, net als jij, een flink aantal hordes over waarom open source software veiliger kan zijn dan closed source software.

Vervolgens sla jij alle hordes over dat het bij open source nog altijd een mogelijkheid is en geen feit. Aan het einde van de dag kun je over beide code sources niets zeggen. Bij closed source heb je uberhaupt geen inzicht, maar bij open source kun je, zelfs met inzicht, nog steeds niets zeggen over hoe bug free de code is. Een inherente eigenschap aan een bug is namelijk dat je 'm wel eerst moet detecteren voordat je 'm kunt fixen. Een bug in de code kun je bewijzen, bugloze code kun je nooit bewijzen!

Zoals het geval is met open source software en iedereen alles mee kan krijgen.

Maar dan moeten mensen dat nog wel doen. Wie garandeert mij dat open source code gecontroleerd is door die illustere community? Het is fijn dat iedereen het kan, maar dan moet het nog wel gebeuren. En ik betwijfel dat ook maar 1% van de (particuliere) open source gebruikers ook maar ooit serieus bug hunt, laat staan hoe weinig mensen dat voor de gehele code doen.

Je kunt hooguit door meerdere partijen code te laten reviewen en uitgebreide unit tests aannemelijk maken dat code bug'vrij' is. Maar dat geldt voor zowel closed source als open source.

Maar gezien je statement denk ik dat deze boodschap niet echt zal aankomen en wens ik je veel plezier op internet met Internet Explorer.

Kom op zeg, gedraag je even als een volwassene.

[Ultraman]

Een bug in de code kun je bewijzen, bugloze code kun je nooit bewijzen!

Eens, dat zeg ik ook

Kom op zeg, gedraag je even als een volwassene.

Daar liet ik mij toch even gaan...Nu weg.

[Reactie gewijzigd door Ultraman op 22 juli 2024 22:28]

[bandidoloco]

Het feit dat de mogelijkheid bestaat om dit lek te ontdekken is net een garantie voor veiligheid, moest hetzelfde lek in Windows zitten wordt het waarschijnlijk nooit ontdekt...

[ronaldmathies]

Daarom heeft de bug 8 jaar in de source code gezeten. In mijn beleving zie ik geen verschil tussen dit en het mischien niet vinden in Windows.

[bandidoloco]

Omdat bij Microsoft niemand na zoveel jaren nog de moeite doet om de broncode te bekijken, soortgelijke bug zou er dus waarschijnlijk eeuwig in blijven met kans op een zero day vulnerability (ook iets wat bij open source nauwelijks voorkomt, want er is altijd wel iemand die doorontwikkeld)

[_Pussycat_]

Er is vaak ook niemand die doorontwikkelt. Zie bv. de DNS server van de Chaos Computer Club, die een sinds 5 jaar niet gepatcht pakket gebruikte:

Parallel dazu veröffentlichte er auch Patches, die das einfache Vergiften des Caches mit falschen IP-Adressen verhindern und sendete diese auch an den Autor der Software Dan J. Bernstein. Doch "djb" kümmerte sich offenbar nicht weiter um das von ihm initiierte Projekt; es gab nie eine neue Version, die die Löcher stopfte.

http://www.heise.de/secur...ter-Software-2112171.html

[Blokker_1999]

securite trough obsucirty == no security at all.

Het is niet omdat iemand de broncode niet kan inzien dat ze geen zwakheden kunnen vinden. Het omgekeerde is ook waar, het is niet omdat de broncode toegankelijk is dat bugs snel boven water komen. Stomme fouten, daar lees je namelijk zo over.

En eigen software is vandaag ook niet meer zo moeilijk te ontcijferen. Steeds meer en meer word in .net geschreven en word na het compileren niet beschermd. Even een dotpeak of ilspy gebruiken en je hebt zo de originele broncode terug.

Met zulke uitspraken mag ik toch echt hopen dat jij in je dagelijkse leven niet veel met IT beslissingen te maken hebt.

[ro8in]

Klopt maar obsecurity geeft wel een mate van veiligheid in de zin dat het meer moeite kost voor een buitenstaander om een lek te vinden. Het is niet gezegd dat zij het nooit zullen vinden, maar het is een stuk moeilijker dan wanneer je direct inzicht hebt in de broncode.

Ik heb vroeger veel web services gedraaid, waarbij bijna altijd de opensource software zoals Wordpress en Joomla de sjaak waren, terwijl de web services die custom geschreven waren nagenoeg onaangetast bleven. Dat wil niet zeggen dat die veiliger waren, maar in de praktijk zijn dit soort opensource pakketten wel het eerste waar hackers naar zoeken, omdat daar de lekken vaak al bekend van zijn uit de broncode.

[RGAT]

Meer veiligheid mag je het dan toch echt niet noemen, hooguit uitstel van beveiligingsproblemen...

[ro8in]

Uitstel geeft wel meer tijd om zelf lekken te ontdekken en eventueel te dichten, voordat een kwaadwillende ermee aan de haal is gegaan.

Ik spreek enkel uit praktijk ervaring. In theorie ben ik het helemaal mee eens dat opensource of closed source in de basis geen verschil maakt in veiligheid. In beide kunnen exploits zitten die kwaadwillende kunnen gebruiken. Echter totale inzicht geven in een systeem maakt het kwaadwillende wel een stuk makkelijker.

Zie het een beetje als een compleet alarm systeem in je huis. Heeft de inbreker geen benul van het systeem zal hij vanaf buiten de zwakheden moeten ontdekken en ondertussen misschien delen van het alarm laten afgaan. Jij hebt dan de tijd om actie te ondernemen en bijvoorbeeld de politie te bellen. Maar heeft hij een complete blauw druk van het systeem met alle zwakheden perfect aangegeven, staat hij midden in je woonkamer voor je het door hebt.

Wat je graag wil is een alarm systeem dat geen zwakheden kent, met opensource zeg je eigenlijk hier heeft de hele wereld een blauw druk van mijn alarm systeem en hoop je dat goedwillende de zwakheden voor je eruit filteren. Echter in de praktijk zijn inbrekers er vaak veel eerder bij want die hebben wat te halen..

[Reactie gewijzigd door ro8in op 22 juli 2024 22:28]

[Blokker_1999]

Alleen gaan een joomla en wordpress ook een veel grotere installbase hebben dan een eigen, gesloten alternatief waardoor het voor hackers ook weer interessanter word om daar lekken in te gaan zoeken.

De lekken zijn niet noodzakelijk bekend vanuit de broncode, maar komen voort uit de populariteit. Maar ook dat is iets waar je mee moet oppassen want populair betekend niet noodzakelijk meer gehacked. Een mooi voorbeeld daarvan zijn webservers. Ondanks dat Apache veel populairder is dan IIS zijn er historisch gezien een pak meer exploits voor IIS te vinden dan Apache.

[Big Mama]

Even een update van CentOS6, CentOS5 en Ubuntu 12.04 gedaan, en zie daar: overal verse GnuTLS packages.

[Reactie gewijzigd door Big Mama op 22 juli 2024 22:28]

[Tweaker626]

Klopt: probleem is al gefixt:
http://www.ubuntu.com/usn/usn-2127-1/

Update instructions voor Ubuntu etc
The problem can be corrected by updating your system to the following package version:
Ubuntu 13.10: libgnutls26 2.12.23-1ubuntu4.2
Ubuntu 12.10: libgnutls26 2.12.14-5ubuntu4.6
Ubuntu 12.04 LTS: libgnutls26 2.12.14-5ubuntu3.7
Ubuntu 10.04 LTS: libgnutls26 2.8.5-2ubuntu0.5

Deze versies komen vandaag gewoon met de standaard update mee.

[Reactie gewijzigd door Tweaker626 op 22 juli 2024 22:28]

[Nonstop decay]

Kijk, dit komt goed van pas bij mijn vraag. Zo te zien heb ik libgnutls26 versie 2.12.23-1ubuntu4.2 al, dus dat lijkt me goed. Ik zie in de lijst van mijn Software Center echter ook een libgnutls 28 staan (en xx27 en xx28). Wat is daar dan weer het verschil mee? Toch een nieuwere versie?

[Nonstop decay]

Een praktische vraag: het artikel stelt dat het is aan te raden te updaten naar versie 3.2.12. Dat is de nieuwe versie van die gnuTLS library neem ik aan? Ik zit net te bladeren in m'n Software Manager (in Linux Mint 16) en ik kom daar verschillende bestanden tegen waar "gnutls" in voorkomt, waaronder een paar met "libgnutls". Ik neem aan dat ik die dan moet updaten, toch? Ik zie er alleen geen één tussen staan met dat versienummer, terwijl dit OS Ubuntugebaseerd is en jij net zegt dat je Ubuntu kon updaten. Heeft iemand een tip of aanwijzing voor me hoe ik dit kan updaten? Of moet ik wachten tot Linux Mint zelf ook deze update beschikbaar stelt?

[himlims_]

Mint en security... http://www.omgubuntu.co.u...t-online-banking-unsecure

[Nonstop decay]

Een beetje offtopic, maar iets verder lezen: http://www.itworld.com/op...mint-need-better-security
Linux Mint zou "onveilig" zijn, omdat ze updates delen in verschillende niveaus, 1-5. (Zie dit plaatje: http://segfault.linuxmint...rom-2013-11-18-143153.png) Sommige van die niveaus worden niet automatisch geüpdatet, omdat ze nog niet zijn getest en je systeem mogelijk instabiel maken. Je kunt er echter zelf voor kiezen om deze alsnog te installeren. Noem je dat onveilig? Ik ben eigenlijk wel blij dat het zo werkt.

[himlims_]

dat is een manier, andere manier is dat mint eigenwijs is; de core/basis van ubuntu/debian 'sloopt' waardoor incompatabiliteit en instabiliteit van komt; geen wonder dat ze extra tijd nodig hebben alvore ze door debian/canonical geverifeerde patches doorvoeren. begrijp hun reactie, maar compleet onnodig wanneer ze volgens de richtlijnen spelen. Ik zie mint ook meer als een windows-me

[Big Mama]

Linux-releases blijven vaak op een bepaalde major versie van de software zitten tijdens de looptijd van de Linux-release. Dit geldt bijvoorbeeld voor de kernel, samba, libreoffice, enz. Bugsfixes worden dan gebackport, zodat de fix ook beschikbaar is voor die Linux-releases.
Dus je hoeft niet per sé op versie 3.2.12 te zitten van GnuTLS, zolangs de bugfix maar gebackport is naar de versie die jij gebruikt.

[hackerhater]

Ik heb zelf (k)Ubuntu 13.10 en volgens mij is het geen default geinstalleerd package meer.
De directe zou gnutls-bin zijn en die is bij mij niet geinstalleerd.

[0x2665]

Yep hetzelfde geld voor Debian en SUSE zie ook de lwn security advisories van gisteren. Hiernaast hebben ook Gentoo en Arch de patch opgenomen in hun repositories.

[Verwijderd]

Debian Wheezy ook

[dukejunior]

Verbazingwekkend om te zien dat dergelijke funtionaliteit pas tijdens een audit naar boven komt. Maar wat ik mij eigenlijk afvraag is waarom "het waarschijnlijk lang gaat duren voordat alle programma's en besturingssystemen bijgewerkt zijn". Als dit in een bibliotheek zit, zou het aanroepen van die functionaliteit toch hetzelfde blijven. De aanpassingen zitten dan toch maar op 1 plaats in de code ? Of is dit te kort door de bocht....

[Loen]

CentOS is de basis voor heel wat verschillende appliances, zoals ook firewalls of applicatieve appliances. CentOS (Red Hat) kan dan een patch leveren, wat ze ook al gedaan hebben, maar de leverancier van de appliance moet dat daarna ook overnemen. Nu hebben we het alleen over CentOS, maar alles wat gebaseerd is op Linux (en dat kan echt alles zijn tegenwoordig) kan die GnuTLS bug hebben...

[Maurits van Baerle]

Het is niet pas bij deze Red Hat audit naar boven gekomen.

De kwetsbaarheid zit er sinds 2005 in. Drie jaar (!) later, in 2008, heeft iemand aan de bel getrokken maar daar is de daaropvolgende zes jaar niets mee gedaan. Het verdient niet bepaald een schoonheidsprijs.

Nou gebruiken veel implementaties OpenSSL en niet GnuTLS, maar op juist een aantal cruciale plekken wordt GnuTLS gebruikt omdat men problemen heeft met de OpenSSL licentie. Grote distro's als Debian bijvoorbeeld maar er zijn ook Apache implementaties en ontelbaar veel hardware devices die GnuTLS gebruiken. En hoe vaak krijgt een parkeerautomaat een update?

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 22:28]

[curumir]

Nou ja, aan de bel getrokken bij een (voor mij) schijnbaar ongerelateerd forum; een openldap forum. Ook Open Source, maar geen forum voor linux OS developers. Dat er drie posts op een forum staan noem ik nog niet bekend.

[Big Mama]

Tja, ligt eraan of dingen statisch of dynamisch gecompileerd zijn. In het eerste geval is de bug meegecompileerd naar de programma-binary. In het laatste geval hoeft alleen de gecompileerde library vervangen te worden.

[Amanush]

Goed nieuws! Het is altijd fijn om te horen dat er een lek is gevonden. Zo kan het weer opgelost worden. Zal er ook een soortgelijk lek zitten in Windows?

Fijn dat het gefixt kan worden!

[Reactie gewijzigd door Amanush op 22 juli 2024 22:28]

[himlims_]

kan opgelost worden - is opgelost:

https://www.gitorious.org...f0aec1878a41c17c41d358a3b

[mcDavid]

En bij thuiskomst stond die update al klaar op mijn Ubuntu systeem

Moest je eens met een windows-systeem hebben, zoiets. Mag je rustig een maand wachten op de volgende patch-tuesday, als je geluk hebt. Met een beetje pech kost het te veel geld en mag je twee of meer maanden wachten.

[Reactie gewijzigd door mcDavid op 22 juli 2024 22:28]

[mojo81]

Klaar om te installeren of geïnstalleerd? Want datzelfde gebeurt dus ook als er een nieuwe bug wordt geïntroduceerd, je hebt hem meteen bij thuiskomst.

[mcDavid]

Dat ligt er maar net aan hoe je je update-policy ingesteld hebt. Ik heb niet voor automatisch installeren gekozen omdat ik graag wil zien wat er geïnstalleerd wordt, maar volgens mij staat dat standaard wel aan.

[MGutker]

Das lekker, heb ik net een peperduur SSL Certificaat gekocht om te gebruiken op mijn (Jawel) ubuntu webserver... En dan blijkt het lek te zijn, waarom vertrouw ik eigenlijk nog op het internet?

[i-chat]

welke webserver je gebruikt maakt hier niet zo heel erg uit want het gaat om de client libs die lek waren, en als je naast dik geld voor dat cert ook dik geld voor het ubuntu atvangage (of hoe cononical dat tegenwordig ook noemt), neer hebt geteld kun je alle support krijgen die je nodig hebt om dit te pachten, punt is, gnutills lijkt inmiddels gepatched, dus alle software die hun eigen versies mee sturen zullen of snel moeten volgen, of je zult mogelijk zelf versies moeten updaten. either way.

doe nu niet alsof je dat cert voor niets hebt gekocht of dat je per sé benadeeld bent want feitelijk heeft het hele internet een hele lange tijd grote risico's gelopen ... en dus echt niet alleen jij.

[Ethelind]

ik had liever dat er helemaal geen lek in zat hehe... wat niet lek is hoeft niet gefixt te worden.

[ronaldmathies]

Waarom wordt hier door tweakers rn in het nieuws artikkel niet gezegt dat dit wel eens een backdoor zou kunnen zijn? Stond ook in het nieuws bericht over de TLS bug bij Apple.

Ik zie het verschil niet, dus volgens mij is dit een backdoor.

[GuardMoony]

Het was geen bewuste fout. Eerder een domme fout ( werd zelf door de schrijver ervan herkend )
Je kunt meer info vinden op volgende site:
http://blog.existentializ...ry-of-the-gnutls-bug.html

[royb3]

Je kan als deelnemer aan een opensource project natuurlijk expres een 'domme fout' aan je programma toevoegen. zodat mensen je geloven wanneer je zegt dat het een domme fout is, maar er wel door mensen misbruik van kan worden gemaakt. Maar er zijn natuurlijk ook een hoop projecten waar zomaar iemand wat aan kan aanpassen, en waar dingen als pull requests niet erg grondig worden nagekeken. of dat mensen zelf de optie krijgen om iets door te zetten.

[bbob]

Ik denk dat jou vraag of opmerking eerder bedoeld is als een bewuste backdoor ?

Iedere fout in de software kan potentieel als backdoor misbruikt worden. Aangezien software door mensen gemaakt is zitten er altijd fouten in, fouten die je normaal niet bewust maakt. Dat soort fouten noem ik geen backdoor.

Een backdoor is voor mij iets dat bewust door iemand is aangebracht met als doel ongemerkt toegang te krijgen.

[Argantonis]

Ik denk dat jou vraag of opmerking eerder bedoeld is als een bewuste backdoor ?

Iedere fout in de software kan potentieel als backdoor misbruikt worden. Aangezien software door mensen gemaakt is zitten er altijd fouten in, fouten die je normaal niet bewust maakt. Dat soort fouten noem ik geen backdoor.

Een backdoor is voor mij iets dat bewust door iemand is aangebracht met als doel ongemerkt toegang te krijgen.

Je spreekt jezelf een beetje tegen. Eerst maak je de opmerking dat hij het wel zal hebben over een bewuste backdoor, dan zeg je dat een backdoor sowieso al bewust is aangebracht. Dat laatste klopt natuurlijk, anders is het gewoon een security-fout, maar een backdoor (achterdeur) is per definitie bewust aangebracht.

[hardwareaddict]

Dit gaat om security code. Niet bepaald code waar 'toevallig'even iets aan veranderd wordt.

Dus het gaat dan direct om backdoors.

Toevalligheid bestaat niet in securitycode.

[aikebah]

Ah... vandaar dat er altijd met PRNG gewerkt wordt.... bij een echte RNG zou het geen securitycode meer zijn. En ik maar denken dat het was vanwege limieten van het systeem

[bstard]

Hebben bijde situaties niet een gelijke bron? Aangezien Apple veel BSD unix door ontwikkeld heeft, en dit soort libs vaak geforked worden voor diverse OOS projecten?

[Maurits van Baerle]

Het is niet dezelfde bron. Beide libraries zijn open source en je kunt direct zien dat ze niet hetzelfde zijn en dat het niet exact dezelfde fout is. Bovendien werd bij GnuTLS de bug geïntroduceerd in 2005 en in iOS in 2012.

[sepulep]

Waarom wordt hier door tweakers rn in het nieuws artikkel niet gezegt dat dit wel eens een backdoor zou kunnen zijn? Stond ook in het nieuws bericht over de TLS bug bij Apple.

Ik zie het verschil niet, dus volgens mij is dit een backdoor.

dit is moeilijk te bewijzen, maar beide bugs zijn wel goede kandidaten want plausibele "oeps foutje.". Maar ik kan toch niet begrijpen hoe iemand dit heeft laten paseren (als je er vanuit gaat dat je toch iets nauwkeuriger naar beveiligings code kijkt): bij de Apple bug (dubbele goto) zie je meteen dat dat geen goede code is, en ook de gnuTLS bug (inconsistent gebruik va een return code, grappig genoeg ook weer met een goto) is vrij duidelijk

[H!GHGuY]

Lees even de Existentialize link. Daar wordt aangehaald dat de code gewijzigd is tijdens een grote refactor.

Uit ervaring weet ik dat grote refactors moeten opgesplitst worden in veel kleine, begrijpbare en reviewbare commits. Dit was hier niet het geval en je kan je zelfs afvragen óf er zelfs is gereviewed...

[Milt]

Een simpele unit test had deze bug kunnen opvangen, net als bij Apple overigens.

[mcDavid]

Sja, in a parallel universe misschien... Software zonder lekken is een utopie, alle software heeft bugs. Als deze gevonden worden door een goedwillende onderzoeker/developer is dat altijd goed nieuws, want het enige alternatief is dat deze in (niet open-source) broncode blijft staan tot een kwaadwillende hacker ze tegenkomt.

[gimbal]

Standaard argument inderdaad. Maar als software ontwikkelaar zeg ik: er zijn bugs en er zijn bugs die zo enorm beschamend zijn dat je ze niet met dat argument kunt goedpraten. Sommige bugs -mogen- niet bestaan omdat ze OF tijdens testrondes gevangen worden, OF binnen aannemelijke tijd gedurende de doorontwikkeling.

Als er een bug in zit waardoor er onder zeer specifieke omstandigheden een crash optreedt: ok. Als je beveiligingscode (MAW: zeer kritische code) compleet teniet kunt doen, dan verdien je billenkoek. Niet dat je het dan ook daadwerkelijk moet krijgen, want het is belangrijker om het probleem op te lossen dan mensen te straffen voor hun fouten.

[kmf]

Inderdaad. Die opensource ontwikkelaars die dit in z'n vrije tijd had gedaan zullen ontslagen moeten worden... of tenminste een salary-cut.

Doe dan gelijk de duizenden testers er ook maar bij.

[Brahiewahiewa]

Nou, je kunt wel gepikeerd reageren op iemand die het waagt een opensource ontwikkelaar aan te vallen, maar er is nog wel zoiets als verantwoordelijkheid. En als jouw code op zo ongeveer alle Linux machines in de wereld draait, dan moet je gewoon zorgen dat het goed is; of je nou betaald wordt of niet

[g4wx3]

Soms is het ook de vraag of een bug een bug is.
Als amateur heb ik al van alles grprogrammeerd, maar wegens ondoordachte ontwerpkeuzes, zijn er soms problemen die je niet kan oplossen zonder een volledige ander ontwerp.

Een bekend voorbeeld is pong (tennis), toen nog met TTL-chips hardwarematig gedesigned, maar de bat's konden niet tot tegen de rand komen. Dit als gevolg van ontwerpkeuzes om zo min mogelijk chips te gebruiken.

Maar sowiso is het heel sterk afgeraden GOTO te gebruiken. We programeren niet meer in BASIC, Je kan het oplossen met SWITCH/CASE, of ELSEIF (ELSIF in VHDL)

[elmuerte]

Schrijf die code maar eens met een switch, dat maakt het enorm onlessbaar.
De reden voor de goto in the gnutls code is het gebrek aan een try { } finally { } constructie.

[DLGandalf]

exception-based programming i.e. try,catch constructies, zijn soms ook ondoorgrondelijk, bovendien zijn exceptions niet bedoeld ter vervanging van control-flow

Dit is de patch:
https://www.gitorious.org...f0aec1878a41c17c41d358a3b

Dit is duidelijk een state machine-achtige fout, iets wat mi. niet opgelost zou moeten worden door een exception. Exceptions gebruik je wanneer iets buiten de verantwoordelijkheid van je programma fout gaat.

[Reactie gewijzigd door DLGandalf op 22 juli 2024 22:28]

[mcDavid]

Fijn om te horen dat jij nooit fouten maakt, maar helaas wordt het overgrote deel van de software ontwikkeld door ontwikkelaars die net als alle mensen in de wereld die weleens iets productiefs doen in hun leven, gewoon fouten maken.

Dit soort dingen afstraffen is wel het allerdomste wat je kunt doen, zeker in een omgeving waar veiligheid op nummer 1 dient te staan. Het enige wat je bereikt met straffen, is dat mensen hun fouten niet meer melden of oplossen, uit angst op hun vingers getikt te worden.

[Blokker_1999]

Dit is zeker geen goed nieuws, op geen enkele manier kan je dit als goed beschouwen. Het enige positieve is dat deze bug boven water is gekomen. Maar aangezien niemand weet hoe lang deze bug al in de implementatie zit kunnen de gevolgen enorm groot zijn.

[Armada651]

Dat weten we wel, sinds 2005, dat is dus erg lang.

[M.l.]

Ongeveer een gros schat ik zo. Maar daar komen we helaas niet zo snel achter, wasrschijnlijk pas als het word misbruikt.

[Verwijderd]

Goed nieuws! Het is altijd fijn om te horen dat er een lek is gevonden. Zo kan het weer opgelost worden. Zal er ook een soortgelijk lek zitten in Windows?

Fijn dat het gefixt kan worden!

Als Windows een bug heeft, reageert iedereen "schandalig" maar hier is de eerste reactie gejuich omdat het opgelost kan worden?

[Ocirina]

Hmm, laatste tijd veel SSL bugs. Wie valt dit nog meer op?

[RoestVrijStaal]

Eerst was het een ondergeschoven kindje, maar nu er in de laatste jaren steeds meer focus is op beveiliging en privacy (o.a. crackende & DDoSsende scriptkiddie-tieners en debacles door de Westerse veiligheidsdiensten en meewerkende bedrijven zoals de RSA) wordt er minder met een 'mooi weer'-gedachte gekeken naar TLS-implementaties.

Maar, net als wat het artikel zegt, het is moeilijk om tls-implementaties grondig te testen.

Van de andere kant, als je ziet dat:

• De laatste versie van TLS (1.2) pas recentelijk bij de populaire browsers is geïmplementeerd, maar in de standaard configuratie uitgeschakeld staat.
• Terwijl de ondersteuning SSL 3.0 en TLS 1.0 en 1.1 niet eruit zijn gesloopt of door een update uit worden geschakeld.
• En ook van het gros van de websites DIE versleuteling gebruiken verouderde versies van TLS of erger nog SSL gebruiken.

Kun je enkel concluderen dat er nog een lange weg te gaan is naar 'echte veiligheid'. Dat ontwikkelaars bugs uit de TLS-implementaties pletten kan ik enkel toejuichen, maar het heeft niet veel zin als 'de andere cruciale pijlers' op losse schroeven staan.

[Reactie gewijzigd door RoestVrijStaal op 22 juli 2024 22:28]

[Maurits van Baerle]

Deze audit zal vrijwel zeker het gevolg zijn geweest van de fout in Apples code. Ik zou er op rekenen dat er meer mensen nu ineens hun TLS code aan het doorspitten zijn dus als MS of Google volgende week aan de beurt is zou ik daar niet van opkijken.

[Ocirina]

Ja, het zal wel naar aanleiding van zijn. Ik heb iig al me devices al gepatcht.

[Tio Nordin]

Vooral die laatste zin baart me zorgen: "Omdat de bibliotheek in zoveel software verweven zit, gaat het waarschijnlijk lang duren voordat alle programma's en besturingssystemen bijgewerkt zijn."
Dat is toch wel een groot verschil met de Apple-bug (die ook niet direct gepatched werd, maar iig een heel stuk sneller).

[emnich]

Apple hoefde maar 1 ding te patchen die ze ook nog eens direct in eigen beheer hadden. Waar het hier om gaat is dat er heel veel producten zijn die werken met deze code en er dus heel veel verschillende producten geupdate moeten worden die elk nog eens door anderen onderhouden worden. Nadat al die producten zijn geupdate door hun developers moeten alle gebruikers ook nog eens hun software bijwerken.

Het is dus een totaal onvergelijkbare situatie.

[curumir]

En dus? Dat de situatie structureel anders is, lijkt juist het punt dat Tio wil maken...

Waar tweakers normaal vrij snel zijn met het opsommen van de voordelen van OS (en vaak terecht), is dit dus een inherent nadeel van het OS model. Zo heeft alles voor en nadelen.

[emnich]

Het punt wat Tio Nordin wilde maken ontgaat me juist. Waar vergelijkt hij Apple nu precies mee? Met Ubuntu, Debian, CentOS, Mint, Puppy, Fedora of met een van de vele duizenden pakketten die gebruik maken van de library?

Dat heeft helemaal niets te maken met voor- of nadelen van het OS model. Je kan juist zeggen dat door het OS model, het makkelijker is voor alle ontwikkelaars om hun software snel te patchen. Dat niet iedereen dat (direct) doet heeft niets te maken met OS of niet.

[Tio Nordin]

Het punt wat ik wilde maken is: Ik maak me zorgen over de snelheid van de ontwikkeling en uitrol van patches. Dat gaf ik toch al duidelijk aan?
Volgens mij zeggen we beide hetzelfde (zoals curumir aangeeft).
In het artikel wordt de Apple-bug aangehaald. Deze was in mijn ogen heel makkelijk te patchen, want 1 product/systeem /ding (zoals je zelf zegt). Dit is dus een heel andere situatie. Onvergelijkbaar.

(Bij nader inzien, en na het lezen van o.a. andere comments, maak ik me trouwens iets minder zorgen, want ik denk dat eea toch sneller gepatched zal worden dan ik aanvankelijk dacht.)

[hackerhater]

Alle software die dynamisch naar een major linken zijn direct bijgewerkt. Software die hard-linkt zal hun eigen software moeten bijwerken.

[The Zep Man]

Vooral die laatste zin baart me zorgen: "Omdat de bibliotheek in zoveel software verweven zit, gaat het waarschijnlijk lang duren voordat alle programma's en besturingssystemen bijgewerkt zijn."

Maak je geen zorgen over dat de ontwikkelaars van software en besturingssystemen hier lang over zullen doen. De identifier is CVE-2014-0092, en je ziet dat bijvoorbeeld een distributie als Debian al op 1 maart een patch heeft doorgevoerd in hun development branch. Het zal daardoor best wel vlot in testing en uiteindelijk in stable verschijnen.

Ik denk dat de grootste vertraging zal komen door organisaties die niet actief hun servers up-to-date houden.

[halofreak1990]

Niet alleen dat, maar er zijn ook pakketten die static libs gebruiken, en die wellicht nooit geüpdate worden. Static-, in tegenstelling tot dynamic libs, vereisen namelijk dat de software opnieuw gecompileerd wordt.

[servies]

Static wordt bijna niet meer gebruikt, in ieder geval volgens mij niet meer in de standaard packages van de verschillende distributies en wel precies om de genoemde reden...

Ik zag toevallig dat m'n CentOS server vanochtend was bijgewerkt met de desbetreffende packages.

[Reactie gewijzigd door servies op 22 juli 2024 22:28]

[Blokker_1999]

Hangt er een beetje van af, de library word veel gebruikt, maar de meeste software zal na een update van gnutls direct beschermd zijn. Zij nemen namelijk allemaal dezelfde bibliotheek om mee verder te werken. Enkel wanneer deze in het project word opgenomen en dus ingebakken zit in de software moet van dat pakket een nieuwe versie worden gemaakt.

[swhnld]

Apple hoefde alleen zijn eigen besturingssysteem te patchen, echter van Linux zijn heel veel varianten in omloop, en elk van de leveranciers moet dit patchen voor hun klanten.

Overigens wel opvallend dat er ineens SSL/TLS bugs gevonden worden in alle besturingssystemen de laatste tijd want ook Windows is recent gepatcht.

[ronaldmathies]

Zit geen verschil tussen, elke linux distributie heeft zijn eigen leverancier en elke leverancier dient zelf de patch te schrijven of toe te passen. Dus op dat punt is het gewoon hetzelfde.

[itarix]

Nadat ik dit artikel had gelezen heb ik toch maar even geupdate op mijn Ubuntu 13.04 installatie. Er stonden twee nieuwe packages voor me klaar gek genoeg wel 2.12.23 inplaats van 3.12.23. Is Ubuntu nou retro of staat er een fout in het artikel van Tweakers.net?

gnutls-openssl27_2.12.23-1ubuntu4.2_amd64.deb
libgnutls26_2.12.23-1ubuntu4.2_amd64.deb

Moet wel zeggen dat ze er snel bij zijn met een fix.

[Reactie gewijzigd door itarix op 22 juli 2024 22:28]

[RoestVrijStaal]

Je moet libgnutls hebben. gnutls-openssl is een ander pakket (extensie voor gnutls om precies te zijn).

[ronaldmathies]

2005 bug geintroduceerd, 2008 bug gemeld, 2014 bug gefixed, is inderdaad snel, duurde maar 6 jaar.

[borft]

Wat een gedoe allemaal, al mijn Debian machines waren gisteren al geupdatet (gewoon een apt-get update && apt-get upgrade was genoeg). Als dat niet snel reageren is, dan weet ik het niet meer

[SunnieNL]

Je vergeet ff dat routers, nassen etc. natuurlijk ook nog getest moeten worden. Wie zegt dat door het fixen van de bug niet een andere is ontstaan. Na het testen moet er een nieuwe firmware gemaakt worden en die wordt vervolgens doorgestuurd.

Veel apparaten (mijn humax mogelijk) zullen de update helemaal nooit van hun leven zien.

[Verwijderd]

Daar was je dan laat mee, ik was maandag avond al zover. Mail gehad via [e-mail] (21:44 uur), en apticron

OT
Ik kan iedereen aanraden apticron te installeren (Debian/Ubuntu) (sudo apt-get update && sudo apt-get install apticron). Via unattended-upgrades kun je die boel ook automatiseren, maar dat lijkt me persoonlijk geen goed idee op een productie server dus die gebruik ik zelf niet.

[wica]

Security packages kan je in het algemeen wel veilig automatisch laten update. Er wordt in de meeste gevallen geen aanpassing gedaan aan de werking van de software. Als dit wel zo iets, wordt die (als het goed is) geblockt tijdens het automatisch updaten.

[Verwijderd]

Ik ben er nooit voorstander van om dit soort processen automatisch te laten verlopen op productie servers. Misschien kan het veilig op een standaard machine zonder custom packages, geen idee. Maar ik wil het risisco niet lopen dat er iets omvalt omdat het systeem zichzelf heeft bijgewerkt.

Ik ben er, mede dankzij mailinglist/apticron, altijd heel vroeg bij en bekijk vooraf om welke modules het gaat en wat de impact op mijn server zou kunnen zijn. Helemaal zeker ben je dan nog steeds niet, maar in ieder geval kun je tijdens de (handmatige) update het proces volgen en direct ingrijpen mocht er toch iets niet in orde zijn.

[divvid]

ligt er aan wat je onder productie server verstaat, onze productie server is er slechts voor een klein publiek, dus kan je die rustig updaten. Als er wat omvalt is het snel opgelost of bij erg kritische zaken gooi je de boel op slot totdat de processen klaar zijn en je rustig kunt updaten.

Voor hosting achtige servers wil je n.m.m. zo snel mogelijk alles updaten en zul je af moeten wegen wat het risico is van downtime tengevolge van een omvallende service of downtime vanwege een hack, dat laatste is natuurlijk niet uit te leggen aan een klant.

Overigens updaten wij als jaren automatisch sinds Ubuntu 12.04 en nog nooit heb ik iets zien omvallen door de updates.

[Verwijderd]

Al jaren 12.04? Nou ja, bijna dan, op 12 april 2 jaar oud

Je kunt het risico nemen, ik doe het echter niet. Da's een keuze die ieder voor zich maar moet nemen.

[borft]

jouw machines waren dus gisteren ook geupdatet, en maandagavond ook, net zoals die van mij. Overigens was de mail op de security lijst om 21:14 al

[Verwijderd]

@borft: sorry, typo van mijn kant.