Beveiligingsbug in OpenSSH

Na de recente security bug in de Apache webserver, is er wederom aankondiging verschenen van een beveiligingsfout in een opensource project. Deze keer betreft het de populaire SSH-daemon OpenSSH. SSH wordt tegenwoordig op zeer veel servers gebruikt om deze op afstand te kunnen beheren. Omdat het programma zoveel gebruikt wordt, zijn de gevolgen van deze bug ook vrij groot. De precieze details van de bug zijn nog niet bekend gemaakt omdat er nog geen adequate oplossing is voor het probleem..

Enkele dagen geleden is er een nieuwe versie van OpenSSH verschenen, met versie nummer 3.3. Deze nieuwe versie bevat onder andere een aantal verbeteringen voor de zogenaamde 'privilege separation modus'. Wanneer SSH in deze modus wordt gebruikt is de bug niet 'exploitable'. Derhalve worden ook alle serverbeheerders aangeraden om deze nieuwe versie van OpenSSH te installeren en gebruik te maken van de privilege separation modus. De bug zelf is echter nog niet uit deze versie verwijderd. De reden om de exacte details van de bug nog niet te publiceren is gelegen in het feit dat deze nieuwe versie nog niet op alle ondersteunde platformen in de privilege separation modus kan werken. Volgens Theo de Raadt, een van de developers van OpenBSD en OpenSSH, is de bug al afgelopen vrijdag aan diverse producenten van Linux en Unix distributies gemeld. Een aantal hebben echter de melding genegeerd.

Men is nu nog volop bezig om de problemen die er zijn met de nieuwe OpenSSH versie op alle ondersteunde besturingssystemen te repareren. De deadline voor deze operatie zal op donderdagavond verlopen, waarna men mogelijk vrijdag een nieuwe OpenSSH versie uit zal brengen. In de loop van volgende week zullen dan de exacte details met betrekking tot de bug gepubliceerd worden alsmede een patch voor OpenSSH. Zodra de bug bekend is zullen er ook snel exploits verschijnen, zo is de verwachting:

There is an upcoming OpenSSH vulnerability that we're working on with ISS. Details will be published early next week.

[...] We've given most vendors since Friday last week until Thursday to get privsep working well for you so that when the announcement comes out next week their customers are immunized. That is nearly a full week (but they have already wasted a weekend and a Monday). Really I think this is the best we can hope to do (this thing will eventually leak, at which point the details will be published).

Customers can judge their vendors by how they respond to this issue.

Reacties (41)

[MikeN]

Volgens Theo de Raadt, een van de developers van OpenBSD en OpenSSH, is de bug al afgelopen vrijdag aan diverse producenten van Linux en Unix distributies gemeld. Een aantal hebben echter de melding genegeerd.

Om het nog leuker te maken, Theo de Raadt over Alan Cox (iemand die veel met de linux kernel te doen heeft ):

Some, like Alan Cox, even went further stating
> that privsep was not being worked on because "Nobody provided any info
> which proves the problem, and many people dont trust you theo" and
> suggested I "might be feeding everyone a trojan" (I think I'll publish
> that letter -- it is just so funny).

De hele bug wordt dus niet eens serieus genomen door sommige mensen. Dat terwijl hij toch zeer serieus lijkt.

[RIP-airco]

ik wil hier nu niet gaan flamen op open source projecten ...
maar uitspraken zoals deze van Alan Cox geven me toch niet echt bijzonder veel vertrouwen als het op de veiligheid van me server aankomt. Niet echt een model-voorbeeld van een behandeling van een BUG.

*mod*
typo fixed

[Carnifex]

Stel je voor dat het niet OpenSource was, dan was het misschien nog niet eens ontdekt. Of het was wel ontdekt, maar omdat er geen oplossing gevonden kan worden wordt het nog maar even niet aan iedereen verteld en dan maar hopen dat de mensen die er misbruik van willen maken er niet achter komen...

e afhandeling kan idd wel wat professioneler

[GiLuX]

je vergeet dat de meeste bugs door users worden ontdekt, niet door de ontwikkelaars van desbetreffend software pakket.

die ontwikkelaars zullen natuurlijk wel hun mond houden,
zover dat kan natuurlijk, want er hoeft maar een medewerker thuis zijn mond voorbij te praten en het is al te laat.

in de open source ontstaat er meteen een rel en is het meestal binnen een dag tot een week verholpen.

bij niet opensource bedrijven moet je altijd 2 dingen hopen:
1 dat de bug uberhaubt erkend wordt
2 dat er op korte termijn een patch wordt uitgebracht
(en dan denk ik idd aan meteen aan een niet nader te noemen software bedrijf uit redmond, USofA, die pas 25 jaar na oprichting dit soort dingen serieus zegt te gaan nemen)

[Anoniem: 58763]

Stel je voor dat het niet OpenSource was, dan was het misschien nog niet eens ontdekt. Of het was wel ontdekt, maar omdat er geen oplossing gevonden kan worden wordt het nog maar even niet aan iedereen verteld en dan maar hopen dat de mensen die er misbruik van willen maken er niet achter komen...

En wat is hierop tegen? als een exploit niet openbaar wordt gemaakt zijn er ook geen script kiddies die ermee aan de gang gaan.
Misschien zou het voor de opensource projecten voortaan wel wat slimmer zijn om niets te zeggen totdat er een oplossing is die voor iedereen werkt.

[MikeN]

Ik denk dat dit dan ook nog wel een staartje zal hebben.

Bij Apache is het gewoon netjes gegaan, maar zoals het hier bij SSH gaat, is het toch ff wat minder allemaal. Dit zou veel beter kunnen.

Alan Cox zal er achteraf zelf ook wel niet zo blij mee zijn dat hij dit heeft gezegd.

[The Noid]

Nouwja, bij de apache bug was zeker ook niet netjes. Daar werd de bug gewoon gepubliceerd zonder eerst apache op de hoogte te stellen, met een niet werkende patch erbij.

Er wordt nu misschien een beetje veel geflamed, maar er wordt ook alles aan gedaan om de veiligheid van ieders machine te waarborgen.

[MikeN]

Maar ten tijde van het publiceren van die bug was de ernst nog helemaal niet bekend. Dus in dat opzicht viel het wel weer mee.

De ernst van deze bug is even iets groter, omdat het hier gaat om een deamon die als root draait.

[AVL]

Over de uitspraken van Theo de Raadt kan anders ook nog een hoop gezegd worden. Ik weet niet hoeveel mensen hier de FreeBSD-security mailing list volgen, maareh... Vriendelijk is anders . Z'n antwoorden zijn kortaf of zelfs beledigend, en ik weet ook nog niet helemaal of ik het eens ben met deze manier van het bekendmaken van een bug.

[Anoniem: 12466]

Hmm...heb hem nog nooit op [e-mail] gezien Probeer es een OpenBSD lijst

Theo is idd "recht voor z'n raap" meestal...Vaak heeft ie echter wel gelijk. Daarbij kun je echt erg vaak om hem lachen...

Heerlijk als mensen er geen doekjes omheen winden

[Calypso]

Vanmorgen ook de bewuste mail van Theo gelezen, en aan dit stukje vallen me 2 dingen op waardoor niet Alan, maar juist Theo als de "verliezer" uit dit verhaal komt:

* "many people don't trust you, Theo"
* "Feeding everyone a trojan"

Sorry, maar als jij met beveiliging bezig bent, en dan een uitspraak doet van "Dan ga ik toch lekker zelf een trojan maken zodat mijn beweringen uit komen", dan is mijn geloof in jou minimaal gehalveerd. En dat is juist wat bij veel mensen het geval is.

Wie weet is deze hele gang van zaken wel een manier (A la Versatel) van Theo om andere OS bouwers te "dwingen" hem te helpen met coderen van het PrivSel stuk?

[Anoniem: 18254]

Eh... Nee.

Alan zei dat hij Theo niet vertrouwde, en dat de fixes die hij voorstelt misschien wel een Trojaans paard zijn. Een vreemd staaltje paranoia van Alan, aangezien hij OpenSSH zelf wel vertrouwt.

Theo zelf had geen enkel plan om een Trojaans paard te maken of te verspreiden.

[Anoniem: 29158]

te vinden op:
http://www.sigmasoft.com/~openbsd/archive/openbsd-announce/200206/msg00003.html

als ik dit zo lees is het probleem dat hij niet heeft verteld waar de bug zit, zodat de vendors ( linux distro's ) eerst kunnen zorgen dat ze een patch klaar hebben staan.

'huh, een patch klaar hebben staan ? moet openssh dat zelf niet doen dan ? ???'
jah... maar de oplossing van hun heeft een aantal konsequenties(ofzo), namelijk dat er veel minder als root wordt gedraaid. dat moet op OS level worden gefixed, en dus per vendor.

maarja, kennelijk willen de vendors eerst weten wat de bug is, wardoor een patch mogelijk NA de exploit komt... en das niet leuk bij ssh, ivb met een x aantal extra deface's

[DaMayan]

Toch weer lullig dat ze niet precies vertellen wat de bug is

[MikeN]

Als ze nu exact zouden vertellen wat de bug is, dan kan hij meteen geexploit worden, gevolg: veel systemen kunnen gehacked worden. Sommige systeembeheerders slapen ook nog, dus als ze meteen een patch uitbregen, samen met de details over de bug, zal nog lang niet iedereen de patch geinstalleerd hebben en zijn nog veel systemen vulnerable.

Waarom releasen ze niet meteen een patch? De bug lijkt heel serieus, je kan nl. root toegang krijgen op de computers. Als ze meteen een patch releasen, kun je door middel van een diffje vrij eenvoudig nagaan waar de fout zat. Nog niet iedereen heeft dan geupgrade, dus zal de bug op veel plaatsen nog geexploit kunnen worden.

Wat ze nu doen is dat ze eerst iets algemeens verbeteren (privilege seperation). Als dit aanstaat, wat vanaf versie 3.3 standaard het geval is, zal de bug niet meer exploitable zijn. De bug is er echter nog wel.
Als straks een groot deel van alle computers is overgestapt op 3.3 met privilege seperation brengen ze (waarschijnlijk volgende week maandag) versie 3.4 uit, waarin de echte fix voor de bug zit.
De crackers weten dat wel waar de fout zit, maar omdat veel computers als 3.3 draaien zullen ze hem niet overal kunnen toepassen.

Het gaat dus in 2 stappen: eerst privilege seperation, dan de echte patch.

[Confusion]

Als ze nu exact zouden vertellen wat de bug is, dan kan hij meteen geexploit worden,

De open source community is over het algemeen (terecht) tegenstander van security through obscurity. Blijkbaar geldt dat echter niet zo universeel als ze doen voorkomen... Als Microsoft dit zou flikken, zou iedereen moord en brand schreeuwen...

[MikeN]

Um, wat wil jij dan? Dat ze nu meteen maar even de bug openbaar maken?
Ik zou dat liever niet zien.

De details van de bug worden ook echt wel openbaar gemaakt hoor, dus dit is _geen_ 'security through obscurity'. Alleen wordt eerst de kans geboden om mensen even hun software te laten patchen.

Als je dit "slecht" vind, wat vind je dan van de standaard regel dat je softwarebedrijven eerst een week de kans moet geven om een bug te fixen, voor hem openbaar te maken?

Wees blij dat ze er even bijzeggen dat er een bug in zit. Zodat je meer gemotiveerd wordt om up te graden.

[MikeN]

Er zijn 2 OS'en waarop Priviledge Separation werkt: OpenBSD en NetBSD.

Uh, maak daar dan even "er waren" van want, ondertussen draait mijn Linux bak ook met Priviledge Separation hoor.

[jochemd]

Er zijn 2 OS'en waarop Priviledge Separation werkt: OpenBSD en NetBSD. OpenBSD is toevallig ook nog een geesteskindje van Theo de Raadt. Als Theo nu alles openbaar maakt, zal hem dat niet in dank worden afgenomen, omdat dan de helft van de OS'en waarop deze bug niet exploiteerbaar is ook nog eens van hem is.

Dan hoor je pas iedereen moord en brand schreeuwen: "Jij probeert iedereen van Linux/Solaris/whatever naar OpenBSD te laten overstappen."

* 786562 Yoshi

[TheLevel]

Blijkbaar is het eindelijk tijd dat er ook bugs in niet-MS software kenbaar gemaakt mogen worden... Niets is dus onfeilbaar. Ik moet wel zeggen dat het erg netjes is dat ze de volledige bug nog niet kenbaar maken maar enkel aangeven in welke richting dat ie zit, tot de bug gefixed is.
Dat is iets dat bij andere operating systemen nogal eens over het hoofd gezien wordt... Men komt een bug tegen en gaat hem dan breeduit uitsmeren op een of andere website, enkel om het bedrijf dat de software maakt(e) een slechte naam te geven... Vind ik wel erg spijtig...

[ACM]

Die bugs werden altijd al aangekondigd.

Bekijk de security lijst van openssh maar eens op [url="http://www.openssh.org."]www.openssh.org.[/url]

Toevallig zijn er nu alleen twee grote bugs in twee van de grotere projecten...

[MikeN]

Ik hoop dat je dit niet al te serieus meent.
Je doet nu net alsof de bugs in MS software ook maar normaal zijn.

Dit is 1 bug in apache en 1 bug in openssh. Deze bugs zitten er al jaren in, en worden nu eindelijk eens opgemerkt.

Microsoft krijgt het voor elkaar om, met name in IIS en IE, bij iedere nieuwe versie, weer nieuwe, grote, beveiligingsbugs te creëren.
Vervolgens duurt het soms nog zeer lang voordat een fix voor deze bugs beschikbaar is. Zo kon ik 3 maanden lang als admin inloggen op de terminal servers op school, simpelweg omdat MS nog geen fix beschikbaar had gesteld.

Er is dus wel degelijk een verschil in de aanpak van MS m.b.t. security bugs en de aanpak van de open source wereld.

[Anoniem: 3226]

Dit is 1 bug in apache en 1 bug in openssh. Deze bugs zitten er al jaren in, en worden nu eindelijk eens opgemerkt

En blijkbaar heeft niemand in al die jaren de source gelezen. Beetje jammer aangezien dat juist als de grote kracht van open source wordt aangedragen

[nhimf]

Volgens mij worden bugs al veel langer openbaar gemaakt dus dat bijv. linux niet onfeilbaar is was allang bekend. Tis alleen dat de bugs sneller opgelost worden dan bij ms.

edit:

ik geloof dat acm net iets eerder was

[mxcreep]

heeft niet echt veel met het wel of niet onfeilbaar zijn van linux te maken...
Als Adobe bugs in zijn software heeft zitten is dat toch ook niet Microsoft zijn schuld of wel soms ???

[deadinspace]

Blijkbaar is het eindelijk tijd dat er ook bugs in niet-MS software kenbaar gemaakt mogen worden... [...] Ik moet wel zeggen dat het erg netjes is dat ze de volledige bug nog niet kenbaar maken maar enkel aangeven in welke richting dat ie zit, tot de bug gefixed is.

Dat is common practise in de security wereld.

* Er wordt een exploit gevonden.
* De maintainer van de software wordt geïnformeerd, zodat deze met een fix kan komen (meestal wordt hier een week oid de tijd voor gegeven).
* Als de fix er is worden de vendors ingelicht en voorzien van de patch.
* De exploit wordt bekend gemaakt op bekende security-meldplaatsen (de mailinglist bugtraq bijvoorbeeld) en wordt bekend gemaakt door de vendor(s). Iedereen wordt aangeraden te upgraden/patchen naar de nieuwere versie, die op dat moment dus meteen beschikbaar is.

Dit gebeurt al jaren zo, met zowel closedsource als opensource software.

Alleen soms is er iemand die een exploit vind te lame om dit eerst bij de maintainer van de software te melden (apache exploit van een weekje geleden bijvoorbeeld).

En soms zijn de maintainers zo lam om de bug niet of pas heel laat te fixen.
Dit lijkt voornamelijk een trekje van de closedsource wereld te zijn, maar ook met opensource software is dat voorgekomen ( *kuch* wu-ftpd *kuch* ).

Niets is dus onfeilbaar.

Dat was -helaas- al langer bekend.

[DDX]

ook leuk als je dus nog linux 2.2 kernel draait :

http://bugzilla.mindrot.org/show_bug.cgi?id=285

[MikeN]

Dit is gewoon een RTFM bug. In README.privsep staat duidelijk:

On systems which lack mmap or anonymous (MAP_ANON) memory mapping,
compression must be disabled in order for privilege separation to
function.

Je krijgt in je logs gewoon een foutmelding over mmap, dus je weet dat je compression uit moet zetten.

Dus met 2.2.x kernel kun je ook gewoon upgraden hoor.

[DDX]

maar toch even opletten als je je machine upgrade en je draait kernel 2.2
compression uitzetten dan...

[Anoniem: 24330]

zolang je met iets als ipchains werkt valt het allemaal toch wel mee? Vaak weet je wel vanaf welke IP nummers of subnetjes de beheerders moeten kunnen inloggen. Dan laat je de rest toch niet toe?

[MikeN]

Bij echt grote servers doe je dit misschien niet, maar ik zit vaak op verschillende computers en andere gebruikers van mijn server ook. OpenSSH staat dus gewoon naar buiten toe open, voor alle ip adressen. (Nu even niet, ben aan het upgraden ).
Dus het kan in principe wel meevallen als je dat zelf wil. Maar als je toch maar van bepaalde adressen toegang toestaat, kun je ook wel telnet gaan draaien. Het enige verschil is dan dat de communicatie opgepikt zou kunnen worden.

[LuCarD]

Voor de minder oplettende mensen. In de Meuk tracker staat de reeds de update.

http://www.tweakers.net/meuktracker/2221

Misschien kan deze bij het artikel geplaatst worden?

[Anoniem: 32081]

Er wordt dus aangeraden om te upgraden naar versie 3.3 waarbij UsePrivilegeSeparation is ge-enabled. Komende maandag wordt echter versie 3.4 uitgegeven waarin de vulnerability zelf is gefixed. EIgenlijk is versie 3.3 dus een tussenoplossing.

[DDX]

3.4 is dus nu al uit

[Anoniem: 51493]

Idd. En het is het verstandigste om te upgraden. Er is ook een bug in PAM in gefixed en de echte bug is er ook in gefixed. 3.3 is remote wel exploitbaar alleen dan kom je in een chroot dankzij UsePriv.

Van OpenSSH.org:
The 3.4 release contain many other fixes done over a week long audit started when this issue came to light. We believe that some of those fixes are likely to be important security fixes. Therefore, we urge an upgrade to 3.4.

Meer gedailleerde info over OpenSSH/PrivSep: http://www.citi.umich.edu/u/provos/ssh/privsep.html

[RoadRunner84]

Deze nieuwe versie bevat onder andere een aantal verbeteringen voor de zogenaamde 'privilege seperation modus'. Wanneer SSH in deze modus wordt gebruikt is de bug niet 'exploitable'. Derhalve worden ook alle serverbeheerders aangeraden om deze nieuwe versie van OpenSSH te installeren en gebruik te maken van de privilege seperation modus.

[zeikmode]
het is separation, seperation bestaat niet
[/zeikmode]

[Sfynx]

Uit voorzorg heb ik poort 22 voor externe IP's dichtgegooid totdat 3.3 op m'n oude Gentoo server staat (compileren duurt even). Dit hele gebeuren geeft maar weer aan hoe alert systeembeheerders moeten blijven.