Denna vecka i säkerhet: Git Deep Dive, Mailchimp och SPF

Först ut, git har granskats. Detta var en insats som sponsrades av Open Source Technology Improvement Fund (OSTIF), en ideell organisation som arbetar för att förbättra säkerheten för Open Source-projekt. Själva revisionen gjordes av forskare från X41 och GitLab, och två kritiska sårbarheter hittades, båda orsakade av samma dåliga kodningsvana — med en int för att hålla buffertlängder.

På moderna system, a size_t är alltid osignerad och har samma bitlängd som arkitekturens bitbredd. Detta är den rätta datatypen för sträng- och buffertlängder, eftersom den garanterat inte flödar över vid hantering av längder upp till det maximala adresserbara minnet i systemet. Å andra sidan, en int är vanligtvis fyra byte lång och signerad, med ett maximalt värde på 2^31-1, eller 2147483647 — cirka 2 GB. En stor buffert, men inte en ohörd mängd data. Kasta något så stort på git, och det kommer att gå sönder på oväntade sätt.

Vårt första exempel är CVE-2022-23521, en out of bounds-skrivning orsakad av en int svämmar över till negativt. A .gitattributes fil kan bindas till ett arkiv med en modifierad git-klient, och att sedan checka ut det arkivet kommer att orsaka num_attrs variabel att svämma över. Tryck överflödet hela vägen runt till ett litet negativt tal, och git kommer då att underallokera attributbufferten kraftigt och skriva all data förbi slutet av den allokerade bufferten.

CVE-2022-41903 är ytterligare ett signerat heltalsspill, den här gången när ett vackert utskriftsformat missbrukas för att göra något oväntat. Ta en titt på detta kodblock:

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

Exploateringsformatet skulle se ut ungefär %>(2147483647)%a%>(2147483646)%x41, där koden ovan körs för varje utfyllnadsinstans (The %>(#) block) som finns i formatet. Första gången genom den här koden läggs (2^31)-1 mellanslag till framför utgångssträngen. Det numret råkar bara vara maxvärdet för ett heltal med fyra bytes tecken. Men kodblocket ovan körs en annan gång, och ytterligare en gång läggs text till bufferten, och skjuter dess längd över det maximala heltalsvärdet. Den första raden i det blocket gör en implicit cast från size_t till int, inställning sb_len till ett negativt värde.

Sedan i memcpy() ring upp, sb->buf är en pekare till starten av bufferten, sb_len är vårt översvämmade stora negativa tal, och offset kommer att vara ett användarkontrollerat värde. Detta betyder platsen för destinationen som skickas till memcpy() kan oavsiktligt ställas in på en lägre minnesplats än början av den avsedda bufferten. Angriparkontrollerad skriver. Jag har lagt till några debugging printf()-satser till detta textblock och kör ett testfall:

$ ./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örsta kvartetten av utgångar där är uppställningen, som fyller stocklinjen med stoppning för att vara max int lång. Den andra kvartetten är buffertöverskridandet, där sb_len sätts till negativ och läggs sedan till offseten för att ge oss en plats 56 byte till vänster om buffertens början. Innehållet som skrivs ut till den platsen är i det här fallet %s, som ersätts av ämnesraden för commit - 44 byte lång. Författarna föreslår att detta skulle kunna beväpnas mot en "git forge", AKA GitHub och GitLab, eftersom dessa mjukvarusviter kör kommandot git archive, som kan anropa en användarkontrollerad vacker sträng.

Fixningar skickades till git-källkoden tillbaka den 8 december, men nya utgåvor som innehåller dessa korrigeringar är just nu tillgängliga. Det finns cirka 2200 instanser av råvaran int problem, och de kommer att ta ett tag att rensa upp, även med några roliga hacks som cast_size_t_to_int(), en inline-funktion som bara dödar programmet om en 2 GB+ size_t hanteras. Så uppdatera!

Mailchimp — igen

Det verkar som att folket på Mailchimp inte kan ta en paus, som deras interna administrationsverktyg fick återigen åtkomst av angripare, vilket leder till exponeringen av 133 kundkonton, inklusive WooCommerce. Det här är tredje gången Mailchimp faller för en social ingenjörskonst eller nätfiskeattack under det senaste året, och varje gång har det resulterat i spjutfiske-e-postmeddelanden till slutanvändare. Så om du finns på någon av Mailchimps e-postlistor, tänk på detta brott nästa gång ett relaterat e-postmeddelande kommer. (Redaktörens anmärkning: Hackadays två nyhetsbrev använder Mailchimp, och vi blev inte meddelade, så vi tror att vi är bra.)

Royal Mail Ransomware

I en berättelse som kan få stora konsekvenser Storbritanniens Royal Mail har drabbats av en ransomware-attack på deras system för hantering av internationell post. Attacken använder Lockbit ransomware, en grupp som misstänks vara ett rysktalande ransomware-gäng. Detta kan vara betydande, eftersom en attack mot en verklig statlig myndighet är mycket allvarligare än en attack mot ett företag. Eftersom Lockbit körs som ransomware-as-a-service, kommer det att bli mycket svårt att avgöra exakt vem som faktiskt genomförde attacken. För närvarande är rekommendationen enkel: skicka inte någon internationell post. Oj.

Skanna SPF-poster

[Sebastian Salla] har vad som kan anses vara en märklig hobby, i form av skanna SPF-poster efter udda felkonfigurationer. I hans senaste äventyr var den genomsökningen de 3 miljoner mest besökta domänerna. Och felkonfiguration hittades.

Men håll ut, vad är en SPF och varför bryr vi oss? Sender Policy Framework är en txt-post som är en del av en domäns DNS-poster. Och det specificerar vilka IP-adresser som faktiskt är auktoriserade att skicka e-post för den domänen. Så om ett inkommande e-postmeddelande påstår sig vara från en domän med en giltig SPF-post, och den sändande IP-adressen inte finns på den posten, är det ganska tydligt inte riktigt från den anspråkade domänen.

Och att få din domäns e-postmeddelanden avvisade på grund av ett SPF-problem är ett av de säkraste sätten att fånga flak. Så det är frestande att göra SPF-skivan lite mer ... *liberal* än den kanske borde vara. Och den mest extrema upprepningen av detta är att bara smälla en +all på din SPF-post och var klar med det. Visst, det berättar för världen att varje spammare var som helst som använder din domän faktiskt skickar riktiga e-postmeddelanden, men det får åtminstone chefens utgående e-post att fungera igen. Med över tusen domäner inställda på SPF +all, tydligen är det vanligare ett fel än väntat.

Det riktigt intressanta är vem som är vem av de felkonfigurerade domänerna, som flera amerikanska statliga myndigheter, andra statliga domäner runt om i världen och flera universitet. Det mest intressanta var det ukrainska försvarsministeriet, där SPF-rekordet klipptes från en -all till +all ca 4 månader sedan.

Bitar och bytes

Tailscale upptäckte ett potentiellt allvarligt problem, där att känna till nod-ID för en annan klient skulle göra det möjligt för en angripare att lägga till noden i sitt eget tailnet. Detta skulle ha satt en angripare på insidan av din VPN, definitivt ett dåligt scenario. Men innan du får dina höggafflar, distribuerades den sårbara koden i mindre än fyra månader innan den fixades. Det rapporterades privat den 11:e denna månad och fastställdes den 12:e. Och för att starta upp lämnar attacken en loggsignatur som Tailscale kunde skanna efter, och drog slutsatsen att den var isolerad till proof-of-concept-testningen. Du kan kontrollera din egen instrumentpanel för eventuella noder som delas från deras eget tailnet för bekräftelse. Och även om det är en otäck sårbarhet, bra för Tailscale för att avslöja det. Många leverantörer skulle ha suttit på den här och aldrig gjort den offentlig.

Smakämnen Linux-kärnan hade ett buffertspill i sin Netfilter-kod, där ett buffertspill kan resultera i både dataläckage och kodexekvering. Det finns ingen väg till fjärrexploatering, men e-postmeddelandet som länkas ovan innehåller en fullständig PoC för en lokal privilegieskalering. Och om kärnexploatering är din grej, har Googles Project Zero en ny text om ämnet, allt om noll-dereferencing.

Och om du använder ManageEngine från Zoho, så idag kan ditt hår brinna, om du inte har uppdaterat till releasen som fixar CVE-2022-47966. Forskare vid Horizon3 har bakåtkonstruerat patchen, och spillde bönorna på denna RCE. Det är ett problem i hur SAML single-sign-on implementeras, delvis på grund av ett extremt gammalt bibliotek paketerat som en del av produkten. Det är en ganska enkel exploatering att göra, så det är dags att dubbelkolla dessa installationer!

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• Platoblockchain. Web3 Metaverse Intelligence. Kunskap förstärkt. Tillgång här.
• Källa: https://hackaday.com/2023/01/20/this-week-in-security-git-deep-dive-mailchimp-and-spf/