----- Forwarded message from Planet Debian -----

From: Planet Debian
Subject: Russell Coker -- Debian SSH Problems
To: ticker-planetdebian[bei]lists.infodrom[punkt]org
Date: Sun, 18 May 2008 07:26:45 +0200 (CEST)

http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/

Russell Coker -- Debian SSH Problems

It has recently been announced that Debian had a serious bug in
the OpenSSL code [1][1], the most visible affect of this is
compromising SSH keys - but it can also affect VPN and HTTPS keys.
Erich Schubert was one of the first people to point out the true
horror of the problem, only 2^15 different keys can be created
[2][2]. It should not be difficult for an attacker to generate
2^15 host keys to try all combinations for decrypting a login
session. It should also be possible to make up to 2^15 attempts to
login to a session remotely if an attacker believes that an
authorized key was being used - that would take less than an hour
at a rate of 10 attempts per second (which is possible with modern
net connections) and could be done in a day if the server was
connected to the net by a modem.

John Goerzen has some insightful thoughts about the issue [3].[3]
I recommend reading his post. One point he makes is that the
person who made the mistake in question should not be lynched. One
thing I think we should keep in mind is the fact that people tend
to be more careful after they have made mistakes, I expect that
anyone who makes a mistake in such a public way which impacts so
many people will be very careful for a long time…

Steinar H. Gunderson analyses the maths in relation to DSA keys,
it seems that if a DSA key is ever used with a bad RNG then it can
be cracked by someone who sniffs the network [4][4]. It seems that
it is safest to just not use DSA to avoid this risk. Another issue
is that if a client supports multiple host keys (ssh version 2 can
use three different key types, one for the ssh1 protocol, one for
ssh2 with RSA, and one for ssh2 with DSA) then a man in the middle
attack can be implemented by forcing a client to use a different
key type - see Stealth's article in Phrack for the details [5][5].
So it seems that we should remove support for anything other than
SSHv2 with RSA keys.

To remove such support from the ssh server edit
*/etc/ssh/sshd_config* and make sure it has a line with "*Protocol
2*", and that the only *HostKey* line references an RSA key. To
remove it from the ssh client (the important thing) edit
*/etc/ssh/ssh_config* and make sure that it has something like the
following:

Host *

Protocol 2

HostKeyAlgorithms ssh-rsa

ForwardX11 no

ForwardX11Trusted no

You can override this for different machines. So if you have a
machine that uses DSA only then it would be easy to add a section:

Host strange-machine

Protocol 2

HostKeyAlgorithms ssh-dsa

So making the default configuration of the ssh client on all
machines you manage has the potential to dramatically reduce the
incidence of MITM attacks from the less knowledgable users.

When skilled users who do not have root access need to change
things they can always edit the file *~/.ssh/config* (which has
the same syntax as */etc/ssh/ssh_config*) or they can use
command-line options to override it. The command *ssh -o
"HostKeyAlgorithms ssh-dsa" user@server* will force the use of DSA
encryption even if the configuration file requests RSA.

Enrico Zini describes how to use *ssh-keygen* to get the
fingerprint of the host key [6]. One thing I would like to know is
how to get a fingerprint from a known hosts file. A common
situation is that machine A has a known hosts file with an entry
for machine B. I want to get the right key in machine C and there
is no way of directly communicating between machine A and machine
C (EG they are in different locations with no network access). It
would be good if I could run a command on machine A to get the
fingerprint and then when talking on the phone to the person at
machine C read out the fingerprint to them.

Docunext has an interesting post about ways of mitigating such
problems [7][6]. One thing that they suggest is using fail2ban to
block IP addresses that appear to be trying to do brute-force
attacks. It's unfortunate that the version of fail2ban in Debian
uses */tmp/fail2ban.sock* for it's Unix domain socket for talking
to the server (the version in Unstable uses
*/var/run/fail2ban/fail2ban.sock*). They also mention patching
network drivers to add entropy to the kernel random number
generator. One thing that seems interesting is the package
*randomsound* (currently in Debian/Unstable) which takes ALSA
sound input as a source of entropy, note that you don't need to
have any sound input device connected.

When considering fail2ban and similar things, it's probably best
to start by restricting the number of machines which can connect
to your SSH server. Firstly if you put it on a non-default port
then it'll take some brute-force to find it. This will waste some
of the attacker's time and also make the less persistent attackers
go elsewhere. One thing that I am considering is having a few
unused ports configured such that any IP address which connects to
them gets added to my NetFilter configuration - if you connect to
such ports then you can't connect to any other ports for a week
(or until the list becomes too full). So if for example I had port
N configured in such a manner and port N+100 used for ssh
listening then it's likely that someone who port-scans my server
would be blocked before they even discovered the SSH server. Does
anyone know of free software to do this?

The next thing to consider is which IP addresses may connect. If
you were to allow all the IP addresses from all the major ISPs in
your country to connect to your server then it would still be a
small fraction of the IP address space. Sure attackers could use
machines that they already cracked in your country to launch their
attacks, but they would have to guess that you had such a defense
in place, and even so it would be an inconvenience for them. You
don't necessarily need to have a perfect defense, you only need to
make the effort to reward ratio be worse for attacking you than
for attacking someone else. Note that I am not advocating taking a
minimalist approach to security, merely noting that even a small
increment in the strength of your defenses can make a significant
difference to the risk you face.

- [1] http://www.debian.org/security/2008/dsa-1571[7]

- [2]
http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-
sslssh-weakness.html[8]

- [3]
http://changelog.complete.org/posts/714-Thoughtfulness-on-the-Open
SSL-bug.html[9]

- [4]
http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html[1
0]

- [5] http://www.phrack.org/issues.html?id=11&issue=59[11]

- [6]
http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html[
12]

- [7] http://www.docunext.com/blog/2008/05/14/my-security/[13]

Share This[14]

05:07am[15] by etbe (Comments[16])

Links:
1. http://www.debian.org/security/2008/dsa-1571
2. http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html
3. http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html
4. http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html
5. http://www.phrack.org/issues.html?id=11&issue=59
6. http://www.docunext.com/blog/2008/05/14/my-security/
7. http://www.debian.org/security/2008/dsa-1571
8. http://blog.drinsama.de/erich/en/linux/2008051401-consequences-of-sslssh-weakness.html
9. http://changelog.complete.org/posts/714-Thoughtfulness-on-the-OpenSSL-bug.html
10. http://blog.sesse.net/blog/tech/2008-05-14-17-21_some_maths.html
11. http://www.phrack.org/issues.html?id=11&issue=59
12. http://www.enricozini.org/2008/tips/ssh-host-key-fingerprint.html
13. http://www.docunext.com/blog/2008/05/14/my-security/
14. http://etbe.coker.com.au/?p=583&akst_action=share-this
15. http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/
16. http://etbe.coker.com.au/2008/05/18/debian-ssh-problems/#comments

--
To UNSUBSCRIBE, send an email to ticker-planetdebian-request[bei]lists.infodrom[punkt]org
with a subject of "unsubscribe". Trouble? Contact listmaster[bei]lists.infodrom[punkt]org

----- End forwarded message -----

--
Stefan Lütje Skelli[bei]jabber.ccc[punkt]de
Key fingerprint = BCB2 48E4 9211 C975 5A3F B192 9B6E CCCF 99CC 44FA
Was haben Windows und ein U-Boot gemeinsam?
Kaum macht man ein Fenster auf, gehen die Probleme los.
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : nicht verfügbar
Dateityp : application/pgp-signature
Dateigröße : 189 bytes
Beschreibung: Digital signature
URL : http://www.easylinux.de/pipermail/ubuntu/attachments/20080518/a96eb02c/attachment-0001.pgp