linux-4.1.15_CVE-2017-1000371

INSTALLATION des Kernel-Quellcodes:

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

  xz -cd linux-4.X.tar.xz | tar xvf -

  Ersetzen Sie "X" 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 Bibliotheks-Headerdateien verwendet werden. Sie sollten zur Bibliothek passen und nicht durch das jeweilige Kernel-des-Tages durcheinandergebracht werden.

• Sie können auch zwischen 4.x-Versionen durch Patchen upgraden. Patches werden im xz-Format verteilt. Um per Patch zu installieren, besorgen Sie sich alle neueren Patch-Dateien, wechseln Sie in das oberste Verzeichnis des Kernel-Quellcodes (linux-4.X) und führen Sie Folgendes aus:

  xz -cd ../patch-4.x.xz | patch -p1

  Ersetzen Sie "x" für alle Versionen, die größer sind als die Version "X" Ihres aktuellen Quellbaums, in der richtigen Reihenfolge, und alles sollte in Ordnung sein. Möglicherweise möchten Sie die Sicherungsdateien (some-file-name~ oder some-file-name.orig) entfernen und sicherstellen, dass keine fehlgeschlagenen Patches vorhanden sind (some-file-name# oder some-file-name.rej). Falls doch, haben entweder Sie oder ich einen Fehler gemacht.

  Im Gegensatz zu Patches für die 4.x-Kernel sind Patches für die 4.x.y-Kernel (auch als -stable-Kernel bekannt) nicht inkrementell, sondern werden direkt auf den Basis-4.x-Kernel angewendet. Wenn Ihr Basiskernel beispielsweise 4.0 ist und Sie den 4.0.3-Patch anwenden möchten, dürfen Sie nicht zuerst die Patches 4.0.1 und 4.0.2 anwenden. Wenn Sie Kernel-Version 4.0.2 ausführen und auf 4.0.3 wechseln möchten, müssen Sie zuerst den 4.0.2-Patch rückgängig machen (d. h. patch -R), bevor Sie den 4.0.3-Patch anwenden. Weitere Informationen dazu finden Sie in Documentation/applying-patches.txt

  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.

  linux/scripts/patch-kernel linux

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

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

  cd linux make mrproper

  Sie sollten nun die Quellen korrekt installiert haben.

SOFTWARE-ANFORDERUNGEN

Das Kompilieren und Ausführen der 4.x-Kernel erfordert aktuelle Versionen verschiedener Softwarepakete. Informationen zu den erforderlichen Mindestversionsnummern und dazu, wie Sie Updates für diese Pakete erhalten, finden Sie in Documentation/Changes. Seien Sie gewarnt, dass die Verwendung übermäßig alter Versionen dieser Pakete indirekte Fehler verursachen kann, die sehr schwer zu finden sind. Gehen Sie also nicht davon aus, dass Sie Pakete einfach aktualisieren können, wenn während des Builds oder des 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 Speicherort für die Ausgabedateien (einschließlich .config) angeben. Beispiel:

Um den Kernel zu konfigurieren und zu erstellen, verwenden Sie:

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 Nebenversion upgraden. In jeder Version werden neue Konfigurationsoptionen hinzugefügt, und es werden seltsame Probleme auftreten, 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" Textbasierte Oberfläche (Klartext).

  "make menuconfig" Textbasierte Farbmenüs, Radiolisten & Dialoge.

  "make nconfig" Erweiterte textbasierte Farbmenüs.

  "make xconfig" Auf X-Windows (Qt) basierendes Konfigurationswerkzeug.

  "make gconfig" Auf X-Windows (Gtk) basierendes Konfigurationswerkzeug.

  "make oldconfig" Beantwortet alle Fragen standardmäßig anhand des Inhalts Ihrer vorhandenen ./.config-Datei und fragt nach neuen Konfigurationssymbolen.

  "make silentoldconfig" Wie oben, vermeidet jedoch, den Bildschirm mit bereits beantworteten Fragen zu überladen. Aktualisiert zusätzlich die Abhängigkeiten.

  "make olddefconfig" Wie oben, setzt jedoch neue Symbole ohne Nachfragen auf ihre Standardwerte.

  "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 die Symbolwerte so weit wie möglich auf 'y' gesetzt werden.

  "make allmodconfig" Erstellt eine ./.config-Datei, indem die Symbolwerte so weit wie möglich auf 'm' gesetzt werden.

  "make allnoconfig" Erstellt eine ./.config-Datei, indem die Symbolwerte so weit wie möglich auf 'n' gesetzt werden.

  "make randconfig" Erstellt eine ./.config-Datei, indem die Symbolwerte auf zufällige Werte gesetzt werden.

  "make localmodconfig" Erstellt eine Konfiguration basierend auf der aktuellen Konfiguration und den geladenen Modulen (lsmod). Deaktiviert jede Moduloption, die für die geladenen Module nicht benötigt wird.

  root@kitploit:~

                      Um ein localmodconfig für einen anderen Rechner zu
                      erstellen, speichern Sie das lsmod dieses Rechners
                      in einer Datei und übergeben Sie es als LSMOD-
                      Parameter.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      Das oben Genannte funktioniert auch beim Cross-
                      Compilieren.
  

  "make localyesconfig" Ähnlich wie localmodconfig, mit dem Unterschied, dass alle Moduloptionen in eingebaute (=y) Optionen umgewandelt werden.

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

• HINWEISE zu "make config":

  • Überflüssige Treiber machen den Kernel größer und können unter bestimmten Umständen zu Problemen führen: Das Abtasten (Probing) nach einer nicht vorhandenen Controller-Karte kann Ihre anderen Controller verwirren.

  • Wenn Sie den Kernel mit einem "Processor type" (Prozessortyp) kompilieren, der höher als 386 eingestellt ist, erhalten Sie einen Kernel, der auf einem 386 NICHT funktioniert. Der Kernel erkennt dies beim Booten und gibt auf.

  • Ein Kernel mit eingebauter Mathematik-Emulation verwendet den Koprozessor weiterhin, falls einer vorhanden ist: Die Mathematik- Emulation wird in diesem Fall einfach nie genutzt. Der Kernel wird etwas größer, funktioniert aber auf verschiedenen Maschinen, unabhängig davon, ob sie einen Mathematik-Koprozessor haben oder nicht.

  • Die Konfigurationsdetails unter "kernel hacking" führen in der Regel zu einem größeren oder langsameren Kernel (oder beidem) und können den Kernel sogar instabiler machen, da einige Routinen so konfiguriert werden, dass sie aktiv versuchen, fehlerhaften Code zu brechen, um Kernel-Probleme zu finden (kmalloc()). Sie sollten daher die Fragen zu "development"-, "experimental"- 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 Sie lilo passend zu den Kernel-Makefiles installiert haben, aber Sie sollten zuerst Ihre spezielle lilo-Konfiguration überprüfen.

  Für die eigentliche Installation müssen Sie root sein, aber kein Teil des normalen Builds sollte dies erfordern. Nehmen Sie den Namen root nicht vergeblich in den Mund.

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

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

  Normalerweise läuft das Kernel-Build-System in einem relativ ruhigen Modus (aber nicht völlig lautlos). Manchmal müssen Sie oder andere Kernel-Entwickler jedoch die Compile-, Link- oder anderen 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

  Wenn das Build-System auch den Grund für den Neuaufbau jedes Ziels angeben soll, verwenden Sie "V=2". Der Standardwert ist "V=0".

• Halten Sie einen Sicherungs-Kernel bereit, falls etwas schiefgeht. Dies gilt besonders für Entwicklungsversionen, da jede neue Version neuen Code enthält, der noch nicht debuggt wurde. Stellen Sie sicher, dass Sie auch eine Sicherung der zu diesem Kernel gehörenden Module aufbewahren. Wenn Sie einen neuen Kernel mit derselben Versionsnummer wie Ihren funktionierenden Kernel installieren, erstellen Sie eine Sicherung Ihres Module-Verzeichnisses, bevor Sie "make modules_install" ausführen.

  Alternativ können Sie vor dem Kompilieren die Kernel-Konfigurationsoption "LOCALVERSION" verwenden, um der regulären Kernel-Version ein eindeutiges Suffix 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 regulärer bootbarer Kernel befindet.

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

  Wenn Sie Linux von der Festplatte booten, verwenden Sie wahrscheinlich LILO, das das in der Datei /etc/lilo.conf angegebene Kernel-Image verwendet. 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 Map-Datei zu aktualisieren!! Wenn Sie das nicht tun, können Sie das neue Kernel-Image nicht booten.

  Die Neuinstallation von LILO ist in der Regel eine Sache der Ausführung von /sbin/lilo. Möglicherweise möchten Sie /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 standardmäßige 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-Bootoptionen, falls geeignet). 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 SCHIEFGEHT:

• Wenn Sie Probleme haben, die auf Kernel-Fehler zurückzuführen zu sein scheinen, prüfen Sie bitte die Datei MAINTAINERS, ob es eine bestimmte Person gibt, die dem Teil des Kernels zugeordnet ist, mit dem Sie Probleme haben. Wenn dort niemand aufgeführt ist, ist das Nächstbeste, sie an mich zu senden ([email protected]) und möglicherweise an eine andere relevante Mailing-Liste oder an die Newsgroup.

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

• Wenn der Fehler zu einer Meldung wie der folgenden führt

  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 Systemprotokoll, reproduzieren Sie diese bitte exakt. Der Dump mag Ihnen unverständlich erscheinen, aber er enthält Informationen, die beim Debuggen des Problems helfen können. Der Text über dem Dump ist ebenfalls wichtig: Er sagt etwas darüber aus, warum der Kernel Code ausgegeben hat (im obigen Beispiel aufgrund eines ungültigen Kernel- Zeigers). 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, wie er ist. Andernfalls müssen Sie das Programm "ksymoops" verwenden, um den Dump zu interpretieren (aber das Kompilieren mit CONFIG_KALLSYMS ist in der Regel vorzuziehen). Dieses Dienstprogramm kann von ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ heruntergeladen werden. Alternativ können Sie die Dump-Suche auch von Hand durchführen:

• Bei Debugging-Dumps wie dem obigen hilft es ungemein, wenn Sie nachschlagen können, was der EIP-Wert bedeutet. Der Hexwert als solcher hilft mir oder sonst jemandem nicht sehr viel: Er hängt von Ihrer speziellen Kernel-Konfiguration ab. Was Sie tun sollten, ist, den Hexwert 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 herauszufinden, müssen Sie die System- Binärdatei finden, die zu dem Kernel gehört, der das Symptom gezeigt hat. Dies ist die Datei 'linux/vmlinux'. Um die Namensliste zu extrahieren und sie mit der EIP aus dem Kernel-Absturz abzugleichen, führen Sie Folgendes aus:

  nm vmlinux | sort | less

  Dies ergibt eine Liste der Kernel-Adressen 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 exakt mit den Funktionsadressen übereinstimmt (tatsächlich ist das sehr unwahrschein- lich), sodass Sie die Liste nicht einfach 'grep'en können: Die Liste gibt Ihnen jedoch den Startpunkt jeder Kernel-Funktion. Wenn Sie also nach der Funktion suchen, deren Startadresse niedriger ist als die gesuchte, auf die aber eine Funktion mit einer höheren Adresse folgt, finden Sie die gesuchte. Tatsächlich kann es eine gute Idee sein, ein wenig "Kontext" in Ihren Problembericht aufzunehmen, also ein paar Zeilen um die interessante Stelle herum.

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

• Alternativ können Sie gdb auf einem laufenden Kernel verwenden. (Nur- Lesen; d. h. Sie können keine Werte ändern oder Breakpoints setzen.) Dazu kompilieren Sie den Kernel zunächst mit -g; bearbeiten Sie arch/i386/Makefile entsprechend und führen Sie dann "make clean" aus. Sie müssen außerdem 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 nun alle üblichen gdb-Befehle verwenden. Der Befehl, um den Punkt nachzuschlagen, an dem Ihr System abgestürzt ist, lautet "l *0xXXXXXXXX". (Ersetzen Sie die XXX durch den EIP-Wert.)

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