Nyt hul i udbredt DHCP-klient: Tillader shell-injektion
DHCP-klienten dhclient fra Internet System Consortium (ISC) er ramt af et nyt sikkerhedshul.
Denne gang er der tale om en fejlagtig filtrering af metadata i serversvarfeltet.
Konsekvensen er, at DHCP-servere får mulighed for at injicere kommandoer, der vil kunne give hackere adgang til systemet på administratorniveau. Det skriver The H.
DHCP-klienten er open source-software og benyttes i mange Linux-distributioner og på UNIX-platformen.
Fejlen betyder, at det ved brug af falske hostnavne - afhængig af operativsystemet og hvilke kommandoer som dhclient-scriptet udfører - bliver muligt at injicere kommandoer direkte til systemets shell og eksekvere dem.
Et succesfuldt angreb kræver dog imidlertid, at der er en kompromitteret eller uautoriseret DHCP-server til stede på det lokale netværk.
Ikke første gang
ISC har udsendt opdateringer, der skulle løse problemet på de berørte udgaver af dhclient, der indbefatter version 3.0.x til 4.2.x.
Firmaet oplyser desuden, at brugerne som et alternativ kan deaktivere evalueringen af hostnavne i scriptet, eller ved at tilføje en ekstra linje kode. Anvisninger til det kan findes på ISC's hjemmeside.
Som Version2 tidligere har skrevet, så er det ikke første gang, at den populære DHCP-klient har haft problemer med sikkerheden.
Tidligere har firmaet haft problemer med en stack overflow-brist, der betød, at hackere kunne få adgang til administratorniveau.
Kommentarer (16)
Så vil jeg lige tillade mig at opsummere henover en række andre debattråde... Hvis man skal have et sikkert system skal man vælge *nix, det er nemlig kun i Windows der er sikkerhedshuller :D
Hvem søren har dog bildt dig det ind? Tror du ikke snarere du tænker på Virus og malware, som sjældent forekommer på Linux platformen?
Vigtige komponenter til Linux platformen har skam også af og til sikkerhedshuller.
Anders: Hvis du søger lidt på http://www.exploit-db.com/ kan du se at der er bunkevis af exploits til *nix også. Primært til Linux, men også en del til Solaris og OSX, og herefter *BSD, AIX, HPUX m.v.
Ja, er det ikke mere bekymrende med Linux-baserede routere, som kører en DHCP-klient op mod deres ISP?
Det tager typisk også langt længere tid at få updateret routere, end PCer/laptops med moderne Linux-distributioner.
hjemme plastic router køre ikke ISC dhcp men bruger dhcp client i busybox, så det er ikke aktuelt.
Ja, er det ikke mere bekymrende med Linux-baserede routere, som kører en DHCP-klient op mod deres ISP?
Antallet af ISP'er med interesse i at hacke deres kunder må vel antages at være nogenlunde begrænset.
Folk der har sat deres laptop[*] op til ukritisk at benytte megafamilierne linksys, d-link og zyxels trådløse familinetværk med sporadisk dækning gennem de fleste byer har nok lidt mere at frygte.
[*]Eller smartphone, i princippet. De bruger nok ikke ISCs klient.
Bruge dette exploit på min skole, da der er flere Linux hosts på netværket, og det ville ikke være særlig svært for mig at sætte en DHCP server op på netværket, og håbe på den svare hurtigere end skolens dhcp.
Helt basalt giver rogue DHCP servere mulighed for alskens man-in-the-middle angreb. Så hvis man tillader at fremmede DHCP-servere opererer på ens netværk, så er man allerede kompromiteret, det aktuelle sikkerhedshul eller ej.
Selvfølgelig er den slags sikkerhedshuller da bekymrende. Men primært fordi det så tvivl om den generelle kvalitet af et centralt stykke software.
@Lars Sommer
Jeg er qua hvad jeg laver til daglig udemærket bekendt med at alle platforme har sikkerhedshuller i forskellige afskygninger, og at alt kan kompromiteres af den som besidder vijlen dertil...
Derfor ved jeg også at man ikke nødvendigvis er mere sikker blot fordi man har valgt et *nix produkt, det handler lige så meget om at lave en korrekt opsætning og nedlåsning af det pågældende system for derved at reducere den attack surface det måtte have... Men intet system er 100 % sikker...
Mit indlæg var ment som en provokation til de personligheder herinde som messer at man skal vælge *nix hvis man vil være sikker...
Hvorfor kan man ikke kryptografisk signere DHCP? eller det kan man sikkert allerede, men hvorfor er det ikke mere udbredt?
Nu da jeg får nærlæst advisoriet (og artiklen) så ligner det en fejl der trivielt kunne have været løst ved at bruge execve(2) direkte istedet for system(3)?
POSIX mangler vist en library funktion der tager argumenter som execve(3) men fork'er og wait'er som system(3).
Kan det mon overhovedet lade sig gøre ?
Man skal vel så levere DHCP serverens public key ud på alle maskiner først, for de kan ikke slå den op i diverse key databaser, for det kræver netværk...som jo konfigureres via DHCP.
Eller tager jeg helt fejl ?
Kan det mon overhovedet lade sig gøre ?
Ja da. Du kender jo heller ikke en httpS servers nøgle før du forbinder dig til den. Den er bare signeret af en anden nøgle du stoler på. Eller også er det lige som SSH hvor du bliver spurgt om du vil stole på nøglen.
Min ide var at du skulle kunne konfigurere din laptop til at reagere forskelligt alt efter hvilket netværk du var på. Forestil dig en firma computer hvor du kunne definere den til at overskrive (dekrypterings nøglen til) de superhemmelige data hvis den blev startet på et netværk hvor der ikke er en DHCP server som du har tillid til? Eller at den bare skal ignorere alle andre end signerede DHCP servere.
Ja da. Du kender jo heller ikke en httpS servers nøgle før du forbinder dig til den.
Nej, men vi kender et globalt unikt navn for serveren som vi kan bruge i en certifikat-kæde. Den måde DHCP bruges på kan vi ikke altid på samme måde på forhånd vide hvem der er authoriseret til at uddele den slags information.
Hvis vi accepterer noget prækonfiguration (en liste af authoriserede DHCP-servere) eller brugerinteraktion (spørg brugeren om serveren er authoriseret), så kan man løse det med den model du foreslår.
Metoden er basalt set beskrevet i RFC3118.
Men det er langt lettere bare at lade sit netværksudstyr klare problemet ved at bortfiltrere ikke-ARP relaterede broadcast-pakker.
Antallet af ISP'er med interesse i at hacke deres kunder må vel antages at være nogenlunde begrænset.
Ja, det kan være. Men en ISP kunne jo blive kompromitteret, udefra eller af en medarbejder.
Forresten så beyndte Debian at tilbyde et patch til CVE-2011-0997 fra d. 10. april. Ubuntu tilbyder det også nu.

