>> [...regular file races...] >Wrong. Perhaps you should do some profiling. This is trivial in lots >of cases. 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 [lcamtufat_private] Iterować jest rzeczą ludzką, wykonywać rekursywnie - boską [P. Deustch] =--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:43:05 PDT