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 , , 51 reacties
Bron: Symantec, submitter: Wouter Tinus

Bij Symantec lezen we over een nieuwe worm voor Linux; Linux.Slapper.Worm. De worm maakt gebruik van een fout in OpenSSL, die een buffer overflow oplevert. Via deze bug krijgt Slapper het voor elkaar om een shell op een ander systeem te draaien. Veel distributies zijn doelwit; onder meer SuSe, Mandrake, Red Hat, Slackware en Debian. De eerste tekenen van de worm komen uit Portugal en Roemenië, waar op het moment ook al systemen zijn waargenomen die door toedoen van de worm DDoS-aanvallen uitvoeren. De technische beschrijving van deze nieuwe worm - die te voorkomen is door naar OpenSSL 0.9.6g te upgraden - ziet er als volgt uit:

LinuxThe worm attempts to connect on Port 80 and it sends an invalid GET request to the server to identify the Apache system. Once the worm finds an Apache system it will try to connect on port 443 to send the exploit code to the listening SSL service on the remote system.

The worm uses a Linux shell code exploit which will run only on Intel systems. This code requires the presence of the shell command /bin/sh in order to execute properly. The worm encodes its own source code named ".bugtraq.c" (thus only a "ls -a" command will show the file) with UU encoding, sends it over to the remote system and decodes the file. After this it compiles the file using gcc and runs the binary which will be called ".bugtraq". These file are placed in the /tmp directory.

Lees verder bij Symantec.

Moderatie-faq Wijzig weergave

Reacties (51)

De bug lijkt al langer bekend te zijn. Zoals het er uitziet zijn openssl 0.9.6d (en eerder) en versie 0.9.7beta2 (en eerder) gevoelig voor deze fout.

Ik gebruik gentoo linux (leuke distro voor de kenner) en die heeft sinds 14 augustus openssl 0.9.6e beschikbaar en sinds 29 augustus openssl 0.9.6g. In de comments voor de update voor 0.9.6e staat:
.

Ik weet niet hoe snel andere firma's hun Linux-spulletjes bijwerken, maar iemand er een beetje op let heeft niets te vrezen dus. ;-)
De bug is rond 30 juli al bekend geworden. Versie 0.9.6e is niet meer 'vatbaar' voor dit virus. De meeste distro's hebben al lang patches en updates voor deze bug. Een upgrade van OpenSSL impliceert vaak ook een aantal andere upgrades zoals bijvoorbeeld OpenSSH en mod_ssl.
Ik gebruik gentoo linux (leuke distro voor de kenner) en die heeft sinds 14 augustus openssl 0.9.6e beschikbaar en sinds 29 augustus openssl 0.9.6g.
Nou, 14 augustus is dus best laat, meer dan twee weken nadat de bug bekend is geworden.
Ik weet niet hoe snel andere firma's hun Linux-spulletjes bijwerken
Ik kan voor de andere distributies niet spreken, maar Debian had al op 29 juni een security update ervoor.
Goh, volgens mij bedoelen ze i386 systemen :P

Maar alle gekheid op een stokje, hieruit blijkt maar weer dat ongeacht het OS, het is belangrijk om de updates en securitysites in de gaten te houden.

Het valt mij wel op dat het gros der security bugs op linux-gebied zich bevinden in de 'veilige' verbindingen, denk aan SSH of zoals nu weer openSSL. Niet draaien dus, die services, tenzij het echt niet anders kan.
Het is meer zo dat de wormpies en exploits juist deze software targetten, omdat iedereen die heeft draaien (grotere kans). Daarnaast wordt deze software heel actief ge-audit door diverse groepen, en foutjes worden dus vaak bekend gemaakt. Een blackhat hoeft maar misbruik te maken van een van de vele foutjes die iedere keer gevonden worden.

Natuurlijk is het simpeler een buffer-overrun te vinden in een minder bekend en belangrijk pakket, maar dit draait op veel minder systemen, en veel minder vaak als root.

Daarnaast moet je als blackhat dan zelf gaan zoeken naar de bugs, omdat dit soort code niet door de rest van de wereld wordt geaudit.

[edit/add-on]
Tevens geld natuurlijk (voor de blackhats/script kiddies) dat een exploit/worm voor een 'secure' product als OpenSSL/Apache/SSH/etc zorgt voor een beter/cooler imago in de script-kiddie wereld dan een suffe exploit voor een of ander raar zelden gebruikt tooltje...
[/edit]

\[edit: spelling]
Jeetje, moet ik die pinguin weer laten ontwormen bij de dierenarts :)
tja, virusses aren't windows-only hé, dus eentje voor linux was te verwachten :+
Kusje, sommige Windows programma's maken ook gebruik van OpenSSL. Het heeft ook weinig met de Linux kernel te maken. Get a clue.
De bug is zo gezegd (voor RedHat) gefixt in openssl-0.9.6b-28.
Mocht dit in mijn post niet duidelijk zijn, dan wil ik dat nog wel benadrukken:
Update regelmatig je systeem. Zo voorkom je dit soort exploits.
Het misverstand waar ik op doel is niet of je je software moet updaten.
Het misverstand is dat je, zoals op diverse plaatsen wordt gesuggereerd, alleen 'veilig bent' als je naar 0.9.6g update.
Dit geldt bv wel als je de sources zelf hebt gecompileerd.
Niet als je gebruikt maakt van de packages (en deze regelmatig update...) die gebruikelijk zijn op je systeem en deze 1,5 mnd geleden gefixt zijn zoals de RPMs voor RedHat en Suse.
Ik vraag me toch sterk af waar de flames nu blijven.

Bij een worm die gebruik maakt van een lek in windows had er allang 'M$ sux0rz' en 'kut OS het zit vol met lekker, ze moeten eens leren coden' enz enz gestaan.
Je moet niet vergeten dat deze worm geen lek in Linux is maar in een third-party programma, OpenSSL.

Het zou hetzelfde zijn als ik bijvoorbeeld Netscape op m'n Windows2000 bak zou installeren en vervolgens blijkt er een beveiligingsfout in Netscape te zitten, dan ga je toch ook niet roepen: Dat #@$#4 Windows?
Een systeem dat Linux als hart heeft (de kernel) is modulair. Windows daarentegen is gewoon 1 groot systeem, waar je verder weinig aan kunt veranderen. Daarom is een vergelijking bijna niet te doen. Linux als kernel zal veel minder security issues hebben dan Windows, maar een Linuxdistributie misschien wel meer omdat er cd's vol software bijzitten.

De laatste tijd is OpenSSL (en SSL in het algemeen) wel vaak in het nieuws voor wat betreft security-issues. Wat ik juist zie is dat er bij veel van dit soort berichten flames komen dat Linux zuigt, terwijl Linux er in principe niks mee te maken heeft (hier nog niet gezien overigens, das weer positief).

Je kunt overigens niks zeggen over het aantal bugs in Windows. Je kunt immers niet in de sourcecode kijken. Wie weet houdt Microsoft (of andere mensen/bedrijven) wel vanalles stil. Wanneer de source open is, kunnen er meer mensen meekijken en bugs opsporen en verhelpen. Dat je dan ook een ietwat verhoogde kans loopt dat er een kwaadwillende een exploit voor gaat maken, alvorens iemand anders de bug ontdekt, weegt IMHO nooit op tegen de openheid en dat je er dus zeker van kunt zijn dat er geen bugs verzwegen kunnen worden.
Dan ga je toch ook niet #@!$ windows roepen?
Dat is dus het probleem, vaak gebeurd dat wel. Jammer genoeg. Windows is altijd de fout van alles (vaak) en bij Linux ligt het aan een 3th party prog, dat je moet hebben, voor bepaalde functionaliteit. Omdat je dit niet bij Linux bij moet kopen, wordt dat appart gezien van ... De Linux/windows groepen kijken hier dus heel anders tegenaan. (Linux groepen zeggen al makkelijk, ligt aan windows, maar linux is koning, dus doet een 3th party progger het vaud)

Edit --> Mag ik gokken dat jij bij de Linux-groep hoort?
Je zegt dat dit een fout is in een 3th party prog (goh, dat gebruik ik nou al te vaak :)), maar het wordt wel bij een stuk of 5 verschillende distro's meegeleverd. Het staat dus niet zo los van Linux, dat er genoeg keuze is ... (anders waren er vast geen 5 distro's die exact deze versie meeleverden).
En ja, ik vind windows geen slecht product.
nou eenvoudig toch? omdat er nu al een patch is ;)
Dat Linux er weinig mee te maken zou hebben en dat er al een patch is geloof ik allemaal wel.
Het punt dat ik duidelijk wil maken is precies wat RedSonic zei:
Dan ga je toch ook niet #@!$ windows roepen?
Dat is dus het probleem, vaak gebeurd dat wel. Jammer genoeg. Windows is altijd de fout van alles (vaak) en bij Linux ligt het aan een 3th party prog, dat je moet hebben, voor bepaalde functionaliteit. Omdat je dit niet bij Linux bij moet kopen, wordt dat appart gezien van ... De Linux/windows groepen kijken hier dus heel anders tegenaan. (Linux groepen zeggen al makkelijk, ligt aan windows, maar linux is koning, dus doet een 3th party progger het vaud)
Spijtig dan, je hebt niet gelijk want GNU/Linux is slechts een kernel. Windows is een kernel met van alles erbij dat klaar voor gebruik is: een OS. Het is hoogstens zo dat GNU/Linux distributies lek zijn. Het spijtige blijft de woordkeus: FreeBSD, OpenBSD, Windows etcetera zijn ook lek mits ze dit geinstalleerd hebben. En de BSD's zijn ook complete OSen :)
Spijtig dan, je hebt niet gelijk want GNU/Linux is slechts een kernel. Windows is een kernel met van alles erbij dat klaar voor gebruik is: een OS.
Ehm, nee. GNU/Linux is een OS, bestaande uit de GNU tools en libs (alleen basistools en libs, nodig om het systeem te laten draaien), en de Linux kernel.

Linux -> kernel
GNU/Linux -> OS

Daar draait dan weer een hele hoop andere software op die niet specifiek is voor GNU/Linux maar ook op andere OSsen zoals FreeBSD, BeOS (vaak) en Windows (minder vaak) draait.
Dus als je geen Apache draait, is er niks aan de hand?
Ik vind het niet erg duidelijk allemaal...

Verder zie je maar weer: als je je systeem niet goed onderhoudt/updeet, is het niet veilig, ongeacht je OS.
Als je geen https(443) draait zit je goed, in elk geval voor deze worm. Hoe het precies zit met een ssh shell account weet ik niet, maar ik vermoed dat je eerst moet zijn ingelogd voordat je van de bug gebruik kunt maken. Met apache is dat iets anders, omdat 'iedereen' een https verbinding kan maken.
Kortom: apache configureren op alleen http en/of je firewall rules aanpassen. Of ssl updaten natuurlijk.
Met apache is dat iets anders, omdat 'iedereen' een https verbinding kan maken.
Ook iedereen kan doorgaans een SSH verbinding beginnen. Op dat moment wordt gebruik gemaakt van SSL hoor.

Elk prog dat statischis gelinked met de SSL libraries is ook vulnerable en moet ook geupdate worden. Dus ook mod_ssl, apache-ssl, stunnel, sshd, ssh.

Je kunt zelf bins/libs checken met ldd en lsof.
apache configureren op alleen http en/of je firewall rules aanpassen. Of ssl updaten natuurlijk.
Updaten natuurlijk. En vooral SSL over HTTP (blijven) gebruiken daar waar nodig.
Elk prog dat statischis gelinked met de SSL libraries is ook vulnerable en moet ook geupdate worden. Dus ook mod_ssl, apache-ssl, stunnel, sshd, ssh.
hee prutser, deze worm werkt alleen op apache-ssl dus de ret is *niet* vulnerable. En je moet een systeem hebben dat al 2.5 maand geen beheer heeft gehad, want op 29 juni was er bij Debian al een auto-upgrade voor apache-ssl (en alle andere ssl progs)....
Ik weet niet zeker of het uitsluitend om Apache in combinatie met SSL-modules gaat.

Als je geen SSL-server op poort 443 draait heb je denk ik al helemaal niets te vrezen. Correct me if I'm wrong...
The worm uses a Linux shell code exploit which will run only on Intel systems
Gelukkig heb ik een AMD, maar ik ga de boel toch maar weer eens updaten. Het was anders toch nodig.

* 786562 Knaart
Volgens mij is je AMD net zo vulnerable als een Intel systeem hoor. Ze bedoelen hier waarschijnlijk x86, dus Intel, AMD, Cyrix, etc, maar niet SPARC, PA-RISC, MIPS, etc.
Zou kunnen, maar het kan net zo goed zijn dat het gaat om een exploit die gebruik maakt van een Intel-optimalisatie, zoals je die in GCC3.x.x kunt kiezen. Maar dat lijkt me inderdaad redelijk onwaarschijnlijk en ik denk dat ze inderdaad iets als 'Intel-compatible' bedoelen, omdat ze nog niet van 'x86' hebben gehoord :+
Het is een misverstand dat je per se moet upgraden naar 0.9.6g.
RedHat (en andere distributies) heeft bijvoorbeeld de gewoonte om niet simpelweg de laatste bleeding edge software aan te bieden via hun up2date tool maar om bugfixes te backporten naar de huidige software.
Zo is deze openssl bug 27 juli gefixt in openssl-0.9.6b-28
:
http://rhn.redhat.com/errata/RHSA-2002-155.html.
Meer informatie over deze bug:
http://online.securityfocus.com/bid/5363
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0656
http://slashdot.org/article.pl?sid=02/09/13/2315246

GET request zoals deze op een RedHat server met openssl-0.9.6b-28 langskwam:
210.248.*.* - - [13/Sep/2002:23:06:35 +0200] "GET / HTTP/1.1" 400 379 "-" "-"
ERROR:
[Fri Sep 13 23:06:35 2002] [error] [client 210.248.*.*] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /
Da's geen misverstand, dat behoor je weten als je die distributie draait.Hierbij is gewoon de oude OpenSSL versie gepatched (revisie 28) omdat ze bij o.a. RedHat en Debian op die manier hun distributies stabiel houden. Geen nieuwe features, alleen security en reliability fixes. Prima methode overigens, maar je moet wel upgraden natuurlijk! Niet naar -g maar wel naar -28 of wat de nieuwste revisie ook is.
Als linux fan vind ik het jammer dat deze exploit er is. In computerland zijn exploits als deze natuurlijk wel te verwachten.

Ik ben wel content met het feit dat het met upgraden te voorkomen is.

Nu hoop ik ook dat nieuwe fouten zoals deze in het vervolg worden opgespoord en verholpen voordat ze "exploit" kunnen worden.
In elk OS zitten bugs en exploits, maar bij unix/linux zijn het een veel kleiner aantal.

Daarnaast komt het zelden voor bij unixlike systemen dat via een exploit root acces krijgt tot het systeem. Ook worden er vaak zaken vereist om een exploit te laten werken. In dit geval dus de gcc compiler. Het moet bekent zijn wanneer je een server in productie omgeving installeerd dat je GEEN compilers mag installeren vanwege het risico op exploits en overbodige overhead. Compilen zou je altijd op een andere machine moeten doen.

Dus vandaar dat je bij exploits op linux/unix altijd goed moet lezen of het lek wel zo ernstig als vermeld. In dit geval zijn er ook vrij veel voorwaarden voor de exploit, maar toevallig voldoen veel machines aan de voorwaarden. Echter goed geconfigureerde machines zijn echter weer niet gevoelig...
Linux/unix heeft minder bugs
Weet je wel zeker dat dit zo is?

Het pakker Linux, waarbij praktisch niets bijgeleverd zit, is uiteraard een stuk kleiner dan een pakker windows, waar 1001 extra progs bijgeleverd worden. In absolute nummers zal linux/unix dus minder fouten hebben. Maar per aantal regels?

Hier stond een hele lange tijd terug al een artikel over op T.net, waaruit bleek dat windows helemaal zo slecht nog niet is ...
Hopen dat ze gevonden worden, voordat ze ge-exploit-ed worden
Nee, ik hoop gewoon dat de mensen die exploiteren, daar gewoon mee stoppen ... (onmogelijk natuurlijk).
En anders, dat het geexploiteerd word is niet erg, als je je systeem maar up-to-date houdt ...

edit-- > www.tweakers.net/nieuws/18672?highlight=bugs
Dus windows loopt nog wel een beetje voor. Maar ik denk (ik denk dus) dat dit komt omdat er in windows veel meer naar fouten word gezocht (om Microsoft zwart te maken). Als er in Linux/Unix naar wordt gezocht, zal dit vaker zijn om de fouten er ook uit te halen, die dus niet in dit rapportje komen.
Zoals ik al zei zijn bugs in andere operating systems vaak ernstiger. Ik doelde daarbij op met name op microsoft systemen. Ik noemde dit niet bij naam, omdat je standaard op tweakers dan meteen flaimebaits over je heen krijgt.

Een exploit op een Microsoft server leidt bijna altijd toe dzat de aanvaller meteen root rechten heeft. Erger nog, vaak zijn er geen speciale voorwaarden aan verbonden voor root access. Daarnaast zijn de exploits vaak kinderlijk eenvoudig uit te buiten. Een beruchte is de grove fouten in cgi scripting waarmee je op bijzonder eenvoudige wijze internet information servers kon kraken en systemen kon overnemen. Nu is het niet erg als zulke exploit 1x voor komt, maar het is elke keer weer raak met windows. Linux en unix systemen hebben daar gewoon minder problemen mee.
Overigens heb ik het idee dat de laatste tijd wat minder ernstige exploits gevonden worden bij microsoft dan eerst. Ik bend aar niet helemaal zeker van, omdat microsoft tegenwoordig zo min mogelijk meedeeld als deze gevonden worden.


note en totaal offtopic: Linux distro's komen standaard met nog véél meer programma's en tools dan bijv. Windows XP. Het grote verschil is dat je geheel vrij bent om de meegeleverde tools wel of niet te installeren of niet één te gebruiken. Je bent vrij in keuze van browsers, file managing tools, webserver, mail enz.
Je moet niet alleen dat artikel lezen, maar ook de commentaren, er waren een paar heel zinnige bij. En vergeet niet na te gaan wie dat onderzoek gefinancierd had en hoe het gedaan was.

Verder wil ik er in het bugs/leaks verband op wijzen dat MS/Windows aanhangers vaak kromme beredeneringen gebruiken (ik spreek van Windows/linux aanhangers in de zin van 'religieus overtuigd', anders heb ik het over MSwin of linux gebruikers...), namelijk dat natuurlijk veel meer virussen op het net zijn die windows machines aanvallen, er zijn er immers zoveel meer.

Dit is niet helemaal juist, er zijn namelijk meer linux machines bekend op het web, nl als webserver (dus kwa ip adres etc).
En toch zijn er meer (succesvolle) aanvallen op IIS servers, en zijn daar meer problemen mee.

(Het lijkt me voor crackers waarschijnlijk interessanter om 'iets groots' te doen, zoals een website defacen.)

Dit geeft wel aan dat de Open Source strategie zich allang bewezen heeft.

Van de andere kant, veel linux aanhangers zien niet in dat er wel degelijk mazen in het web kunnen zitten, die gebruikt kunnen worden.

Een goede sysop, linux of windows, moet nou eenmaal goed bijblijven en zijn systeem beheren, daar wordt hij voor betaald.
en deze is de schuld van Microsoft??? ""Een beruchte is de grove fouten in cgi scripting waarmee je op bijzonder eenvoudige wijze internet information servers kon kraken en systemen kon overnemen""

Zo lopen er toch heel wat rare types rond die echt niet weten waar ze over praten.

In de OS zelf zitten bij MS net zo weinig bugs als bij een kale Linux. De randprogrammatuur, al dan niet van derde partijen is een ander verhaal.
Als je veel applicaties bij je systeem mee wilt leveren dan krijg je dus ook veel potentiele bugs.

Linux distros hebben er net zoveel!
Het pakker Linux, waarbij praktisch niets bijgeleverd zit, is uiteraard een stuk kleiner dan een pakker windows, waar 1001 extra progs bijgeleverd worden. In absolute nummers zal linux/unix dus minder fouten hebben. Maar per aantal regels?
Ehm... 1001 extra progs? Dat lijkt mij minstens een factor 20 overdreven.

En bij GNU/Linux hangt het van de distributie af, maar bijvoorbeeld Debian Stable wordt geleverd met meer dan 8,500 packages (meer dan 10,500 zelfs voor Debian Unstable). En Debian levert voor al die packages dus ook nog eens uitstekende security updates (de fix tegen deze bug zit al sinds 29 juli in de Debian Stable security updates bijvoorbeeld).

Aangezien bij GNU/Linux meestal de bugs in al die software wordt vergeleken met de bugs in Windows zelf plus een paar populaire applicaties (Office, Outlook, IE en IIS bijvoorbeeld) kun je zeker concluderen dat GNU/Linux minder bugs heeft ja, en dat zulke exploits meestal *veel* sneller gefixt worden.
Gebruikt een ssl exploit bekend vanaf juni of juli ofzoiets.
Als je een apache server draait moet je de toegang tot gcc ontzeggen dan kent ie zn worm niet compilen.
daarom draait een webserver toch ook als "nobody" "web" of zo'n soort user?
Maar als user nobody, web of www-data kan apache doorgaans nog prima bij een compiler (zoals /usr/bin/gcc) hoor.
Als user nobody, web of www-data (of hoe de user ook heet) kan apache geen schade aanrichten, behalve daar waar hij schrijfrechten heeft (meestal alleen /var/www). Maar compilen kan hij gewoon.

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