Anders Johansson wrote:
On Friday 08 February 2008 14:36:00 Aaron Kulkis wrote:
Other than *very* *old*, uncorrected code with buffer-overflow vulnerabilities, due to calls to strcat(3) instead of strncat(3), and similar pitfalls which are now very well understood since the first use in th 1987 Morris Worm, you have to provide some hard documentation (i.e. code sections) to make your point here.
Well, no, the morris worm wasn't the first time it was used. This paper
http://homes.cerias.purdue.edu/~spaf/tech-reps/823.pdf
was written shortly after the worm incident, and it describes buffer overflows as Although experienced C programmers are aware of the problems with these routines, they continue to use them.
I was a Computer Systems Engineering student when the Morris Worm hit, and until then, the problems of using strcat() instead of using strncat() were looked at more as a problem of exacerbating program bugs, but few if anybody had considered it to be a vehicle for overwriting the stack with both bogus stack-frame information AND rogue code.
I would say the situation is similar today. Experienced programmers are aware of the problems, but some continue to use the problematic functions, and inexperienced programmers just don't know any better.
What schools are these programmers graduating from where the use of strcat() doesn't bring about grading penalties? After the Morris worm was dissected, by George Goble(*) -- he of the original dual-CPU Unix kernal fame, the profs at Purdue were quite adamant that the use of strcat() and other unbounded functions must end, and their use MUST be replaced with their bounded cousins (strncat() and the rest). (*) We were lucky enough in the Electrical Engineering school to have some Gould Unix machines which we beta-tested for Gould, and were both very obscure at the time, and their design was based on the IBM 370 CPU, and thus the buffer overflows which were effective against both the VAX-11 and the 680x0-based Sun Microsystems machines.
We still see security patches issued for buffer overruns
We shouldn't panic, but we also shouldn't become complacent. I have complained in the past about the disturbing practice of encouraging people to disable signature checks on rpms, simply because it makes it easier to install a package. Given this practice, that would be a brilliant way of introducing bad code on a system
And bad code doesn't have to be "if(!strcmp(user, "blackhat") strcat(passwd, "password");", it could just as well be to change fgets() to gets(). I'd like to see the code review that would catch that in a hurry, and it would then be trivial to crack the program
For starters: grep -e "strcmp(\| gets(\|strcat(" *.c *.h
Anders
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org