Wie kann ich CVEs im Ubuntu zlib-Paket korrigieren, wenn eine neue Version nicht über apt-get verfügbar ist?

Ich habe mehrere Cloud-Stacks, auf denen Ubuntu 14.04.2 ausgeführt wird, und ich muss CVEs korrigieren, denen ich in der zlibBibliothek ausgesetzt bin (speziell zlib1gund zlib1g-dev. Schließlich muss ich diese Systeme auf eine neuere Version von Ubuntu migrieren, jedoch bis ich dies getan habe Blocker für das Upgrade behoben Ich muss vorhandene CVEs abschwächen.

• Was sind die Best Practices für das Upgrade von Systempaketen?
• Was sollte ich mir über das Brechen Sorgen machen / wie kann ich auf funktionelle Regression testen?

Was ich gerade teste, ist das Hinzufügen von Quellen aus neueren Versionen von Ubuntu (z. B. artful):

sudo cp /etc/apt/sources.list /etc/apt/sources.list.d/artful.list
sudo vim /etc/apt/sources.list.d/artful.list  # replace "trusty" with "zesty"
sudo apt-get update

Pin alle Pakete an trusty:

$ cat /etc/apt/preferences

Package: *
Pin: release n=trusty
Pin-Priority: 900

Package: *
Pin: release o=Ubuntu
Pin-Priority: -10

Aktualisieren Sie dann bestimmte Pakete mit:

apt-get install --only-upgrade <package> -t zesty

Das Paket, das ich aktualisieren muss: zlib1g/zlib1g-dev

• CVE-2016-9840 (hoch)
• CVE-2016-9841 (kritisch)
• CVE-2016-9842 (hoch)
• CVE-2016-9843 (kritisch)

Durch das Aktualisieren von Systempaketen erhalte ich keine Version von zlib1g, bei der die CVEs behoben sind. Ich brauche Version> = am 1:1.2.8.dfsg-4nächsten ist wahrscheinlich 1:1.2.11.dfsg-0ubuntu1von zesty. Sehen:

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

$ sudo apt-get update && apt-get upgrade

$ dpkg -s zlib1g | grep Version:
Version: 1:1.2.8.dfsg-1ubuntu1

Inhalt von /etc/apt/sources.list:

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.

deb http://archive.ubuntu.com/ubuntu/ trusty main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates main restricted

## Uncomment the following two lines to add software from the 'universe'
## repository.
## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://archive.ubuntu.com/ubuntu/ trusty universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty universe
deb http://archive.ubuntu.com/ubuntu/ trusty-updates universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-updates universe

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
# deb http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-backports main restricted

deb http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security main restricted
deb http://archive.ubuntu.com/ubuntu/ trusty-security universe
deb-src http://archive.ubuntu.com/ubuntu/ trusty-security universe
# deb http://archive.ubuntu.com/ubuntu/ trusty-security multiverse
# deb-src http://archive.ubuntu.com/ubuntu/ trusty-security multiverse

Ohne genauere Angaben darüber, was gepatcht werden soll und in welcher Tasche der Ubuntu-Repositorys sich die Software für eine bestimmte Version befindet, ist es unmöglich, Ihnen eine vollständige Antwort zu geben, die eng genug ist.

Aber ich werde versuchen, Ihnen einen Überblick darüber zu geben, wie Sie die Sicherheitsprobleme in Ubuntu-Paketen "patchen" können.

Softwarepakete in Main und von der Community bereitgestellte Patches in Universe über $RELEASE-securityRepositorys

Für Sicherheitspatches, die in Paketen von Benutzern zur Berücksichtigung durch das Sicherheitsteam in Universe-Paketen eingereicht wurden, und Sicherheitspatches durch das Sicherheitsteam selbst in Ubuntu-Hauptpaketen sind sie nach ihrer Veröffentlichung in den $RELEASE-securityRepositorys (z. B. xenial-security) und den $RELEASE-updatesRepositorys verfügbar . Auf diese Weise können Sie einfach ein sudo apt-get update && sudo apt-get dist-upgradePatch ausführen und alle Patches abrufen.

Wenn Sie die einzelnen CVEs im CVE-Tracker verfolgen , erfahren Sie, ob für einen CVE bereits ein Fix in Ubuntu veröffentlicht wurde, sowie die Bestimmung des Prioritätsniveaus des CVE durch das SEcurity-Team und wie schnell es behoben werden muss (Standard ist "Mittel", unabhängig davon des CVE-Schweregrads).

Pakete, die in den Repositorys nicht aktualisiert wurden

Wir haben hier zwei Probleme. Erstens erhalten Universe-Pakete nur dann Patches, wenn die Community sie dem Sicherheitsteam zum Anzeigen und Überprüfen zur Verfügung stellt. Zweitens wird eine große Anzahl von Paketen infolgedessen nicht aktualisiert.

Sie haben zwei Lösungen für diese Probleme: Entweder erstellen Sie die Pakete selbst mit den Patches neu oder warten, bis ein Update in den Repositorys landet (oder dass jemand die Patches für das Sicherheitsteam sendet).

Für die erste Lösung müssen Sie das Verpackungshandbuch von Schritt 1 bis Schritt 3.9 befolgen und dann die in Abschnitt 6 beschriebenen Schritte ausführen, wenn Sie sie für die Repositorys senden möchten, und die gepatchten Pakete lokal auf Ihrem System erstellen und installieren .

Der eigentliche Prozess hierfür ist je nach Paket sehr, sehr komplex, so dass es unmöglich ist, ihn hier zu beantworten.

Benutzerdefinierte kompilierte Software

Ihre einzige Hoffnung besteht darin, Patches selbst auf die Software anzuwenden und neu zu kompilieren und zu installieren. Dies gilt für alles, wo die Software nicht in den Repositorys enthalten ist oder in denen Sie Dinge installiert haben, die Sie zuerst kompiliert haben. Der Prozess dafür ist unendlich vielfältig, daher ist es unmöglich, hier zu antworten.

Wenn Sie einen CVE haben, den Sie reparieren müssen, und der nicht in den offiziellen Repositorys für die von Ihnen verwendete Version behoben ist, sollten Sie keine Pakete aus einer beliebigen zukünftigen Version herunterladen und installieren. Solche Pakete können gut installiert werden, es gibt jedoch keine Garantie dafür, dass vorhandene andere vorhandene Software möglicherweise mit ihnen zusammenarbeiten kann. Die ABIs oder APIs haben sich möglicherweise geändert, möglicherweise erheblich, möglicherweise nicht. Subtile Änderungen reichen möglicherweise aus, um schwer zu debuggende Fehler zu verursachen. (Wenn eine Bibliothek nicht wie erwartet geladen wird, kann eine Befehlszeilen-App einen Fehler auslösen, bei dem die Datei nicht gefunden wurde, obwohl die Datei des Befehls eindeutig vorhanden ist!)

Was ich vorschlagen würde ist:

1. Überprüfen Sie, ob ein Patch für die von Ihnen verwendete Version verfügbar ist, entweder in CVE-Berichten an anderer Stelle oder im Upstream.
2. Wenn dies der Fall ist, laden Sie das Quellpaket des betreffenden Pakets herunter und ändern Sie es: Wie kann ich den Quellcode der über apt-get installierten Pakete abrufen und ändern?
   • Verwenden Sie diese Optionquilt , um den Patch anzuwenden (siehe Debian-Wiki oder dieses Debian-Hwoto ).
   • Ich würde vorschlagen, dass Sie nur den niedrigstwertigen Teil der Versionsnummer (die Teile nach dem letzten -) stoßen - sicherlich nicht den Teil vor dem ersten :, der Epochennummer.
3. Installieren Sie das so erstellte Paket.

Dies ist viel wahrscheinlicher, um die Kompatibilität mit anderen Komponenten des Betriebssystems aufrechtzuerhalten (sofern das Update selbst nichts kaputt macht), während Sie dennoch ein Upgrade durchführen können, wenn ein Update die Repositorys Ihrer Version erreicht. Auf diese Weise können Sie auch garantieren, dass der bestimmte CVE, den Sie reparieren möchten, so weit wie möglich behoben ist, was bei dem Paket aus einer beliebigen zukünftigen Version möglicherweise nicht der Fall ist.

So habe ich es bei meinem ersten Start gemacht.

1. Ich habe meine Anwendung in Mikrodienste mit einem benutzerdefinierten Basis-Docker-Image gepackt. Die Mikrodienste basierten alle auf Node.js, das war also die Grundlage
2. Ich habe diese Dienste mit Kubernetes / Docker Compose in Stage / Prod-Umgebungen bereitgestellt
3. Ich habe diese Docker-Bilder auf cloud.docker.com gespeichert, das über einen schönen Docker-Bildscanner verfügt, der relevante CVEs findet, indem er in die Bilder schaut.

So bin ich zu den relevanten CVEs gekommen. Dann

4. Ich habe die CVEs gelesen, um zu sehen, welche angewendet wurden. Diese 4 CVEs sehen aus wie:
   • Mit inftrees.c in zlib 1.2.8 können kontextabhängige Angreifer möglicherweise nicht spezifizierte Auswirkungen haben, indem sie falsche Zeigerarithmetik nutzen.
   • Mit inffast.c in zlib 1.2.8 können kontextabhängige Angreifer möglicherweise nicht spezifizierte Auswirkungen haben, indem sie falsche Zeigerarithmetik nutzen.
   • Die inflateMark-Funktion in inflate.c in zlib 1.2.8 kann es kontextabhängigen Angreifern ermöglichen, über Vektoren, die Linksverschiebungen negativer Ganzzahlen beinhalten, nicht spezifizierte Auswirkungen zu haben.
   • Die Funktion crc32_big in crc32.c in zlib 1.2.8 kann es kontextabhängigen Angreifern ermöglichen, über Vektoren mit Big-Endian-CRC-Berechnung nicht spezifizierte Auswirkungen zu haben.

Für mich bedeuten "nicht spezifiziert" und "kontextabhängig", dass dies ein ziemlich theoretischer Angriff ist. Dies würde bedeuten, dass Bösewichte mit viel Geld in dich eindringen wollten - im Gegensatz zu normalen Bösewichten, die jemanden brechen wollen. Nur Sie wissen, wo Sie Ihre Ressourcen am besten einsetzen können.

Für meinen Fall gab es Chrome-CVEs (Chrome ist die Basis für Node.js), die für meine Anwendungsfälle nicht zutrafen. Daher habe ich sie ignoriert und auf Upstream-Korrekturen gewartet. Manchmal gab es Dinge, die sofort behoben werden mussten, also:

5. Ich habe die Docker-Bilder aktualisiert. Da alle Mikrodienste mit einem benutzerdefinierten Basis-Docker-Image gestartet wurden, konnte ich Knoten- und Betriebssystem-Updates relativ schnell veröffentlichen.
6. Bereitstellen auf der Bühne, Rauchtest auf der Bühne und Bereitstellen in der Produktion.

Ich habe hier einige andere Antworten positiv bewertet - hoffentlich bekommen Sie, wonach Sie suchen.