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