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
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:06:52 PDT