Nyt hul i udbredt DHCP-klient: Tillader shell-injektion

Sikkerhedsbrist i DHCP-klienten dhclient kan give hackere root-adgang.

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.

Læs også: Hul i DHCP-klient til Linux kan give fuld kontrol med pc'en

Tidligere har firmaet haft problemer med en stack overflow-brist, der betød, at hackere kunne få adgang til administratorniveau.

Læs også: VMware tre måneder om at rette kritisk DHCP-hul

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (19)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Lundin

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.

  • 1
  • 0
Dennis Skovborg Jørgensen

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.

  • 0
  • 0
Peter Makholm Blogger

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.

  • 5
  • 0
Anders Johansen

@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...

  • 0
  • 0
Peter Makholm Blogger

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).

  • 0
  • 0
Jon Bendtsen

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.

  • 0
  • 0
Peter Makholm Blogger

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.

  • 1
  • 0
Lars Lundin

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.

  • 1
  • 0
Uffe Seerup

Men det er langt lettere bare at lade sit netværksudstyr klare problemet ved at bortfiltrere ikke-ARP relaterede broadcast-pakker.

Hvordan gør jeg det, hvis jeg fx. hedder McDonald og har en restaurant hvor en kedelig person har købt et rogue access point og han tager med ind og begynder at udstede inficerede DHCP svare til mine kunders tablets, mobiltelefoner og laptops?

  • 0
  • 0
Troels Henriksen

Og hvorfor kalder den en shell(!) med root privilegier?

Skal en proces som dhclient ikke blot prøve at skaffe en IP adresse og så notificere netværksinterfacet?

Det kræver root-rettigheder at sætte IP-adressen på netværksenheden. Det er selvfølgelig rigtigt, at det er en fundamental brist i Unix-sikkerhedssystemet at root er så grovkornet en ting.

  • 0
  • 0
Log ind eller Opret konto for at kommentere