From owner-freebsd-security Sat Sep 30 12:22:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 8CD4337B502; Sat, 30 Sep 2000 12:22:17 -0700 (PDT) Received: (from kris@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id MAA64508; Sat, 30 Sep 2000 12:22:17 -0700 (PDT) (envelope-from kris@FreeBSD.org) Date: Sat, 30 Sep 2000 12:22:17 -0700 From: Kris Kennaway To: Jordan Hubbard Cc: "Brian F. Feldman" , Roman Shterenzon , Kris Kennaway , security@FreeBSD.org Subject: Re: Security and FreeBSD, my overall perspective Message-ID: <20000930122217.A51270@freefall.freebsd.org> References: <2376.970339459@winston.osd.bsdi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <2376.970339459@winston.osd.bsdi.com>; from jkh@winston.osd.bsdi.com on Sat, Sep 30, 2000 at 11:44:19AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Sep 30, 2000 at 11:44:19AM -0700, Jordan Hubbard wrote: > > Who has the motivation (of any type) to find and fix the likely hundreds of > > security problems left, though? > > Again, the word is "likely" here and I could just as easily say that > parts of what we currently ship in the bindist are "likely" to have > bugs because past experience has shown this to be true and software is > always an exercise in compromise between time/resources available and You could say that, but you'd be making an unsupported claim of likelihood. You are confusing "probable" with "well, we can't rule it out", which of course applies to 99% of all code. Not so for what I did with pine: it's had two problems reported in the past few weeks, and a look at the code shows that because of the offensive (as opposed to defensive) way it's written it is very likely that more problems OF THE SAME KIND lurk beneath the surface. Given this, I have something concrete to point to when I say problems are likely. > Some people have also cited arguments that if we don't protect the > administrators from their own incompetence, they'll feel betrayed by > FreeBSD and go run Windows or something (which has an excellent > track-record for security). I also think that's a ridiculous argument > since, if followed to the letter, can only lead to situations like we > have in society today where every activity which could be even > remotely considered dangerous is either forbidden or comes with > warning labels 10 inches high, right down to the hot coffee ("WARNING: > This is HOT COFFEE. DO NOT POUR IT INTO YOUR CROTCH!"). Well, thats NOT what I meant, and you're reading a different interpretation into my words. Read on: > This is Unix. You're supposed to have at least a minimum level of > clue in order to use it and dumbing it down so that this is no longer > necessary would not constitute an advance. If we want to do something > useful when it comes to all-around security, we should: Okay, quick show of hands. How many people blindly trusted pine before this week? How many people would pick up a copy of fsdb(8) and/or ipfw(8) and feel blindly confident they know how to use it properly without screwing themselves up? There are three points at work here: 1) Tools which are documented as being dangerous or which can compromise your security fall into the "well, it's your own fault category". 2) Almost no-one thinks about client applications as a security risk. Most of us are trained to think of servers as potential points of weakness, but client applications like pine and netscape get little attention. 3) Theres nothing an end-user can do to protect himself with certainty from pine, short of "don't read mail with it". Again, this is a statistically uncertainty given that I havent spent days of my life doing a thorough code audit, but I'm willing to put money on the existence of further vulnerabilities in the code. What I have done (and will finish doing when I add the install-time security warning) is move pine into category 1. > (a) Continue to issue advisories for both the "system" and for > ports so that people are properly informed about > vulnerabilities when they're actually found (and not just > "suspected"). No-one's breathed a word about changing this. However, I will be adding a cautionary warning on the next pine advisory, dealing with the currently known remotely exploitable buffer overflow, that it is the opinion of the security officer that there are probably further problems waiting to be discovered. > (b) Add a new field to the ports infrastructure which indicates > level of "trust" the project/security people have in that > port. E.g. instead of having one big knob rather off-puttingly > labelled 'FORBIDDEN', have a 'TRUST' or 'SECURITY_LEVEL' variable > which goes from 1 to 10. Then the ports infrastructure can, if > it wishes to, issue warnings of varying severity based on the > trust level. I've thought about this, but it needs someone to implement it, so we have to work with existing tools in the meantime. > (c) Start doing meaningful auditing of code and stop chasing > various illusions of security. By this, I mean not just Waitasec, what do you mean "start"? FreeBSD is basically the only operating system project which *is* auditing this kind of code (impression based on the security advisory output of all of the other OSes). > blindly grepping around and assuming one is doing something > useful by replacing certain functions with ones which > bounds-check but actually *reading* the code and seeing > where the genuine flaws lie. And again, there was more than blind grepping involved here with pine. But it's simply not something I have the time, nor the inclination to correct, the code misdesign being too endemic and the required time investment being singularly massive. Patches by anyone else will be gratefully accepted, but a warning about the trust level of the code will remain in the meantime. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message