Date: Sun, 1 Oct 2000 01:05:37 +0200 (SAST) From: Justin Stanford <jus@security.za.net> To: Warner Losh <imp@village.org> Cc: Jordan Hubbard <jkh@winston.osd.bsdi.com>, security@FreeBSD.ORG Subject: Re: Security and FreeBSD, my overall perspective Message-ID: <Pine.BSF.4.21.0010010105240.26020-100000@fyre.somcol.co.za> In-Reply-To: <200009302258.QAA13969@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
<Lusers point of view> Sounds good to me. </Lusers point of view> On Sat, 30 Sep 2000, Warner Losh wrote: > In message <2376.970339459@winston.osd.bsdi.com> Jordan Hubbard writes: > : (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 body is proposing that we change that. At least not that I'm aware > of. > > : (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. > > 1 to 10 is too many levels. But I'm not sure what the right number > is, so let's assume it is N and move on. > > I like this idea of having N levels. It is a generalization of what > we've done in the past. In addition, we can issue warnings in the > packages based on these levels, which is also good. > > : (c) Start doing meaningful auditing of code and stop chasing > : various illusions of security. By this, I mean not just > : 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. They may lie completely > : outside the area of buffer overflows (there being many many > : ways to write insecure code) or they may be very specific > : buffer overflows, where the user has an actual opportunity to > : control the data going in. Data which is simply moving around > : internally and never has the opportunity to overflow under > : user control is not data you have to worry too much about. > : In fact, in some cases you might prefer the code to > : dump core and actually expose the bug rather than just > : silently truncating data and producing rather more > : erroneous results. > > Kris and I have read the code to pine. While I haven't discussed it > with Kris, it looks like there are lots of problems in pine that are > waiting to be exploited. It is a feeling I've gotten from working on > this sort of thing for a long time, rather than a specific "this line > of code is wrong." Generally, we, and OpenBSD, have gone the way of > truncating long strings almost all the time. This has proven to be an > effective deterrant. The arguments about what is better have largely > been theoretical and haven't been implemented on a wide spread basis > as the buffer truncation has been. To date I'm unaware of any > problems caused by simply truncating the data. > > Reading the code takes a whole lot of time. Especially the pine > code. It takes a lot know know what is going on. > > Requoting: > : Data which is simply moving around > : internally and never has the opportunity to overflow under > : user control is not data you have to worry too much about. > > Ah, there's the rub. Now you too are into the probabilty game. It is > hard to identify such data (since most programs have very little > purely internal data, although much of the external data does come > from trusted locations (eg /etc/master.passwd)). It is hard to know. > With > 4000 instances of unsafe API usage, it is very likely that > we'll see at least 10 bugs bite people in this area. Assume that each > instance has a .1% chance of being an exploitable buffer overflow > (this number may be too low). This means that the chances of there > being NO exploitable buffer overflows are .999^4000, or 1.8%. The > chances therefore that there is at least one buffer overflow is 98.2%. > Even if we assume there's a .01% chance, there's still a 33% chance > that we have at least one that's exploitable. Those are horrible > odds, in my opinion (and I was conservative in calculating them > because I used 4000 rather than the actual number). > > That's why it is hard to know if this port is safe or not. The odds > are extremely high that it isn't. On Jordan's scale I'd rate this at > a 9. 10 would be for ports with known security problems. > > I do like the trust level metric. For ports that we've extensively > reviewed, we could rate them 1. For ports that we haven't, but that > run as normal users we could rate them as 2. For ports we haven't > that run at elevated privs, we could default to 5 (all these assume N > is 10). > > Warner > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010010105240.26020-100000>