Bugtraq mailing list archives
Re: EMERGENCY: new remote root exploit in UW imapd
From: mouse () RODENTS MONTREAL QC CA (der Mouse)
Date: Tue, 28 Jul 1998 14:09:36 -0400
Beware of the Dijkstra phenomenon.
The phenomenon is that immodular code seems more ``productive'' than heavily modularized code. You can read or write many more lines per hour of malloc(), strcpy(), free() than of unfamiliar high-level routines.
This is actually "you can read or write many more lines per hour of familiar calls than unfamiliar calls"; if you're not familiar with malloc(), strcpy(), and free(), you can't churn them out very fast either - at least not with even the minimal correctness most programs exhibit.
Of course, the modular code ends up being _much_ smaller.
This is far too dogmatic a statement. It is true in many circumstances, but it is also false in plenty of other circumstances. I recently wrote a program to check if a file had been touched recently (for a suitable value of "recently") and if not, to restart the daemon that should have been touching it. The code calls only a handful of routines more than once: fprintf (3 calls), exit (6 calls), open (2), dup2 (3), close (2), strerror (3). (The routines called only once are lstat, gettimeofday, fork, ioctl, setpgrp, chdir, unlink, getdtablesize, execle.) I don't for a moment believe using "modular code" would have made this program "_much_ smaller". Indeed, I *am* using a "modular" module, namely stdio, and my offhand guess is it's responsible for more than half the program's size (when linked static - otherwise stdio's contribution isn't easy to work out; the static version is over four times the size of the non-static version, on disk). The modular code usually ends up being slower, too. Not enough slower to matter, in many circumstances, but it's something to keep in mind.
It also lets you independently check the correctness of each module; this scales to arbitrarily large systems if the modules remain small.
It also means that a missed bug affects an arbitrarily large proportion of the system as a whole, of course. der Mouse mouse () rodents montreal qc ca 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Current thread:
- Re: EMERGENCY: new remote root exploit in UW imapd, (continued)
- Re: EMERGENCY: new remote root exploit in UW imapd Dave Andersen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Jim Greene (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Peter Jeremy (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd IBS / Andre Oppermann (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 22)
- Re: EMERGENCY: new remote root exploit in UW imapd Adam Shostack (Jul 23)
- Security Bulletins Digest vtmue () HEAVEN RUF UNI-FREIBURG DE (Jul 23)
- Apache 1.3.1 Released! Aleph One (Jul 23)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 22)
- Re: EMERGENCY: new remote root exploit in UW imapd Alex Le Heux (Jul 22)
- Re: EMERGENCY: new remote root exploit in UW imapd D. J. Bernstein (Jul 28)
- Re: EMERGENCY: new remote root exploit in UW imapd der Mouse (Jul 28)
- Object tag crashes Internet Explorer 4.0 Georgi Guninski (Jul 28)
- Re: Object tag crashes Internet Explorer 4.0 Matt Rose (Jul 29)
- Re: EMERGENCY: new remote root exploit in UW imapd David Schwartz (Jul 28)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 29)
- Object tag crashes Internet Explorer 4.0 Georgi Guninski (Jul 28)
- Re: EMERGENCY: new remote root exploit in UW imapd D. J. Bernstein (Jul 29)
- Re: EMERGENCY: new remote root exploit in UW imapd Bill Royds (Jul 29)