For noen dager siden ble nyheten gitt ut at i C-standardbibliotekene uClibc og uClibc-ng, brukt i mange innebygde og bærbare enheter, en sårbarhet er identifisert (med CVE ennå ikke tildelt), som tillater substitusjon av dummy-data i DNS-cachen, som kan brukes til å forfalske IP-adressen til et vilkårlig domene i cachen og omdirigere forespørsler til domenet til angriperens server.
Om problemet nevnes at dette påvirker ulike Linux-fastvare for rutere, tilgangspunkter og IoT-enheter, så vel som innebygde Linux-distribusjoner som OpenWRT og Embedded Gentoo.
Om sårbarhet
Sårbarhet skyldes bruk av forutsigbare transaksjonsidentifikatorer i koden for å sende forespørsler av DNS. DNS-spørrings-IDen ble valgt ved ganske enkelt å øke telleren uten ytterligere randomisering av portnumrene, som gjorde det mulig å forgifte DNS-cachen ved forebyggende å sende UDP-pakker med falske svar (svaret vil bli akseptert hvis det kommer før svaret fra den virkelige serveren og inkluderer riktig identifikasjon).
I motsetning til Kaminsky-metoden som ble foreslått i 2008, er det ikke engang nødvendig å gjette transaksjons-IDen, siden den i utgangspunktet er forutsigbar (i utgangspunktet er den satt til 1, som øker med hver forespørsel, og ikke velges tilfeldig).
For å beskytte deg selv mot ID-gjetting, spesifikasjonen anbefaler videre bruk av en tilfeldig fordeling av nettverksportnumre opprinnelsen som DNS-spørringene sendes fra, noe som kompenserer for den utilstrekkelige størrelsen på IDen.
Når portrandomisering er aktivert, for å danne et dummysvar, er det i tillegg til å velge en 16-bits identifikator også nødvendig å velge nettverksportnummeret. I uClibc og uClibc-ng ble slik randomisering ikke eksplisitt aktivert (når binding ble kalt, ble en tilfeldig kilde UDP-port ikke spesifisert), og implementeringen var avhengig av operativsystemkonfigurasjonen.
Når portrandomisering er deaktivert, bestemme hvilken forespørsels-ID som skal økes, er merket som en triviell oppgave. Men selv i tilfelle av randomisering, trenger angriperen bare å gjette nettverksporten fra området 32768-60999, som han kan bruke massiv samtidig sending av dummy-svar på forskjellige nettverksporter for.
Problemet har blitt bekreftet i alle gjeldende versjoner av uClibc og uClibc-ng, inkludert de nyeste versjonene av uClibc 0.9.33.2 og uClibc-ng 1.0.40.
"Det er viktig å merke seg at en sårbarhet som påvirker et standard C-bibliotek kan være ganske kompleks," skrev teamet i et blogginnlegg denne uken.
"Ikke bare ville det være hundrevis eller tusenvis av anrop til den sårbare funksjonen på flere punkter i et enkelt program, men sårbarheten vil påvirke et ubestemt antall andre multi-leverandør programmer konfigurert til å bruke det biblioteket."
I september 2021 ble informasjon om sårbarheten sendt til CERT/CC for koordinert array-forberedelse. I januar 2022, problemet ble delt med mer enn 200 produsenter knyttet til CERT/CC.
I mars var det et forsøk på å kontakte vedlikeholderen av uClibc-ng-prosjektet separat, men han svarte at han ikke kunne fikse sårbarheten selv og anbefalte offentlig offentliggjøring av informasjon om problemet, i håp om å få hjelp til å utvikle en løsning. samfunnet. Fra produsentene kunngjorde NETGEAR utgivelsen av en oppdatering med fjerning av sårbarheten.
Det er viktig å merke seg at en sårbarhet som påvirker et standard C-bibliotek kan være ganske kompleks. Ikke bare ville det være hundrevis eller tusenvis av anrop til den sårbare funksjonen på flere punkter i et enkelt program, men sårbarheten vil påvirke et ubestemt antall andre programmer fra flere leverandører som er konfigurert til å bruke det biblioteket.
Det bemerkes at sårbarheten manifesterer seg i enheter fra mange produsenter (for eksempel brukes uClibc i firmware fra Linksys, Netgear og Axis), men siden sårbarheten forblir uoppdatert i uClibc og uClibc-ng, detaljert informasjon om enheter og spesifikke produsenter hvis produkter det er et problem, inntil de avsløres.
Endelig hvis du er interessert i å vite mer om det, kan du sjekke detaljene I den følgende lenken.