Correct - the approaches work fine when race conditions are eliminated

Posted Aug 16, 2007 14:35 UTC (Thu) by dwheeler (guest, #1216)
In reply to: Please educate a curious cat by felixfix
Parent article: Exploiting races in system call wrappers

Correct; the attacks ONLY work if the design permits race conditions. The notion that user-space data will stay unchanged during a kernel call is untrue is practically all of today's OSs, and this attack worked in the 1960s and 1970s too (it's well-documented). The solutions are well-documented, too; eliminate the race condition. The "easy" way is to copy all data into the kernel, and then use that protected version. The trick is to get good performance as well.

to post comments

Correct - the approaches work fine when race conditions are eliminated

Posted Aug 23, 2007 7:13 UTC (Thu) by Cato (guest, #7643) [Link]

Indeed - this model of 'copy first then check' was known as 'touch once programming' over 20 years ago, so there's little excuse for repeating this mistake again. Perhaps what's needed is smarter static analysis tools that can point out this sort of error?

Getting good performance is a challenge, but with the speed of modern CPUs I'd rather spend some CPU cycles on copying than spend many administrator hours responding to a security breach.