Subject: Re: OpenSSH Priv Sep and Remote Exploit?
To: Jason R Thorpe <firstname.lastname@example.org>
From: Theo de Raadt <email@example.com>
Date: 06/27/2002 12:09:24
> Nonetheless, informing the security contact of each vendor through
> the appropriate means that "this bug exists, keep it under wraps"
> would have let those vendors plan accordingly.
This is clear balony.
Considering that the resolver thing was leaked about 5 hours after it
hit us, from inside FreeBSD and into NetBSD and who knows where else,
and that noone wants to own up to who was involved in that, there is
no way I'm going to tell any such vendor!
Another bug of the same scope showed up at the same time, was handled
very rapidly, and you guys proved that you cannot keep it under wraps.
> Instead, panic ensued
> as people scrambled to find ways to update their systems. That was
> totally unnecessary, as all they needed to do was change a line in
> their config files.
If I had pointed out what change was needed in the config files, it
would have been out immediately. Saying ChallengeResponse focuses it
from 27,000 lines to 400 lines of code. It would have been found by
someone else immediately.
While talking to CERT late yesterday, I did suddenly realize that I
could have said "Disable Protocol 2", as that solves the problem and
constrain the search to approximately 5000 lines of code. But that
was after ISS jumped the gun. And quite frankly, I think constraining
it to 5000 lines of code is still too big of a hint.
27000 lines is on more of a hint than any of these people had 2 weeks
ago, before all this happen. And we know they audit for such things.
And we know they watch our commit lists.
> Instead, people who, for one reason or another, were not able to update
> their systems were sitting ducks for anyone who might have had an exploit
> for the problem (in the event of an information leak). Again, totally
> unnecessary, as all they needed to do was change a line in their config
If I had told you guys, you would have leaked the information. If you
want to help prove that this is not the case, please find out for me
who it was that leaked the information out of the FreeBSD group (who
had 12 people on their security-officer mailing list!), so that we can
expell such untrustworthy individuals from the circle of trust.
If you don't built trust, I have every reason to do it exactly like this
next time something comes along.
At the moment, there is no trust of their operation, or in NetBSD's
really either, since NetBSD developers who learned of the leak are
refusing to say who leaked to them!
I contacted itojun very early on because I knew he could work on a fix
without telling anyone. I knew I could trust him. And he told noone.
Apparently such trust is hard to come by elsewhere.
The person who disclosed this bug is also quite concerned about this
> Consider people who ship embedded products that contain OpenSSH (*BSD
> based, Linux based, QNX based, whatever) ... these people certainly
> can't easily upgrade their systems.
Then they were able to disable ssh, or filter port 22; my warning
allowed them do to that. The fact that my notice did not say " you
can disable or filter" does not make me responsible; if they cannot
think that through themself... good god.. as Marc Espie said.. my
posting was an IQ test. You must have at least 20. Do you not have
I don't care if I hurt your feelings. When the httpd thing came out,
I shut down httpd immediately, then rebuilt it according to the
initial patch. Then according to the next patch. Then according to
the third patch. What else was I to do? I got no heads up -- and did
I scream? Nope.
> However, they do generally have
> contacts w/ CERT, and thus could have been informed in an appropriate
> way about this problem and taken appropriate action.
I talked to CERT. It took them 48 hours to get the message out, and
that was only after I pushed them very very hard. It was totally
outside of their normal mode of operation! I had to tell them to stop
making notes, and start writing up a 5 line notice. I am glad they were
able to adapt, because this bug is different.
> Instead, there was an ad-hoc (and somewhat selective, from the looks
> of it) means of disclosing information about the problem to vendors,
Oh, it was VERY selective. ISS said 7 people knew in their operation,
4 people in OpenBSD knew (markus, millert, provos, and I), and 11
people in some other "hacker" group knew (but there is overlap between
that group and ISS). I think it was 15 total. Noone else did. This
one was taken seriously. Even by the hacker group. This one was
dangerous to the community. Careful disclosure was the idea.
ISS told noone except for me. Not a single vendor was told as far as
I know. I told no other vendor. They phoned, they mailed, they asked
for details to get up a rung. I said nothing. Even the snapshot
binaries I was building for our users didn't contain the binary fix; I
wanted to, but I was afraid that someone would disassemble our
binaries and find it! Instead, our binaries shipped with privsep
And it wasn't leaked as far as we know so far, unlike the resolver
one, apparently, which leaked immediately by going through vendor
contacts. Vendor contacts like YOU.
Don't tell me it would have worked any other way. I really do know
better. And this is not the first time I've been here. I've been
involved in the disclosure of over 40 holes to BUGTRAQ, and I know
better than YOU, Jason.
> resulting in rumor and panic, and a groundswell of distrust for the
> OpenSSH software and the people involved in developing it.
Hey, you're just being jealous...
> who use security-sensitive software need to be able to trust the people
> who develop security-sensitive software. The way this particular event
> transpired was no way to build that trust. Is that what you want?
If you don't like our software, you don't have to run it. Notice the
"NO WARRANTY" clause? Maybe you should take it a bit more seriously
than you do, because you put it on your software too.
Fact is, don't you DARE accuse me of not being trustworthy, while
people who are involved in security information leaks hide within your
organization. You too, Perry. Come on, tell us who it was. Don't
grant an amnesty for such idiotic behaviour.