Vlákno názorů ke zprávičce Stack Clash - lokální zranitelnost v Linuxu, BSD a Solarisu od Havis 911 - Tych zranitelnosti suvisiacich s Stack Clash bude viacej: glibc:...

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