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>] [day] [month] [year] [list]
Date: Tue Sep 13 03:11:58 2005
From: wari00 at gmail.com (Roberto Gomez BolaƱos)
Subject: Mozilla Firefox "Host:" Buffer Overflow

Larry Seltzer wrote:

>>And how exactly do you propose to "leave out the details and PoC" when the

>>presence of the bug and the steps taken to fix it can not be concelaed from
>>public view given that the source code and the entire CVS entries are freely
>>available for anyone to browse?

>You really don't think it woudl slow them down?

who is "them" ?
And you want to slow "them" down from doing... what?

Maybe it is not evident to you that a source code diff between vulnerable and 
non-vulnerable versions of a software package is enough information to figure
out all the details needed to identify and trigger the bug and to
write an exploit
for it it.  After all, you are not suppossed to know this right?
You're the security
center editor for eWeek not some hardcore software developer or security expert.

Hell, not even a source code diff is necessary anymore, a binary patch is
sufficient to identify the bug and develop an exploit for it.

So there! Thats some newsworthy information for your prestigious magazine maybe
you should seek clearance from your sponsors to write about it. It will sell 
a bunch more copies.

Trust me! THIS IS HOT NEWS

Meanwhile, I am still waiting for your proposal for a way to leave out
details and
PoC for vulnerabilities found in open source projects.

>>The proposal for obscurity serves well closed-source innitiatives and

>>development processes that have limited or no public visibility but it fails
>>in the presence of OSS. The "responsible disclosure" advocates act as if
>>Linux,*BSD,Mozilla and a zillion other open source projects did not exist in
>>reality.

>The Mozilla team obviously disagrees with you, since they do try to hide
>unresolved security problems, at least until (as in this case) the beans get
>spilled in some other way.

Hmm may be... but then again how is that different from MSRC then?
In any case, I can not say how the Mozilla or other OSS development
teams work and if they do try to hide security vulnerabilities or not but what 
I can do is browse their CVS tree and bug tracking system:

https://bugzilla.mozilla.org/show_bug.cgi?id=307259

So what I read in the publicly available bug entry above does not support your
theory, perhaps you have some secret 3l337 knowledge about how the team
really works WRT security flaws that you want to share with the list?

uhm no wait I forgot...

not talking about this will slow THEM down
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050912/a050f8db/attachment.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ