Date: Mon, 20 Jul 1998 10:19:34 -0700 (PDT) From: patl@phoenix.volant.org To: Paul Hart <hart@iserver.com> Cc: security@FreeBSD.ORG Subject: Re: The 99,999-bug question: ... Message-ID: <ML-3.3.900955174.5641.patl@asimov> In-Reply-To: <Pine.BSI.3.96.980720090640.6101B-100000@anchovy.orem.iserver.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Sun, 19 Jul 1998, Brett Glass wrote: > > > It'll only get worse, especially so long as we use C; the language is > > so prone to array overruns and buffer overflow exploits. > > The language only does what it is told, how can it be held responsible? C > is not prone to exploitation, C programmers are. And they're still making > the same tired mistakes over and over. Nonsense. C makes it -very- easy to shoot yourself in the foot. You have to go out of your way to avoid it. It requires constant vigilance. C programmers are still makeing the same tired mistakes because C encourages those mistakes. And, unfortunately, aspects of the C language design make it difficult, if not impossible, to add any sort of compiler-generated checking. (Array-pointer equivalence is one of the more brain-damaged misfeatures.) More reasonable languages make you go out of your way to shoot off your toes. > > I don't think anyone should feel antagonized when I emphasize the > > importance of fixing this problem -- especially after the extensive > > personal cost it has had, and will have, for me. > > Brett, this type of exploit has been around for many years (one element of > the original Internet worm was based on a buffer overflow in fingerd). > And each time someone gets hacked they have the same grandiose visions for > building elaborate kludges to make sure they're never hacked again. But, > alas, these visions are only Band-Aid solutions. The real problem is > flawed application code. Instead of dreaming up fancy kernel kludges, > let's direct our efforts toward auditing code, thus attacking the problem > at the root. Auditing code is only part of the correct approach. Another major goal is to restrict the scope of potential damage if a program is compromised. One way to do this is to avoid root permission; or to irrevocably surrender it at the earliest possible moment. (One of the reasons I chose the Cyrus IMAP server over imap-uw is that Cyrus delivery runs entirely as a non-privileged pseudo-user; and the server gives up root permission as soon as it has bound to the privileged port.) And, yes, another approach is to use languages with built-in bounds checking, etc. The use of such languages doesn't eliminate security hazards; but it does help. And it allows the programmer to focus on the higher-level design issues. > I don't want to seem callous to your plight because I know how you must > feel, but does not the old adage "once bitten, twice shy" apply to your > situation? You were hacked. Now you know better. Can we assume that > this will not happen again? The only way to be completely secure is to keep your machine in a secure room; with NO external access or network connectivity. But that's not really compatible with running a mail server... :-) Cracks happen. Have a good backup and recovery plan. Have a good detection plan. > BTW, you aren't running imapd are you? A new hole, just as evil as the > popper hole, was recently revealed in that. See the Bugtraq archives at > http://www.netspace.org. Only in the imap-uw code. It doesn't affect Cyrus. -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ML-3.3.900955174.5641.patl>