Ping af død! FreeBSD retter crashtastic fejl i netværksværktøjet

Et af de første netværksværktøjer på lavt niveau, som enhver computerbruger lærer om, er det ærværdige ping nytte.

Opkaldt efter den eponyme lydeffekt fra enhver gammeldags krigsfilmscene, der involverer ubåde, er kommandoen et metaforisk ekko (se hvad vi gjorde der?) af undervandsversionen af ​​RADAR kendt som SONAR.

Du sender et ping (mere som en støj, ind virkelighed) ind i de saltede dybder, og ved at måle, hvor lang tid det tager for dets uhyggelige ekko at komme tilbage til dig, og ved at estimere lydens hastighed i det omgivende hav, kan du beregne afstanden til det objekt, der producerede ekkoet.

Spændende, i betragtning af at du sikkert har hørt forkortelsen TCP/IP brugt som en generisk beskrivelse af protokollimen, der driver internettet, ping teknisk set ikke bruger TCP/IP overhovedet.

Faktisk er TCP/IP en forkortelse for transmissionskontrolprotokol over internetprotokollen, og refererer til en mekanisme på ret højt niveau til at sende data over internettet på en sådan måde, at netværket selv lægger en masse af "fungerede det faktisk korrekt?" indsats for dig.

For eksempel i TCP-forbindelser er alle bidder af data, du sender, garanteret enten at ankomme intakte i den anden ende eller forårsage en fejl, så du ved, at de ikke nåede det.

Desuden, selvom forskellige datastykker ender med at tage forskellige ruter på tværs af internettet (f.eks. på grund af belastningsbalancering, midlertidige udfald eller andre gendannede fejl), og selvom nogle bidder tager længere tid at ankomme end andre, vil TCP-data blive korrekt bufret op og præsenteret i den rigtige rækkefølge i den anden ende.

Ping er anderledes

ping kommandoen bruges dog typisk til at kontrollere, om en computer, du er interesseret i, overhovedet er online, især hvis den ikke accepterer den slags TCP-forbindelser på højt niveau, du ville forvente, såsom at modtage e-mail eller tillade SSH-login.

Dette hjælper dig hurtigt med at afgøre, om et udfald sandsynligvis skyldes, at netværket eller selve serveren går ned, eller på grund af, at individuelle tjenester, der kører på den pågældende server, ikke starter korrekt.

Som et resultat, ping bruger en protokol på meget lavere niveau end TCP.

Faktisk ping bruger ikke engang TCPs mere afslappede fætter UDP, forkortelse for bruger datagram protokol, som er en måde at overføre data på, der er hurtig og nem, men populært kaldes send-og-håb (eller, hvis du er en kynisk slags, som spray-and-pray).

UDP selv informerer dig ikke om, hvorvidt dine data er kommet til den anden ende eller ej, og selvom de ankommer intakte, holder UDP ikke styr på den rækkefølge, som dine pakker oprindeligt blev sendt i, så det kan ikke omarrangere dem kl. den anden ende, hvis de kommer der ud af rækkefølge.

Ping, for hvad det er værd, bruger en protokol på meget lavt niveau, specielt designet til fejlfinding og netværksrekonfigurationsformål, kendt som ICMP, eller internetkontrolmeddelelsesprotokol.

Typisk håndteres direkte i operativsystemkernen, så ICMP/IP-pakker er næsten sikre på at komme igennem, selvom ingen netværkssoftware på højere niveau er kommet korrekt op, inkluderer ICMP især to specielle meddelelsestyper:

• Skriv 0x08. Officielt kaldet ICMP EchoDette en slags pakke kaldes normalt en ekko-anmodning. Det er hvad ping program sender ud for at sondere efter aktive computere på netværket.
• Skriv 0x00. Officielt kaldet ICMP Echo Reply, er denne pakketype præcis hvad der står. En computer, der er i live, online og ikke er konfigureret til at blokere ICMP Echo-trafik, formodes at sende denne slags pakke direkte tilbage til den computer, der anmodede om det.

Sådan her:

$ ping -c 3 -p 4E414B45445345435552495459 nakedsecurity.sophos.com MØNSTER: 0x4e414b45445345435552495459 PING news-sophos.go-vip.192.0.66.227 af data fra 56 af 84 af 64 af 192.0.66.227. 192.0.66.227 bytes fra 1 (53): ICMP_SEQ = 84.0 TTL = 64 tid = 192.0.66.227 ms 192.0.66.227 bytes fra 2 (53): ICMP_SEQ = 85.1 TTL = 64 Time = 192.0.66.227 MS 192.0.66.227 byte fra 3 (53): icmp_seq=84.8 ttl=3 tid=3 ms --- news-sophos.go-vip.net ping statistik --- 0 pakker transmitteret, 2004 modtaget, 84.025% pakketab, tid 84.644ms rtt min/ avg/max/mdev = 85.062/0.446/XNUMX/XNUMX ms

For at se en ping i aktion på et lidt lavere niveau, vil vi bruge Lua-koden, som du kan finde i slutningen af ​​artiklen, til at konstruere vores egen ICMP Echo-pakke og til at læse det svar, der kommer tilbage, hvis nogen:

$ sudo luax ping.lua nakedsecurity.sophos.com Sender ICMP ECHO-anmodning til 192.0.66.227 --> 00000000 08 00 03 02 bb 5a 6f 1d 50 69 6e 67 52 65P. Requ.Zo 71 | 75 00000010 65 73 74d 4 65 73 73 61 67 65 20 42 42 35 41 |estMessage BB36A5| 6 00000020 46 31 |F44D | Fik tilbage--> 1 00000000 45 00 00 f37 af 6 00 00 35 01 94f c7 0 00 e42 |E..3....7.....B.| 5 XX XX XX XX 00000010 00 00b 0 bb 02a 5f 6d 1 50 69e 6 |.........Zo.Ping| 67 00000020 52 65 71 75 65 73 74d 4 65 73 73 61 67 65 20 |RequestMessage B| 42 00000030 42 35 41 36 46 31 |B44A5F6D |

I øvrigt skulle vi bruge sudo ovenfor for at køre vores script med superbrugerrettigheder, fordi vi har oprettet det, der er kendt som en rå IP-stik – en, der kan laves i ethvert underliggende format, vi kan lide, inklusive TCP, UDP og, efter behov her, ICMP.

På mange Linux/Unix-systemer er ping kommandoen leveret af din distro fungerer uden eksplicit at blive givet root-privilegier, normalt fordi den er installeret med specielle sikkerhedsfunktioner eller med dens setuid flagsæt, hvilket betyder, at det starter med at køre under en anden brugerkonto end den bruger, der kørte det.

Veldesignet ping programmer vil selvfølgelig automatisk kassere deres ekstra privilegier, når de har åbnet den rå socket, de har brug for.

Vi har udeladt denne privilegie-slip kode fra vores eksempelscript for korthedens skyld. Du kan bruge posix.unistd.setpid() funktion for at skifte til en uprivilegeret konto efter oprettelse af socket, men før afsendelse eller modtagelse af data.

Undersøgelse af svaret

Som du måske genkender i datadumpet fra vores script ovenfor, inkluderer netværkssocket-funktionen, vi bruger til at læse data tilbage fra den reagerende server, ikke kun ICMP Echo Reply-dataene, men også lavniveau-IP (internetprotokolheadere) i den underliggende pakke.

Vi har ikke forsøgt at parse eller på anden måde behandle disse data, men FreeBSD ping programmet skal gøre det for at give mening i svaret, herunder give mening om eventuelle fejlmeddelelser, der kommer tilbage.

Hvis ping bliver afvist på en eller anden måde, vil Echo-svaret typisk ikke kun omfatte dets egne IP-headere (som vist ovenfor), men også en referencekopi af IP-headerne og ICMP-dataene, der optrådte i den oprindelige udgående anmodning.

IPv4-pakkeheadere ser normalt meget ud som du ser ovenfor, hvor IP-headerne starter med 45 00 00 37... og fortsæt i 20 bytes i alt, op til og med de bytes vist som ...XX XX XX XX, som er IP-adressen på min bærbare computer.

Sådan her:

00000000 45 00 00 37 f6 af 00 00 35 01 94 7f c0 00 42 e3 |E..7....5.....B.| 00000010 XX XX XX XX |.... | IP-version og headerlængde: 0x45 (4 = IPv4, 5 = fem 32-bit ord, dvs. 20 bytes Tjenestetype og overbelastningsdata: 0x00 Samlet pakkelængde: 0x0037 (decimal 55) Sekvensinformation: F6 AF 00 00 Time-to -live (hop tilbage): 0x35 (decimal 53) Protokoltype: 0x01 (ICMP) Kontrolsum: 0x947F (decimal 38015) Afsender computerens IP-nummer: C0 00 42 E3 (192.0.66.227 = nakens.comity) IP-modtager. bærbar): XX XX XX XX (REDAKTØRT = mit eget IP-nummer)

FreeBSD'er ping programmører, lader det til, at antage, at overskrifter af denne slags faktisk altid ville være nøjagtigt 20 byte lange, baseret på denne header-længdeværdi i den første byte af 0x45, der angiver IPv4 (0x4?) med et 5-DWORD (0x?5), eller 20-byte, header.

Med kun 20 bytes at bekymre sig om, tildelte programmørerne buffere med fast størrelse på stakken, hvor de kunne opbevare en kopi af IP-headerne i svaret, plus eventuelle indlejrede IP-headere fra den oprindelige anmodning, hvis der var en fejltilstand at håndtere .

Du kan gætte, hvor det går hen.

Den første byte i IPv4-headeren kan lovligt have en hvilken som helst værdi fra 0x45 (den mindste headerstørrelse på 5 DWORDs eller 20 bytes, som vist) op til 0x4F (betegner 15 DWORDs, fordi 0xF er decimal 15 eller 60 bytes headerdata i alt), hvilket giver mulighed for en valgfri ekstra 40 bytes headerdata.

Disse sjældne, men lovlige, ekstra header-bytes kan bruges til forskellige funky og usædvanlige "funktioner" med nysgerrige navne som f.eks. Selektiv rettet udsendelse, Eksperimentel flowkontrol , Upstream Multicast-pakke – ting, som vi har hørt om, men aldrig bevidst brugt eller endda set.

Pas på cyberkriminelle, der sætter dig på prøve

Som du kan forestille dig, da disse ekstra felter næsten aldrig bruges, vil du måske aldrig se en IPv4-pakke med andet end 0x45 i starten og med 20 bytes headerdata i alt, medmindre du er stødt på en flok cyberkriminelle, der er klar til at sætte dig på prøve.

Desværre er der ikke meget, der forhindrer en angriber i at rigge en server op, der gætter på, om du bruger FreeBSD, og ​​bevidst genererer overdimensionerede ICMP/IP Echo Reply-pakker for at fremprovokere en stak bufferoverløb inde i din ping program.

Hvis du nogensinde tjekker for at se, om deres server er aktiv (hvilket du måske endda gør, eller måske især, hvis du synes, det er mistænkeligt!), kan du blive ramt af et svar, der er fanget i snavs.

I bedste fald din ping programmet vil gå ned; i værste fald, som FreeBSD-sikkerhedsrådgivningen generøst indrømmer, "det kan være muligt for en ondsindet vært at udløse fjernudførelse af kode i ping."

Heldigvis, som FreeBSD-forfatterne også påpege, "Ping-processen kører i en kapacitets-sandbox på alle berørte versioner af FreeBSD og er derfor meget begrænset i, hvordan den kan interagere med resten af ​​systemet på det punkt, hvor fejlen kan opstå."

Du skal med andre ord helt sikkert lappe, men risiciene kan betragtes som beskedne.

Navnlig ping programmet er ikke kun låst i en sandkasse, men kører ikke som root, når buggykoden nås, som bekræftet i sikkerhedsmeddelelsen: "Hvornår ping kører, skaber den den rå socket, der er nødvendig for at udføre sit arbejde, og tilbagekalder derefter sine forhøjede privilegier."

Som beskrevet ovenfor kræves superbrugerbeføjelser kun for at erhverve en rå IP-socket fra operativsystemet, ikke for at bruge sendto() , recvfrom() fungerer på det stik bagefter.

Denne fejl har fået den officielle identifikator CVE-2022-23093; det er dokumenteret i sikkerhedsrådgivningen FreeBSD-SA-22:15.ping.

Hvad skal jeg gøre?

• Hvis du er en FreeBSD-bruger, blot opdatere de berørte udgivelser (FreeBSD 12 og FreeBSD 13) til deres seneste versioner, hvor denne fejl er rettet.
• Hvis du er netværksprogrammør, Sørg altid for, at du har taget højde for pakkeoverskrifter, der kunne indikere usædvanlige størrelsesvariationer. Det faktum, at du aldrig selv har set nogen variation, forhindrer dig ikke i at stå over for en pakke i morgen, der er ud over det sædvanlige, men alligevel fuldkommen lovlig.
• Hvis du er netværksadministrator, overveje at blokere IPv4-pakker med IP-headere, der ikke er 20 bytes store. Hvis du virkelig ser ud til at have behov for at tillade nogle softwareprodukter at bruge usædvanlige IPv4-header-indstillinger, kan du overveje at logge disse usædvanlige pakker for at finde ud af hvorfor.

Pas på derude!

---

EKSEMPEL KODE TIL DEMONSTRATION AF PING-TRAFIK

---