piwik no script img

„Shellshock“-Lücke bei Apple und LinuxDie erste Angriffswelle läuft

Nach dem Bekanntwerden einer 20 Jahre alten Sicherheitslücke wird diese schon ausgenutzt. Panik privater Nutzer ist unangebracht.

Auch Apple-Rechner sind von der Sicherheitslücke betroffen. Bild: dpa

KÖLN taz | Von einer neuen Sicherheitslücke zu sprechen ist eine gelinde Übertreibung: Die nun „Shellshock“ getaufte Lücke in dem Programm Bash ist nach aktuellen Informationen über 20 Jahre alt. So lange versteckte sie sich unentdeckt in dem Programm, das heute noch auf fast allen Linux-Rechnern und auch auf aktuellen Apple-Computern vorinstalliert ist.

Es handelt sich bei Bash um eine sogenannte Shell, also ein Programm, mit dem Administratoren per Kommandozeile rudimentäre Verwaltungsaufgaben durchführen und automatisieren können. Die nun entdeckte Sicherheitslücke ist erstaunlich einfach auszunutzen: Man muss dem Programm neben einem normalen Befehl nur noch einige „Umgebungsvariablen“ übergehen und der Computer führt so ziemlich jeden Befehl aus: Dateien auslesen, Passwörter ändern oder auch andere Rechner attackieren.

Die erste Angriffswelle rollt bereits. Wie das Magazin Wired berichtet, haben Angreifer dank Shellcode massenhaft fremde Rechner übernommen und damit begonnen, unter anderem das Netz des Internet-Dienstleisters Akamai und der US-Regierung zu attackieren. Andere Angreifer sind offenbar noch auf der Suche nach weiteren Rechnern, die sie übernehmen können, bevor sie zur Tat schreiten.

Größer als Heartbleed?

Dies könnte aber nur ein Vorgeschmack sein auf das, was noch kommen mag. Denn es ist unklar, in wie vielen Geräten der „Shellshock“ noch lauert und wie viele Wege Angreifer finden, ihn auszunutzen. So hat Apple angekündigt, sein Betriebssystem MacOS X abzudichten – eine akute Gefahr für Privatanwender sieht der Konzern nach Medienberichten jedoch nicht, da das schadhafte Programm auf Apple-Rechnern nicht einfach über das Internet aktiviert werden kann.

Die in den Medien verbreiteten Spekulationen, ob „Shellshock“ noch schlimmer als die im April entdeckte Sicherheitslücke „Heartbleed“ ist, sind weitgehend Kaffeesatzleserei. Denn einerseits sind die Lücken sehr verschieden: Heartbleed erlaubte quasi jedem den Arbeitsspeicher von Servern auszulesen und dort nach verwertbaren Informationen wie Passwörtern zu suchen. Shellshock bietet jedoch direkten Zugriff auf den Rechner – sofern der Angreifer einen Weg findet, Bash zu aktivieren.

Doch die Parallelen sind eindeutig: Hier wie da geht es um eine Sicherheitslücke in freier Software, die – da sie kostenlos und im Einsatz erprobt ist – bedenkenlos in unzählige Systeme integriert wurde. In zahlreichen Geräten wie Internet-Routern oder Videorekordern steckt mittlerweile ein kleines, spezialisiertes Linux-System.

Verlierer: Open Source

Sicherheitsforscher Robert Graham sieht einen der Stützpfeiler der Sicherheit offener Software nun widerlegt: „Open-Source-Aktivisten vertreten die Theorie, dass Open Source-Software weniger Fehler haben wird, weil jeder den zugrundeliegenden Quellcode überprüfen kann“, //:schreibt er in seinem Blog. Dass die fatale Bash-Lücke über 20 Jahre unentdeckt blieb, sieht er als Gegenbeweis: Der durchschnittliche Programmierer schreibe 10 Mal häufiger Programme statt bestehende Programme zu lesen. Spezialisierte Code-Reviewer, die solche Fehler ausmerzen, leisteten sich hingegen nur die Hersteller kommerzieller Software.

Das ist freilich eine Verkürzung: Auch bei kommerziellen Systemen fallen immer wieder uralte Sicherheitslücken auf. So wurden Windows-98-Nutzer nicht zum Wechsel gedrängt, weil das System nicht mehr funktioniert, sondern weil Microsoft keine Sicherheitsupdates für Privatnutzer mehr bereitstellt.

Doch auch das Krisenmanagement ist kein Aushängeschild für die Open-Source-Gemeinde. So hat das am Donnerstag eilig verbreitete Update das Problem nicht ganz beseitigt – immer noch konnten Angreifer unbefugt Befehle in Server einschleusen. Die Hoffnung bleibt aber, dass Open-Source dabei hilft, neben dem Uralt-Programm nun möglichst schnell die Problemlösung zu verbreiten. Privatnutzer können also wenig tun, außer in den nächsten Tagen nach Sicherheitsupdates Ausschau zu halten.

taz lesen kann jede:r

Als Genossenschaft gehören wir unseren Leser:innen. Und unser Journalismus ist nicht nur 100 % konzernfrei, sondern auch kostenfrei zugänglich. Texte, die es nicht allen recht machen und Stimmen, die man woanders nicht hört – immer aus Überzeugung und hier auf taz.de ohne Paywall. Unsere Leser:innen müssen nichts bezahlen, wissen aber, dass guter, kritischer Journalismus nicht aus dem Nichts entsteht. Dafür sind wir sehr dankbar. Damit wir auch morgen noch unseren Journalismus machen können, brauchen wir mehr Unterstützung. Unser nächstes Ziel: 40.000 – und mit Ihrer Beteiligung können wir es schaffen. Setzen Sie ein Zeichen für die taz und für die Zukunft unseres Journalismus. Mit nur 5,- Euro sind Sie dabei! Jetzt unterstützen

Mehr zum Thema

8 Kommentare

 / 
  • Die bash hat einen bug!

    .

    und?

    .

    Es dauert ein Script und n Minuten alle User mit .login .cshrc auf tcsh um zu stellen :-)

    .

    Und... shellscripte von USERN die mit Rootrechten laufen???? Systemübernahmen bei grossen Providern weil die bash defekt ist?

    .

    Wenn man UNIX Systeme mit rechtemanagment wie unter Windows betreibt vielleicht, aber dann kann man auch gleich die Soft aus Redmont nehmen :-((

    .

    knurrt Sikasuu

    • @Sikasuu:

      Das erinnert mich daran, dass bei Heartbleed einige Stimmen nach GnuTLS gerufen haben ;-)

      • @Peter Ulber:

        Und vor Heartbleed hatten gerade viele Leute von GnuTLS auf OpenSSL gewechselt, weil es einen Bug in GnuTLS gab. Interessantes Timing.

  • oh oh herr ulber, ihr wissen zum thema laesst allerdings auch stark zu wuenschen uebrig. Zum einen ist "quell-offen" mitnichten das gegenteil von "proprietaer". Es gibt durchaus quell-offene, proprietaere software. Wenn du den code frei veraendern und veroeffentlichen darfst, _dann_ ist es nicht proprietaer.

    Auch erschliesst sich mir der zusammenhang zwischen open-source und verhinderung von "vendor lock-in" nicht wirklich. Verkrustete SuSe architekturen in zahlreichen unternehmen beweisen eher die zusammenhangslosigkeit.

     

    Interessanterweise haette das vendor lock-in phaenomen im falle von shellshock ja eine eher mildernde wirkung, ein einzelner vertreiber wuerde die patches fuer die befallende systeme viel effektiver verteilen. Es ist zwar schoen, dass der bug (nach bekanntwerden) schnell gefixt wurde, nur wie wird gewaehrleistet, dass die patches auch eingespielt werden? Sie finden heute immer noch zig apache server im netz die seit jahren nicht mehr gepatched wurden.

     

    Desweiteren ist die bash auch nicht _die_ benutzerschnittstelle. Was sie wohl meinen ist die bourne-shell, die quasi standard auf *nix-artigen betriebsystemen ist. Aus diesem grund werden skripts die auf moeglichst vielen systemen laufen koennen sollen im bourne-shell dialekt geschrieben (deswegen steht in solchen skripts im shebang auch /bin/sh und nicht /bin/bash). Die bash ist (wie viele andere shells) einfach nur eine zur bourne-shell kompatible shell, die meist auf /bin/sh verlinkt ist. Auf embedded systemen bspw. laeuft oft keine bash, sondern irgendeine andere, bourne-kompatible, resourcenschonende shell-variante.

     

    Das code reviews nur selten bis gar nicht passieren, kann ich so nicht bestaetigen. Der code review ist im uebrigen auch nicht der weisheit letzter schluss in SW-QA, unit-tests, modul-tests, integrations tests, etc. pp. sind imho um einiges wichtiger.

    • @Teufels Advokat:

      "Es gibt durchaus quell-offene, proprietaere software." Stimmt, darüber kann man sich streiten. Manche stellen auch "proprietär" und "quelloffen + frei" gegenüber. Ich habe im Zusammenhang mit "freier Software" vom Vendor lock-in gesprochen. Da in diesem Fall das Forken oder Weiterentwickeln des Codes möglich ist, bin ich nicht an "Friss oder stirb" der Hersteller gebunden. Dass viele ihre eingesetzte Software nicht ordentlich warten, ist kein Gegenargument. Neben freier Software sind natürlich noch offene Standards als wichtige Faktoren zu nennen. Ich habe nicht die Bash als "die" Benutzerschnittstelle bezeichnet, sondern die Bash, insofern sie eine Shell (wie auch die Kornshell oder die Bourne shell usw.) ist. Ich habe nicht gesagt, dass Code Reviews nie passieren, aber eigene Stellen dafür gibt es meines Wissens doch eher selten. Und natürlich haben Sie Recht, dass das allein nicht genügt.

  • Es hat keine 2 Tage gedauert, bis der Bug gefixt war. Und jetzt werden gerade auch alle möglichen anderen Teile von Bash auf Herz und Nieren geprüft.

     

    Nicht nur von Hobbyisten, sondern auch von Firmen, die Freie Software nutzen und verkaufen.

     

    Statt ewig auf einen einzelnen Hersteller warten zu müssen, wurden binnen Stunden erste Lösungen veröffentlicht und nach wenigen Tagen war das Problem durch Ad-Hoc Kooperationen der verschiedensten Programmierer gelöst. Jetzt muss der Fix nur noch in die verschiedensten Distributionen verteilt werden und Shellshock ist Vergangenheit.

     

    Zur Gefahr durch diesen Fehler: Es dauerte keine zwei Tage ihn zu beheben. Selbst im schlimmsten vorstellbaren Fall mit sofortigen massiven Angriffe gegen alle verwundbaren Server, die zu einem teilweisen Ausfall des Stromnetzes geführt hätten, wäre der Bug behoben gewesen, bevor der Inhalt einer geschlossenen Tiefkühltruhe angetaut wäre (wenn es länger dauert als das, wird es kritisch, weil die Nahrungsversorgung in Gefahr gerät).

  • Drittens ist der Vorteil von quelloffener Software (Open Source) in erster Linie, die MÖGLICHKEIT, den Quellcode einzusehen. So lassen sich natürlich auch Schwachstellen und vor allem Hintertüren entdecken. Open Source ist in diesem Sinne gerade nach der NSA-Affäre eine quasi notwendige, aber noch lange keine hinreichende Bedingung für ein sicheres Programm. Viertens ist "kommerziell" und "Open Source" kein Gegensatz, oder wie verstehen Sie das Geschäftsmodell etwa von Google oder Red Hat. Das Gegenteil von "quelloffen" ist "proprietär", also nicht-quelloffen. Und "professionelle Code-Reviewer" können sich meist nur größere oder auf Sicherheit spezialisierte Firmen leisten, unabhängig davon, welche Art von Software sie vertreiben oder einsetzen. Im übrigen, wer heutzutage "bedenkenlos" Software einsetzt, egal ob proprietär, quelloffen oder frei, der handelt schlicht verantwortungslos. Sicherheit ist kein Produkt, sondern eine Einstellung. Aber Unwissenheit und Ignoranz diesbezüglich sind leider weit verbreitet, wie nicht zuletzt Ihr Artikel belegt. Schreiben Sie bitte über andere Dinge, von denen sie mehr verstehen! Denn es ist anstrengend, diesen Unsinn tagtäglich wieder aus den Köpfen herausklopfen zu müssen. Vielleicht informieren Sie sich mal bei der FSFE zu diesem Thema.

  • Sie kennen sich offensichtlich mit der Materie ganz und gar nicht aus. Erstens ist die Bash als Shell DIE Benutzerschnittstelle zum Betriebsystem, natürlich insbesondere bei Servern ohne X oder Wayland. Zweitens wird freie Software nicht deswegen eingesetzt, weil sie "kostenlos" und "im Einsatz erprobt ist". Freie Software hat nichts mit "Freeware" zu tun. Letztere zeichnet sich dadurch aus, dass sie "free as free beer" ist. Freie Software ist der Lizenz nach "free as in freedom". Die Gründe für den Einsatz freier Software sind also in erster Linie in den Möglichkeiten der Lizenz suchen, d.h. man kann den Quelltext einsehen, ihn verändern und (die Software) weitergeben. So verhindert man beispielsweise einen "Vendor lock-in".