Erinnern Sie sich an Heartbleed? Wenn man dem heutigen Hype Glauben schenkt, spielt Shellshock in der gleichen Liga und hat einen ebenso fantastischen Namen, wenn auch ohne cooles Logo (jemand in der Marketingabteilung dieser Sicherheitslücken muss sich darum kümmern). Aber ganz im Ernst: Es hat das Potenzial, eine große Sache zu werden, und wie schon bei Heartbleed wollte ich etwas Definitives zusammenstellen, damit ich die Situation in den Griff bekomme und andere den Hype von der wahren Gefahr trennen können.
Zur Einstimmung möchte ich einige Inhalte aus dem Blogbeitrag von Robert Graham wiedergeben, der einige hervorragende Analysen zu diesem Thema erstellt hat. Stellen Sie sich eine HTTP-Anfrage wie diese vor:
target = 0.0.0.0/0port = 80banners = truehttp-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html)http-header = Cookie:() { :; }; ping -c 3 209.126.230.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
Die, wenn sie an eine Reihe anfälliger IP-Adressen gerichtet ist, zu folgendem Ergebnis führt:
Kurz gesagt hat Robert soeben eine Reihe von externen Rechnern dazu veranlasst, ihn anzupingen, indem er einfach eine sorgfältig ausgearbeitete Anfrage über das Internet gestellt hat. Das wirklich Besorgniserregende daran ist, dass er diese Rechner tatsächlich dazu gebracht hat, einen beliebigen Befehl (wenn auch einen eher harmlosen Ping) auszusenden, und das eröffnet eine ganze Welt von sehr ernsten Möglichkeiten. Lassen Sie mich das erklären.
Was ist Bash und warum brauchen wir sie?
Überspringen Sie dies, wenn es ein alter Hut ist, aber der Kontext ist wichtig für diejenigen, die mit Bash nicht vertraut sind, also lassen Sie uns ein grundlegendes Verständnis schaffen. Bash ist eine *Nix-Shell oder anders ausgedrückt, ein Interpreter, mit dem Sie Befehle auf Unix- und Linux-Systemen ausführen können, in der Regel über eine Verbindung über SSH oder Telnet. Sie kann auch als Parser für CGI-Skripte auf einem Webserver fungieren, wie wir sie typischerweise auf Apache laufen sehen. Es gibt sie seit den späten 80er Jahren, wo sie sich aus früheren Shell-Implementierungen entwickelt hat (der Name leitet sich von der Bourne-Shell ab), und sie ist enorm beliebt. Es gibt noch andere Shells für Unix-Varianten, aber die Sache mit der Bash ist die, dass sie die Standard-Shell für Linux und Mac OS X ist, die offensichtlich extrem weit verbreitete Betriebssysteme sind. Das ist ein wichtiger Faktor, warum dieses Risiko so signifikant ist – die Allgegenwärtigkeit der Bash – und sie wird als „eines der am häufigsten installierten Dienstprogramme auf jedem Linux-System“ beschrieben.
Sie können ein Gefühl für den Bash-Fußabdruck bekommen, wenn Sie sich die neuesten Netcraft-Webserver-Statistiken ansehen:
Wenn die Hälfte des Netzes mit Apache läuft (der typischerweise auf Linux zu finden ist), ist das ein beträchtlicher Teil eines sehr, sehr großen Kuchens. Derselbe Netcraft-Artikel berichtet, dass wir gerade die Marke von einer Milliarde Websites überschritten haben, und obwohl ein Großteil davon auf denselben Hosts läuft, ist das immer noch eine ganze Menge an Bash-Installationen. Oh – das sind auch nur Webserver, vergessen Sie nicht, dass es einen Haufen anderer Server gibt, auf denen Linux läuft, und wir werden später auch auf andere Geräte mit Bash zurückkommen.
Bash kann für eine ganze Reihe typischer Verwaltungsfunktionen verwendet werden, von der Konfiguration von Websites bis hin zur Steuerung eingebetteter Software auf einem Gerät wie einer Webcam. Natürlich ist dies keine Funktionalität, die für die ganze Welt zugänglich sein soll, und theoretisch geht es um authentifizierte Benutzer, die Befehle ausführen, zu deren Ausführung sie autorisiert wurden. Theoretisch.
Was ist der Fehler?
Lassen Sie mich mit der CVE aus der NIST-Schwachstellendatenbank beginnen, weil sie ein gutes Gefühl für den Schweregrad vermittelt (Hervorhebung von mir):
GNU Bash through 4.3 verarbeitet abschließende Zeichenketten nach Funktionsdefinitionen in den Werten von Umgebungsvariablen, was entfernten Angreifern erlaubt, beliebigen Code über eine manipulierte Umgebung auszuführen, wie durch Vektoren demonstriert wird, die das ForceCommand-Feature in OpenSSH sshd, die Module mod_cgi und mod_cgid im Apache HTTP Server, Skripte, die von nicht spezifizierten DHCP-Clients ausgeführt werden, und andere Situationen einbeziehen, in denen das Setzen der Umgebung über eine Privilegiengrenze zur Bash-Ausführung erfolgt.
Sie stufen den Schweregrad mit „10 von 10“ ein, mit anderen Worten, so schlimm wie es nur geht. Hinzu kommt, dass der Angriff leicht auszuführen ist (die Zugriffskomplexität ist gering) und, was vielleicht am wichtigsten ist, keine Authentifizierung erforderlich ist, wenn Bash über CGI-Skripte ausgenutzt wird. Die obige Zusammenfassung ist ein wenig verworren, daher sollten wir uns auf die Mechanismen des Fehlers beschränken.
Das Risiko besteht darin, dass innerhalb einer Bash-Shell Umgebungsvariablen beliebig definiert werden können, die eine Funktionsdefinition angeben. Das Problem beginnt, wenn Bash nach der Funktionsdefinition weiterhin Shell-Befehle verarbeitet, was wir als „Code-Injection-Attacke“ bezeichnen würden. Schauen wir uns noch einmal Roberts Beispiel an und nehmen wir nur diese Zeile:
http-header = Cookie:() { :; }; ping -c 3 209.126.230.74
Die Funktionsdefinition ist () { :; }; und der Shell-Befehl ist die ping-Anweisung und die nachfolgenden Parameter. Wenn dies im Kontext einer Bash-Shell verarbeitet wird, wird der beliebige Befehl ausgeführt. In einem Web-Kontext würde dies über einen Mechanismus wie ein CGI-Skript geschehen und nicht unbedingt als Anfrage-Header. Es lohnt sich, das Advisory von seclists.org durchzulesen, in dem mehr ins Detail gegangen wird, einschließlich der Feststellung, dass der Pfad und der Query-String potenzielle Angriffsvektoren sein könnten.
Eine Möglichkeit, diesen speziellen Angriffsvektor zu entschärfen, besteht natürlich darin, einfach alle CGI-Funktionen zu deaktivieren, die eine Shell aufrufen, und in der Tat wird dies von einigen empfohlen. In vielen Fällen wird dies jedoch eine schwerwiegende Änderung sein, die zumindest ausführliche Tests erfordert, um sicherzustellen, dass sie nicht sofort zu Problemen auf der Website führt, was in vielen Fällen der Fall sein wird.
Der obige HTTP-Beweis ist ein einfacher, aber effektiver, wenn auch nur eine Implementierung über ein gängiges Protokoll. Sobald man Telnet und SSH und anscheinend sogar DHCP mit einbezieht, erhöht sich die Reichweite dramatisch, so dass wir hier keineswegs nur über die Ausnutzung von Web-App-Servern sprechen. (Offenbar besteht das Risiko nur bei SSH nach der Authentifizierung, aber in einem so frühen Stadium der öffentlichen Bekanntgabe werden wir unweigerlich noch andere Angriffsvektoren auftauchen.)
Was man auch nicht vergessen darf, ist, dass der Umfang des potenziellen Schadens weit über das Anpingen einer beliebigen Adresse hinausgeht, wie in Roberts Beispiel, das einfach nur ein netter kleiner Beweis dafür ist, dass er einen Rechner dazu bringen konnte, einen Shell-Befehl auszugeben. Die Frage ist nun folgende: Welchen Schaden könnte ein Angreifer anrichten, wenn er einen Shell-Befehl seiner Wahl auf einem beliebigen anfälligen Rechner ausführen kann?
Welche Auswirkungen könnte das haben?
Das Potenzial ist enorm – sich einen Shell-Befehl auf einem Rechner zu verschaffen, war für einen Angreifer schon immer ein großer Gewinn, weil er damit die Kontrolle über die Zielumgebung erlangt. Zugriff auf interne Daten, Neukonfiguration von Umgebungen, Veröffentlichung von eigenem bösartigem Code usw. Die Möglichkeiten sind nahezu grenzenlos und lassen sich zudem leicht automatisieren. Es gibt bereits viele, viele Beispiele für Exploits, die leicht auf eine große Anzahl von Rechnern abgefeuert werden könnten.
Bei der Ausführung von beliebigem Code in einer Shell auf bis zur Hälfte der Websites im Internet ist das Potenzial leider ziemlich groß. Eine der offensichtlichen (und besonders fiesen) Möglichkeiten ist das Auslesen interner Dateien, die öffentlich zugänglich sind. Passwortdateien und Konfigurationsdateien mit Anmeldeinformationen sind die naheliegendsten, könnten aber auch auf alle anderen Dateien auf dem System ausgedehnt werden.
Der gleiche Ansatz könnte auch beim Schreiben von Dateien auf das System angewandt werden. Dies ist möglicherweise der einfachste Vektor zur Verunstaltung von Websites, den wir je gesehen haben, ganz zu schweigen von einer sehr einfachen Möglichkeit, Malware zu verbreiten
Oder wie wäre es damit: Ein Wort, das ich immer wieder sehe, ist „Wurm“:
Wenn wir im Zusammenhang mit bösartigen Computern von einem Wurm sprechen, meinen wir einen sich selbst reproduzierenden Angriff, bei dem ein bösartiger Akteur Code erstellt, der sich über Ziele hinweg verbreiten kann. Eine sehr wirksame Umsetzung dieser Methode wurde beispielsweise mit dem MySpace-XSS-Wurm von Samy beobachtet, bei dem es einem sorgfältig erstellten JavaScript gelang, die Seiten von einer Million Opfern in weniger als einem Tag zu „infizieren“.
Die Sorge bei Shellshock ist, dass sich ein Angriff dieser Art mit einer alarmierenden Geschwindigkeit replizieren könnte, insbesondere zu einem frühen Zeitpunkt, wenn die Mehrheit der Rechner noch gefährdet ist. Theoretisch könnte dies in der Form geschehen, dass ein infizierter Rechner nach anderen Zielen sucht und den Angriff auf sie überträgt. Dies wäre auch keineswegs auf öffentlich zugängliche Rechner beschränkt; wenn dies hinter der Unternehmensfirewall geschieht, sind dem Himmel keine Grenzen gesetzt.
Es wird bereits daran gearbeitet, dies auszunutzen. Das ist es, was diese frühen Tage so interessant macht, da das Wettrüsten zwischen denjenigen, die sich um Patches bemühen, und denjenigen, die sich um Angriffe bemühen, sich aufheizt.
Welche Versionen von Bash sind betroffen?
In den Schlagzeilen steht alles bis 4.3 oder in anderen Worten, ungefähr 25 Jahre an Bash-Versionen. Wenn man bedenkt, dass jeder dies mit Heartbleed vergleicht, sollte man bedenken, dass die betroffenen Versionen von OpenSSL nur zwei Jahre alt waren, was im Vergleich zu Shellshock ein Tropfen auf den heißen Stein ist. Ja, die Leute aktualisieren ihre Versionen, aber nein, sie tun es nicht durchgängig, und wie auch immer man es betrachtet, die Bandbreite der gefährdeten Maschinen wird bei Shellshock deutlich höher sein als bei Heartbleed.
Aber das Risiko könnte auch über 4.3 hinausgehen. Schon jetzt gibt es Berichte über Patches, die nicht vollständig wirksam sind, und angesichts der Geschwindigkeit, mit der sie verteilt werden, ist das nicht allzu überraschend. Dies ist eine Sache, die diejenigen, die davon betroffen sind, sehr genau im Auge behalten wollen, nicht nur „patchen und vergessen“.
Wann haben wir zum ersten Mal davon erfahren und wie lange sind wir schon gefährdet?
Die erste Erwähnung, die ich im öffentlichen Äther gefunden habe, war diese sehr kurze Zusammenfassung auf seclists.org, die am Mittwoch um 14:00 Uhr GMT erschien (etwa Mitternacht heute Morgen für diejenigen, die am östlichen Ende von Australien leben). Die Details kamen in der von mir erwähnten Empfehlung eine Stunde später, also gegen Mittwochmittag in Europa oder am Morgen in den USA. Es ist noch zu früh, um eine weit verbreitete Ausnutzung in freier Wildbahn zu beobachten, aber das könnte auch sehr bald passieren, wenn das Risiko seinem Potenzial gerecht wird.
Wenn man über das hinausgeht, was öffentlich bekannt gegeben wurde, wurde der Fehler offenbar letzte Woche von Stéphane Chazelas entdeckt, einem „Unix/Linux-, Netzwerk- und Telekommunikationsspezialisten“ in Großbritannien. Abgesehen davon spricht Akamai in seinem Beitrag über den Fehler davon, dass er schon seit „längerer Zeit“ vorhanden ist, und natürlich gibt es anfällige Versionen von Bash schon seit zweieinhalb Jahrzehnten. Wie bei Heartbleed stellt sich die Frage, ob böswillige Akteure schon vorher davon wussten und ob sie es aktiv ausgenutzt haben.
Sind unsere „Dinge“ betroffen?
Hier wird es interessant – wir haben eine Menge „Dinge“, auf denen Bash laufen könnte. Wenn ich diesen Begriff verwende, beziehe ich mich natürlich auf das „Internet der Dinge“ (IoT), d.h. die zunehmende Verbreitung von IP-Adressen und drahtlosen Adaptern in allem, von unserem Besteck über unsere Türschlösser bis hin zu unseren Glühbirnen.
Auf vielen IoT-Geräten laufen eingebettete Linux-Distributionen mit Bash. Dieselben Geräte haben bereits in anderen Bereichen schwerwiegende Sicherheitslücken aufgewiesen, z.B. LIFX-Lichtkugeln, bei denen vor ein paar Monaten festgestellt wurde, dass sie WLAN-Zugangsdaten preisgeben. Auch wenn es sich nicht um eine Bash-Schwachstelle wie Shellshock handelt, so zeigt es uns doch, dass wir durch die Vernetzung unserer Geräte eine ganz neue Welt von Schwachstellen an Stellen betreten, die vorher nie gefährdet waren.
Edit: Einige Leute haben auf die weite Verbreitung von BusyBox hingewiesen, die die Ash-Shell auf mobilen Geräten ausführt. Geräte, auf denen dies läuft, scheinen nicht durch Shellshock gefährdet zu sein. Die Schwierigkeit für den Verbraucher besteht darin, dass er nicht weiß, was auf seinen Geräten läuft, und das schließt auch traditionellere „Dinge“ wie Router ein. Die lange Geschichte dieses Fehlers bedeutet, dass wir mehr als ein paar Jahrzehnte an Geräten da draußen haben, die verschiedene Entwicklungen verschiedener eingebetteter Betriebssysteme durchlaufen haben, und wir haben jetzt eine sehr vielfältige Landschaft von Maschinen und Shells, die einen langen Zeitraum überspannt.
Das bringt viele neue Herausforderungen mit sich; wer denkt zum Beispiel aktiv daran, seine Glühbirnen regelmäßig zu patchen? Bedenken Sie auch die Langlebigkeit der Geräte, in denen diese Software auftaucht, und ob sie tatsächlich aktiv gewartet werden. In einem Fall wie den anfälligen Trendnet-Kameras von vor ein paar Jahren gibt es zweifellos eine große Anzahl von ihnen, die immer noch im Internet zu finden sind, denn was das Patchen angeht, sind sie so gut wie ein „Einstellen und Vergessen“. In diesem Fall gibt es sogar einen ganzen Twitter-Account, der sich der Verbreitung von Bildern widmet, die er von ahnungslosen Besitzern anfälliger Versionen aufgenommen hat. Es ist ein großes Problem, für das es keine einfachen Lösungen gibt, und es wird uns noch sehr lange begleiten.
Aber Bash-Shells sind auch in vielen allgemeineren Geräten vorhanden, zum Beispiel in unseren Heimroutern, die in der Regel mit dem Internet verbunden sind. Erinnern Sie sich, wann Sie das letzte Mal die Firmware Ihres Routers gepatcht haben? Ok, wenn Sie das hier lesen, dann sind Sie vielleicht der Typ Techniker, der seinen Router tatsächlich patcht, aber versetzen Sie sich in die Lage des Durchschnittsverbrauchers und fragen Sie sich das noch einmal. Genau.
Alle unsere Dinge laufen auf dem Microsoft-Stack, sind wir gefährdet?
Kurze Antwort „nein“, lange Antwort „ja“. Zuerst die einfache Antwort: Bash ist nicht nativ in Windows enthalten, und es gibt zwar Bash-Implementierungen für Windows, aber sie sind nicht weit verbreitet und werden nicht auf Consumer-PCs zu finden sein. Es ist auch nicht klar, ob Produkte wie win-bash überhaupt anfällig für Shellshock sind.
Die längere Antwort lautet: Nur weil Sie in einer überwiegend Microsoft-zentrierten Umgebung arbeiten, bedeutet das nicht, dass Sie Bash nicht auch auf Rechnern laufen lassen, die anderen diskreten Zwecken innerhalb dieser Umgebung dienen. Als ich über Heartbleed schrieb, bezog ich mich auf Nick Cravers Beitrag über die Umstellung von Stack Overflow auf SSL und auf dieses Diagramm ihrer Infrastruktur:
Es gibt Nicht-Microsoft-Komponenten, die vor ihrem Microsoft-Anwendungsstapel sitzen, Komponenten, die der Datenverkehr passieren muss, bevor er die Webserver erreicht. Es handelt sich dabei auch um Komponenten, die hinter der Firewall über erhöhte Rechte verfügen können – welche Auswirkungen hat es, wenn Shellshock auf diese Komponenten angewendet wird? Shellshock hat das Potenzial, sich nicht nur auf gefährdete Bash-Implementierungen auszuwirken, sondern auch auf ein breiteres Ökosystem anderer Maschinen.
Ich bin ein Systemadministrator – was kann ich tun?
Erstens ist es trivial herauszufinden, ob Sie gefährdet sind, da es sich um ein leicht reproduzierbares Risiko handelt. Es gibt einen sehr einfachen Test, den The Register vorschlägt: Führen Sie einfach diesen Befehl in Ihrer Shell aus:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
Sie werden mit einem Echo „erwischt“ und haben den Fehler erfolgreich ausgenutzt.
Natürlich liegt die Priorität hier auf dem Patchen von Risikosystemen, und der Patch läuft im Wesentlichen darauf hinaus, sicherzustellen, dass kein Code nach dem Ende einer Bash-Funktion ausgeführt werden kann. Linux-Distributionen wie Red Hat geben eine Anleitung zum Patchen von Risikosystemen heraus, also sollten Sie sich vorrangig darum kümmern.
Wir werden unweigerlich auch Definitionen für Intrusion Detection Systeme sehen, und es wird sicherlich gemeinsame Muster geben, nach denen man hier suchen kann. Dies könnte sich für viele Unternehmen als eine gute kurzfristige Lösung erweisen, insbesondere dort, wo es strenge Testanforderungen gibt, bevor Patches für gefährdete Systeme aufgespielt werden. Qualys strebt eine Definition an, mit der der Angriff ziemlich schnell erkannt werden kann, und auch andere IDS-Anbieter arbeiten rund um die Uhr daran.
Zu den anderen, drastischeren Optionen gehören das Ersetzen von Bash durch eine alternative Shell-Implementierung oder das Abschotten gefährdeter Systeme. Aber das ist wahrscheinlich die Natur dieses Fehlers für viele Menschen – harte Entscheidungen, die greifbare geschäftliche Auswirkungen haben könnten, um potenziell viel bedeutendere Auswirkungen zu vermeiden.
Das andere Thema, das jetzt häufig auftauchen wird, ist die Frage, ob Shellshock bereits in einer Umgebung ausgenutzt wurde. Dies kann schwer festzustellen sein, wenn die Angriffsvektoren nicht protokolliert werden (was oft nicht der Fall ist, wenn sie per HTTP-Request-Header oder POST-Body weitergegeben werden), aber es ist wahrscheinlicher als bei Heartbleed, wo die Heartbeat-Payloads normalerweise nirgendwo protokolliert werden, es sei denn, es handelt sich um vollständige PCaps. Dennoch wird die häufigste Antwort auf die Frage „Wurden wir über Shellshock angegriffen?“ wie folgt lauten:
Dummerweise heißt das nicht „Nein, wir haben Beweise, dass es keine Kompromittierungen gab“, sondern eher „Wir haben keine Beweise, die sich über die gesamte Lebensdauer dieser Schwachstelle erstrecken.“ Wir bezweifeln, dass das viele Leute tun – und das lässt die Systembesitzer in der unangenehmen Lage, nicht zu wissen, was, wenn überhaupt, kompromittiert worden sein könnte.
Lasst die Spekulationen darüber beginnen, ob die NSA daran beteiligt war…
Ich bin ein Verbraucher – was kann ich tun?
Es kommt darauf an. Shellshock betrifft Macs, wenn Sie also OS X verwenden, scheint das zum jetzigen Zeitpunkt gefährdet zu sein, was einerseits schlecht ist, da OS X weit verbreitet ist, andererseits aber leicht (und hoffentlich schnell) behoben werden kann, da es einen ziemlich bewährten Update-Mechanismus gibt (d.h. Apple kann Updates aus der Ferne auf den Rechner bringen).
Wenn Sie einen Mac benutzen, kann das Risiko leicht getestet werden, wie in dieser Stack Exchange-Antwort beschrieben:
Es ist ein einfacher Test, obwohl ich bezweifle, dass der durchschnittliche Mac-Benutzer sich wohl fühlen wird, wenn er den vorgeschlagenen Fix durchführt, der eine Neukompilierung von Bash beinhaltet.
Die größere Sorge sind die Geräte, die keinen einfachen Patching-Pfad haben, zum Beispiel Ihr Router. Wenn Sie nicht gerade auf der Website des Herstellers nach aktualisierter Firmware suchen, wird dies eine wirklich harte Nuss sein, die zu knacken ist. Router, die von Internetanbietern zur Verfügung gestellt werden, sind oft gesperrt, so dass die Verbraucher weder die Konfiguration noch die Firmware willkürlich ändern können, und es gibt auch nicht immer einen Remote-Upgrade-Pfad, den sie auslösen können. Kombiniert man dies mit der riesigen Auswahl an Geräten und Altersgruppen, die es gibt, könnte dies besonders knifflig werden. Natürlich ist es auch nicht die Art von Sache, die der Durchschnittsverbraucher gerne selbst durchführen würde.
Kurz gesagt, der Rat an die Verbraucher lautet: Achten Sie auf Sicherheitsupdates, insbesondere für OS X. Achten Sie auch auf alle Hinweise, die Sie von Ihrem Internetanbieter oder anderen Anbietern von Geräten erhalten, auf denen eingebettete Software läuft. Seien Sie vorsichtig bei E-Mails, in denen Sie um Informationen gebeten oder angewiesen werden, Software auszuführen – auf solche Ereignisse folgen häufig Phishing-Angriffe, die die Ängste der Verbraucher ausnutzen. Die Leute stecken ihre iPhones in die Mikrowelle, also denken Sie nicht einen Moment lang, dass sie nicht ein zufälliges Stück Software ausführen werden, das ihnen per E-Mail als „Lösung“ für Shellshock zugeschickt wird!
Zusammenfassung
Wahrscheinlich haben wir das Ausmaß dieser Sicherheitslücke noch gar nicht ergründet. Natürlich werden viele Vergleiche mit Heartbleed gezogen, und wir haben aus dieser Übung eine Reihe von Dingen gelernt. Zum einen hat es etwas gedauert, bis wir begriffen haben, in welchem Ausmaß wir von OpenSSL abhängig sind. Zum anderen hatte es eine sehr lange Nachwirkung – noch Monate nach dem Ausbruch waren Hunderttausende bekannter Hosts verwundbar.
Aber in einer Hinsicht ist der Heartbleed-Vergleich nicht fair – das hier ist potenziell viel schlimmer. Heartbleed ermöglichte den Fernzugriff auf kleine Datenmengen im Speicher der betroffenen Rechner. Shellshock ermöglicht die Einspeisung von Remote-Code in beliebige Befehle vor der Authentifizierung, was potenziell viel schlimmer ist. In dieser Hinsicht muss ich Robert zustimmen:
Es ist noch sehr, sehr früh – zum Zeitpunkt der Erstellung dieses Artikels ist erst ein halber Tag vergangen – und ich vermute, dass wir bisher nur an der Oberfläche dessen kratzen, was uns noch bevorsteht.
Sicherheit