libmagic asi nie je uplne najlepsi napad

[sammko]

#1332

Pastujem zo slacku:

Pretože libmagic nemá najlepšiu reputaciu, ale aj keby mal, tak je to presne tá jedna vec, ktorá môže byť deravá. Parsovanie vstupov je asi najčastejší attack vector. A to na to stačí aby ten software parsoval jeden konkrétny formát, nie libmagic, ktorý je určený na to, aby pochopil všetky formáty na svete. Okrem toho je to native libka v C. Neexistuje ani šanca, že tam nie sú desiatky RCE. (samozrejme závisí odkiaľ je ten libmagic a kto ho ako kompiluje, kompilátory dnes vedia generovať kadečo, aby sa zabránilo takýmto exploitom, no samozrejme to nie je riešenie)
Takže niekto tam uploadne exploit, payload sa execne v procese toho uwsgi s prístupom do databazy a tak ďalej a tak podobne. Riešení niekoľko: púšťať libmagic v nejakom sandboxe. Toto znie komplikovane, ale verím, že sú na presne takéto účely hotové riešenia. Sandboxy sú ale deravé a my riešime iný (ľahší) problém ako "dostanem súbor, chcem zistiť čo to je", konkrétne chceme zistiť či je súbor PDF alebo nejaký docx alebo xlsx ako pozerám. PDF je trivialne, ma asi 4B magic number na začiatku. docx a xlsx su zipka, takže buď to vie akceptovať ľubovoľné zip (tiež magic number) alebo sa dá pozrieť či sa v tom zipku nachádza súbor so správnym názvom (toto robí aj libmagic pre tieto formaty), nazvy suborov v zip nie su komprimovane. Dokopy asi 10 riadkov pythonu, ktorý bude bezpečnejší, asi rádovo rýchlejší a máme o dependency menej.

A teda ak nie RCE, tak aspoň DOS, čo tiež nie je nejaké super, keď nám niekto bude zhadzovať uwsgi. Chápem, že možno nie sme nejaký top target, ale ten prínos libmagic-u v tejto situácii je zaporny

Proof of concept:

def is_zip(buf):
    return buf.startswith(b'PK\3\4')

def is_pdf(buf):
    return buf.startswith(b'%PDF-')

def is_rtf(buf):
    return buf.startswith(b'{\\rtf1')

def is_msooxml(buf, T):
    if not is_zip(buf):
        return False

    have_ct = False
    offset = 0
    while True:
        try:
            x = buf.index(b'PK\3\4', offset, 2048)
        except ValueError:
            return False
        
        fname = buf[x+30:x+45]
        if fname == b'[Content_Types]':
            have_ct = True
        if fname.startswith(T) and have_ct:
            return True
        offset = x+1
    return False

def is_docx(buf):
    return is_msooxml(buf, b'word')

def is_xlsx(buf):
    return is_msooxml(buf, b'xl')

Taketo nieco spolu s kontrolou pripony ma takmer nulovu sancu nefungovat, ak teda niekto aktivne nevymysla subory, ktore prejdu a nie su platne. Tomu samozrejme ale nepomoze ani libmagic.

[sammko]

Ak by ste to chceli pouzit, tak sa treba zamysliet nad tym while True, moc som to nerobil. Mal by skoncit, lebo ten buf.index skape ked je offset vacsi ako end, to je tych 2048, alebo ked nic nenajde.

Also ten have_ct check moze robit problemy, citujem msooxml z Magdir z libmagic:

# .docx, .pptx, and .xlsx are XML plus other files inside a ZIP
#   archive.  The first member file is normally "[Content_Types].xml".
#   but some libreoffice generated files put this later. Perhaps skip
#   the "[Content_Types].xml" test?

[black3r]

Na druhu stranu myslis ze fakt si niekto da tu namahu studovat nase zdrojaky aby nasiel utocny vektor a skombinoval 0day libmagicu a custom payload na pristup k nasej DB?

Osobne udaje o 3000 ludoch su tazko motivacia pre velke hackerske skupiny a ak by sa o to pokusil nejaky riesitel ja osobne by som mu skor zatlieskal...

[sammko]

To samozrejme chapem, ze to ma velmi nizku pravdepodobnost. Ale vravim, aj keby nie nieco take, tak staci trapny segfault aby to bolo otravne. Ale to tiez moze byt jedno.

Myslel som to skor tak, ze v situacii keby to este nebolo naimplementovane a rozhodujem sa medzi takymto riesenim a tym, ktore je teraz v mastri, tak si vyberiem toto, lebo ten potencialny bezpecnostny problem nema a bude rychlejsie. Ci uz sa to niekomu bude chciet vymenit, to je druha vec.

[black3r]

Chapem, na druhu stranu ja som zasadny odporca praktik NIH a Security by Obscurity, tak som chcel poskytnut pohlad z druhej strany.

Libmagic je zabehnuta kniznica vyvijana 30+ rokov ako sucast cli toolu "file". Existujuce riesenia, ak su osvedcene a stale vyvijane maju hlavnu vyhodu ze mas mensiu sancu narazit na nejaky obskurny edge case bug, ako napr. to co spominas s libreoffice (btw medzi riesitelmi mame nadpriemerne zastupenie linuxakov takze aj libreoffice pouzivatelov).

[sammko]

Určite nevravím, že teraz všetko treba kodiť od zakladov, ale keď je to takéto jednoduché..
Súhlasím, že NIH je často problem, ale zasadny odporca by som sa nenazval, existujú situácie, kedy človek narazí na viac problemov keď sa snaží nejakú knižnicu použiť, ako keby to mal programovať sám. A potom následný maintenance, keď sa knižnici mení API po každom update.
Toto samozrejme odbáča od libmagic, ktorého API sa nezmenilo už hodne dlho :D

file má trochu iné požiadavky na bezpečnostné vlastnosti, ako formular zaveseny na webe.

No každopádne sa mi zdá, že viac menej súhlasíme, len sa mierne prikláňame k opačným riešeniam. Ja to nechavam na vas, spravte ako uznate za vhodne, určite menší odpor má nechať to tak, ako to je. Neurazim sa, ak to rovno teraz zavrieme, ak sa teda @ano95 ešte nepustil do implementovania :D

[gardenerik]

Nepustil 😄 Stále som úplne nepobral, prečo je libmagic taký "zlý"... Diera sa môže objaviť vo všetkých našich deps a aj v trojsten webe samotnom, alebo mi niečo z toho ušlo?

[black3r]

Stále som úplne nepobral, prečo je libmagic taký "zlý"... Diera sa môže objaviť vo všetkých našich deps a aj v trojsten webe samotnom, alebo mi niečo z toho ušlo?

No na rozdiel od vacsiny deps toto pracuje priamo s vstupom od pouzivatelov (tj. je to "attack surface", alebo inaksie povedane "vstupna brana" pre utocnika) a je to pisane v C = jazyku v ktorom vedia existovat overflow bugy umoznujuce RCE exploity.

[gardenerik]

Aha.. Díky za objasnenie, hneď to dáva väčší zmysel 😅