linux-3.0.35_CVE-2019-10220

INSTALLATION DER KERNEL-QUELLEN:

• Wenn Sie die vollständigen Quellen installieren, legen Sie das Kernel-Tarball in ein Verzeichnis, für das Sie Berechtigungen haben (z. B. Ihr Home-Verzeichnis) und entpacken Sie es:

  root@kitploit:~

   gzip -cd linux-3.X.tar.gz | tar xvf -
  

  oder bzip2 -dc linux-3.X.tar.bz2 | tar xvf -

  Ersetzen Sie "XX" durch die Versionsnummer des neuesten Kernels.

  Verwenden Sie NICHT den Bereich /usr/src/linux! Dieser Bereich enthält einen (meist unvollständigen) Satz von Kernel-Headern, die von den Library-Header-Dateien verwendet werden. Sie sollten zur Bibliothek passen und nicht von dem jeweiligen Kernel-du-jour durcheinandergebracht werden.

• Sie können auch zwischen 3.x-Veröffentlichungen durch Patchen aktualisieren. Patches werden im traditionellen gzip- und im neueren bzip2-Format verteilt. Um durch Patchen zu installieren, holen Sie alle neueren Patch-Dateien, wechseln Sie in das oberste Verzeichnis der Kernel-Quellen (linux-3.x) und führen Sie aus:

  root@kitploit:~

   gzip -cd ../patch-3.x.gz | patch -p1
  

  oder bzip2 -dc ../patch-3.x.bz2 | patch -p1

  (wiederholen Sie xx für alle Versionen, die größer sind als die Version Ihres aktuellen Quellbaums, in_der_Reihenfolge) und Sie sollten fertig sein. Sie möchten vielleicht die Sicherungsdateien (xxx~ oder xxx.orig) entfernen und sicherstellen, dass keine fehlgeschlagenen Patches (xxx# oder xxx.rej) vorhanden sind. Wenn welche vorhanden sind, haben entweder Sie oder ich einen Fehler gemacht.

  Im Gegensatz zu Patches für die 3.x-Kernel sind Patches für die 3.x.y-Kernel (auch als -stable-Kernel bekannt) nicht inkrementell, sondern werden direkt auf den Basis-3.x-Kernel angewendet. Bitte lesen Sie Documentation/applying-patches.txt für weitere Informationen.

  Alternativ kann das Skript patch-kernel verwendet werden, um diesen Prozess zu automatisieren. Es ermittelt die aktuelle Kernel-Version und wendet alle gefundenen Patches an.

  root@kitploit:~

   linux/scripts/patch-kernel linux
  

  Das erste Argument im obigen Befehl ist der Speicherort der Kernel-Quellen. Patche werden aus dem aktuellen Verzeichnis angewendet, aber ein alternatives Verzeichnis kann als zweites Argument angegeben werden.

• Wenn Sie zwischen Veröffentlichungen mit den stabilen Serien-Patches (z. B. patch-3.x.y) aktualisieren, beachten Sie, dass diese "Punktveröffentlichungen" nicht inkrementell sind und auf den 3.x-Basisbaum angewendet werden müssen. Wenn Ihr Basiskernel beispielsweise 3.0 ist und Sie den 3.0.3-Patch anwenden möchten, wenden Sie nicht und müssen Sie nicht zuerst die 3.0.1- und 3.0.2-Patches anwenden. Wenn Sie Kernel-Version 3.0.2 ausführen und auf 3.0.3 springen möchten, müssen Sie zuerst den 3.0.2-Patch rückgängig machen (d. h. patch -R) bevor Sie den 3.0.3-Patch anwenden. Weitere Informationen dazu finden Sie in Documentation/applying-patches.txt

• Stellen Sie sicher, dass keine alten .o-Dateien und Abhängigkeiten herumliegen:

  root@kitploit:~

   cd linux
   make mrproper
  

  Sie sollten nun die Quellen korrekt installiert haben.

SOFTWAREANFORDERUNGEN

Das Kompilieren und Ausführen der 3.x-Kernel erfordert aktuelle Versionen verschiedener Softwarepakete. Konsultieren Sie Documentation/Changes für die erforderlichen Mindestversionsnummern und wie Sie Updates für diese Pakete erhalten. Beachten Sie, dass die Verwendung übermäßig alter Versionen dieser Pakete indirekte Fehler verursachen kann, die nur sehr schwer aufzuspüren sind. Gehen Sie also nicht davon aus, dass Sie Pakete einfach aktualisieren können, wenn während des Builds oder Betriebs offensichtliche Probleme auftreten.

BUILD-VERZEICHNIS FÜR DEN KERNEL:

Beim Kompilieren des Kernels werden alle Ausgabedateien standardmäßig zusammen mit dem Kernel-Quellcode gespeichert. Mit der Option "make O=output/dir" können Sie einen alternativen Ort für die Ausgabedateien (einschließlich .config) angeben. Beispiel: Kernel-Quellcode: /usr/src/linux-3.N Build-Verzeichnis: /home/name/build/kernel

So konfigurieren und bauen Sie den Kernel: cd /usr/src/linux-3.N make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install

Bitte beachten Sie: Wenn die Option 'O=output/dir' verwendet wird, muss sie für alle Aufrufe von make verwendet werden.

KONFIGURATION DES KERNELS:

Überspringen Sie diesen Schritt nicht, auch wenn Sie nur eine kleinere Version aktualisieren. In jeder Veröffentlichung werden neue Konfigurationsoptionen hinzugefügt, und es treten merkwürdige Probleme auf, wenn die Konfigurationsdateien nicht wie erwartet eingerichtet sind. Wenn Sie Ihre vorhandene Konfiguration mit minimalem Aufwand in eine neue Version übernehmen möchten, verwenden Sie "make oldconfig", das Sie nur nach den Antworten auf neue Fragen fragt.

• Alternative Konfigurationsbefehle sind: "make config" Reine Textschnittstelle. "make menuconfig" Textbasierte Farbmenüs, Radiolisten und Dialoge. "make nconfig" Erweiterte textbasierte Farbmenüs. "make xconfig" X-Windows (Qt)-basiertes Konfigurationswerkzeug. "make gconfig" X-Windows (Gtk)-basiertes Konfigurationswerkzeug. "make oldconfig" Standardmäßig alle Fragen basierend auf dem Inhalt Ihrer vorhandenen ./.config-Datei und Fragen zu neuen Konfigurationssymbolen. "make silentoldconfig" Wie oben, vermeidet jedoch das Überladen des Bildschirms mit bereits beantworteten Fragen. Aktualisiert zusätzlich die Abhängigkeiten. "make defconfig" Erstellt eine ./.config-Datei unter Verwendung der Standard-Symbolwerte aus entweder arch/$ARCH/defconfig oder arch/$ARCH/configs/${PLATFORM}_defconfig, abhängig von der Architektur. "make ${PLATFORM}_defconfig" Erstellt eine ./.config-Datei unter Verwendung der Standard-Symbolwerte aus arch/$ARCH/configs/${PLATFORM}_defconfig. Verwenden Sie "make help", um eine Liste aller verfügbaren Plattformen Ihrer Architektur zu erhalten. "make allyesconfig" Erstellt eine ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'y' gesetzt werden. "make allmodconfig" Erstellt eine ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'm' gesetzt werden. "make allnoconfig" Erstellt eine ./.config-Datei, indem Symbolwerte so weit wie möglich auf 'n' gesetzt werden. "make randconfig" Erstellt eine ./.config-Datei, indem Symbolwerte auf zufällige Werte gesetzt werden.

  Weitere Informationen zur Verwendung der Linux-Kernel-Konfigurationswerkzeuge finden Sie in Documentation/kbuild/kconfig.txt.

  ANMERKUNGEN zu "make config":

  • Das Vorhandensein unnötiger Treiber macht den Kernel größer und kann unter bestimmten Umständen zu Problemen führen: Die Suche nach einer nicht vorhandenen Controller-Karte kann Ihre anderen Controller verwirren.
  • Das Kompilieren des Kernels mit "Processor type" auf höher als 386 führt zu einem Kernel, der NICHT auf einem 386 funktioniert. Der Kernel erkennt dies beim Booten und gibt auf.
  • Ein Kernel mit eingebauter Math-Emulation verwendet den Coprozessor, falls vorhanden: Die Math-Emulation wird in diesem Fall einfach nie verwendet. Der Kernel wird etwas größer, funktioniert aber auf verschiedenen Maschinen, unabhängig davon, ob sie einen Math-Coprozessor haben oder nicht.
  • Die "kernel hacking"-Konfigurationsdetails führen normalerweise zu einem größeren oder langsameren Kernel (oder beidem) und können den Kernel sogar weniger stabil machen, indem einige Routinen so konfiguriert werden, dass sie aktiv versuchen, schlechten Code zu brechen, um Kernel-Probleme zu finden (kmalloc()). Daher sollten Sie die Fragen zu "Entwicklung", "experimentell" oder "Debugging"- Funktionen wahrscheinlich mit 'n' beantworten.

KOMPILIEREN DES KERNELS:

• Stellen Sie sicher, dass mindestens gcc 3.2 verfügbar ist. Weitere Informationen finden Sie in Documentation/Changes.

  Bitte beachten Sie, dass Sie mit diesem Kernel weiterhin a.out-Benutzerprogramme ausführen können.

• Führen Sie "make" aus, um ein komprimiertes Kernel-Image zu erstellen. Es ist auch möglich, "make install" auszuführen, wenn lilo installiert ist, das zu den Kernel-Makefiles passt, aber Sie sollten zuerst Ihre spezifische lilo-Konfiguration überprüfen.

  Für die eigentliche Installation müssen Sie root sein, aber kein normaler Build sollte dies erfordern. Nehmen Sie den Namen root nicht vergeblich.

• Wenn Sie Teile des Kernels als `modules' konfiguriert haben, müssen Sie auch "make modules_install" ausführen.

• Ausführliche Kernel-Kompilierungs-/Build-Ausgabe:

  Normalerweise läuft das Kernel-Build-System in einem relativ ruhigen Modus (aber nicht völlig still). Manchmal müssen Sie oder andere Kernel-Entwickler jedoch Kompilierungs-, Link- oder andere Befehle genau so sehen, wie sie ausgeführt werden. Verwenden Sie dazu den "verbose"-Build-Modus. Dies geschieht durch Einfügen von "V=1" in den "make"-Befehl. Z.B.:

  make V=1 all

  Um das Build-System zu veranlassen, auch den Grund für das Neuerstellen jedes Ziels mitzuteilen, verwenden Sie "V=2". Die Voreinstellung ist "V=0".

• Halten Sie einen Backup-Kernel bereit, falls etwas schiefgeht. Dies gilt insbesondere für Entwicklungsveröffentlichungen, da jede neue Version neuen Code enthält, der noch nicht debuggt wurde. Stellen Sie sicher, dass Sie auch ein Backup der zu diesem Kernel gehörenden Module aufbewahren. Wenn Sie einen neuen Kernel mit der gleichen Versionsnummer wie Ihr funktionierender Kernel installieren, erstellen Sie ein Backup Ihres Modulverzeichnisses, bevor Sie "make modules_install" ausführen. Alternativ können Sie vor dem Kompilieren die Kernel-Konfigurationsoption "LOCALVERSION" verwenden, um einen eindeutigen Suffix an die reguläre Kernel-Version anzuhängen. LOCALVERSION kann im Menü "General Setup" gesetzt werden.

• Um Ihren neuen Kernel zu booten, müssen Sie das Kernel-Image (z. B. .../linux/arch/i386/boot/bzImage nach der Kompilierung) an den Ort kopieren, an dem sich Ihr normaler bootbarer Kernel befindet.

• Das Booten eines Kernels direkt von einer Diskette ohne Hilfe eines Bootloaders wie LILO wird nicht mehr unterstützt.

  Wenn Sie Linux von der Festplatte booten, verwenden Sie wahrscheinlich LILO, das das Kernel-Image verwendet, das in der Datei /etc/lilo.conf angegeben ist. Die Kernel-Image-Datei ist normalerweise /vmlinuz, /boot/vmlinuz, /bzImage oder /boot/bzImage. Um den neuen Kernel zu verwenden, speichern Sie eine Kopie des alten Images und kopieren Sie das neue Image über das alte. Dann MÜSSEN SIE LILO ERNEUT AUSFÜHREN, um die Ladeabbildung zu aktualisieren!! Wenn Sie dies nicht tun, können Sie das neue Kernel-Image nicht booten.

  Die Neuinstallation von LILO erfolgt normalerweise durch Ausführen von /sbin/lilo. Sie möchten vielleicht /etc/lilo.conf bearbeiten, um einen Eintrag für Ihr altes Kernel-Image (z. B. /vmlinux.old) anzugeben, falls das neue nicht funktioniert. Weitere Informationen finden Sie in der LILO-Dokumentation.

  Nach der Neuinstallation von LILO sollte alles bereit sein. Fahren Sie das System herunter, starten Sie neu und genießen Sie es!

  Wenn Sie jemals das Standard-Root-Gerät, den Videomodus, die Ramdisk-Größe usw. im Kernel-Image ändern müssen, verwenden Sie das Programm 'rdev' (oder alternativ die LILO-Boot-Optionen, wenn angebracht). Es ist nicht nötig, den Kernel neu zu kompilieren, um diese Parameter zu ändern.

• Starten Sie mit dem neuen Kernel neu und genießen Sie es.

WENN ETWAS SCHIEFLÄUFT:

• Wenn Sie Probleme haben, die auf Kernel-Fehler zurückzuführen zu sein scheinen, überprüfen Sie bitte die Datei MAINTAINERS, um zu sehen, ob es eine bestimmte Person gibt, die mit dem Teil des Kernels verbunden ist, mit dem Sie Probleme haben. Wenn dort niemand aufgeführt ist, dann ist das Zweitbeste, mir eine E-Mail zu senden ([email protected]) und möglicherweise an jede andere relevante Mailing-Liste oder an die Newsgroup.

• Bitte teilen Sie in allen Fehlerberichten mit, um welchen Kernel es sich handelt, wie das Problem reproduziert werden kann und wie Ihre Konfiguration ist (verwenden Sie Ihren gesunden Menschenverstand). Wenn das Problem neu ist, teilen Sie mir dies mit, und wenn das Problem alt ist, versuchen Sie mir mitzuteilen, wann Sie es zum ersten Mal bemerkt haben.

• Wenn der Fehler zu einer Meldung wie

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  oder ähnlichen Kernel-Debugging-Informationen auf Ihrem Bildschirm oder in Ihrem Systemlog führt, reproduzieren Sie dies bitte exakt. Der Dump mag für Sie unverständlich erscheinen, enthält aber Informationen, die beim Debuggen des Problems helfen können. Der Text oberhalb des Dumps ist ebenfalls wichtig: Er sagt etwas darüber aus, warum der Kernel Code gedumpt hat (im obigen Beispiel liegt es an einem ungültigen Kernel-Zeiger). Weitere Informationen zur Interpretation des Dumps finden Sie in Documentation/oops-tracing.txt

• Wenn Sie den Kernel mit CONFIG_KALLSYMS kompiliert haben, können Sie den Dump so senden, ansonsten müssen Sie das Programm "ksymoops" verwenden, um den Dump zu interpretieren (aber die Kompilierung mit CONFIG_KALLSYMS wird normalerweise bevorzugt). Dieses Dienstprogramm kann heruntergeladen werden von ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternativ können Sie die Dump-Suche manuell durchführen:

• Beim Debuggen von Dumps wie dem obigen hilft es enorm, wenn Sie nachschlagen können, was der EIP-Wert bedeutet. Der Hex-Wert als solcher hilft mir oder irgendjemand anderem nicht sehr viel: Er hängt von Ihrer spezifischen Kernel-Konfiguration ab. Was Sie tun sollten, ist, den Hex-Wert aus der EIP-Zeile zu nehmen (ignorieren Sie die "0010:"), und ihn in der Kernel- Namensliste nachzuschlagen, um zu sehen, welche Kernel-Funktion die betreffende Adresse enthält.

  Um den Namen der Kernel-Funktion zu finden, müssen Sie die System-Binärdatei finden, die mit dem Kernel verbunden ist, der das Symptom gezeigt hat. Dies ist die Datei 'linux/vmlinux'. Um die Namensliste zu extrahieren und sie mit dem EIP aus dem Kernel-Absturz abzugleichen, führen Sie Folgendes aus:

  root@kitploit:~

   nm vmlinux | sort | less
  

  Dadurch erhalten Sie eine Liste der Kernel-Adressen, sortiert in aufsteigender Reihenfolge, aus der es einfach ist, die Funktion zu finden, die die betreffende Adresse enthält. Beachten Sie, dass die von den Kernel-Debugging- Meldungen angegebene Adresse nicht unbedingt genau mit den Funktionsadressen übereinstimmt (tatsächlich ist das sehr unwahrscheinlich), sodass Sie die Liste nicht einfach 'grep'en können: Die Liste gibt Ihnen jedoch den Startpunkt jeder Kernel-Funktion, sodass Sie durch Suchen nach der Funktion, die eine niedrigere Startadresse als die gesuchte hat, aber von einer Funktion mit einer höheren Adresse gefolgt wird, die gewünschte finden. Tatsächlich kann es eine gute Idee sein, in Ihrem Problembericht ein wenig "Kontext" hinzuzufügen, indem Sie ein paar Zeilen um die interessante Zeile herum angeben.

  Wenn Sie aus irgendeinem Grund das Obige nicht tun können (Sie haben ein vorkompiliertes Kernel-Image oder ähnliches), hilft es, mir so viel wie möglich über Ihre Konfiguration zu erzählen. Bitte lesen Sie das Dokument REPORTING-BUGS für Details.

• Alternativ können Sie gdb auf einem laufenden Kernel verwenden. (schreibgeschützt; d.h. Sie können keine Werte ändern oder Haltepunkte setzen.) Um dies zu tun, kompilieren Sie den Kernel zuerst mit -g; bearbeiten Sie arch/i386/Makefile entsprechend, führen Sie dann "make clean" aus. Sie müssen auch CONFIG_PROC_FS aktivieren (über "make config").

  Nachdem Sie mit dem neuen Kernel neu gestartet haben, führen Sie "gdb vmlinux /proc/kcore" aus. Sie können jetzt alle üblichen gdb-Befehle verwenden. Der Befehl, um den Punkt nachzuschlagen, an dem Ihr System abgestürzt ist, ist "l *0xXXXXXXXX". (Ersetzen Sie die XXXe durch den EIP-Wert.)

  gdb auf einem nicht laufenden Kernel schlägt derzeit fehl, weil gdb (fälschlicherweise) den Start-Offset ignoriert, für den der Kernel kompiliert wurde.