Názory k článku
Stack Clash - lokální zranitelnost v Linuxu, BSD a Solarisu

Tych zranitelnosti suvisiacich s Stack Clash bude viacej:
glibc: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000366
sudo: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000367
exim: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000369
libffi: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-1000376

ano, vzhledem k tomu, že se musí překompilovat všechny binárky a knihovny, tak by každá z nich mohla mít své CVE

gcc -fstack-check urcite pomaha, ale ma urcite obmedzenia
https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01343.html
GCC upstream ma plan urobit novu variantu -fstack-check=<something>

Bude zaujimave pozriet ako sa s touto "Memory Management vulnerability" vysporiadaju jednotlive distribucie. Neviem si dost dobre predstavit ako prekompiluju vsetky balicky (snad jedine Gentoo to bude mat bez problemov).

"Neviem si dost dobre predstavit ako prekompiluju vsetky balicky (snad jedine Gentoo to bude mat bez problemov)."

Unika mi neco? Kde je problem v tom zmenit buildscript, povysit versi, zbuildit, prohnat pres QA a releasovat?

"Unika mi neco? Kde je problem v tom zmenit buildscript, povysit versi, zbuildit, prohnat pres QA a releasovat?"

No zober si napr najnovsi Debian Stretch, ktory ma 51 687 balickov. Teraz si toto cislo vynasob poctom architektur ktore su zranitelne (x86 amd64 arm?). Dalej zoberme ze 1% balickov bude mat nejaky problem s -fstack-check (optimisticky odhad), na ktory treba zasah vyvojara a upravu zdrojoveho kodu daneho balicku. Myslim ze prave toto moze byt ten problem, kde nepomoze ani to, ze mame super vykonne build servery a tinderboxy ;)

Moc tomu nerozumím tak prosím o vysvětlení.

Když se alokuje prostor pro lokální proměnné, dělá se probe každé stránky, pokud je potřeba větší velikost než je velikost stránky.

Funkce alloca také dělá probe.

Chybu buffer overrun nepočítám, to je jiný druh chyby.

Takže v čem je problém?

Pokud jsem to pochopil správně, tak ve zmíněných operačních systémech se v případě, že "dojde" zásobník (což je detekováno tak, že dojde k výpadku stránky na adrese pod jeho dnem (stack start)), jádro jej prodlouží (alokováním stránky, která vypadla, popř. dalších).

Pokud k výpadku stránky nedojde, jádro nedetekuje nic. Což je právě klíčové (stejně jako fakt, že zásobník může růst "donekonečna", což je rozdíl např. oproti Windows). Zásobník pak "přeteče" do něčeno jiného (obvykle haldy). Pak již tam jsou hlavně detaily o tom, jak daného chování docílit.

Pochybuji, že se dělá explicitní probe při každé implicitní alokaci lokálních proměnných. Obvykle se pouze sníží hodnota ukazatele na vrchol zásobníku (ESP na ia32, RSP na amd64/x64). Neznám bohužel detaily z linuxového či BSD světa (jen něco z WIndows).

Právěže Windows, tedy přesněji kompilátor VC++ dělá probe každé stránky, pokud se alokuje něco většího.

Ano, ale ve Windows se guard page používá trochu jinak – ohraničuje aktuálně alokovnou oblast zásobníku (dno). Když se na ní narazí, alokuje se další stránka/y a guard page se posouvá dále. Z čehož vyplývá, že guard page se používá ke stejnému účelu jako page fault v *NIXech/BSD. Pokud se tedy alokuje větší část na zásobníku, je nutné onu guard page nepřeskočit.

Zaujimava analyza z dielne grsecurity:
https://grsecurity.net/an_ancient_kernel_hole_is_not_closed.php

Na tuto zranitelnost vydal Andrea Arcangeli v roku 2004 patch, ktory ale nebol zahrnuty do kernelu.
No a v roku 2005 bola Davidom Howellsom omylom pridany do kernelu riadok
int heap_stack_gap = 0
ktory sa prvy krat objavil v prave v patchi od AA: http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-09/7904.html