From owner-freebsd-security Mon Jul 20 10:19:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA04499 for freebsd-security-outgoing; Mon, 20 Jul 1998 10:19:54 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA04491 for ; Mon, 20 Jul 1998 10:19:53 -0700 (PDT) (envelope-from patl@phoenix.volant.org) From: patl@phoenix.volant.org Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with smtp (Exim 1.92 #8) id 0yyJb7-0003Ni-00; Mon, 20 Jul 1998 10:19:37 -0700 Received: from localhost by asimov.phoenix.volant.org (SMI-8.6/SMI-SVR4) id KAA09561; Mon, 20 Jul 1998 10:19:34 -0700 Date: Mon, 20 Jul 1998 10:19:34 -0700 (PDT) Reply-To: patl@phoenix.volant.org Subject: Re: The 99,999-bug question: ... To: Paul Hart cc: security@FreeBSD.ORG In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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