Date: Mon, 3 Feb 1997 07:42:18 -0600 (CST) From: "Thomas H. Ptacek" <tqbf@enteract.com> To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Cc: tqbf@enteract.com, dg@root.com, torbjorn@norway.eu.net, freebsd-security@FreeBSD.ORG Subject: Re: Critical Security Problem in 4.4BSD crt0 Message-ID: <199702031343.HAA29502@enteract.com> In-Reply-To: <809.854976019@critter.dk.tfs.com> from "Poul-Henning Kamp" at Feb 3, 97 02:20:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
This thread really isn't going anywhere. My concrete suggestion is that you release security announcements as soon as you become aware of a security problem with your code, whether you found it or someone else did. If there's something I can do to help ensure that this happens, let me know. > Some of them, but remember that there is also a great deal of misguided > youth out there. Perhaps I have a bit more experience dealing with the "misguided youth" combing FreeBSD code than you do. Perhaps not. If I had to place a bet on whether the FreeBSD project or the underground had any particular bug, I would almost always put my money on the underground. Again, it seems to me like combing your source tree looking for coding errors is not your top priority; nobody expects it to be. However, if you're not doing that, you really don't have a choice but to resort to full disclosure. I think the bad guys are way ahead of you. > Rendering /sbin/restore broken as a result... :-( I'm not impressed. Oh well. I don't want to get into an argument about the merits or demerits of Mr. de Raadt. I'm sure you don't either. OpenBSD has it's strong points, FreeBSD has it's strong points, let's leave it at that. > I'm not really active in that end of it, and I'm sure we can use more > people for it :-) So if you have some time... Think about how much time and effort I've spent so far. =) I have time. I'm not dependant on the FreeBSD project to make this information public, as you know. I also don't speak for the FreeBSD project, so I'd prefer that announcements about security issues in FreeBSD be handled by a representative of the FreeBSD project. Again, my complaint is simply that prior experience has shown that security-related problem reports do not elicit announcements from the FreeBSD team to their users. I think this is wrong. In most cases, these problem reports affect many, many people running older versions of your operating system. As long as they're on the FTP site, they're supported. > This is unfortunately a lot easier said than done. If you want to spear > head this effort, please say so, we can always use more manpower. Heh. If you can point me to all the announcements you've made in the past year, I can fill you in on everything else I know about or have reported, and I can type them up in the format of your previous announcements. You can then feel free to distribute them as you wish. > Then again, chances are that they havn't, we will (usually) never know. Well, let's look at it this way: there's a problem in your 2.1.x code that renders *every single executable program* vulnerable to a trivially exploitable stack overrun. As stated before, this problem is now being actively exploited by unknown parties on the network. The bad guys knew about this before you did. To me, that's telling. I'm not trying to indict you for not knowing. I didn't know until I took a closer look at the twisted monstrosity that is your locale code (sorry, had to say it. =]). I'm simply suggesting that the most effective way to assist your users in maintaining secure systems is to disclose the vulnerabilities, along with patches, as quickly as possible. > How about this: If you find a hole, you send us a patch, and if we > do not fix it within a particular period (two weeks ?) you can post it > to the world ? Two weeks? You think a vulnerability window of (at least) two weeks is acceptable? I'd just as soon post it to the world immediately, so affected systems could get themselves patched. That's me, though. What would require a two week delay? Anything the obvious patch would break would be worth breaking to maintain security; you can release an "official, effective" patch later on and treat the initial one as a workaround. > not washing our laundry in public. If I find a security hole, and > nobody has explited it yet, I still see no reason for me to yell > out over the entire world that it's there. The fact that people Well, you and I disagree on that point. My perspective on this issue is pretty simple. I don't assume for a moment that I am the first person to find any given problem that I find. Experience has proven me right most of the time. Given this, I feel it's fairly important to neutralize the problem immediately by posting information about it. Silent fixes to your code don't help people that are running vulnerable code. When you find problems, the majority of the people running your code are vulnerable, even after you fix the problem. I think silent fixes are bad. I think every time you find a problem and silently fix it, you ignore the possibility that criminals on the network already found and are exploiting the problem - you're thus potentially allowing systems to be broken into. I'd much rather have to wade through your dirty laundry than see my systems broken into simply because I didn't have the time to keep -current. You obviously don't expect all your users to run -current (in fact, I get the impression that you discourage it for non-developers). You obviously want your users to be running secure versions of your OS. The only way to do this is to provide them with security information as it becomes available. Where do we disagree on this? ---------------- Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tqbf@enteract.com] ---------------- "I'm standing alone, I'm watching you all, I'm seeing you sinking."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702031343.HAA29502>