Wie kann ich die Shellshock-Sicherheitsanfälligkeit auf einem veralteten Ubuntu-System beheben, das ich nicht aktualisieren kann?
15341
Claus
Ich habe ein System, das ich remote verwalte (2 Zeitzonen entfernt) und Ubuntu 9.04, Jaunty, ausführt. Aus verschiedenen Gründen, vor allem weil ich wirklich sehr misstrauisch bin, weil ich versuche, ein Distributionsupgrade von so weit aus durchzuführen, kann ich es nicht auf eine neuere Version aktualisieren. Offensichtlich wird es nicht mehr unterstützt und es gibt keine offiziellen Patches. Gibt es Anweisungen, wie ich den Code patchen und bash selbst neu kompilieren kann, um die Shellshock-Schwachstellen zu entfernen?
Was haben Sie zu diesem Thema recherchiert? Die einfachste Lösung wäre wahrscheinlich, sie selbst neu zu erstellen und zu patchen. ** Möglicherweise müssen Sie dies akzeptieren, es ist einfach Zeit, den Server zu aktualisieren. **
Ramhound vor 9 Jahren
5
Ja, das ist meine Rückfalloption. Der Server ist auf dem Weg nach draußen, ich versuche nur, dass er so lange hinkt, bis das Geld für seinen Ersatz eingeht. Wenn ich vor Ort wäre, würde ich die Kugel beißen und das Update durchführen, aber ich habe das selten ohne Probleme, und ohne die Hände darauf legen zu können, würde ich es nicht riskieren, wenn ich es nicht getan habe zu.
Claus vor 9 Jahren
0
Holen Sie sich einfach ein paar Stichworte auf der Seite, damit die Leute das finden können. Außerdem arbeitete ich für Mac, OS X und Mavericks auf der Grundlage des Tests, der unter http://arstechnica.com/security/2014/09/bug-in-bash-shell-creates-big-security-hole-on-thing veröffentlicht wurde -mit-nix-in-it /
vor 9 Jahren
0
Wenn es nicht gepatcht wird, ändert sich das "Hinken mit" schnell. Seien Sie ganz klar, ** Sie benutzen eine Distribution, die vor fünf Jahren herauskam **. Der Support wurde im Oktober 2010 eingestellt. Sie müssen sich um viele Schwachstellen kümmern.
tedder42 vor 9 Jahren
1
Dies hat AskUbuntu gestohlen, von jemandem, der es von Hacker News gestohlen hat. Arbeitete auf zwei alten Servern für mich
mkdir src cd src wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz #download all patches for i in $(seq -f "%03g" 1 28); do wget http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f "%03g" 1 28);do patch -p0 < ../bash43-$i; done #build and install ./configure --prefix=/ && make && make install cd .. cd .. rm -r src
Update: Ich habe gerade bemerkt, dass Sie, wenn Sie --prefix=/den configure-Befehl nicht hinzufügen, auf dem /usr/local/bin/bashneuesten Stand sind und /bin/bashtrotzdem verwundbar sind.
Es gibt einen Fehler im Skript: Die Sequenz "0 25" sollte "1 26" sein. Wenn Sie dies lesen und die Antwort bearbeiten können, aktualisieren Sie sie bitte. Vielen Dank!
joelparkerhenderson vor 9 Jahren
0
Während `` ./configure --prefix = / && make` gut läuft, scheint es für `make install`` sudo` zu sein
Stewart vor 9 Jahren
0
Vielen Dank, dass Sie dies herausgebracht haben - eine faire Möglichkeit, Dinge während der Migration zu patchen. Einige Leute haben viele vms und es ist nicht realistisch, jede neu zu erstellen. Es ist wichtig, diese sofortige Lösung zu verwenden und gleichzeitig eine längerfristige Lösung zu finden.
Jas Panesar vor 9 Jahren
0
@ rubo77 Es muss jetzt 1 27 sein (der neue 27 Patch ist der wichtigste)
joelparkerhenderson vor 9 Jahren
0
Bevor ich bash erfolgreich kompilieren konnte, musste ich einige Abhängigkeiten installieren: `sudo apt-get install build-essential bison texinfo`
jcarballo vor 9 Jahren
0
Behebt es CVE-2014-7169 und CVE-2014-7186? Ich bin immer noch anfällig für sie, nachdem ich diese Befehle ausgeführt habe. Ich verwende die Prüfungen von https://www.linode.com/docs/security/security-patches/patching-bash-und-the-shellshock-vulnerability
Florent2 vor 9 Jahren
0
Es sieht nicht nach einem Patch für 7186 oder 7187 aus. 7169 * wird von den Patches hier abgedeckt. Bei Verwendung der Überprüfungen von der Linode-Site werden meine Computer als * nicht * anfällig für 7169 angezeigt.
unkilbeeg vor 9 Jahren
0
Patch 28 hinzugefügt. Dieses Problem * scheint *, um die Sicherheitsanfälligkeit CVE-2014-7186 / 7187 zu beheben.
unkilbeeg vor 9 Jahren
1
@jcarballo: Es funktioniert, wenn ich gerade `sudo apt-get install build-essential 'installiert habe. Warum Bison und Texinfo?
rubo77 vor 9 Jahren
0
@ rubo77: Ich nehme an, dass in verschiedenen Systemen (Distributionen, Server- / Desktopversion usw.) "./configure" ausgeführt wird, wenn der Build anders eingerichtet werden kann. In meinem Fall bat mich bash, die Abhängigkeiten von Bison und Texinfo aufzulösen (der Build schlug fehl). Ich hätte das möglicherweise umgehen können, indem ich Flags für ./configure (siehe `./configure --help`) aufbaute, aber das brauchte ich nicht.
jcarballo vor 9 Jahren
0
Dies ist ein Duplikat von [Was ist die CVE-2014-6271-bash-Sicherheitsanfälligkeit (Shellshock) und wie kann ich das Problem beheben?] (Http://askubuntu.com/a/528171). Das Skript kann ** alle herunterladen patches **
rubo77 vor 9 Jahren
0
2
Erik Duindam
Es gibt auch eine Lösung, Ihre sources.list auf die neueste zu aktualisieren und dann apt-get zu verwenden, um nur bash zu aktualisieren. Es ist wirklich schnell und ich habe einen Artikel darüber geschrieben. Folgendes tun Sie grundsätzlich:
Aktualisieren Sie auf die neuesten "vertrauenswürdigen" Ubuntu-Apt-Get-Repositorys (möglicherweise müssen Sie auch die URLs "old-repositories.ubuntu.com" ändern, wenn Sie sie verwenden. Überprüfen Sie den verknüpften Artikel):
sudo sed -i 's/YOUR_OS_CODENAME/trusty/g' /etc/apt/sources.list
Das wird nicht helfen. Wie das OP sagte, wird es nicht mehr unterstützt, daher gibt es kein Upgrade für bash.
Andrew Ferrier vor 9 Jahren
2
-3
R..
Eine einfache Möglichkeit ist, bash nicht zu verwenden. Stellen Sie sicher dash, dass installiert ist und dass /bin/shein Symlink zu dashnicht ist bash. (Dies ist die Standardeinstellung für einige Versionen von Debian, aber ich bin mir nicht sicher, was Ubuntu ist.) Wenn Sie Benutzerkonten für den ssh-Zugriff mit erzwungenen Befehlen haben, müssen Sie auch deren Login-Shells ändern. Eventuell müssen Sie auch explizit nach Skripten suchen, die bash verwenden. grepping for #!/bin/bashsollte sie finden.
Das ist ein bisschen wie zu sagen: "Wir haben festgestellt, dass Sie in C ++ Segfaults haben können, verwenden Sie stattdessen Java" ...
DevSolar vor 9 Jahren
5
Eine nähere Analogie wäre, jemandem mitzuteilen, der einen Fehler im GCC erlebe, um zu klingeln. Beide implementieren dieselbe Sprache (mit unterschiedlichen, aber manchmal überlappenden Sätzen von nicht standardmäßigen Erweiterungen), und es ist unwahrscheinlich, dass der eigentliche Bedarf nach "bash", aber eher nach "Shell Interpreter" besteht.
R.. vor 9 Jahren
3
Wie Sie schon sagten, gibt es Skripte, die explizit bash verwenden könnten. Selbst wenn Sie für vorhandene Dateien, die bash verwenden, grep, kann jemand in Zukunft ein neues Skript zu dem System hinzufügen, das explizit bash verwendet. Dasselbe gilt für eingebettete Systeme, die busybox verwenden (/ bin / sh verweist auf busybox), aber auch bash installiert haben. Am besten aktualisieren Sie die Bash in den verwundbaren Systemen.
jcarballo vor 9 Jahren
0
Die Mehrheit der Unix / Linux-Skripts erfordert bash oder eine andere moderne Shell wie ksh oder zsh. Diese verfügen über eine Vielzahl von Funktionen, die die Menschen in jeder Sprache erwarten, aber nicht in den "Bare-Bones" -Hüllen wie (BusyBox) ash / Dash / sh (Original) vorhanden sind. Diese einfacheren Schalen haben nur 20 bis 30% der Funktionalität der größeren Schalen, was sie schneller macht. Sie erfordern jedoch den umfangreichen Einsatz externer Dienstprogramme für viele allgemeine Vorgänge wie die erweiterte Zeichenfolgenbehandlung und das Musterabgleichen. Bash und so können Asche laufen, et al. Skripte. Aber nicht umgekehrt.
DocSalvager vor 9 Jahren
0