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]
From: sert at snosoft.com (John Scimone)
Subject: it's all about timing

I agree with this.  However, in the Snosoft case the facts has been smeared by 
all the different stories going around.  I will not get into it in detail but 
we have been working with HP on this for 4+ months, bending over backwards 
for them to keep everything out of the eyes of the public.  All the time 
putting up with threats of suit for nonsense issues.  The bottom line is that 
we went above and beyond what is reasonable for a research group to do 
because we knew how serious the issue is, and after managing to do this for 
so long something got leaked which was inevitable with the amount of people 
working on the problem.  I believe if instead of it being a leak we released 
an advisory on the issue (we couldn't do this b/c of HP's legal department 
strong-arming us) after 2 months nevermind 4 months it would have been more 
than reasonable.  Look for an official statement tonight on our website 
www.snosoft.com with the exact details but I'm sick of going through the day 
listening to the facts get smeared b/c of false reports.

-sert


On Wednesday 31 July 2002 09:26 pm, Florin Andrei wrote:
> (i'm going to go a little bit further from the HP/Snosoft case, so don't
> be surprised if some of the statements below do not fit 100% in that
> case)
>
> All these problems will vanish if people will choose to disclose
> vulnerabilities in a responsible way.
> Sure, HP's response has been harsh. But every security problem
> (especially when it's accompanied by an exploit) should be reported
> first to the vendor! There should be no exception from this rule. The
> person doing the reporting should give the vendor a reasonable period of
> time to fix it; say, a few weeks or so.
>
> Only if the vendor does nothing in these weeks, only then the
> report/exploit/whatever should be made public.
>
> If hacker H writes a comment on Slashdot, making public an exploit
> against some software made by vendor V, and does not notify V in advance
> (say, 2...4 weeks in advance), and then V sues H, then who's right?
>
> H is right, because (s)he disclosed a vulnerability, and disclosing is
> good.
> V is right, because not being warned in advance, their customers are
> left to the mercy of script kiddies.
> H is wrong, because (s)he's obviously looking for cheap publicity (i
> published a zero-day exploit; mine is bigger), not for improving
> security.
> V is wrong, because they are filing a lawsuit against open disclosure,
> which is not a good thing.
>
> See?
>
> And the solution is so simple: DO NOT publish "zero-day exploits". Give
> the damn vendors an early warning. Only if they are lazy and do nothing
> within a reasonable time (2...4 weeks), only then you are entitled to go
> slashdot-happy.
>
> I'm a big fan of open disclosure, freedom of speech, etc. But people who
> look for cheap publicity are not my favourites. If H is going to publish
> the exploit without early warning, i'll say V has all the rights in the
> world to sue the crap out of H, and put him(her) in jail for one
> thousand years, and i'll applaud that.
> However, if there was an early warning, within a reasonable time, like
> one month or so (unlike some popular security companies did recently),
> and the vendor did nothing and didn't provide a good reason for the
> delay (because such reasons could exist, if you think of it), then H is
> 100% entitled to publish whatever exploit he likes.
>
> It's all about timing. It's all about being reasonable.


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ