s verzí 7 došlo k velkému refactoru některých částí, vč. téhle, je to tam určitě celou verzi 7, tj. tak 15 let. Ve verzi 6 je ale dotčený kód stejný, už ale neumím rychle dohledat, jestli zneužití nebrání jiná část. Poslední větší úprava chybného kódu proběhla v roce 2001 na verzi 6, https://github.com/vim/vim-history/commit/a2aaceb7ce102b5060cd6f6db0e58b5fe7c58bca
Není ale nic jednoduššího než si to vyzkoušet, ve zprávičce je odkaz na funkční PoC.
17. 6. 2019, 12:07 editováno autorem komentáře
pokud mí ale ten ukázkový kód spustí příkaz při otevření vim, mohu mít jistotu, že ta verze zranitelná prostě je. Pokud se ale nic nestane, máš pravdu, že nemohu tvrdit, že zranitelná není.
Podle krátkého čtení kódu, to na zranitelnost ve vim 6 ale vypadá, nemám nikde tak starou verzi (kód se mi na první pokus nepodařilo zkompilovat kvůli závislostem), abych to odzkoušel a mohu aspoň tvrdit, že se to tam děje také. Pro verzi 6 žádný patch zatím nevyšel, je ale poměrně triviální ho backportovat.
Tak pak mi asi něco uniká? Protože podle mne spustit PoC přirozeně stačí aby měl člověk jistotu.
Nevím jak fungují standardně útoky, ale crackerům se asi obecně moc nechce zkoumat alternativní scénáře, když můžou vzít perfektně zdokumentovanou chybu a pomocí daného postupu zneužít miliony nezaplátovaných distribucí.
Takže předpokládám, že vezmou stávajicí koncept, na základě něj připraví útok a ten testují. Kdo nezáplatoval má smůlu, kdo záplatoval má vyhráno.
Takže pokud na vašem distru postup nezafunguje, předpokládám že jste z obliga.
Pokud spustíte ověření konceptu a chyba se projeví, máte jistotu, že je váš systém chybou postižen. Pokud se ale neobjeví, neznamená to, že váš systém napadnutelný není – může to být nedostatek toho prototypu. Na některých příkladech je to evidentní – až se zase objeví nějaká chyba v procesorech, může někdo napsat pro ověření aplikaci, kterou přeloží jenom pro Windows. Vy tu aplikaci na Linuxu samozřejmě nespustíte – což ale neznamená, že váš procesor není postižený.
Takže pokud na vašem distru ověření konceptu nefunguje, nevypovídá to vůbec nic o tom, zda je nebo není zranitelné.
Ono záleží. Jsou typy chyb, kde neúspěch zneužití může znamenat jen to, že se člověk málo snažil. Extrémním příkladem jsou různé side channels, kde může jít konkrétní exploit snadno (i neúmyslně) rozbít, aniž by se tím zranitelnost opravila.
Jsou ovšem i chyby, kde lze udělat spolehlivý exploit a je pak prakticky jisté, že jeho nefunkčnost znamená vyřešení zranitelnosti. Pokud teda programátor nebyl lajdák/kreativec a neudělal něco ve stylu zabanování curlu.
Tady je to takové hraniční. Zneužívá se stabilní funkcionalita, nečekám tedy náhlé nečekané rozbití exploitu třeba změnou názvu. (Něco jiného by bylo nedokumentované REST API, kde by exploit mohl dávat falešně negativní výsledky kvůli přejmenování endpointu. To se u modelines jen tak nestane.) Nicméně – zvlášť pokud se to vezme blacklistem – se tu může objevit třeba jiná funkce, kterou půjde dosáhnout téhož. Pak je ale otázka, jestli to ještě považovat za tutéž zranitelnost, nebo ne.