OpenSSL mit Fehlerhaften Schüsseln

[berlinerbaer]

Betrifft uns das auch (noch) ?
http://ubuntuusers.de/ikhaya/1038/

Seit September 2006 erzeugt OpenSSL bei Debian-basierten Betriebssystemen auf Grund eines fehlerhaften Patches leicht zu knackende Schlüssel.

Was muss man nun tun? Ist das mit den üblichen Updates für Etch behoben?

[charno]

Betrifft uns das auch (noch) ?
http://ubuntuusers.de/ikhaya/1038/

Seit September 2006 erzeugt OpenSSL bei Debian-basierten Betriebssystemen auf Grund eines fehlerhaften Patches leicht zu knackende Schlüssel.

Was muss man nun tun? Ist das mit den üblichen Updates für Etch behoben?

Dies wird mit dem neuen ssh-server und ssh-client paket behoben.

Achtung: Diese Pakete werden aufgrund einer neuen Abhängigkeit bei einem upgrade nicht automatisch eingespielt, es wird ein Dist-Upgrade benötigt!

Code: Alles auswählen

aptitude update
aptitude dist-upgrade

Grüsse
Charno

[Kokopelli]

Betrifft uns das auch (noch) ?
http://ubuntuusers.de/ikhaya/1038/

Seit September 2006 erzeugt OpenSSL bei Debian-basierten Betriebssystemen auf Grund eines fehlerhaften Patches leicht zu knackende Schlüssel.

Was muss man nun tun? Ist das mit den üblichen Updates für Etch behoben?

Dies wird mit dem neuen ssh-server und ssh-client paket behoben.

Das stimmt nicht, die Schlüssel in ~/.ssh müssen von Hand neu generiert werden, ebenso evtl. vorhandene in authorized_keys. Da gab es aber letzte Woche dutzende threads und blogs in beliebigen Sprachen dazu, wie und warum was aktualisiert werden muss.

[berlinerbaer]

da reicht es nicht einfach, das Verzeichnis .ssh auf allen Rechnern zu löschen?
Anders scheint er ja das ganze System zu beschädigen . . . .

Code: Alles auswählen

~# aptitude dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut... Fertig
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Schreibe erweiterte Statusinformationen... Fertig
Lese Task-Beschreibungen... Fertig
Erzeuge Tag-Datenbank... Fertig
Die folgenden Pakete werden nicht verwendet und werden ENTFERNT:
  bsh gcj-4.1-base gij gij-4.1 lapack3 libcurl3 libgcj-bc libgcj-common
  libgcj7-0 libhsqldb-java libicu36 libjaxp1.3-java libjline-java
  libmdbtools libservlet2.3-java libufsparse libwpd8c2a libxalan2-java
  libxerces2-java libxt-java openoffice.org-base openoffice.org-calc
  openoffice.org-draw openoffice.org-impress openoffice.org-math
  openoffice.org-writer refblas3 ttf-opensymbol
Die folgenden Pakete werden aktualisiert:
  libspeex1
1 Pakete aktualisiert, 0 zusätzlich installiert, 28 werden entfernt und 0 nicht aktualisiert.
Muss 76,4kB an Archiven herunterladen. Nach dem Entpacken werden 63,4MB frei werden.
Wollen Sie fortsetzen? [Y/n/?]                 

Natürlich nein. Da aktualisiere ich nur das eine Paket. Woher will das System wissen, dass ich Openoffice-Impress nicht brauche !? Ich brauche es täglich! Spaßiges Ding

[berlinerbaer]

die Pakete openssh-client, openssh-server und ssh haben die Versionsnummer 1:4.3p2-9etch2. sind das die neuen Pakete oder geht es noch neuer?

[Danielx]

Ich brauche es täglich! Spaßiges Ding

Wie sieht es denn mit "apt-get dist-upgrade" aus?
Das sollte weniger Probleme machen.

die Pakete openssh-client, openssh-server und ssh haben die Versionsnummer 1:4.3p2-9etch2. sind das die neuen Pakete oder geht es noch neuer?

Das ist die aktuelle Version.

Gruß,
Daniel

[rendegast]

Code: Alles auswählen

Die folgenden Pakete werden nicht verwendet und werden ENTFERNT:
  bsh gcj-4.1-base gij gij-4.1 lapack3 libcurl3 libgcj-bc libgcj-common
  libgcj7-0 libhsqldb-java libicu36 libjaxp1.3-java libjline-java
  libmdbtools libservlet2.3-java libufsparse libwpd8c2a libxalan2-java
  libxerces2-java libxt-java openoffice.org-base openoffice.org-calc
  openoffice.org-draw openoffice.org-impress openoffice.org-math
  openoffice.org-writer refblas3 ttf-opensymbol

Kontrollier mal den Status der Pakete in aptitude.
Sind vermutlich durch eine Aktion mit debfoster, deborphan oder Einstellungen in aptitude als 'pa' markiert.
Manuell mit "+" oder "M" korrigieren.

[holgerw]

Ich brauche es täglich! Spaßiges Ding

Wie sieht es denn mit "apt-get dist-upgrade" aus?
Das sollte weniger Probleme machen.

die Pakete openssh-client, openssh-server und ssh haben die Versionsnummer 1:4.3p2-9etch2. sind das die neuen Pakete oder geht es noch neuer?

Das ist die aktuelle Version.

Gruß,
Daniel

Hi Daniel,

vorsicht, Peter verwendet Etch, da sollte er, wenn aptitude das Standardwerkzeug ist, kein apt-get verwenden.

In Lenny und Sid kann das meines Wissens nach wieder gemischt werden.

Aber wenn ich dies aptitude Sache hier wieder lese, wundere ich mich ein weiteres Mal, dass diesem Werkzeug gegenüber apt-get der Vorzug gegeben wird, mit dem Argument, es löse Abhängigkeiten besser auf - das tut es in der Tat bei vielen wohl etwas zu gründlich . Es heißt dann immer: Gehe in die aptitude Konfiguration, und stelle dies und das ein. Warum ist es nicht standardmäßig schon seitens der Maintainer so eingestellt, dass es bei kleinen Ungereimtheiten nicht das halbe System entfernen will? Mein Eindruck ist jedenfalls, dass hier die meisten Paketmanagement-Klage-Threads mit aptitude, und nicht mit apt-get zusammen hängen.

Beste Grüße,
Holger

[Danielx]

Richtig, bei Etch ist aptitude nun die bevorzugte Methode zur Paketverwaltung auf der Konsole.

Aber wenn ich dies aptitude Sache hier wieder lese, wundere ich mich ein weiteres Mal, dass diesem Werkzeug gegenüber apt-get der Vorzug gegeben wird, mit dem Argument, es löse Abhängigkeiten besser auf - das tut es in der Tat bei vielen wohl etwas zu gründlich .

Ich bevorzuge auch apt, aptitude ist einfach nichts für mich...

Gruß,
Daniel

[rendegast]

Das stimmt nicht, die Schlüssel in ~/.ssh müssen von Hand neu generiert werden, ebenso evtl. vorhandene in authorized_keys.

Eine ganze Menge Pakete brauchen openssl, libssl0.9.8
http://www.heise.de/security/Schwache-K ... ung/107808
http://lists.debian.org/debian-security ... 00152.html

Laut einem Debian-Sicherheits-Advisory erzeugen alle OpenSSL-Pakete der Distribution seit einschließlich Version 0.9.8c-1 vom 17. September 2006 verwundbare Zufallszahlen. Die Debian-Maintainer empfehlen Anwendern und Admins, sämtliche von einer fehlerhaften Version ausgestellten Zertifikate und Schlüssel nach einem OpenSSL-Update neu zu erstellen. Gegebenenfalls sollten schwache X.509-Zertifikate zurückgerufen werden. Auch mit ihnen ausgestellte Chiffrate und Signaturen sollten laut Advisory als geknackt gelten.

http://www.heise.de/security/Der-kleine ... kel/108001
http://wiki.debian.org/SSLkeys
http://www.debian.org/security/key-rollover/
https://www.debianforum.de/forum/viewto ... =1&t=99338




----------------------------------------------------------------------------------------

Aber wenn ich dies aptitude Sache hier wieder lese, wundere ich mich ein weiteres Mal, dass diesem Werkzeug gegenüber apt-get der Vorzug gegeben wird, mit dem Argument, es löse Abhängigkeiten besser auf - das tut es in der Tat bei vielen wohl etwas zu gründlich ;-).

Liegt wohl mehr an
a) leichte Umstellung der Optionen in der GUI
b) Speicherung der Einstellungen in ~/.aptitude, IMO ein falsches Design

Ich mache das mit Links der configs auf eine Datei und erreiche ein homogenes Verhalten für alle Benutzer und su/sudo-Möglichkeiten.
Die Depends parsen können doch alle Tools, was sie damit machen ist Einstellungssache.
aptitude hat gegenüber apt-get das Feature "iA", that's all.

Und für "Versehen" läuft ein Paket-Proxy, damit ist schnell wieder repariert :-)


EDIT 20080523: Korrektur: ----------------------------
apt-get hat /var/lib/apt/extended_states, was in Verbindung mit /var/lib/dpkg/status auf ein ähnliches Ergebnis wie "i A" von aptitude kommen sollte.
"Ahnlich", denn mit 'dpkg -l' komme ich auf 675 Pakete, während in extended_states 1100 Einträge "Auto-Installed: 1" sind (virtuelle Pakete?).