Bug#481192: openssh-server: openssl update with blacklists possibly breaks the system when the admin didn't read dsa mail
> # 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.)
> I was aware of this problem but considered it absolutely acceptable
> given the severity of the bug.
I strongly disagree.
> > * 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.
> > * 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?
> 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.
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).
> 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 realise that this upgrade is not the best experience that could have
> been offered in an ideal world, but this is not an ideal situation.
> Please don't lecture me about priorities being users; my priority is
> precisely our users, but I consider their security to be of higher
> importance than their comfort, and in a situation where there is very
> little opportunity to manage both, I'll go for the former.
After all do no harm.
Helmut
Reply to: