On Fri, 21 Jul 2000, David Ford wrote:
>> 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
Jeeze. That is what was TRIED at first. It didn't seem to go
over too good. When that happens, the party that finds the bug
usually gives up and says, fine have it your way, and posts.
Andre posted the problem with minimal detail (minimal
disclosure), and proposed solutions. He was attacked left right
and center from all sides, from people that seemed to have strong
religious reasons or other CS reasons for not allowing it. Many
of which have backed down now, or have ran out of arguments and
are now saying "oh, well I don't know the technical specs of IDE,
so I can't really speak for standards..." They keep rehashing
the fact that root can destroy anything he likes anyways without
really considering that maybe root doesn't WANT to destroy it,
wether or not it is possible. Few people are considering the
situation where there is NO root user - capabilities system.
These arguments always go like this:
1) Well, we will put code in the kernel to stop haxors from doing
that.
2) Then joe hacker will write to /dev/mem
1) No, we'll disable /dev/mem
2) Then he'll do direct I/O
1) Then we'll disable direct I/O
2) Then he'll insmod a module that overrides it.
1) Then we'll disable module loading
2) Then he'll compile a new kernel, install it, relilo and reboot
1) No, we'll have disabled "root" and be using capabilities
2) He'll get in via social engineering the admin.
1) We'll kill the admin, burn all belongings, move his family out
of the country. Then we'll burn the installed OS onto CDROM
and run from a live filesystem with no random access storage.
2) He'll personally come there, and sneak in, removing the cd,
and activating the hard disk used to make the CDROM to begin
with, and THEN destroy it.
1) Nope, we'll put the computer in cement, inside a 2 foot thick
metal box buried 200 feet underground with 50 locks attached any
one of which explodes if tampered with.
2) He'll bring a diamond drill, and a payloader, and a bomb
squad, some welders...
1) My dad can beat up your dad.
2) No, my Uncle can beat up your dad.
1) My car engine displaces more water than yours.
2) My car costs more money than yours and is more efficient
1) My penis is bigger than yours
2) That's not what your mom tells me
1) Leave my mom out of this and I'll leave this out of your mom.
2) You are an arsehole..
ad infinitum...
After about round 2, the rest is pointless pissing match ending
up in no solution and possibly hurt feelings.
>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.
In this case, Andre *DID* offer the info without giving details,
and since he is IDE maintainer, effectively he amounts to the
vendor because it was him fixing it. The fix wasn't
accepted. Equivalent to "we don't want to hear about it, and
wont do anything about it, go away". To which he said I QUIT,
here is the exploit, and here is another.
After that, the problem is OUT, and NOW we are seeing people
STILL CLAIMING their claims that it is useless, but with a
twist. Now they're saying it is useless, but since it does this
and that it is probably a good idea, so I'd like to see it in the
kernel too, so please put it in Andre, even though it is useless
and someone can still get in root and do it anyway, and my Dad
_can_ really beat up your dad.
When a vendor doesn't respond - they leave no alternative but
silence or disclosure. Disclosure is the proper way IMHO.
>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 buck starts here, not with distributions. Fix the kernel,
then notify the distributions, and that way a patch exists.
THEN wait the grace period, and publically give the details.
>> 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.
Which was done by Andre, and met by vigorous opposition. Such
opposition that it was the sole reason for the rapid public full
disclosure in the first place. Piss off someone that knows about
an exploit and is trying to help fix it, and risk full immediate
disclosure. That is the way it goes.
>Yes it is. Now the proper thing to do is send modem2brick.c to
>the vendor along with discussion and suggested fix if possible.
Certainly. I agree 100%.
>Talk with the vendor as necessary then publicly announce it.
Yep.
>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.
So you follow my logic as well. Then you likely also understand
that when the vendor (developers) do not respond, or respond
hostile, then that can end up speeding up disclosure
significantly - for spite, revenge, or merely to prove a point.
>Do you take pleasure in admins being ahead of the packet kiddie
>or the packet kiddie ahead of the admin?
Neither. You NEVER know what joe hacker allready knows, and has
been using all along.
>> 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
Unlikely. I hope *your* system is NOT harmed. I hope NOBODY has
any harm from this.
>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.
No, I agree with that fully.
>- 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
Well, the first three are ok, but the latter I disagree
with. Once an exploit is known, then it will have a script from
SOMEWHERE anyways. If one comes with the script, then it is more
likely to be taken seriously, even if someone does not grok the
exploit explanation.
Really, its the whole "don't post virus source code" thing..
FULL disclosure is the ONLY way to be secure.
>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.
This really is difficult to prove statistically, and can best
only be guessed. Both sides of the argument that is.
>A code fragment that clearly illustrates the bug is sufficient
>for completely full disclosure.
To illustrate a problem, yes. To make it completely
demonstrable, one needs code or must work their own out. It is
really a choice of the person who discovered it - there is no
right or wrong way.
>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.
You assume only script kiddies use the stuff. *I* download
exploits often to test on my OWN stuff to see if I truely am at
risk. Knowing only what it is, or does, without code, one may
not have the technical skill to whip up code to test out the
systems that potentially need testing for a particular exploit.
Also, analyzing a particular exploit may show up another possible
one that may have been missed.
Sorry, I'm in the *FULL* disclosure camp, and that includes
source too. That is just preference though.
TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:17 EST