
Analysiert und demonstriert die Linux-Kernel-Schwachstelle CVE-2023-28772 und stellt einen gepatchten oder verwundbaren Kernel-Quellcode für Sicherheitsforschung und Bildungszwecke bereit.
Linux-Kernel Version 4.x http://kernel.org/
Dies sind die Versionshinweise für Linux Version 4. Lesen Sie sie sorgfältig, denn sie erklären, worum es geht, wie der Kernel installiert wird und was zu tun ist, wenn etwas schiefgeht.
WAS IST LINUX?
Linux ist ein Klon des Betriebssystems Unix, der von Grund auf von Linus Torvalds mit Unterstützung eines locker verbundenen Teams von Hackern aus dem Internet geschrieben wurde. Es zielt auf POSIX- und Single UNIX Specification-Konformität ab.
Es verfügt über alle Funktionen, die Sie von einem modernen vollwertigen Unix erwarten, einschließlich echtem Multitasking, virtuellem Speicher, Shared Libraries, Demand Loading, gemeinsam genutzten Copy-on-Write- Executables, richtigem Speichermanagement und Multistack-Netzwerk (einschließlich IPv4 und IPv6).
Es wird unter der GNU General Public License vertrieben – weitere Details finden Sie in der beiliegenden COPYING-Datei.
AUF WELCHER HARDWARE LÄUFT ES?
Obwohl ursprünglich für 32-Bit-x86-basierte PCs (386 oder höher) entwickelt, läuft Linux heute auch auf (mindestens) den Architekturen Compaq Alpha AXP, Sun SPARC und UltraSPARC, Motorola 68000, PowerPC, PowerPC64, ARM, Hitachi SuperH, Cell, IBM S/390, MIPS, HP PA-RISC, Intel IA-64, DEC VAX, AMD x86-64, AXIS CRIS, Xtensa, Tilera TILE, AVR32 und Renesas M32R.
Linux ist leicht auf die meisten 32- oder 64-Bit-Allzweckarchitekturen portierbar, solange sie eine Paged Memory Management Unit (PMMU) und einen Port des GNU C-Compilers (gcc) (Teil der GNU Compiler Collection, GCC) besitzen. Linux wurde auch auf einige Architekturen ohne PMMU portiert, obwohl die Funktionalität dann offensichtlich etwas eingeschränkt ist. Linux wurde auch auf sich selbst portiert. Sie können den Kernel jetzt als Userspace-Anwendung ausführen – dies wird UserMode Linux (UML) genannt.
DOKUMENTATION:
Es gibt eine Vielzahl von Dokumentationen sowohl in elektronischer Form im Internet als auch in Büchern, sowohl Linux-spezifisch als auch zu allgemeinen UNIX-Fragen. Ich empfehle, die Dokumentationsunterverzeichnisse auf jeder Linux-FTP-Site für die LDP (Linux Documentation Project)-Bücher anzusehen. Diese README ist nicht als Dokumentation des Systems gedacht; es gibt viel bessere Quellen.
Im Unterverzeichnis Documentation/ befinden sich verschiedene README- Dateien: Diese enthalten typischerweise kernel-spezifische Installations- hinweise für einige Treiber usw. Siehe Documentation/00-INDEX für eine Liste, was in jeder Datei enthalten ist. Bitte lesen Sie die Datei Changes, da sie Informationen über Probleme enthält, die durch ein Upgrade Ihres Kernels entstehen können.
Das Unterverzeichnis Documentation/DocBook/ enthält mehrere Anleitungen für Kernel-Entwickler und -Benutzer. Diese Anleitungen können in verschiedenen Formaten ausgegeben werden: PostScript (.ps), PDF, HTML und Man-Pages, unter anderem. Nach der Installation rendern "make psdocs", "make pdfdocs", "make htmldocs" oder "make mandocs" die Dokumentation im gewünschten Format.
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 das Verzeichnis /usr/src/linux! In diesem Bereich befinden sich (meist unvollständige) Kernel-Header, die von den Bibliotheks-Header-Dateien verwendet werden. Diese sollten mit der Bibliothek übereinstimmen und nicht durch den gerade aktuellen Kernel durcheinandergebracht werden.
Sie können auch zwischen 4.x-Versionen durch Patchen aktualisieren. Patches werden im xz-Format verteilt. Um durch Patchen zu installieren, holen Sie sich alle neueren Patch-Dateien, wechseln Sie in das oberste Verzeichnis des Kernel-Quellcodes (linux-4.X) und führen Sie 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 Quellbaum, der Reihe nach, und alles sollte in Ordnung sein. Sie sollten die Backup-Dateien (dateiname~ oder dateiname.orig) entfernen und sicherstellen, dass keine fehlgeschlagenen Patches (dateiname# oder dateiname.rej) vorhanden sind. 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-Kernel 4.x angewendet. Wenn Ihr Basis-Kernel 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 springen 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. Mehr dazu lesen 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. Konsultieren Sie Documentation/Changes für die erforderlichen Mindestversionsnummern und wie Sie Updates für diese Pakete erhalten. Seien Sie gewarnt, dass die Verwendung extrem 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 standardmäßig alle Ausgabedateien 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-4.X
Build-Verzeichnis: /home/name/build/kernel
Zum Konfigurieren und Erstellen des Kernels verwenden Sie:
cd /usr/src/linux-4.X
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: 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 Konfigurations- optionen hinzugefügt, und es treten seltsame Probleme auf, wenn die Konfigurationsdateien nicht wie erwartet eingerichtet sind. Wenn Sie Ihre vorhandene Konfiguration mit minimalem Aufwand auf eine neue Version übertragen möchten, verwenden Sie "make oldconfig", das Sie nur nach den Antworten auf neue Fragen fragt.
Alternative Konfigurationsbefehle sind:
"make config" Klartext-Schnittstelle.
"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 Nachfragen zu neuen Konfigurationssymbolen.
"make silentoldconfig" Wie oben, aber vermeidet das Überladen des Bildschirms mit bereits beantworteten Fragen. Aktualisiert zusätzlich die Abhängigkeiten.
"make olddefconfig" Wie oben, setzt aber neue Symbole auf ihre Standardwerte, ohne nachzufragen.
"make defconfig" Erstellt eine ./.config-Datei unter Verwendung der Standardsymbolwerte entweder aus arch/$ARCH/defconfig oder arch/$ARCH/configs/${PLATFORM}_defconfig, abhängig von der Architektur.
"make ${PLATFORM}_defconfig" Erstellt eine ./.config-Datei unter Verwendung der Standardsymbolwerte 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.
"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.
Um eine 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 obige funktioniert auch beim Cross-Compilieren.
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 installiert haben, das zu den Kernel-Makefiles passt, aber Sie sollten zuerst Ihre spezielle lilo-Konfiguration überprüfen.
Um die eigentliche Installation durchzuführen, müssen Sie root sein, aber keiner der normalen Build-Schritte sollte das erfordern. Nehmen Sie den Namen root nicht missbräuchlich in den Mund.
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 dafür den "verbose" Build-Modus. Dies geschieht, indem Sie "V=1" in den "make"-Befehl einfügen. Z.B.:
make V=1 all
Um das Build-System auch den Grund für den Neubau jedes Ziels angeben zu lassen, verwenden Sie "V=2". Die Voreinstellung ist "V=0".
Halten Sie einen Backup-Kernel bereit, falls etwas schiefgeht. Dies gilt insbesondere für Entwicklungsversionen, 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 derselben Versionsnummer wie Ihr funktionierender Kernel installieren, erstellen Sie ein Backup Ihres Module-Verzeichnisses, bevor Sie "make modules_install" ausführen.
Alternativ können Sie vor dem Kompilieren die Kernel-Konfigurations- option "LOCALVERSION" verwenden, um einen eindeutigen Suffix an die reguläre Kernel-Version anzuhängen. LOCALVERSION kann im Menü "General Setup" eingestellt 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 bootfähiger Kernel befindet.
Das Booten eines Kernels direkt von einer Diskette ohne die 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 NEU AUSFÜHREN, um die Ladekarte zu aktualisieren!! Wenn Sie das nicht tun, können Sie das neue Kernel-Image nicht booten.
FALLS ETWAS SCHIEFGEHT:
Wenn Sie Probleme haben, die auf Kernel-Fehler zurückzuführen zu sein scheinen, überprüfen Sie bitte die Datei MAINTAINERS, 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, ist das Nächstbeste, sie an mich ([email protected]) und möglicherweise an eine andere relevante Mailingliste oder an die Newsgroup zu senden.
Bitte geben Sie in allen Fehlerberichten bitte an, um welchen Kernel es sich handelt, wie das Problem zu reproduzieren ist und wie Ihr Setup aussieht (gesunder Menschenverstand). Wenn das Problem neu ist, teilen Sie mir das mit, und wenn das Problem alt ist, versuchen Sie bitte 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 ähnliche Kernel-Debugging-Informationen auf Ihrem Bildschirm oder in Ihrem Systemlog führt, bitte duplizieren Sie sie exakt. Der Dump mag Ihnen 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 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, andernfalls müssen Sie das Programm "ksymoops" verwenden, um den Dump zu interpretieren (aber das Kompilieren mit CONFIG_KALLSYMS wird normalerweise bevorzugt). Dieses Dienstprogramm kann von ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ heruntergeladen werden. Alternativ können Sie die Dump-Suche von Hand durchführen:
Bei der Fehlersuche in Dumps wie oben hilft es enorm, wenn Sie nachschlagen können, was der EIP-Wert bedeutet. Der Hex-Wert als solcher hilft mir oder anderen nicht sehr viel: Er hängt von Ihrer speziellen 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 nachschlagen, um zu sehen, welche Kernel-Funktion die fehlerhafte Adresse enthält.
Um den Namen der Kernel-Funktion herauszufinden, 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 mit dem EIP aus dem Kernel-Absturz abzugleichen, führen Sie aus:
nm vmlinux | sort | less
Dies gibt Ihnen eine Liste der Kernel-Adressen, sortiert in aufsteigender Reihenfolge, aus der es einfach ist, die Funktion zu finden, die die fehlerhafte 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 unwahrschein- lich), so dass Sie die Liste nicht einfach 'grep'en können: Die Liste gibt Ihnen jedoch den Startpunkt jeder Kernel-Funktion, so dass Sie durch die Suche nach der Funktion, die eine Startadresse hat, die niedriger ist als die gesuchte, aber gefolgt von einer Funktion mit einer höheren Adresse, die gewünschte finden. In der Tat kann es eine gute Idee sein, ein wenig "Kontext" in Ihren Problembericht aufzunehmen, indem Sie ein paar Zeilen um die interessante Stelle herum angeben.
"make localyesconfig" Ähnlich wie localmodconfig, mit dem Unterschied, dass alle Moduloptionen in integrierte (=y) Optionen umgewandelt werden.
Weitere Informationen zur Verwendung der Linux-Kernel-Konfigurations- werkzeuge finden Sie in Documentation/kbuild/kconfig.txt.
HINWEISE zu "make config":
Nicht benötigte Treiber machen den Kernel größer und können unter bestimmten Umständen zu Problemen führen: Die Suche nach einer nicht vorhandenen Controllerkarte kann andere Controller verwirren.
Das Kompilieren des Kernels mit einem "Processor type" höher als 386 führt zu einem Kernel, der NICHT auf einer 386 funktioniert. Der Kernel erkennt dies beim Booten und gibt auf.
Ein Kernel mit integrierter arithmetischer Emulation verwendet den Koprozessor, falls vorhanden, trotzdem: Die arithmetische 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 mathematischen Koprozessor haben oder nicht.
Die Konfigurationsdetails des "kernel hacking" 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, fehlerhaften Code zu unterbrechen, um Kernel-Probleme zu finden (kmalloc()). Daher sollten Sie die Fragen zu "entwicklungs-", "experimentellen" oder "debugging"- Funktionen wahrscheinlich mit 'n' beantworten.
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) zu spezifizieren, 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 Sie aus irgendeinem Grund das Obige nicht tun können (Sie haben ein vorcompiliertes Kernel-Image oder ähnliches), hilft es, mir so viel wie möglich über Ihr Setup mitzuteilen. Bitte lesen Sie das Dokument REPORTING-BUGS für Details.
Alternativ können Sie gdb auf einem laufenden Kernel verwenden. (Nur-Lese-Zugriff; d.h. Sie können keine Werte ändern oder Haltepunkte setzen.) Um dies zu tun, 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 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 nun alle üblichen gdb-Befehle verwenden. Der Befehl, um den Punkt nachzuschlagen, an dem Ihr System abgestürzt ist, ist "l *0xXXXXXXXX". (Ersetzen Sie die XXX durch den EIP-Wert.)
gdb auf einem nicht laufenden Kernel schlägt derzeit fehl, weil gdb (fälschlicherweise) den Startoffset ignoriert, für den der Kernel kompiliert wurde.