Date: Fri, 16 Feb 2001 11:50:45 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: Ruslan Ermilov <ru@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: [Call for *quick* review] architecture-specific manpages Message-ID: <Pine.NEB.3.96L.1010216112538.56503B-100000@fledge.watson.org> In-Reply-To: <20010216100833.G2869@sunbay.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Feb 2001, Ruslan Ermilov wrote: > Two days ago I fixed the bug in manpath that would allow a malicious > user create empty catpages, and sent the notice to security-officer > (which you are a member of). I got no replies so far, and I am a bit > confused since (in my opinion) this definitely deserves the security > advisory. If the security-officer responds slowly to requests, it's because we keep having to put out fires because people keep committing security problems to the tree. Often times, we receive little or no assistance from code maintainers in correcting problems they've introduced, and usually end up fixing the problems ourselves rather than being able to rely on code maintainers to do the job right the first time, or fix it when a mistake is pointed out. We have little or no success at pursuading people who introduce security holes to offer us any assistance in helping them in their future commits, as we ask them to send mail to the -audit list for review, and more than likely they flat out refuse, saying we can go read the changes in the repository later and to stop wasting their time. Often, we're busy being flamed for security holes introduced by other people that we spend time fixing. The following two paragraphs refers not specifically to you, when saying "you", but rather the FreeBSD developer community as a whole, so please don't take it personally, as it's not clear that 3/4 of this applies to the man bug you're refering to. So if you have a problem with the security-officer timelag, there are a number of things you can do. For one, you can cooperate in making our lives easier by looking for review on the -audit mailing list, so we don't have to sit there and play CVS games to find and fix all the security holes. That way you can be involved in the testing and fixing of the problems, and not have us constantly looping on buildworld trying to fix problems before they are MFC'd or -CURRENT turns into -STABLE. You can avoid MFC'ing rapidly before we've had a chance to review code, especially if the code is sensitive to security (i.e., it runs with privilege (daemons, periodic code, ...), runs setuid or setgid to any user, binds network ports, uses /tmp without using mkstemp(), and so on). You can try to remember a few simple coding guidelines, such as always checking return values on string functions (or any function) and attempting to fail cleanly and "closed", and not reproducing security holes that have been fixed literally thousands of times before. You can remember that every time we have to release a security advisory, it costs a lot of people a lot of time and money. It takes us substantial time to evaluate/fix the problem, write the advisory, build patches for various branches and releases, and then provide support for all the people who can't figure it out. It costs everyone money who has to upgrade to deal with a security problem, and that adds up to a lot of money in administrator time. Security holes and fixes aren't "fire and forget", they waste everyone's time. And when the vulnerabilities result in active exploitation and compromise, then they result in people switching away from FreeBSD. Also, they make us look pretty rediculous. We've released more security advisories this year than Microsoft has (28 vs 12). If you exclude ports and re-releases (leaving aside the ipfw rerelease, which should not be ignored), we're doing better, but even so, that's far from good. Since the beginning of the year, we've averaged over an advisory a week on the base system, and yes, we have more in the queue. This year we've been particular prone to failure in the contrib code (BIND, OpenSSH), but last year was fraught with base system problems that were clearly not in the base code. Many of this year's advisories have been on problems introduced a fair distance in the past; many of last year's that was not true for (i.e., the problem was reported within 6 months of it being committed, and typically in a release branch). And, if you're interested, there are repeat offenders who seem to be responsible for the majority of the security holes we deal with. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010216112538.56503B-100000>