Date: Sat, 30 Sep 2000 16:58:19 -0600 From: Warner Losh <imp@village.org> To: Jordan Hubbard <jkh@winston.osd.bsdi.com> Cc: security@FreeBSD.ORG Subject: Re: Security and FreeBSD, my overall perspective Message-ID: <200009302258.QAA13969@harmony.village.org> In-Reply-To: Your message of "Sat, 30 Sep 2000 11:44:19 PDT." <2376.970339459@winston.osd.bsdi.com> References: <2376.970339459@winston.osd.bsdi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009302258.QAA13969>