Bugtraq mailing list archives
Re: EMERGENCY: new remote root exploit in UW imapd
From: kragen () POBOX COM (Kragen)
Date: Tue, 21 Jul 1998 12:36:06 -0400
On Fri, 17 Jul 1998, Andy Church wrote:
How many file races and symlink-following errors (for example) would we hear about if programs were written in such a language? Lots.
True. But the number of bugtraq postings would still drop by half, and the number of root-compromise holes would drop by perhaps a factor of three. Of course, buffer overflows are fashionable this year. Perhaps next year it'll be something else.
(And if not, imagine the performance hit when every array access has to be bounds-checked. Security is good, but if it drops performance into a tar pit you'll still have plenty of problems-- especially when your competitor is using a faster C program.)
I've heard that bounds-checking typically increases the time to do things by 30-50%. The bounds-checking egcs people are optimistic that this can be reduced. Even so, it's much smaller than the variance introduced by different degrees of optimization and efficient design. Also, many security-sensitive programs are not speed-critical. httpd nntpd, and mail servers are exceptions, of course, but finger, su, xterm, and the hundreds of other programs in which buffer-overflows have been recently found are not.
I have to say that I've never programmed in Ada or Modula-2 myself (and it's been years since I've touched Pascal, which I recall as being similar to Modula-2), so I can't comment on just how appropriate they'd be to server programs or deny that using such a language could improve security. But we won't get _truly_ secure programs until people can program securely; and people that can program securely can write secure programs in _any_ language.
There have been proposals to require mechanically-verifiable proofs of certain security properties for secure programs. This would increase development time, but would make it impossible to publish programs that did not have these properties. I think this is probably silly. Kragen
Current thread:
- Re: New Java Security Flaw Found, (continued)
- Re: New Java Security Flaw Found Greg Alexander (Jul 18)
- Re: New Java Security Flaw Found Sean Garagan (Jul 20)
- Fwd: Security warning: Netscape 4.0x https & Squid 1.2beta proxy Fred Donck (Jul 20)
- N-Base Vulnerability Advisory TTSG (Jul 20)
- IRIX 6.4 ioconfig(1M) and disk_bandwidth(1M) Vulnerability SGI Security Coordinator (Jul 20)
- IRIX 6.3 & 6.4 mailcap vulnerability SGI Security Coordinator (Jul 20)
- Bounds Checking Aleph One (Jul 20)
- Re: Bounds Checking Ari Heitner (Jul 21)
- Re: Bounds Checking Andrew McNaughton (Jul 21)
- Re: New Java Security Flaw Found Greg Alexander (Jul 18)
- Re: EMERGENCY: new remote root exploit in UW imapd Andy Church (Jul 17)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Craig Spannring (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd matt (Jul 17)
- Re: EMERGENCY: new remote root exploit in UW imapd Niall Smart (Jul 17)
- Bounds checking - historical aside Russell Fulton (Jul 20)
- Re: Bounds checking - historical aside Brett Glass (Jul 21)
- Re: EMERGENCY: new remote root exploit in UW imapd Alex Belits (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Kragen (Jul 21)
- Bounds checking - historical aside Russell Fulton (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Allen Smith (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Allanah Myles (Jul 20)
- Re: EMERGENCY: new remote root exploit in UW imapd Dave Andersen (Jul 21)