.srt te drága: VLC ParseJSS Null Skip Subtitle Remote Code Execution

 ( hendrick | 2017. május 26., péntek - 9:20 )

https://www.reddit.com/r/security/comments/6czzz7/subtitles_open_you_up_to_hackers_when_using/
http://blog.checkpoint.com/2017/05/23/hacked-in-translation/
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-8310
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-8311
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-8312
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-8313
http://git.videolan.org/?p=vlc.git;a=commitdiff;h=775de716add17322f24b476439f903a829446eb6

https://www.checkpoint.com/defense/advisories/public/2017/cpai-2017-0433.html
"A remote code execution vulnerability exists in VLC Subtitles mechanism. The vulnerability is due to the way VLC parses subtitle files. Successful exploitation could result in arbitrary code execution on the client machine."

Asszony elég sok feliratot tölt le, vajon mit keressek bennük? Ha lesz egy kis időm, beletúrok párba random - jó lenne több konrétum, de egyelőre szűkszavúak - hátha találok valami érdekeset :)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A git diffekbe belenézve:

Ez, amit te linkeltél: http://git.videolan.org/?p=vlc.git;a=commitdiff;h=775de716add17322f24b476439f903a829446eb6

Ha jól látom valami vezérlőkarakterek kiparszolása tud elcsúszni, ha \C vagy \F a vezérlőkarakterlánc, akkor kettőt ugrik a pointer, de nem tudjuk hova. Ha utána pont vége van a parszolt stringnek, akkor túlcímzés lehet, és beleolvas abba amit ott talál. Ami akármi lehet, vagy ha pontosan ismerjük a programot és lehet vezérelni, akkor bármi más crafted cucc is. Amire keresni kell, az \c vagy \f a fájl végén. Gondolom a fájl végén nincs sok értelme vezérlőkaraktert írni, tehát ha ilyet találsz, az valami célból kraftolt cucc. Hirtelen nem tudom elképzelni, hogy ezzel crash-en kívül mit lehetne szándékosan csinálni, úgyhogy valószínűleg nem ezt használják támadásra, hanem az erősebbeke. Inkább erre építenék ha blackhat lennék (bár ezt se tudom, hogy hogy lehet kódfuttatásra használni):

Ezek úgy néz ki lezáratlan HTML tag-ekre követnek el hibát, túlcímez a stringen:
http://git.videolan.org/?p=vlc/vlc-2.2.git;a=blobdiff;f=modules/codec/subsdec.c;h=addd8c71f30d53558fffd19059b374be45cf0f8e;hp=1b4276e299a2a6668047231d29ac705ae93076ba;hb=7cac839692ab79dbfe5e4ebd4c4e37d9a8b1b328;hpb=3477dba3d506de8d95bccef2c6b67861188f6c29

Tehát lezáratlan TAG-eket kell keresned. Ilyet lehet, hogy véletlenül is csinálnak a jómadarak (ha kézzel HTML-eznek), úgyhogy tippem szerint lesz egy rakás fals pozitív is, ha ilyenekre keresel.

Amúgy SZVSZ ilyen jellegű programokat menedzselt nyelven kellene írni, ami eleve nem enged túlcímzést. És nem "kézzel" kellene parszolni, hanem valami erre való libbel. Na nem mintha én még sose csináltam volna hasonlót, de más kódját könnyű fikázni :-).

"ilyen jellegű programokat menedzselt nyelven kellene írni, ami eleve nem enged túlcímzést"
Az a szerencséd, hogy hajbazer nem önkéntes szabadságát tölti, különben itt indulna egy 500+-os thread :)

:-)

Na, jobban kielemeztem az elsőt, amire azt írtam, hogy nem tudom elképzelni mit lehetne csinálni vele.

A description szerint: "Potential heap based buffer overflow in ParseJSS in VideoLAN VLC before 2.2.5 due to skipping NULL terminator in an input string allows attackers to execute arbitrary code via a crafted subtitles file."

Szerintem úgy működik, hogy a for ciklusban egy új pufferbe másolja át a forrás stringet, de úgy, hogy közben a kommenteket, vezérlőkaraktereket átírja másra.

Létrehoz egy cél puffert, aminek a hosszát eleve úgy állítja be, hogy tuti elég hosszú legyen:

psz_orig2 = calloc( strlen( psz_text) + 1, 1 );

De ha a forrás pufferben átugorja a string terminátor NULL karaktert, akkor adott esetben sokkal több adatot másolhat a célpufferbe (ami a memóriában ott van éppen, azt fogja JSS markupként tovább parszolgatni). Magyarul a memóriába jócskán bele tud szemetelni.

Ahhoz, hogy ezt támadásra ki lehessen használni meg kell sejteni, hogy mi lesz az, ami a forrásbuffer tartalma után van - ha szerencsénk van (mármint a támadónak), akkor szintén a médiából letöltött dolog, tehát befolyásolható a támadó által. És az is fontos, hogy a psz_orig2 puffert túlcímezve hova írunk. Ehhez is kell némi szerencse, hogy jó helyre jöjjön ki.

Én úgy csinálnám, hogy egy népszerű buildből indulnék ki, és debuggerrel megnézném, hogy hova esnek ezek a címek, és próbálnék olyan konstellációt csinálni, amiben valami fontos dolgot tudok célzottan felülírni a kraftolt datával. De ez már egy hosszabb elemzés lenne, dolgoznom is kell.

Ha pontosan tudod, hogy a programon belül mely hívások mely memória címeken vannak, akkor elvileg egy ilyen overflow-val oda is tudsz jumpolni nyomban (jump to address stored in a register) és szabadon használhatod az adott hívást, anélkül, hogy saját kódot kéne a memóriába beinjektálnod, és NOP-olnod se kell. A dolog hátránya, hogy 1-1 kód csak adott verzióra működik/működhet, mivel a memória címek verziónként változhatnak, illetve hogy ha van ASLR akkor azt külön meg kell még kerülni.
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Közben találtam egy hangyányit több konkrétumot + rengeteg találgatás: https://news.ycombinator.com/item?id=14408859