IT IS EXPLOITABLE, and it will be exploitable... Look, strcpy and other
dangerous functions SHOULD NOT BE USED anymore, so there shouldn't
be any new trivial buffer overflows... But we still have noticable
amount of them every month. That's why we are designing generic fixes -
we're expecting that every program is bug-free, BUT ALSO we're using
non-executable stack patch, just for better security. We can't make
an universal kernel fix, which stops every attack, but we can at least
incerase skill needed to perform attacks... Non-executable stack
patch isn't the perfect solution, but it _prevents_ probably over 90%
exploitation attempts.
>It IS entirely possible to audit code. You are just talking lazy.
But, as you said: "There is no fix to gcc.c yet, and I've spent about
10 hours at trying to code a working one so far. It's a bitch.".
In the meantime, I wrote my kernel workaround in hour... It's
only TEMPORARY, secondary solution, but it works. One day, there will
be a better fix, preventing every race condition... But until yesterday,
most of these security holes (in gcc, gzexe, etc) were caught by
symlink fix. Now, symlink fix is not sufficient to prevent new
exploits, but 'secure pipes' can stop them.
_______________________________________________________________________
Micha³ Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.pl]
Iterowaæ jest rzecz± ludzk±, wykonywaæ rekursywnie - bosk± [P. Deustch]
=--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=