Bug#481192: openssh-server: openssl update with blacklists possibly breaks the system when the admin didn't read dsa mail
On Wed, May 14, 2008 at 09:16:42PM +0200, Helmut Grohne wrote:
> > # doesn't break the system in general, and even when it does is totally
> > # justifiable; see below
>
> We seem to disagree about breaking a system is justifiable. (I'd say:
> After all do no harm.)
(The stock English phrase is "First do no harm", by the way.)
> > > * Add a notice to NEWS.Debian. (Suggestion from Nico Golde.)
> > I thought of that, but the problem with that is that there's no way to
> > stop it showing up again on upgrade to lenny.
>
> So what's the problem? This can be considered absolutely acceptable
> given the severity of the bug.
I think further confusion is liable to be unhelpful.
Please don't confuse the fact that I don't like any of your suggestions
so far with not being open to *any* suggestions. Be creative. :-) I
haven't thought of anything good yet, but you might ...
> > > * Make "no" an option on replacing the host key.
> > I don't think it's acceptable to give people a nice easy way to ignore
> > this problem; it's far too severe. The old host keys are backed up in
> > .broken so the admin can put them back.
>
> An admin could perhaps answer no, then generate a new key himself and
> *after* deploying the pubkey switch the host key. This sounds less
> disruptive and perfectly acceptable.
>
> > If admins are paying enough attention to think of answering "no" to a
> > host key regeneration prompt, I see no reason why they wouldn't also be
> > paying enough attention to confirm the new host key immediately after
> > it's generated and update their client. I can't imagine any situation
> > where you would be awake enough to do the former but not the latter.
>
> What about first updating clients and then updating servers?
You can do that if you like. My concern is immediate damage limitation.
> > Which is worse: not being able to log into your own system, or everyone
> > on the Internet being able to log into your system? Clearly the latter.
> > I am not exaggerating in the slightest here; the exploit is *trivial*
> > and if you have weak keys then it is only a matter of time before every
> > script kiddie on the planet can log into your system. It was imperative
> > that use of these keys be disabled as soon as possible. If that involves
> > a few people being inconvenienced, it's worth the trouble.
>
> First of all it is my problem what happens with my system if I do not
> apply security patches (or replace keys), so please don't force me to do
> so.
This is potentially on the scale of the Internet worm, except for a
modern age. I am not exaggerating. It is my problem when your system is
compromised and starts emitting bogons all over the place. It is my
problem when tens of thousands of systems are compromised and start
emitting bogons all over the place. If fixing that involves some people
calling me names, I'm a big boy and can cope.
After the initial mitigation has been done, I'll be willing to consider
making things a bit more lightweight.
> Then this hole could have been used for two years and script kiddies
> will only pop up tomorrow, so I can afford another day (and many will
> probably afford like weeks) as the brute forcing keys isn't much easier
> than brute forcing passwords (after all the key space still is like
> 2^16).
You are overestimating the time required by some way.
> > There will probably be a few systems in isolated networks where the
> > exploit is not important, and those admins will be inconvenienced with
> > less justification if they fail to notice the ability to use
> > "PermitBlacklistedKeys yes". However, I expect that most such systems
> > will have local admins available (e.g. corporate networks), and again I
> > think this is worth it.
>
> Again we disagree.
I'm OK with people hating me because of this. All I care about is
getting this bug off the network as fast as humanly possible.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: