Updates zu Wheezy (Spectre und Meltdown)

[gnude]

Hallo
ich habe einen root Server im Internet der mit Wheezy läuft.
Wenn ich den nun aktuallisiere, sind für Wheezy (Debian 7) schon
updates für die beiden Sicherheitslücken verfügbar?
Bei Ubuntu ist ja soweit ich weiss bisher nur Meltdown gefixed.

Wie spiele ich die Updates am besten ein?

apt-get update
apt-get distupgrade

dann ein reboot?

[Tintom]

Ernsthafte Frage: Administrierst du den Server wirklich?

[gnude]

Naja
früher war aptitude die bevorzugte Wahl
bei Debian. Ich weiss nicht wie es aktuell ist. Und wie weit die Patches fortgeschritte sind.
Das Thema ist ja recht unübersichtlich.....

[uname]

Zur Frage apt-get vs. aptitude kann ich nicht viel beitragen. Wird wohl beides funktionieren.

Aber deine Update-Frage sollte eigentlich bei allen notwendigen Updates relevant sein. Warum hast du nicht viel früher gefragt? Ich gehe mal davon aus, dass es in der Vergangenheit notwendige Patches gab (Kernel, Apache2, PHP, ...), die für deinen Server weitaus wichtiger waren als Spectre und Meltdown.


Wo du aber dabei bist, solltest du dich mit dem LTS-Support-Ende von Wheezy beschäftigen, da das irgendwann dein eigentliches Problem wird:

https://wiki.debian.org/LTS

Sicherheitshalber installiere mal apt-show-versions und schau ob deine Pakete wirklich noch supportet werden.

apt-show-versions |grep wheezy |more
apt-show-versions |grep -v wheezy |more

Jeweils durchklicken und Gedanken machen. Die zweite Liste ist interessanter und sollte eigentlich leer sein.

[dufty2]

"Verfolgen" kann man es auf den sog. "security-tracker":
https://security-tracker.debian.org/tra ... kage/linux

CVE-2017-5754 (Meltdown): wheezy fixed
CVE-2017-5753 (Spectre Variant 1): wheezy vulnerable
CVE-2017-5715 (Spectre Variant 2): wheezy vulnerable

[gnude]

@uname
Vielen Dank für die Antwort. Ich bin seit eingier Zeit hauptsächlich auf Ubuntu Servern
unterwegs und hier ist apt die bevorzugte Paketverwaltung. Von älteren Debian Systemen
wie Lenny oder Squeeze weiss ich noch das man aptitude empfohlen hat und der Installer
auch mit aptitude das System erstellt hat. Später hat sich das wohl geändert. Aber so tief
bin ich nicht mehr drin.

Updates ist immer ein spannendes Thema und bei Debian wie auch Ubuntu sollten Fehlerupdates
ja keine Features ändern. Trotzdem habe ich erst gestern erlebt das die aktuellsten Ubuntu
Updates eine Reihe von selbstentwickelten Perl Scripten lahmgelegt haben. Wie immer das auch geht.

Wichtiger als Spectre und Meltdown? Ich bin mir nicht sicher, aber kann ich mir vorstellen. Denn ein
Programm muss ja zur Ausführung gebracht werden. Und bei einem Mailserver werden ja zunächst
keine Programme gestartet. Gleiches gilt für xmpp oder dlna. Sehe ich das richtig?
Die Informationspolitik ist hier sehr undurchsichtig.

Supportende ist in der Tat ein Problem. Allerdings bin ich für diesen Server nicht mehr
lange zuständig. Aber trotzdem ist das ein spanneder Punkt der auf die ToDo Liste kommt.

@dufty2
Danke. Kurz und knackig.

[MSfree]

@uname
Vielen Dank für die Antwort. Ich bin seit eingier Zeit hauptsächlich auf Ubuntu Servern
unterwegs und hier ist apt die bevorzugte Paketverwaltung. Von älteren Debian Systemen
wie Lenny oder Squeeze weiss ich noch das man aptitude empfohlen hat und der Installer
auch mit aptitude das System erstellt hat. Später hat sich das wohl geändert. Aber so tief
bin ich nicht mehr drin.

Es ist (zumindest bei Debian) völlig wurscht, ob man apt, apt-get oder aptitude verwendet, man kann die drei sogar sorglos mischen. Solche Kuriositäten

Code: Alles auswählen

apt update
apt-get upgrade
aptitude install ssh

Bringen Debian jedenfalls überhaupt nicht durcheinander.

aptitude ist halt als interaktives Programm, mit dem man Pakete suchen kann und sich auch eine Übersicht anzeigen lassen kann, recht bequem. Wenn ich nach etwas suche, nutze ich jedenfalls eher aptitude als apt-cache search. Andererseits nutze ich für updates/upgrades auch aus Gewohnheit apt-get.

[scientific]

Ich bin jetzt verwirrt...
Ich hab auf meinem Laptop stretch + backports.

uname -a gibt mir:
Linux aldebaran 4.14.0-0.bpo.2-amd64 #1 SMP Debian 4.14.7-1~bpo9+1 (2017-12-22) x86_64 GNU/Linux
Ist mein Kernel jetzt anfällig oder nicht? Ich kann mit der Info auf Linux aldebaran 4.14.0-0.bpo.2-amd64 #1 ... GNU/Linux nix anfangen.

lg scientific

[smutbert]

@scientific
Soweit ich das überblicke ist dein System damit für alles anfällig. Ein Microcode-Update für einige CPUs (Haswell und Broadwell habe ich ausprobiert) gegen Spektre 2, das alleine aber nichts hilft, ist in der unstable- und testing-Version von intel-microcode (3.20180108.1) und die Page Table Isolation gegen Meltdown ist auch erst im Kernel von unstable angekommen (linux-image-4.14.0-3-amd64 4.14+89). In den backports sieht es damit afaik düster aus.

[scientific]

Boa... das ist aber schon zach.

CentOS7 ist schon seit einigen Tagen abgedichtet... Mit stable hab ich da (wenn ich nicht den originalen Kernel von stable-backports 4.9.65-3+deb9u2 nehme) ein schönes offenes Loch...

Den Kernel aus sid und den Microcode auf stable zu installieren, ist ja nicht besonders empfehlenswert...

lg scientific

[scientific]

@smutbert

Code: Alles auswählen

grave Fehler von intel-microcode (3.20170707.1~deb9u1 → 3.20180108.1) <Ausstehend>
b1 - #886998 - intel-microcode: regressions on Haswell, Broadwell (crashes/reboots) and Kaby Lake (sleep-to-ram)

klingt jetzt nicht so vertrauenswürdig... ich hab einen haswell-laptop...

Und

Code: Alles auswählen

 # dpkg -l|grep linux-image
ii  linux-image-4.13.0-trunk-amd64                              4.13.1-1~exp1                               amd64        Linux 4.13 for 64-bit PCs
ii  linux-image-4.14.0-0.bpo.2-amd64                            4.14.7-1~bpo9+1                             amd64        Linux 4.14 for 64-bit PCs
ii  linux-image-4.14.0-3-amd64                                  4.14.13-1                                   amd64        Linux 4.14 for 64-bit PCs

ist auch nicht die von dir genannte Version von 4.14.0.3-amd64 die ich soeben aus sid installierte....

[smutbert]

Doch das

Code: Alles auswählen

ii  linux-image-4.14.0-3-amd64                                  4.14.13-1     

ist sie, wenn ich mich nicht komplett irre (alles ab 4.14.11?) sollte was meltdown angeht einigermaßen ok sein. Ansonsten stütze ich mich hauptsächlich auf das was ich hier im Forum lese und dieses Tool [1].

und ja es ist zach, aber was erwartet man sonst von einem "Security SuperGAU"?

Dass in CentOS schon alles abgedichtet ist, fällt mir nicht ganz leicht zu glauben:
Google ist nach dem was ich gelesen habe, bis jetzt der einzige der behauptet, dass Spectre überhaupt komplett abgedichtet werden kann.
Bei Variante 2 von Spectre benötigt die nicht-Google-Lösung/-Entschärfung ein Microcode-Update, das zuletzt noch nicht für alle CPUs existiert hat und das zumindest bei Broadwell- und Haswellsystemen schon für spontane Neustarts gesorgt hat [2]. Hat es nicht außerdem geheißen, dass für gegen Spektre alles neu kompiliert werden muss, nicht nur der Kernel?

[1] https://github.com/speed47/spectre-meltdown-checker/
[2] https://www.heise.de/newsticker/meldung ... 40326.html

[hikaru]

@scientific:
Die Backports kriegen im Gegensatz zu den regulären Quellen keine Sicherheitsupdates. In linux-image-4.9.0-5-amd64 aus Stretch ist Meltdown bereits gefixt. Zumindest Haswell selbst braucht auch keinen neueren Kernel, so dass du vermutlich auf den Backports-Kernel verzichten kannst.
Andererseits sind Kernel weitgehend austauschbar, so dass es als Übergangslösung kein Problem sein sollte, statt des Backports-Kernels linux-image-4.14.0-3-amd64 aus Sid auf deinem System zu fahren. (ohne Gewähr!)

PS: Dieser Stretch-relevante Teil der Diskussion würde vermutlich besser in den Hauptthread zu Meltdown/Spectre [1] passen, oder in einen eigenen Thread, statt hier in den Softwarearchäologen-Thread.


[1] viewtopic.php?f=37&t=168134

[smutbert]

Für diese Bemerkung missbrauche ich diesen Thread aber noch: Der neue Kernel ist in den backports (linux-image-4.14.0-0.bpo.3-amd64) angekommen.

[xcomm]

Hi Gemeinde,

nochmal zum Original-Post zurück.

"sind für Wheezy (Debian 7) schon updates ... verfügbar?"

Das ist kein gepatchter Kernel, oder?

Code: Alles auswählen

Package: linux-image-3.2.0-5-amd64
Source: linux
Version: 3.2.96-3

Wird es in wheezy LTS keinen gepatchten Kernel geben, weil das nur ab 4.xx geht?


Danke, xcomm

P.S::
backports (Debianlinux-image-4.14.0-0.bpo.3-amd64) scheint mir nicht wheezy-backports sondern höher.
https://packages.debian.org/wheezy-back ... mage-amd64
wheezy-backports linux-image-amd64 (3.16+63~bpo70+1)

[hikaru]

Aus dem Changelog für linux-image-3.2.0-5-amd64

linux (3.2.96-3) wheezy-security; urgency=high

* [amd64] Implement Kernel Page Table Isolation (KPTI, aka KAISER)
(CVE-2017-5754)
* Bump ABI to 5 and apply deferred stable changes:
- Input: i8042 - break load dependency between atkbd/psmouse and i8042
- Input: i8042 - set up shared ps2_cmd_mutex for AUX ports
- ACPICA: Utilities: split IO address types from data type models.
- ALSA: Enable CONFIG_ZONE_DMA for smaller PCI DMA masks
- libata: Align ata_device's id on a cacheline
- libata: Ignore spurious PHY event on LPM policy change
- net/ipv6: add sysctl option accept_ra_min_hop_limit
* USB: core: prevent malicious bNumInterfaces overflow (CVE-2017-17558)
* [x86] KVM: Fix stack-out-of-bounds read in write_mmio (CVE-2017-17741)
* crypto: salsa20 - fix blkcipher_walk API usage (CVE-2017-17805)
* crypto: hmac - require that the underlying hash algorithm is unkeyed
(CVE-2017-17806)
* KEYS: add missing permission check for request_key() destination
(CVE-2017-17807)

-- Ben Hutchings <ben@decadent.org.uk> Sat, 06 Jan 2018 22:07:04 +0000

Da ist also für Meltdown schon ein Fix drin.
Der Wheezy-Backports-Kernel hat seit Dezember 2014 keine Updates mehr gesehen.

[xcomm]

Danke nochmal !

vi `dpkg -L linux-image-3.2.0-5-amd64 | grep change`