Vita di un sys-admin

MANNAGGIA A DEBIAN! ‘Sta volta hanno fatto una cazzata!

Avete server Debian installati dal 2006 in poi? AGGIORNATE IMMEDIATAMENTE OPENSSL E RICREATE TUTTE LE VOSTRE CA, CERTIFICATI PEM, CHIAVI SSH DI CLIENT E SERVER.

Leggete qui:

http://www.debian.org/security/2008/dsa-1571

Ed anche qui:

http://wiki.debian.org/SSLkeys (c’e’ un tool che dovrebbe aiutarvi a capire quali server SSH sono vulnerabili e quali no… anche se non e’ detto che non possa generare falsi positivi/negativi).

“”Luciano Bello discovered that the random number generator in Debian’s openssl
package is predictable. This is caused by an incorrect Debian-specific change
to the openssl package (CVE-2008-0166). As a result, cryptographic key
material may be guessable.”"

“Well, it looks like it’s more toward the minutes or seconds range, because dowkd.pl contains a simple list of around 260,000 fingerprints for these vulnerable keys… that is, if you’re vulnerable, I can look your SSH server’s host key fingerprint up in a rather small database to find your private key.Yikes.”

“It was a modification from the debian package maintainers that has cause the issue. In short they disabled the random portion of encryption process, also known as the iv, salt, seed. Which means basically means all the keys are predictable, because the randomness has been removed. This in turn creates weak keys, and a target for brute force and man in the middle attacks. The bug is limited to Debian systems, and its clones, since it was introduced by the Debian maintainers.”

Modificare il codice di un pacchetto critico come OpenSSL, frutto di lunghi studi matematici sulla crittografia e fare sta cazzata. Complimenti!!!!

Pare che la patch malsana risalga al 2 Maggio 2006. Ben 2 anni. Vi rendete conto di quanti server in tutto il mondo possono essere vulnerabili?!!!?!

Ci aspettano ore di davanti ai computer per aggiornare caterve di macchine. COMPLIMENTI!

Update:

Per sshd basta usare questi comandi:

# apt-get update
# apt-get install libssl-dev openssl
# rm /etc/ssh/ssh_host*
# dpkg-reconfigure openssh-server

Ovviamente la fingerprint del vostro server ssh cambiera’.

Update2:

Ovviamente  se usate certificati SSH RSA per accedere ai server senza password (o anche con la password) dovete ricrearli con ssh-keygen ed aggiornare authorized_keys su ogni macchina a cui avete accesso. CHE PALLE!

Ovviamente tutti i consigli solo se il vostro server e’ stato isntallato dopo il 2006 o la vostra chiave RSA e’ stata creata dopo il 2006.

Update 3:

Popularity: 25% [?]

pallotron Comunicazioni, Informatica, Lamentazioni, Linux, Software debian, free software, gnu, linux, merda, openssl, security, Software Libero, ssh, ssl

Salve,

Oggi ho sclerato una giornata per fare il troubleshooting di una cosa su Solaris. Problemi di comunicazione random tra apache che fa reverse proxy verso un tomcat nella stessa Zona di Solaris con traffico passante sulla interfaccia di loopback. Pero’:

root@solaris # ./tcpdump -n -i lo0
tcpdump: /dev/lo0: No such file or directory
 
root@solaris # snoop -d lo0
snoop: /dev/lo: No such file or directory

Solaris. Sei proprio un sistema operativo di merda!

Leggete http://phildev.net/ipf/IPFsolaris.html#solaris12:

# Why can’t I filter on the loopback interface, or virtual interfaces?
The loopback interface on Solaris is a “fake” interface. You cannot filter it, nor can you snoop it. This is for performance reasons. Virtual interfaces in Solaris are very similar, to filter on them, use the physical interface instead.

Perfomance reasons! Ma andatevene affanculo va’!
Alla fine sono riuscito a sniffare in un altro modo invertendo il reverse proxy verso un tomcat di un altro nodo e sniffando sulla interfaccia reale… sono riuscito ad isolare il problema e a decidere chi dei due sia il colpevole (almeno credo) e domani ci lavoro.

Saluti.

Popularity: 24% [?]

pallotron Esperienze, Informatica, Lamentazioni, Lavoro, Unix lamentazione, Lavoro, merda, sniff, snoop, solaris, sysadmin, Unix