[7332] in bugtraq
Re: EMERGENCY: new remote root exploit in UW imapd
daemon@ATHENA.MIT.EDU (Kragen)
Tue Jul 21 16:54:30 1998
Date: Tue, 21 Jul 1998 12:36:06 -0400
Reply-To: Kragen <kragen@POBOX.COM>
From: Kragen <kragen@POBOX.COM>
X-To: Andy Church <achurch@DRAGONFIRE.NET>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To: <199807171248.IAA25275@Bahamut.dragonfire.net>
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
