FTP-server van GNU-project gehackt

C|Net meldt, evenals SlashDot, dat de FTP-server van de Free Software Foundation (FSF) is gehackt. Het betreft de server ftp.gnu.org welke gebruikt wordt voor het hosten van diverse GNU-projecten zoals automake, gcc en autoconf welke onder andere bij veel Linux-distributies worden meegeleverd.

Het grootste probleem is dat de cracker hierdoor toegang had tot de broncode welke als betrouwbaar wordt beschouwd en door veel mensen wordt geïnstalleerd en gebruikt. De cracker had de mogelijkheid om de broncode zo aan te passen dat een bepaald programma bijvoorbeeld een trojan-horse met zich meedraagt. Aangezien volgens een officieel statement van de FSF de hack al in maart van dit jaar heeft plaatsgevonden is er een kans dat ook oudere bestanden ongemerkt aangepast zijn. Ook de backups na die datum zijn mogelijk niet betrouwbaar, waardoor er een flink aantal bestanden met de hand opnieuw op de server moeten worden gezet.

De hack is verricht met gebruikmaking van de zogenaamde ptrace-bug in de Linux-kernel. De aanval op de FTP-server van de FSF is op de dag gebeurd dat deze ptrace-bug is bekend gemaakt. De ptrace-bug maakt het mogelijk om, wanneer men een gebruikersaccount op de server heeft, eenvoudig root-gebruikersrechten te verkrijgen zonder dat men hiervoor toestemming heeft. Om een herhaling van deze problemen te voorkomen worden alle bestanden op de GNU ftp-server voorzien van een GPG-handtekening door een betrouwbaar persoon:

The attacker compromised the project's servers to the root level, gaining complete control over the system, according to the GNU Project. The attack was carried out using an exploit that was revealed on March 17, and for which a patch only became available a week later. During that week, the intruder compromised the system and installed a piece of malicious code known as a Trojan horse, according to evidence found on the machine.

Reacties (65)

[EfBe]

los van het feit of je windows/linux aanhangt, het is wel slordig dat ze, nadat ze wisten van het lek (de patch voor het lek kwam pas een week na de ontdekking van het lek) gewoon die site open hebben gehouden, wellicht in de hoop dat het wel mee zou vallen. DAT is nog het trieste, kennelijk is de beheerder van die site niet de beste die je kunt krijgen.

[n4m3l355]

een OS project gaat constant door je kunt niet tegen duizenden.. miljoenen is zelfs waarschijnlijker van jongens.. ff niet we moeten wachten op een patch. je weet niet wanneer een patch komt en je hebt wel zoveel luitjes die eraan willen zitten. wat misschien wel een idee was om een backup van het geheel te draaien.. wat waarschijnlijk zoveel data is dat het niet gaat

[arnob]

welkom in de wereld van servers
kan je nou niet bedenken dat er wel meer situaties zijn waarin hele bedrijven kunnen sluiten als hun server(s) niet beschikbaar is (zijn)

[Verwijderd]

gewoon die site open hebben gehouden, wellicht in de hoop dat het wel mee zou vallen

Ook jij kunt niet lezen. Dat de bak gehackt was is onopgemerkt gebleven in maart. De patch kwam later uit dan de exploit.

[eamelink]

Hij kan wel lezen, maar jij snapt hem niet.

De exploit was bekend, dus hadden de systeembeheerders kunnen weten dat hun bak kwetsbaar was. Maakt niet uit of er al of geen patch voor is.

Ze dachten dus idd zoals Otis zegt, "het zal wel mee vallen." De andere optie zou zijn geweest om de software met de bug stop te zetten, alternatieven op te starten, wat waarschijnlijk heel ingrijpend zou zijn geweest, maar toch, bij zulke belangrijke services moet dat misschien wel.

[Verwijderd]

De exploit was bekend, dus hadden de systeembeheerders kunnen weten dat hun bak kwetsbaar was. Maakt niet uit of er al of geen patch voor is.

Je bak is altijd kwestbaar! Denk eens aan exploits 'in the wild'. Als iedereen zich elke keer als een advisory of exploit eerder dan een patch uit is gekomen druk moet maken dan heb je geen leven meer.

Hoe zij denken weet ik niet, want ik ben hen niet. Ik ga af op wat zij zeggen.

[sonix666]

Inderdaad, erg briljant hoe enorm vaak snel op Windows security bugs gezeken wordt, maar deze is net als de Windows RPC bug zeker niet mis!

[smooc]

Het is natuurlijk totaal onvergelijkbaar:

Je vegelijkt de bug (RPC) met een hack (ingebroken in GNU FTP server). Daarbij heeft de omvang van deze hack niet dezelfde orde van grote als die van de RPC bug.

Staan blijft natuurlijk dat het op z'n zachtst gezegd matig is dat de admin van die server het niet eerder hebben ontdekt. Zoiezo (hoewel het er in dit geval niet toe doet, de hack was local) is een FTP server een zorgenkindje.

[Domino]

Niet?

Misschien niet direct de hack zelf, maar wat dacht jij van eventueel aangepaste broncodes die door duizenden, misschien wel miljoenen mensen gecompileerd en gebruikt gaat worden?

[Tijger]

Dit is erger, men heeft maanden lang met een ongepatchte server sources verspreid die nu als verdacht moeten worden beschouwd.

Het gaat niet om de bug, het gaat om het feit dan men ruim 4 maanden lang deze machine blijkbaar niet gepatched heeft terwijl er sources op staan waarop men moet kunnen vertrouwen.

[jeroendekkers]

Het gaat niet om de bug, het gaat om het feit dan men ruim 4 maanden lang deze machine blijkbaar niet gepatched heeft terwijl er sources op staan waarop men moet kunnen vertrouwen.

Nee, de server was gekraakt voordat er een patch beschikbaar was. Als je het lekt daarna dicht dan blijft de rootkit er nog steeds op staan.

[Silentpuma]

Gepost door SmooC vrijdag 15 augustus 2003 - 17:52 Score: 3 (Interessant)
Het is natuurlijk totaal onvergelijkbaar:

Je vegelijkt de bug (RPC) met een hack (ingebroken in GNU FTP server). Daarbij heeft de omvang van deze hack niet dezelfde orde van grote als die van de RPC bug.

Staan blijft natuurlijk dat het op z'n zachtst gezegd matig is dat de admin van die server het niet eerder hebben ontdekt. Zoiezo (hoewel het er in dit geval niet toe doet, de hack was local) is een FTP server een zorgenkindje.

Jij draait zeker Linux op je bak

[Verwijderd]

Die RPC bug heeft tot gevolg dat Winows bakken remote te rooten en te crashen waren. De schade van de worm zien we morgen denk ik meer van.

Deze WuFTPd bug heeft tot gevolg gehad dat een handje vol FTPd's geroot zijn geweest... en dat terwijl deze FTPd niet meer veel gebruikt wordt. Mbt. GNU.org waarschijnlijk niks omdat er waarschijnlijk niks trojaned is. De enige impact is wat chaos bij een handje vol onwetenden die al in hun broek schijten als ze het woord 'hack' lezen [zonder verder te kijken -nofi.] en dat de FTPd + inhoud een tijdje plat ligt.

Nog steeds geen duidelijke verschillen volgens jou?

(ok dat had ik dus blijkbaar verkeerd gelezen het heeft niks met WuFTPd te maken maar met ptrace. Iig, da's een local; geen remote. Impact, relatief gezien stukken minder)

[berend_engelbrecht]

Dit is erger, omdat het lek in Windows gedicht kan worden (en al is), waarna het probleem minder wordt en verdwijnt zonder dat de gebruikers daar veel moeite voor hoeven te doen. Dat is een gewone bug zoals in elk besturingssysteem voorkomt. Het ergste was de te verwachten DDOS attack op windowsupdate.com, maar daar heeft Microsoft adequate (zij het wat drastische) maatregelen tegen genomen zodat die niet kan plaatsvinden.

Hier gaat het niet om de omvang van het lek, dat is heel klein, maar om de gevolgen. Die zijn veel erger omdat de vertrouwelijkheid van de code in het geding is en omdat er heel veel werk van de developers nodig zal zijn om de schade te herstellen. In feite zou een virus beter geweest zijn, omdat de schade die daar door aangebracht wordt meestal systematisch en dus eenvoudig op te sporen is (en zelfs vaak automatisch te herstellen, zoals bekend). Hier is een kwaadwillend persoon of personen in het geding geweest, die ook heel goed in staat mag worden geacht om zijn eigen sporen uit te wisselen.

[Verwijderd]

En dan al de linux gurus maar zeiken over de windows security huh

[RetepV]

Nou ben ik geen Linux goeroe, maar om nou gelijk triomfantelijk te gaan doen als er één keertje een lelijke bug in Linux zit lijkt me flamebait.

En dan nog. Bij Microsoft werken honderden testers aan het veilig maken van Windows. Die worden betaald en indirekt betaal jij die weer. Toch zijn ze ineffectief. Jij legt dus in feite geld neer voor weinig tot niks.

In het geval van Linux leg je geen geld neer en zitten er hooguit evenveel bugs in als in Windows. Waarschijnlijk zelfs minder.

Minder bugs wil trouwens niet zeggen dat de bugs ook minder heftig zijn...

[hardwareaddict]

Hallo,

je vergeet 1 ding.

Als iemand die al 10 jaar professioneel unix en ook professioneel linux gebruikt heb ik wel wat recht van spreken hier. Probleem na probleem onder linux altijd gehad. Alle oplossingen en progressies van linux waren voor 99% COMMERCIELE progressies.

Voorbeeld van progressie van gcc 2.95 naar 3.xx nu : COMMERCIELE lieden die betaalt door of SUSE of door REDHAT of door SGI of door AMD en door veel andere partijen, progressie geboekt hebben.

jawel het GCC team is totaal onbetaald hoor, maar de PROGRESSIE is volledig commercieel. Zo herinner ik mij van het onbetaalde team een 5tal pagina's met geblaat van wat ze verbeterd hadden van 2.95 naar 2.96. Ik ging op een aantal MB source code toen meten hoeveel van dat geblaat in werkelijkheid dus code changes inhielden.

DROEVIG WEINIG. Ik mat 0.01% effectiviteit. Dus de code per saldo werd ook niet sneller erdoor.

Nee toen de commerciele progressie. Hoppa 20% sneller gelijk.

Linux kernel. Ik heb jarenlang gepost over allerlei bugs in die kernel en compiler die voor belangrijke software alleen via allerlei knullige hacks valt op te lossen van de kernel die je gebruikers van maar moeten gebruiken.

Linus verontschuldigde zich, Alan Cox verontschuldigde zich dat het niet zijn pakkie aan was (wie dan wel????) en dat dit soort dingen lastig lagen in de SMP linux kernel.

De todo list had natuurlijk die changes allang sinds 1997 ongeveer en heeft die nog steeds want ze zijn nog niet uitgevoerd.

Controle krijgen over de kernel als je maar een login op het systeem hebt is helemaal niet zo moeilijk hoor. Er zijn wel meer bugs in de kernel als die in maart gepost. De enige reden dat die er niet uit gehaald worden is omdat er nog geen commerciele reden was om ze eruit te halen. Want het is een enorme rewrite van de kernel op multiprocessing/multithreading gebied.

Probleem is dat geheugen automatisch van gebruiker naar root permissie gaat zodra er iets mis is.

Nu worden dan ineens een hele berg bugs gefixed door commerciele inspanningen van met name IBM en SGI die al dan niet SUSE/Redhat betalen en/of zelf die changes maken.

Onderschat SGI niet als het gaat om de NUMA changes in de kernel.

IRIX van SGI draait al jaren op cc-NUMA machines natuurlijk en met x86-64 gaan die changes voor linux heel belangrijk worden zo die niet al belangrijk zijn.

Maar dit is werkelijk alle vlakken in de hele linux distributie kernel zo.

Alles wat ingewikkeld is, is commercieel geproduceerd.

Het voordeel van linux t.o.v. windows is dan ook niet het principe waarmee de software geproduceerd wordt, maar het principe van gratis gebruik ervan.

Het geleuter dat niet-commerciele inspanning progressie betekent is natuurlijk al veel gehoord uit studentenmond, maar totaal onjuist. Elke insider kan dat zo ontzenuwen. Bij deze.

MVG

[NiGeLaToR]

Wordt lid van CERT e.d. en je zult zien dat de bugs elkaar snel opvolgen. Alleen als je telt Windows vs Linux zijn er evenveel bugs, als je het splitst per distributie kom je lager uit.

Verder zijn er meer Windows gebruikers, meer hackers op zoek naar bugs en dus wordt er mee gevonden. Zeuren over de meeste bugs is irrelevant, wees blij dat er iig wat aan gebeurt.

Dat die machine gehackt is zonder dat ze het wisten is een redelijke blamage natuurlijk.

[NiGeLaToR]

Erm, ik zit midden tussen beide werelden en er komen echt vaak unix/linux bugs boven water in de volgende rootkit. Weet niet wat jij erger vind, of dat je pc na 60 uit gaat of omdat je ontdekt dat er een hele berg deamons op root draaien (zonder jouw wachtwoord). Tuurlijk zijn die er met windows ook, maar kom nou niet met het verhaal dat de open source wereld z'n bugjes eerder heeft dan er exploits zijn - das namelijk practisch gezien onzin.

Een goede beheerder patch z'n hele loon bij elkaar en dan nog moet je allerlei andere dingen bedenken om de echte hackers te slim af te zijn. Soms kan dat ook gewoon niet.

Weet je wat ik dom gelul vind, is dat men niet in ziet dat bugs geen direct resultaat van een slecht product zijn alswel een resultaat van een hele berg etters die op r00t geilen. 9/10 exploits hebben nix met de werking van het systeem te maken en zijn dus louter dingen waar je je tig jaar trug niet mee bezig hield. Magoed, je kent het gezegde he Ignorance is a bless...

[Room42]

Verder zijn er meer Windows gebruikers, meer hackers op zoek naar bugs en dus wordt er mee gevonden. Zeuren over de meeste bugs is irrelevant, wees blij dat er iig wat aan gebeurt.

Ooh ik vind dit onderhand zo'n dom geleuter aant worden! Het is toch wel heel duidelijk dat het bij microsoft echt niet goed zit!
Het gebeurt gewoon TE VEEL dat een bug eerder gevonden wordt door een hacker dan een debugger in Windows!

Ze zijn er wel mee aan het werk, maar ze zijn daar veel te laat mee!!

[Verwijderd]

Ik vind het wel een goed punt..
Nu is de stand in bugs gelijk (kan iets verschil zijn)..
Ik zou wel eens willen weten hoeveel er boven water komt als het aantal gebruikers gelijk zou zijn en dus ook het aantal hackers/crackers die zoeken in beide omgevingen..
Ik denk dat de meesten dan nog bedrogen uitkomen..
Er is trouwens iets van MS waar zover ik weet nog geen lek in is geweest.. DNS service.. kun je van Bind niet zeggen..

[Verwijderd]

En dan al de linux gurus maar zeiken over de windows security huh

WuFTPd. Zoek eens naar de geschiedenis van dat ding. Een van de oudste FTPd's, maar hij staat ook bekend vanwege een aantal local en remote vulnerabilities. Daarnaast is het niet zo dat deze 'default' wordt meegelevert bij distro's. Al tijden niet meer. Vroeger wel, ja. Dit in contrast met Windows waar wel van alles default wordt meegelevert en wel van alles default draait. Neem nou bijvoorbeeld MSIE. En nee, Mozilla installeren is niet de oplossing, want 3rd party programma's zoals Outlook en ICQ gebruiken MSIE dan nog steeds.

Ik snap dan ook niet waarom GNU.org voor deze FTPd heeft gekozen. Ik heb wel gelezen dat de bak niet zo'n hoge prioriteit had. Al met al is er voor distributies en self-compilers (a-la *BSD/Gentoo) weinig aan de hand vanwege MD5(/SHA1/RD160) en bovendien lijkt het er sterk op dat er niks is getrojaned, zie de analyse in het statement.

[jeroendekkers]

Mag ik vragen wat wu-ftpd met dit te maken heeft? De server is gekraat door de ptrace exploit, niet door een lek in de ftp daemon. Daarnaast draait de ftp van gnu.org geen wu-ftpd maar de GNU ftpd uit inetutils zover ik weet.

[Jit]

Van een andere post op /. begreep ik dat het vsftpd is dat er op draait; vs als in very secure.

Daarnaast was het een shellaccount waarmee de hack is uitgevoerd en anders dan dat het om de ftp-server van het GNU-project gaat, heeft het ftp-protocol of een ftpd er niks mee te maken dat ik weet.

[Verwijderd]

Hoe dom is het dan ook niet om eerst bekend te maken waar het lek zit en pas een week later een patch beschikbaar te stellen....

[Jit]

Local root-exploits zijn alleen vervelend als je untrusted users op je server toelaat. Of als je user accounts opde server hebt draaien waarvan op eoa wijze een kwaadwillende het wachtwoord van heeft weten te achterhalen.

Het is dus een afweging van tussen gebruikersvriendelijkheid en beveiliging. Als het laatste altijd zou overwinnen dan waren er ook geen ISPs meer met telnet servers, of gebruikers die Outlook Express als emailclient mogen gebruiken...

Of het in dit geval om een echte hack ging of een gebruiker die kwaadwillend is geworden is nog niet helemaal duidelijk heb ik begrepen. Iig hebben ze nu maar voor beveiliging gekozen en (tijdelijk) alle shell toegang tot de machine afgesloten.

* 786562 Jit

[Mac_Cain13]

Dan ben je gewaarschuwd en kun je een firewall instellen, zelf een patch schrijven of je server down brengen zodat je niet gepakt kunt worden.

[iKiddo]

Firewall instellen tegen een shell-bug -> LOL!
Server down brengen is ook niet echt een optie.
Zelf een patch schrijven? Ik denk dat de kans groter is dat de bug dan geexploit wordt dan dat de patch sneller geschreven zal zijn.

[Verwijderd]

Om een herhaling van deze problemen te voorkomen worden alle bestanden op de GNU ftp-server voorzien van een GPG-handtekening door een betrouwbaar persoon

Moet dit niet PGP zijn? (Pretty Good Privacy)

[NoControl]

GPG is de (gratis) GNU-versie van PGP...

Van de website:

GnuPG is a complete and free replacement for PGP. Because it does not use the patented IDEA algorithm, it can be used without any restrictions. GnuPG is a RFC2440 (OpenPGP) compliant application.

edit:
Too slow

[Verwijderd]

GNU Privacy Guard

[Mayco]

waarom komt dit nieuws nu pas uit als de hack al in maart heeft plaatsgevonden?

[Verwijderd]

Het statement dat op de FTP site staat verklaart waarom het nu pas bekend is:

A root compromise and a Trojan horse were discovered on gnuftp.gnu.org, the FTP server of the GNU project. The machine appears to have been
cracked in March 2003, but we only discovered the crack in the last week of July 2003.

Wat daarna gebeurde enzo, ga ik niet allemaal nablaten en quoten dat kun je in het statement lezen in het nieuwsartikel staat de link.

(En T.net is trouwens enkele dagen 'te laat'. Wat er is gebeurd in de tussentijd, nogmaals, dat kun je lezen.)

[egeltje]

Het beroerde is niet _dat_ ze gehacked zijn, maar dat het vijf maanden geduurt heeft vor ze door hadden dat er een trojan op het systeem aanwezig was.

Daarnaast beschouwen ze access tot de code als 'vertrouwelijk'. Het grote argument dat iedereen voor Open Source gebruikt, is dat iedereen de code kan controleren. Nu kunnen ze zelf de daad bij het woord voegen en kijken hoe betrouwbaar die stelling is.

Het lijkt me sterk dat GNU afhankelijk is van een ftp server voor sourcecode beheer, dus een compromise is redelijk snel en simpel te herstellen door een rebuild vanuit un CVS...

[Verwijderd]

Het beroerde is niet _dat_ ze gehacked zijn, maar dat het vijf maanden geduurt heeft vor ze door hadden dat er een trojan op het systeem aanwezig was.

Huh? Een rootkit bedoel je?

De source is naar alle waarschijnlijk niet getrojaned/backdoored.

Daarnaast beschouwen ze access tot de code als 'vertrouwelijk'. Het grote argument dat iedereen voor Open Source gebruikt, is dat iedereen de code kan controleren. Nu kunnen ze zelf de daad bij het woord voegen en kijken hoe betrouwbaar die stelling is.

Grapje zeker? Dat werkt iets anders. Jij mag best iets toevoegen in de source, jazeker. Dat mail je dan naar een developer. Die reviewed het, en dan voegt-ie het toe. Zo kun jij code toevoegen. Als je daadwerkelijk vaak iets toevoegt en er ontstaat een band dan krijg je CVS access. Wellicht bestaan er andere, soortgelijke manieren maar het principe lijkt me duidelijk: je kunt iets toevoegen, en je kunt de source bekijken en verspreiden maar direct aanpassingen maken: nee. Zou leuk zijn, ff wat UNIX code erin zetten, dan naar SCO mailen, en dan gaat SCO ze aanklagen haha

Het lijkt me sterk dat GNU afhankelijk is van een ftp server voor sourcecode beheer, dus een compromise is redelijk snel en simpel te herstellen door een rebuild vanuit un CVS...

Mja. In het statement staat de functie van de FTPd en de bak. Het komt er op neer dat de projecten op de bak in die mate regelmatig geupdate werden (gedevved werden) dat er geen backups van waren.

[iKiddo]

het is simpeler om gewoon de MD5 sums te checken, dat doen ze dus ook.

[kodak]

Nou, zo simpel was dat dus niet. Die checksums die op de server stonden gaven geen garantie gezien de hacker ook de mogelijkheid had om deze te hergenereren wanneer hij/zij een bestand had aangepast. De originele checksums waren de enige garantie, die dus bij de maintainers van de software vandaan gehaald moet worden. Vandaar dat ze ook besloten hebben om per 1 aug. die checksums door de maintainers te laten signeren en zo de herkomst te waarborgen.

[stunn0r]

Daarnaast beschouwen ze access tot de code als 'vertrouwelijk'. Het grote argument dat iedereen voor Open Source gebruikt, is dat iedereen de code kan controleren. Nu kunnen ze zelf de daad bij het woord voegen en kijken hoe betrouwbaar die stelling is.

droppie... ze beschouwen de toegang tot de code niet vertrouwelijk ze beschouwen de code als _betrouwbaar_ als in dat je de code kan vertrouwen
oftewel dat hij schoon is..

Het grootste probleem is dat de cracker hierdoor toegang had tot de broncode welke als betrouwbaar wordt beschouwd en door veel mensen wordt geïnstalleerd en gebruikt.

en daarnaast zijn het ook nog is woorden van de poster van dit artikel.. want GNU zal wel geen officiele verklaring in het nederlands afleggen.

maar dat ze er 5 maanden over doen om er achter te komen dat ze gehacked zijn is eigenlijk wel triest ja

[iKiddo]

Nou, zo simpel was dat dus niet. Die checksums die op de server stonden gaven geen garantie gezien de hacker ook de mogelijkheid had om deze te hergenereren wanneer hij/zij een bestand had aangepast. De originele checksums waren de enige garantie, die dus bij de maintainers van de software vandaan gehaald moet worden. Vandaar dat ze ook besloten hebben om per 1 aug. die checksums door de maintainers te laten signeren en zo de herkomst te waarborgen.

Dat weet ik, maar het gaat erom dat ze niet de hele source code door hoeven te spitten:

Het grote argument dat iedereen voor Open Source gebruikt, is dat iedereen de code kan controleren. Nu kunnen ze zelf de daad bij het woord voegen en kijken hoe betrouwbaar die stelling is.

[jep]

Het is al veel eerder in het nieuws geweest.

[Illusion]

Gek dat dat nieuws nu pas hier bekend is.... Ik wist het eigenlijk al een paar dagen

Ik vraag me af of veel GNU projecten vanf die server gemirrored zijn... Ik heb nl nogal wat gedownload de laatste tijd, maar nooit van specifiek die site. Zou ik nu toch corrupte code kunnen hebben???

[Mac_Cain13]

Gek dat dat nieuws nu pas hier bekend is.... Ik wist het eigenlijk al een paar dagen

Dan had je het moeten submitten! Had het hier eerder gestaan. Nu gaat Yep er met de eer vandoor.

Ik vraag me af of veel GNU projecten vanf die server gemirrored zijn... Ik heb nl nogal wat gedownload de laatste tijd, maar nooit van specifiek die site. Zou ik nu toch corrupte code kunnen hebben???

Zou kunnen als een mirror ff zijn files geupdate heeft met behulp van de gehackte server. Je kunt natuurlijk straks, als de broncode gecheckt is, ff deze onderdelen updaten. Is wel zo veilig.

[Matthijs Hoekstra]

En hoe weet je dat die Mirror de 'goede' bestanden heeft?

Probleem is dat niemand kan 'garanderen' wat de juiste bestanden zijn.

[berend_engelbrecht]

Je weet zeker dat die mirror dezelfde bestanden heeft als de centrale server, omdat die zeer regelmatig geupdate worden. Daar hebben ze nou die MD5 hashes voor, zodat je snel kan zien wat veranderd is en automatisch kan synchroniseren.

Dus als een bestand op de centrale server gehackt zou zijn, weet je zeker dat die mirror ook niet goed is, behalve als hij voor maart gestopt is om de boel te mirroren.

Alleen als de developers externe kopieen van hun projecten hebben gehouden onafhankelijk van het centrale code repository heb je kans op een zekere correctie. Voor een groot project is het echter erg lastig (en geen good practice) om buiten CVS om te werken. Een beetje code project heeft al snel een paar honderduizend regels code, daar heeft niemand volledig zicht meer op, zelfs niet als je vanaf dag 1 bij de ontwikkeling betrokken was. Ik spreek uit ervaring.

[CumpsD]

Behalve de developers zelf hoop ik?

[Verwijderd]

nou ik kan me niet voorstellen dat iemand zo dom zou zijn om zijn main opslag van source code op een ftp te houden wat betekent dat wat er wel op de ftp staat een copie is van het origineel

dus ik snap het moeite niet hoor purge de ftp patch de leak upload original software en voila je weet dat alles weer goed is

dat ze de moeite nemen om alles weer te checken is achtelijk

[zeroxcool]

Kan goed zijn dat die FTP gekoppeld is aan CVS. Dan kan ik me eigen goed voorstellen dat alleen in die omgeving alleen de source te vinden is...

[Sfynx]

Als er gerommeld is met de code, is dit echt heel erg. Bijvoorbeeld Bash veranderen, zodat deze een backdoor installeert zodra het als root wordt uitgevoerd.

*hopelijk kunnen ze straks met zekerheid zeggen dat de code niet veranderd is*

[Verwijderd]

GNU-monks work

Wel vreemd dat onbetrouwbare mensen een useraccount op z'n server hebben.

[G33rt]

als iemand betrouwbaar lijkt en dus al een account heeft, en hij wil een grap uithalen of koestert iets tegen iemand, kan ie het wel misbruiken. zelfs de meest betrouwbare mensen kunnen omslaan hoor

[The - DDD]

Precies, de meeste systemen worden gehacked van binnenuit. Iemand heeft een of andere vorm van toegang tot het systeem nodig om vanuit te gaan werken.

De leuke verhaaltjes van een wachtwoord raden op basis van toeval kan toegepast worden, maar iedere zichzelf respecterende systeembeheerder zorgt ervoor dat een bepaald ingang naar het systeem volledig geblokkeerd word zodra er verdachte activiteit plaats vind. Tig mislukte logins binnen een korte periode valt op.