Unreal IRCd distribuerte trojaner

Unreal IRCd distribuerte trojaner

Innleggav ak » tir 15.06.2010 9:05

Fri programvare distribueres gjennom mange ulike kanaler og man kan ikke ta det for gitt at det man installerer er det samme som utvikleren la ut på nettet. Det fikk de som lager Unreal (en Internet Relay Chat server) erfare, en av utgivelsene deres ble erstattet med en hacket versjon og har ligget ute på mange speil siden november 2009. Nøyaktig hva den uønskede koden gjorde er ikke klart, men hvis man kombinerer det med en svakhet i Linux så er det nesten ubegrenset.

Dette viser fire ting:
1) Selv om man står fritt til å se på koden, er det nesten ingen som gjør det.
2) Unreal må ha hatt en sikkerhetsbrist som har latt angriperen legge denne filen på et av speilen. Det kan fort skje, da speilene som regel er basert på frivillighet.
3) Man bør signere pakkene, helst med GPG, alternativt ihvertfall utgi MD5 og SHA1 checksums.
4) AppArmor og SELinux kan fungere som siste skanse for å begrense skaden av slike angrep.

Løsningen ligger primært i det tredje punktet. Når du bruker pakkesystemer som APT eller RPM så er alle pakker signert med PGP (Pretty Good Privacy, Gnu Privacy Guard er en slik implementasjon). Det vil si at man regner en tversum av hele filen og så signerer man denne. Signering involverer to nøkler, hvor bare distribusjonen har begge. Med den andre nøkkelen kan sluttbrukere sjekke at signaturen ble laget av noen som har den første nøkkelen.

Alt dette skjer automatisk, så hvis du har UiO som pakkebrønn, og en hacker klarer å legge en uekte fil på speilet hos UiO, så vil pakkehånteringsprogrammet ditt avvise den etter at den har blitt lastet ned. Dette beskytter også mot feil i overføringen.

Frittstående prosjekter kan gjøre det samme, og legge den offentlige nøkkelen sin ut på hjemmesiden slik at folk kan laste den ned. Mange legger allerede ut MD5 og SHA1 verdier. Disse er ikke helt sikre som signaturer, spesielt MD5 har vist svakheter, men det gjør det likevel mye vanskeligere å snike inn endringer, men de gjør det mye vanskeligere for en eventuell angriper. Torrent filer har forøvrig samme system innebygget for å forhindre at noen tukler med innholdet av filene.

Du kjører programmene som følger:

md5sum test.txt
11db0ca1b1f53b1a5e7ced1523a13d45 test.txt



sha1sum test.txt
9c9ef76f9bcd3a980e83e93446e30393e47a0075 test.txt


Husk at disse bare gir økt sikkerhet dersom de distribueres på en annen måte enn filene. Som regel er det best om de ligger rett på prosjektets hjemmeside.

Administrator
Brukerens avatar
medlem i 236 måneder
 

Re: Unreal IRCd distribuerte trojaner

Innleggav omaha » tir 15.06.2010 10:30

Her er en kommentar til denne historien:

http://www.itworld.com/open-source/1109 ... ce=smlynch
medlem i 204 måneder
 

Gentoo har RMD160, SHA1 og

Innleggav QtanJ » tir 15.06.2010 15:51

Gentoo har RMD160, SHA1 og SHA256. Det hjelper derimot lite når denne er laga av den kjeldekodeversjonen som har trojanar i seg. Dette fører faktisk til at dersom ein hadde lasta ned riktig versjon ville ein fått feilmelding om at pakka hadde feil checksum. Dette symptomet er fiksa no, men eg kan berre venta og sjå kva som skjer vidare.

UnrealIRCd og tilsvarande servarprogram bør derimot ikkje få lov til å kunne gjera så mykje galt. Dei bør køyre som brukarar som ikkje kan gjera meir enn dei må. Difor er det bra at det vert oppdaga her, og kan føre til strengare kontroll generelt.

Når eg faktisk vil lese kjeldekoden brukar eg som regel scm(cvs, svn, git, osb.).

diff -r path/to/release path/to/scm-tag-release burde derimot vera enkelt nok. Til og med i eit automatisk skript.
medlem i 209 måneder
 

Du har et viktig poeng, det

Innleggav ak » tir 15.06.2010 19:22

Du har et viktig poeng, det er kun trygghet i RPM og APT dersom de som lager pakker for distribusjonen gjør dette etter kunstens regler, og det skal man ikke ta for gitt.

Men hvis du kompilerer selv, og sammenligner mot SCM, hvorfor sjekker du da ikke bare ut fra SCMet? (Selvfølgelig bra at du kan fange opp ting som problemet beskrevet ovenfor, men dersom SHA1 og MD5 er tilgjengelig så er det antageligvis like bra.)

Administrator
Brukerens avatar
medlem i 236 måneder
 

Kommandoen var meint som ein

Innleggav QtanJ » tir 15.06.2010 19:39

Kommandoen var meint som ein illustrasjon på kor enkelt det hadde vore å forsikre seg mot slike feil som i tematittel. Det var einaste grunn til at eg tok det med.
medlem i 209 måneder
 


Returner til Artikler (Linux1)



Hvem er i Forumene

Registrerte brukere: Ingen registrerte brukere