De upptäckte en sårbarhet i uClibc- och uClibc-ng-biblioteken som påverkar Linux-firmware 

För några dagar sedan släpptes nyheten om det i C-standardbiblioteken uClibc och uClibc-ng, används i många inbäddade och bärbara enheter, en sårbarhet har identifierats (med CVE ännu inte tilldelad), vilket tillåter substitution av dummy-data i DNS-cachen, som kan användas för att förfalska IP-adressen för en godtycklig domän i cachen och omdirigera förfrågningar till domänen till angriparens server.

Om problemet nämns att detta påverkar olika Linux-firmware för routrar, åtkomstpunkter och IoT-enheter, såväl som inbäddade Linux-distributioner som OpenWRT och Embedded Gentoo.

Om sårbarhet

Sårbarhet beror på användningen av förutsägbara transaktionsidentifierare i koden för att skicka frågor av DNS. DNS-fråge-ID valdes genom att helt enkelt öka räknaren utan ytterligare randomisering av portnumren, vilket gjorde det möjligt att förgifta DNS-cachen genom att förebyggande skicka UDP-paket med falska svar (svaret kommer att accepteras om det anländer före svaret från den riktiga servern och inkluderar korrekt identifiering).

Till skillnad från Kaminsky-metoden som föreslogs 2008 är det inte ens nödvändigt att gissa transaktions-ID:t, eftersom det initialt är förutsägbart (initialt är det satt till 1, vilket ökar med varje begäran, och inte väljs slumpmässigt).

att skydda dig själv mot ID-gissning, specifikationen rekommenderar vidare användning av en slumpmässig distribution av nätverksportnummer ursprunget från vilket DNS-frågorna skickas, vilket kompenserar för den otillräckliga storleken på ID:t.

När portrandomisering är aktiverad, för att bilda ett dummysvar, är det förutom att välja en 16-bitars identifierare också nödvändigt att välja nätverksportnumret. I uClibc och uClibc-ng var sådan randomisering inte explicit aktiverad (när bind anropades specificerades inte en slumpmässig källa UDP-port) och dess implementering berodde på operativsystemets konfiguration.

När portrandomisering är inaktiverad, bestämma vilket begäran-id som ska öka markeras som en trivial uppgift. Men även i fallet med randomisering behöver angriparen bara gissa nätverksporten från intervallet 32768-60999, för vilken han kan använda massiv samtidig sändning av dummysvar på olika nätverksportar.

Problemet har bekräftats i alla aktuella versioner av uClibc och uClibc-ng, inklusive de senaste versionerna av uClibc 0.9.33.2 och uClibc-ng 1.0.40.

"Det är viktigt att notera att en sårbarhet som påverkar ett standard C-bibliotek kan vara ganska komplex", skrev teamet i ett blogginlägg denna vecka.

"Det skulle inte bara finnas hundratals eller tusentals anrop till den sårbara funktionen vid flera punkter i ett enda program, utan sårbarheten skulle påverka ett obestämt antal andra program från flera leverantörer som är konfigurerade att använda det biblioteket."

I september 2021 skickades information om sårbarheten till CERT/CC för samordnad arrayförberedelse. I januari 2022, problemet delades med mer än 200 tillverkare associerad med CERT/CC.

I mars gjordes ett försök att separat kontakta underhållaren av uClibc-ng-projektet, men han svarade att han inte kunde åtgärda sårbarheten själv och rekommenderade offentliggörande av information om problemet, i hopp om att få hjälp med att utveckla en lösning. samhället. Från tillverkarna tillkännagav NETGEAR lanseringen av en uppdatering med borttagning av sårbarheten.

Det är viktigt att notera att en sårbarhet som påverkar ett standard C-bibliotek kan vara ganska komplex. Inte bara skulle det finnas hundratals eller tusentals anrop till den sårbara funktionen vid flera punkter i ett enda program, utan sårbarheten skulle påverka ett obestämt antal andra program från flera leverantörer som är konfigurerade att använda det biblioteket.

Det noteras att sårbarheten visar sig i enheter från många tillverkare (till exempel används uClibc i firmware från Linksys, Netgear och Axis), men eftersom sårbarheten förblir oparpad i uClibc och uClibc-ng, detaljerad information om enheter och specifik tillverkare i vars produkter det finns ett problem, tills de avslöjas.

Slutligen om du är intresserad av att veta mer om detkan du kontrollera detaljerna I följande länk.


Lämna din kommentar

Din e-postadress kommer inte att publiceras. Obligatoriska fält är markerade med *

*

*

  1. Ansvarig för uppgifterna: Miguel Ángel Gatón
  2. Syftet med uppgifterna: Kontrollera skräppost, kommentarhantering.
  3. Legitimering: Ditt samtycke
  4. Kommunikation av uppgifterna: Uppgifterna kommer inte att kommuniceras till tredje part förutom enligt laglig skyldighet.
  5. Datalagring: databas värd för Occentus Networks (EU)
  6. Rättigheter: När som helst kan du begränsa, återställa och radera din information.