lkml.org 
[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: TO HELL WITH IT THEN......(re: disk-destroyer.c)
"Mike A. Harris" wrote:

> Actually, I disagree. One of the things necessary for security
> to work is full disclosure. Making things unknown, doesn't make
> them unknown. Undisclosed == closed source. If we believed in
> closed source, we would be working at Microsoft. Getting it out
> in the open causes the problem to be taken seriously. Actually,
> it FORCES the problem to be taken seriously.

Again, I did not say don't every discuss it. I said release it responsibly.
That form follows:

a) find the bug, do the exploit and fix.
b) notify the vendor
c) wait ~two weeks
d) announce it

And this form follows. There is nothing at all wrong with the courtesy of
giving the vendor a chance to fix the bug before you announce it.

With the LK, your daily changelog would have an "ATA protocol violation API
fix". Then when distro's have been notified you make a public announcement
of it: "ATA protocol violation API allowed possibly dangerous commands to be
sent to the IDE processor".


> The same thing happens every day with exploits. Someone finds a
> major security hole in program A. They write an exploit for it,
> and a description of the problem, then warn the company who made
> the program. The company threatens to sue if they announce it,
> and then does nothing about it.

And the respected people grant the vendor advance warning.


> This is likely what will happen now to Linux, and possibly other
> vendors as well. The hard disk manufacturers need to design
> products that are designed with security in mind, as so does the
> industry in general. For years I've wondered about the ability
> to fry a modem via the flash update. Now I'm practically
> convinced that it is as easy as sniffing I/O ports with dosemu
> debug options. grepping and then writing modem2brick.c

Yes it is. Now the proper thing to do is send modem2brick.c to the vendor
along with discussion and suggested fix if possible. Talk with the vendor as
necessary then publicly announce it. Everyone is warm and has happy feelings
when bugs are responsibly released. Vendors and admins get antsy when
exploits are announced and admins have to wait for a vendor to scramble while
the packet kiddies have a party.

Do you take pleasure in admins being ahead of the packet kiddie or the packet
kiddie ahead of the admin?


> >By carrying on about it for a week, it's a nice honeypot for
> >that malicious kiddie to search the archives and build a
> >workable exploit to destroy hardware.
>
> Good. At this point, I hope they do, just to prove Andre right
> so he can come back and laugh at everyone who gave him CS
> bullshit stories.

And I hope your system is first found :P

I have NEVER advocated CS and and NEVER said NEVER disclose it. Let me make
myself clear again since a lot of people seem to think that I mean never
disclose it when I say delay before disclosure.

- I never said don't ever disclose it.
- I did say and have frequently referenced a two week disclosure window.
- I have never said closed source.
- I find zero value in providing a tool that will by far and wide be used
only by script kiddies. Out of a thousand people reading bugtraq, one or two
of them will be using the exploit for good uses and of those one or two, they
probably know how to make an intentionally broken tool work. I.e. a little
more complex than #ifdef IKNOWWHATTOFIX 3.141579.

A code fragment that clearly illustrates the bug is sufficient for completely
full disclosure. A fully operable shell script that compiles an embedded
program to exploit the bug is not neccesary and only sates the hunger of the
packet kiddie.

-d

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."


begin:vcard
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard
\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.224 / U:0.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site