Beveiligingsgat in rsync oorzaak recente open source-hacks

Secunia komt met het bericht dat een beveiligingsgat in rsync waarschijnlijk de oorzaak is geweest van de recente open source-hacks. Onlangs berichtten we al over de fout die toen nog onbekend was, en over de twee gehackte Linux-servers. Met deze rsync-hack is het voor kwaadwillenden mogelijk om de rechten van de rsync-server te krijgen en daarmee op andere systemen in te breken. Voor meer informatie over welke Linux-distributies hier kwetsbaar voor zijn, zie deze NewsForge-pagina. Secunia adviseert onder andere de chroot-functionaliteit te gebruiken om eventueel misbruik van dit beveiligingsgat tegen te gaan:

On December 1st, 2003, we discovered that the "Savannah" system, which is maintained by the Free Software Foundation and provides CVS and development services to the GNU project and other Free Software projects, was compromised at circa November 2nd, 2003. The compromise seems to be of the same nature as the recent attacks on Debian project servers; the attacker seemed to operate identically. However, this incident was distinctly different from the modus operandi we found in the attacks on our FTP server in August 2003. We have also confirmed that an unauthorized party gained root access and installed a root-kit ("SucKIT") on November 2nd, 2003.

Reacties (32)

[Anoniem: 61323]

Dit artikel slaat echt nergens op...

Er is echt compleet geen relatie tussen de kraak van Savannah en Debian, en die van Gentoo.

Iedereen doet maar een gok en trekt z'n eigen conclusies... Als je werkelijk wist wat er gebeurt was dan snap je dat de titel puur onzin is...

Debian servers waren gekraakt met een local exploit en gesniffed paswoord op een andere bak waarop geen rsync draaide...

Savannah is gekraakt met iets anders dan rsync, maar dat is nog niet publiek. (er draait niet eens rsync op mensen!)

[smoking2000]

Deze Rsync vuln. icm met de Linux kernel <2.4.23 || <2.6-test9 do_brk() vuln maakt het tot een voledige remote root compromise.

GNU, Debian, Gentoo allemaal slachtoffer

[Anoniem: 1322]

Damm... dit is echt niet lekker. Lijkt qua ernst op de RPC bug van Microsoft.

Geeft weer aan, dat systemen meestal zo veilig zijn zoveel als de beheerder aan veiligheid denkt

Deze bug was niet bekend dus neem ik aan dat je het niet op de systeembeheerders kunt afschuiven.

[Anoniem: 2141]

ware het niet dat _iedereen_ met windows 't RPC gat heeft (/had) en lang niet iedereen met linux last heeft van rsync gaten

[Anoniem: 2141]

die verhouding met slachtoffers / niet-slachtoffers bij windows ligt veeeeeeeel erger dan bij deze rsync situatie

[Ablaze]

Alleen mensen met Windows NT hadden/hebben hier last van.

[Anoniem: 66797]

ligt veel hoger OF is veel erger...

lagere school nederlands acht je dat al te beheersen...

maar goed verder is je punt duidelijk...

[Anoniem: 90138]

Het ligt veel hoger of het is veel erger. Bij lagere school-nivo Nederlands wordt je al geacht dat te beheersen. "maar goed" Is geen schrijftaal en al helemaal niet netjes aan het begin van een zin. Verder verwachten ze van lagere-school scholieren vaak ook dat ze iedere zin met een hoofdletter beginnen en met één punt eindigen ipv. drie en dat je niet een nieuwe paragraaf begint voor iedere zin.

Toch opvallend hoe iemand die aan zijn handle te zien een 30-jarige fan van een van de grootste schrijvers allertijden is die er bovendien om bekend staat een professor in de taal geweest te zijn zoveel ernstige fouten maakt bij het verbeteren van het taalgebruik van een ander.

[Anoniem: 94640]

Mandrake heeft al een patch klaar:
http://www.mandrakesecure.net/en/advisories/advisory.php?name=MDKSA-20 03:111

[Biazz]

Redhat heeft ook al een rsync fix uit. Via up2date, red-carpet of gewoon via ftp te krijgen. Zie: https://rhn.redhat.com/errata/RHSA-2003-398.html

maar in alle eerlijkheid, vrij weinig redhat systemen hebben rsync enabled (staat standaard uit). Dus de gewone redhat gebruiker was niet kwetsbaar. Hetzelfde geldt voor gebruikers van de meeste andere distros, dus zie 't niet te somber in, smoking2000

[Anoniem: 7750]

En maar blijven zeiken over Windows.... Linux heeft dus gewoon hetzelfde probleem... Om het nog maar niet te hebben over de "response tijd" waar zo over gezeken wordt....

[Tozz]

Niemand heeft gezegd dat Linux veilig is. Maar het is nou eenmaal zo dat in Linux minder critieke fouten zitten. En ja, nu zijn er toevallig 2 achter elkaar gevonden... Bad luck, maar dat maakt het nog geen onveilig systeem.

En wat is er mis met de responsetijd?

[deadinspace]

Om het nog maar niet te hebben over de "response tijd" waar zo over gezeken wordt...

Kernel brk() exploit:

20/11/2003: Enkele Debian machines gecracked (bron)
26/11/2003: Ontdekt dat de crackers root hadden verkregen door de brk() bug te exploiten. (bron)
28/11/2003: Linux 2.4.23 gereleased met fix voor de brk() bug (bron)

Van het bepalen dat de brk() bug exploitable was tot release nieuwe kernel met fix: 2 dagen. Patches waren al eerder beschikbaar.

Rsync exploit:

02/12/2003: Gentoo server gecracked (bron)
04/12/2003: nieuwe rsync versie released met fix (bron)

Van eerste compromise tot fix: 2 dagen. Van het moment dat bepaald was dat rsync de boosdoener was tot de release was dus nog korter.

Geen onaardige response times dus, aangezien die fixes ook eerst getest moeten worden enzo.

[SirBlade]

2 dagen, dat is nou niet bepaald uitgebreid getest imho.

Maar moet er nu ook niet op iedere server waar deze bug op aanwezig was en waar (nieuwe) source-code op staat, die sources helemaal worden nagelopen op backdoors enzo? Bij debian en Gentoo zijn ze op tijd betrapt, maar wie weet waren de servers van (bv) slackware en apache al een maand geleden gehacked en heeft de nieuwste versie daarvan nu en handige ongedocumenteerde extra ingang.

[yootje]

Haha, gaat het snel is het nog niet goed voor je.

Grapjas.

[Anoniem: 73130]

Bijna niemand draait rsync in server mode. Ik gebruik het veel maar altijd getunneld over een ssh verbinding. Die vergelijking met RPC is dus misplaatst, bijna iedere windows gebruiker had die RPC poort open staan.

Zullen we eens ophouden met dat gezeik over 'Over windows zeiken'? MS verdient miljarden aan het verkopen van een onveilig OS, hoeveel verdienen de Linux makers?

Je krijgt in ieder geval a lot less bagger for your buck...

[yootje]

Met het verschil dat er in Linux toch wel minder zitten als in Microsoft end e response tijd van Linux ech wel sneller is. Maar een OS 100% veilig maken is een illusie en in elk OS zitten dan ook wel beveiligingsgaten.

[Anoniem: 43136]

sorry ik volg je niet echt, 2 of 3 dagen geleden werd ontdekt dat een gentoo server gehackt was, men wist niet hoe dit had plaats gevonden, maar men had zulke goede beveiligings systemen in plaats dan men de stappen van de aanvaller kon nagaan, een nog onbekend probleem in rsync kon ontdekken aan de hand hier van, en de patch hiervoor releasen, in +- 3 dagen!!

dat is wel even wat anders dan microsoft, die een frontpage lek 3/4 jaar ongepatcht liet

[DataGhost]

wat zeur je over response tijd man... 3 dagen oid nadat dat lek bekend was (iig toen de 2e server gehackt was besloot ik te gaan kijke) was er via urpmi netjes een nieuwe kernel beschikbaar hoor... ff installe, reboote en ik kan weer... ik zie je probleem niet

[Anoniem: 82475]

hoe lang doet MS over een bigfix dan?

MS wil dat een bug pas naar buiten komt als er een fix voor is anders komen hackers op ideetjes... de waarheid lijkt mij meer dat MS er gewoon veel tijd voor moet nemen om zoiets te fixen. als je kijkt hoe lang sommige bugs in bv Word blijven zitten.

2 dagen voor deze fix is gewoon belachelijk bloedjesnel lijkt mij. a

[Oxi]

Ik heb nog niets gezien van de beveiliging van de 2.2 tree kernels zoals debian die standaard meelevert
Ik heb wel 2.6.0-test11-bk2 (dus van gisteren) maar op me server heb ik nog 2.2.20-idepci.
Voorlopig heb ik maar poort SSH gemapt naar me 2.6 bak en niet de 2.2 bak tot ik het zeker weet

[deadinspace]

Ik heb nog niets gezien van de beveiliging van de 2.2 tree kernels zoals debian die standaard meelevert

van debian-announce:

Linux 2.2.x is not vulnerable to this exploit because boundary checking is done before. It is also believed that Sparc and PA-RISC kernels are not vulnerable since user and kernel addresses are stored in different address spaces on these architectures.

Dus 2.2 kernels zijn niet vulnerable voor de brk() exploit. 2.0 kernels afaik ook niet trouwens.

[Anoniem: 73130]

Zolang je die vulnerable rsync niet naar buiten open hebt staan ben je veilig. De brk() exploit is alleen gevaarlijk als de boeven al binnen zijn.

[Anoniem: 71926]

Nu het ontdekt is, is het probleem ook al opgelost neem ik aan?

[twan1]

er was al een oplossing -> nieuwe kernel installeren of patchen

[deadinspace]

er was al een oplossing -> nieuwe kernel installeren of patchen

Dit gaat niet over de kernel, dit gaat over rsync. De oplossing is dus upgraden naar een versie van rsync waarin dit opgelost is (2.5.7 of de versies van distributies met backported security fixes).

[cold]

jep in versie 2.5.7 wel

[RIP-airco]

in een unstable kernel

[Anoniem: 93114]

erm, das rsync 2.5.7

[deadinspace]

in een unstable kernel

Versie 2.5.7 van rsync.

Wat kernels betreft, 2.5.7 is een onderhand behoorlijk oude versie uit de experimental tree... Daar gaan ze echt geen aandacht meer aan schenken hoor

[basb]

eh, rsync gebruikte ik jaren geleden al niet, omdat veiligheid niet echt toppie is van deze tool.

Kennelijk toch meer gebruikt dan menig beheerder lief is


Geeft weer aan, dat systemen meestal zo veilig zijn zoveel als de beheerder aan veiligheid denkt

[Anoniem: 97370]

Zo zie je maar weer, niet alle os(en) zijn perfect.....