lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5705323910D7D2118E3400C00D0062C102CD623E@phyexha.physics.uiuc.edu>
Date: Mon, 19 Jan 2004 16:39:09 -0600 (CST)
From: Damian Menscher <menscher@...c.edu>
To: Alun Jones <alun@...is.com>
Cc: bugtraq@...urityfocus.org
Subject: Re: What is the point here?


On Sun, 18 Jan 2004, Alun Jones wrote:

> And the moderators for this mailing list need to take some responsibility
> (ooh, that's going to get my post rejected, for sure!), and start rejecting
> "updated" POCs unless they serve some security _improvement_ purpose.  For
> instance, if the vendor disclaims the presence of the bug, downplays it, or
> uses the POC's tie to one OS or another to claim that other OSes are safe.

That's dangerously subjective.  Rather than putting the weight on the
moderators, how about the posters show some responsibility?  Most posts
are doing it for the publicity -- if it's negative perhaps they'll learn
to be more responsible in the future.

> Posting exploits is _not_ a measure of first-resort.  Exploits should be
> used as proof of concept in the last-resort, when vendors or admins have
> entirely ignored a problem that you have tried to warn them about.  Exploits
> should be released as proof of concept _after_ a successful patch has been
> released, so that admins can test that the patch fixes the hole (of course,
> that would mean they'd want to test the exploit on an unpatched machine
> first), or so that they can verify that the patch applies a full fix.

I agree completely.  Let the company release a patch, and release a POC
shortly after so admins can test the fix.

> I'd like to think that Bugtraq positions itself as something more than a
> semi-sneaky, behind-the-back-of-the-vendors rant group, or an assembly point
> for root-kit starters.  Moderators, please stop accepting posts where the
> poster has stated specifically that they have not yet notified the vendor,
> or where the only new thing that is contributed is a more insidious version
> of an existing exploit.  And posters, please consider carefully before you
> post whether what you post is going to contribute to an increase in security
> or a decrease in security.  If you cannot claim that your post will help to
> improve security, then do us a favour and take it somewhere else.

Um, no.  As a system administrator, I would love for these POC posts to
not exist, but if the code is written, I want to see it.  The entire
purpose of bugtraq (in my eyes) is to inform sysadmins of the existence
of exploit codes.  If they're rejected from here, it's not going to stop
their distribution in IRC.  It's just going to give sysadmins a false
sense of security.

Damian Menscher [braces himself for the flood of vacation messages]
-- 
-=#| Physics Grad Student & SysAdmin @ U Illinois Urbana-Champaign |#=-
-=#| 488 LLP, 1110 W. Green St, Urbana, IL 61801 Ofc:(217)333-0038 |#=-
-=#| 4602 Beckman, VMIL/MS, Imaging Technology Group:(217)244-3074 |#=-
-=#| <menscher@...c.edu> www.uiuc.edu/~menscher/ Fax:(217)333-9819 |#=-


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ