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
severity 481192 wishlist
thanks
On Wed, May 14, 2008 at 03:22:07PM +0200, Helmut Grohne wrote:
> The recent update has two big problems:
> 1) Yes it tells the admin that it will replace the host key, but does
> not allow him to stop and do that step later.
> 2) It disables weak keys without further notice.
>
> This was both documented in the DSA, however only about 30000 admins
> will read that and as such cannot be considered an information source
> that reaches everyone.
I was aware of this problem but considered it absolutely acceptable
given the severity of the bug.
> Suggestions:
> * 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.
> * 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.
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.
> * Ask whether weak keys should be disabled.
>
> Especially the last point can result in the admin locking himself out of
> the system which is bad.
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.
(For the avoidance of doubt, I have never previously encountered a
problem severe enough to merit such a statement, and I hope to never
encounter another.)
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.
> Even if this is a users fault this behaviour is not nice and Debian's
> priority should by policy be its users.
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.
Cheers,
--
Colin Watson [cjwatson@debian.org]
Reply to: