Denne uken i sikkerhet: Git Deep Dive, Mailchimp og SPF

Førstemann, git har blitt revidert. Dette var en innsats sponset av Open Source Technology Improvement Fund (OSTIF), en ideell organisasjon som arbeider for å forbedre sikkerheten til Open Source-prosjekter. Selve tilsynet ble gjort av forskere fra X41 og GitLab, og to kritiske sårbarheter ble funnet, begge forårsaket av den samme dårlige kodevanen - ved å bruke en int å holde bufferlengder.

På moderne systemer, en size_t er alltid usignert, og har samme bitlengde som arkitekturens bitbredde. Dette er den riktige datatypen for streng- og bufferlengder, siden den garantert ikke renner over når du håndterer lengder opp til maksimalt adresserbart minne på systemet. På den annen side, en int er vanligvis fire byte lang og signert, med en maksimal verdi på 2^31-1, eller 2147483647 — omtrent 2 GB. En stor buffer, men ikke en uhørt mengde data. Kast noe så stort på git, og det vil gå i stykker på uventede måter.

Vårt første eksempel er CVE-2022-23521, en out of bounds-skriving forårsaket av en int renner over til negativt. EN .gitattributes filen kan forpliktes til et depot med en modifisert git-klient, og deretter sjekke ut det depotet vil føre til num_attrs variabel til overløp. Skyv overflyten hele veien rundt til et lite negativt tall, og git vil da i stor grad underallokere attributtbufferen, og skrive alle disse dataene forbi slutten av den tildelte bufferen.

CVE-2022-41903 er nok et signert heltallsoverløp, denne gangen når et vakkert utskriftsformat blir misbrukt til å gjøre noe uventet. Ta en titt på denne kodeblokken:

 int sb_len = sb->len, offset = 0; if (c->flush_type == flush_left) offset = padding - len; else if (c->flush_type == flush_both) offset = (padding - len) / 2; /* * we calculate padding in columns, now * convert it back to chars */ padding = padding - len + local_sb.len; strbuf_addchars(sb, ' ', padding); memcpy(sb->buf + sb_len + offset, local_sb.buf, local_sb.len);

Utnyttelsesformatet vil se omtrent slik ut %>(2147483647)%a%>(2147483646)%x41, der koden ovenfor kjører for hver utfyllingsforekomst (The %>(#) blokker) funnet i formatet. Den første gangen gjennom denne koden legger til (2^31)-1 mellomrom foran på utdatastrengen. Dette tallet er tilfeldigvis maksverdien til et heltall med fire byte fortegn. Men kodeblokken ovenfor kjøres en annen gang, og en gang til legges tekst til bufferen, og skyver lengden over den maksimale heltallsverdien. Den første linjen i den blokken gjør en implisitt cast fra size_t til int, omgivelser sb_len til en negativ verdi.

Så i memcpy() anrop, sb->buf er en peker til starten av bufferen, sb_len er vårt overfylte store negative tall, og offset vil være en brukerkontrollert verdi. Dette betyr plasseringen til destinasjonen som sendes til memcpy() kan utilsiktet settes til en lavere minneplassering enn starten på den tiltenkte bufferen. Angriper kontrollert skriver. Jeg har lagt til noen debugging printf()-setninger til denne tekstblokken, og kjører en testcase:

$ ./bin-wrappers/git log -1 --pretty="format:%>(2147483647)%a%>(2147483635)%s" >/dev/null
Padding: 2147483647
sb_len: 0
offset: 2147483647
Memcpy: Padding: 2147483635
sb_len: -2147483647
offset: 2147483591
Memcpy: CI: upgrade to macos-12, and pin OSX version
=================================================================
==844038==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x7fd8989f97c8 at pc 0x7fdb15e49d21 bp 0x7ffe8fa5c100 sp 0x7ffe8fa5b8b0
WRITE of size 44 at 0x7fd8989f97c8 thread T0
0x7fd8989f97c8 is located 56 bytes to the left of 4831838268-byte region [0x7fd8989f9800,0x7fd9b89f983c)

Den første kvartetten med utganger der er oppsettet, priming av logglinjen med polstring for å være maks. int lang. Den andre kvartetten er bufferoverløpet, hvor sb_len er satt til negativ, og deretter lagt til offset for å gi oss en plassering 56 byte til venstre for starten av bufferen. Innholdet som blir skrevet ut til det stedet er i dette tilfellet %s, som blir erstattet av emnelinjen til commit - 44 byte lang. Forfatterne foreslår at dette kan være våpen mot en "git forge", AKA GitHub og GitLab, ettersom disse programvarepakkene kjører git archive-kommandoen, som kan påkalle en brukerkontrollert pen streng.

Rettelser ble presset til git-kildekoden tilbake 8. desember, men nye utgivelser som inneholder disse rettelsene er akkurat nå tilgjengelig. Det er omtrent 2200 forekomster av råstoffet int problemet, og det vil ta litt tid å rydde opp, selv med noen morsomme hacks som cast_size_t_to_int(), en innebygd funksjon som bare dreper programmet hvis en 2 GB+ size_t er håndtert. Så oppdater!

Mailchimp — Igjen

Det ser ut til at folk i Mailchimp ikke kan ta en pause, som deres interne administrasjonsverktøy ble igjen åpnet av angripere, som fører til eksponering av 133 kundekontoer, inkludert WooCommerce. Dette er tredje gang Mailchimp har falt for et sosialt ingeniør- eller phishing-angrep det siste året, og hver gang har resultert i spyd-phishing-e-poster sendt til sluttbrukere. Så hvis du er på noen Mailchimp-e-postlister, husk dette bruddet neste gang en relatert e-post kommer. (Redaktørens merknad: Hackadays to nyhetsbrev bruker Mailchimp, og vi ble ikke varslet, så vi tror at vi er gode.)

Royal Mail Ransomware

I en historie som kan få store konsekvenser, Storbritannias Royal Mail har blitt utsatt for et løsepengeangrep på deres system for håndtering av internasjonal post. Angrepet bruker Lockbit ransomware, en gruppe som mistenkes for å være en russisktalende ransomware-gjeng. Dette kan være betydelig, ettersom et angrep på en faktisk offentlig etat er mye mer alvorlig enn et angrep på en bedrift. Siden Lockbit kjører som løsepengevare-som-en-tjeneste, vil det være svært vanskelig å fastslå nøyaktig hvem som faktisk utførte angrepet. Foreløpig er anbefalingen enkel: ikke send internasjonal post. Uff.

Skanner SPF-poster

[Sebastian Salla] har det som kan anses som en merkelig hobby, i form av skanning av SPF-poster for merkelige feilkonfigurasjoner. I hans siste eventyr var denne skanningen de 3 millioner mest besøkte domenene. Og feilkonfigurasjon ble funnet.

Men stå på, hva er en SPF og hvorfor bryr vi oss? Sender Policy Framework er en txt-post som er en del av et domenes DNS-poster. Og den spesifiserer hvilke IP-adresser som faktisk er autorisert til å sende e-post for det domenet. Så hvis en innkommende e-post hevder å være fra et domene med en gyldig SPF-post, og avsender-IP-adressen ikke er på den posten, er det ganske tydelig ikke egentlig fra domenet som kreves.

Og at domenets e-poster blir avvist på grunn av et SPF-problem er en av de sikreste måtene å fange flak på. Så det er fristende å gjøre SPF-platen litt mer ... *liberal* enn den kanskje burde være. Og den mest ekstreme gjentakelsen av dette er å bare slå en +all på SPF-posten din og vær ferdig med den. Jada, det forteller verden at hver spammer hvor som helst som bruker domenet ditt faktisk sender ekte e-poster, men det får i det minste sjefens utgående e-poster til å fungere igjen. Med over tusen domener satt til SPF +all, tilsynelatende er det mer vanlig en feil enn forventet.

Den virkelig interessante biten er hvem som er hvem av disse feilkonfigurerte domenene, som flere amerikanske offentlige etater, andre statlige domener rundt om i verden og flere universiteter. Den mest interessante var det ukrainske forsvarsdepartementet, der SPF-rekorden ble klippet fra en -all til +all ca 4 måneder siden.

Bits og bytes

Tailscale oppdaget et potensielt alvorlig problem, der å kjenne node-IDen til en annen klient ville tillate en angriper å legge til noden til sitt eget tailnet. Dette ville ha satt en angriper på innsiden av VPN-en din, definitivt et dårlig scenario. Men før du får høygaflene dine, ble den sårbare koden distribuert i mindre enn fire måneder før den ble fikset. Det ble privat rapportert den 11. denne måneden, og løst den 12. Og for å starte opp, etterlater angrepet en loggsignatur som Tailscale var i stand til å skanne etter, og konkluderte med at den var isolert til proof-of-concept-testingen. Du kan sjekke ditt eget dashbord for eventuelle noder som deles ut av deres eget tailnet for bekreftelse. Og selv om det er en ekkel sårbarhet, bra for Tailscale for å avsløre det. Mange leverandører ville ha sittet på denne og aldri offentliggjort den.

De Linux-kjernen hadde et bufferoverløp i Netfilter-koden, hvor et bufferoverløp kan resultere i både datalekkasje og kodekjøring. Det er ingen vei til ekstern utnyttelse, men e-posten som er koblet til ovenfor inneholder en fullstendig PoC for en lokal rettighetseskalering. Og hvis kjerneutnyttelse er noe for deg, har Googles Project Zero det en ny artikkel om emnet, alt om null dereferencing.

Og hvis du bruker ManageEngine fra Zoho, kan håret ditt i dag brenne, hvis du ikke har oppdatert til utgivelsen som fikser CVE-2022-47966. Forskere ved Horizon3 har reversert oppdateringen, og sølt bønnene på denne RCE. Det er et problem i hvordan SAML enkeltpålogging implementeres, delvis på grunn av et ekstremt gammelt bibliotek pakket som en del av produktet. Det er en ganske enkel utnyttelse, så det er på tide å dobbeltsjekke disse installasjonene!

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• Platoblokkkjede. Web3 Metaverse Intelligence. Kunnskap forsterket. Tilgang her.
• kilde: https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf/