Movatterモバイル変換

[0]ホーム
URL:

Home page logo
bugtraq logo

Bugtraqmailing list archives

PreviousBy DateNext
PreviousBy ThreadNext

Re: DJB's students release 44 *nix software vulnerability advisories

From: Stephen Samuel <samuel () bcgreen com>
Date: Tue, 21 Dec 2004 11:39:49 -0800
Side effects is my issue here.It'a a fine thing to encourage programers to design their software well,and fix bugs quickly. I've got no problems with punnishing programmersfor bad code, but there are different issues to deal with in the classroomand out in the wild.If you wanted to run a course where students are failed for having one bugin a 10,000 line project, they were aware of the standards going in, andgiven the training and tools such that the standard wss achievable, notonly wouldn't I have a problem with it -- I'd encourage everybody I knewto hire anybody who passed the course.  (at least, anybody I knew whogave a rat's ass about producing quality code).When dealing with code out in the wild, however, you have two communitiesto consider -- the programming community and the user community. Hmm. OK,three -- there's also the cracking community.We're now living in a world where the time from description of a bugand creation of a commercially viable exploit can approach zero.  The'commercially viable' exploits are viruses and worms used to generatezombie armies of tens of thousands of remote-controllable 'bot machinesthat can spread spam, launch DDOS exploits and do whatever else theircontrollers wish.Out in the wild, there is a wide gamut of care about producing qualitycode and fixing bugs.  At one extreme is Microsoft taking about 6 monthsto *NOT* fix a security bug in WMP 9. (The fix is only available in WMP10 released this week).  That the programmer who reported the bug to MSwould wait the 6 months for _any_ real response from MS, I would agreewith your probble determination that it is a disservice to the usercommunity and does little more than reward MS for "trying to protecttheir shoddy security practices."Near the other extreme are BSD coders working feverishly to fix a bug(and find any related errors) with _theoretical_ secrity issues intheir code in mere hours because the code was security related and theyfelt a very real responsibility to ensure that their community had securecode.I would think that an optimal responsible disclosure policy should bedesigned to (as much as possible) punnish the former while enabling thelatter.  Not all coders hav achieved your standard of never, everreleasing buggy code at any time of their life. As much as we may wishotherwise, I doubt that that day will arrive soon either.  A realisticdisclosure policy needs to take into accunt the interests of the threecommunities I mentioned above.I would suggest that a realistic disclosure policy would:1) Discourage and punnish shoddy security practices.2) Enable responsible software maintainers to realisticly respond   to bugs.3) Give the user community timely and usable information about bugs in   the code that they're using.4) Minimize the ability of the cracker community to exploit these bugs   before 1 and 2 haveYour zero Time To Respond approach would address 1, but do nothingto astisfy 2-4.  It doesn't so much punnish bad programmers as itdoes encourage crackers to read your missives.  Even the best ofprogrammers have to sleep, and if you release your exploit justexploit just as the team/person responsible for the maintenance ofa piece of software is going to sleep, crackers will have up to8 hours to code and use your bug before the responsible programmereven wakes up to read the email about exploited code.Even if rd party coders have managed to generate a fix, there won'tbe an official release of the fix until the responsibe programmershave at least had an opportunity to vette the proposed fixes.A reasonable and responsible disclosure policy should be to (unlessthere are signs that an exploit is already in use) allow responsiblea realistic (if short) opportunity to fix the instant bug and audittheir code for similar errors -- thus at least allowing the*possibility* that a fix could be released at the same time as theannouncement of the bug.If a fix can be announced at the same time as the bug, users have anopportunity to install the fix while crackers are still crafting acommercial exploit.I don't think that 24-48 hours (or even longer) is an unreasonablearning time for unexploited bugs.  I'm not asking for time to 'bedelusional', I'm asking for a reasonable ammount of time for aresponsible programmer to ensure that his/her user community isproperly served and protected from the effects of the bugs.6 months with no fix, on the other hand is obscene. I honestlydoubt if companies like Microsoft will ever treat Security asa genuine responsibility aas opposed to a PR issue.  On the otherhand, it is far less likely that they'll start respondingreasonably if they don't even have a hope of being able to crafta fix before crackers have created a 'live' exploit.D. J. Bernstein wrote:> Shu T. Messenger writes:>>>In each case, Professor Bernstein notified the author of the>>vulnerable package on Dec 15 via e-mail. This mail hit Bugtraq on the>>16th, giving one day for vendors to provide fixes.>>> Actually, I sent all of these notifications to the public securesoftware> mailing list (http://securesoftware.list.cr.yp.to) at the same time that> I sent them to the authors. It certainly wasn't my intention to give the> authors an extra day of self-delusion.>>>>Is the class on responsible disclosure next semester perhaps?Also posted:http://www.bcgreen.com/comments/2004/bug-release.html--Stephen Samuel +1(604)876-0426                samuel () bcgreen comhttp://www.bcgreen.com/~samuel/   Powerful committed communication. Transformation touching     the jewel within each person and bringing it to light.
PreviousBy DateNext
PreviousBy ThreadNext

Current thread:

[8]ページ先頭
©2009-2026 Movatter.jp