Login
Newsletter
Werbung

Thema: Bash: Kritische Sicherheitslücke entdeckt

31 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von hjb am Do, 25. September 2014 um 14:59 #

Der Fehler sollte nicht unterschätzt werden. Zumindest wenn man mit einem Laptop unter wegs ist und sich in fremde Netze einklinkt oder wenn man einen Webserver betreibt, sollte man updaten. Die wichtigsten Distributionen haben bereits Updates herausgegeben. Wenn man sichergehen will, dass keine verwundbare Version der Bash mehr läuft, sollte man außerdem das System neu booten.

[
| Versenden | Drucken ]
  • 1
    Von Ruediger am Do, 25. September 2014 um 15:25 #

    Ich kann mir nicht vorstellen, dass man diese Lücke sinnvoll ausnutzen kann. Wie sollte man durch einen Angriff eine Umgebungsvariable ändern?

    Das einzige was mit einfällt ist, wenn jemand ein Shell Skript per cgi startet. Dann kann jemand in seinem Browser einfach () { ... als Parameter übergeben. Nur wird sowas ernsthaft eingesetzt?

    [
    | Versenden | Drucken ]
    • 1
      Von panzi am Fr, 26. September 2014 um 04:37 #

      Lässt sich sau einfach ausnützen bei CGI Servern. Ich hab unsere Server mit dem Tool getestet: shellshocker.sh
      Hatten keine Probleme. Aber einen einfachen Demo CGI Server konnte ich damit "erfolgreich" testen.

      Bei git über ssh (wo man eigentlich keine Shell bekommen sollte sondern nur mit einen git Prozess am anderen Ende redet) soll es angeblich auch gehn (-> GitHub!).

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Sep 2014 um 04:39.
      [
      | Versenden | Drucken ]
    0
    Von blubbermal am Do, 25. September 2014 um 15:32 #

    Bin zwar kein Programmierer und wusste nicht mal das man in der Bash Shellfunktionen über Umgebungsvariablen einfügen kann.

    Wer einen Webserver betreibt und per CGI auf die Bash zugreifen lässt, na ja, so wieso keine gute Idee...
    Per SSH kann man keine Shellfunktionen übergeben.
    Debian/Ubuntu sind wohl kaum betroffen, weil diese die Dash als Systemshell nutzen.

    Ubuntu, Mageia, Gentoo, Suse sind schon mit Patches versorgt und auch steht es jedem frei, die C-Shell zu nutzen ;-)

    [
    | Versenden | Drucken ]
    • 0
      Von blubbermal am Do, 25. September 2014 um 15:36 #

      Per SSH kann man keine Shellfunktionen übergeben. ... außer die in der Config definierten locale

      [
      | Versenden | Drucken ]
      0
      Von #! am Do, 25. September 2014 um 15:44 #

      Die Dash????

      [
      | Versenden | Drucken ]
      • 0
        Von blubbermal am Do, 25. September 2014 um 15:50 #

        Meinste nicht, mir war so?
        Habe gerade kein Deb* bei der Hand, führe doch mal ein ls -l /bin/sh aus.

        [
        | Versenden | Drucken ]
        • 0
          Von Anonymous am Fr, 26. September 2014 um 22:13 #

          Also das Testscript aus dem Artikel schlägt jedenfalls unter Ubuntu 12.04 an, trotz "dash". :huh:

          [
          | Versenden | Drucken ]
          • 0
            Von haha am Sa, 27. September 2014 um 12:30 #

            Weit du überhaupt, was du tust?

            Wenn du das System, welches die Dash benutzt auf Bash testest, was soll da für ein Ergebnis herauskommen?

            [
            | Versenden | Drucken ]
            • 0
              Von abcdefgh am So, 28. September 2014 um 17:32 #

              Ich verwende LX-Terminal unter Debian Wheezy.

              Im LX-Terminal hatte das im Artikel erwähnte Skript mit der Ausgabe "vulnerable" angeschlagen. Nach dem Einspielen des Bash-Updates unterblieb diese Ausgabe.

              [
              | Versenden | Drucken ]
              • 0
                Von irgendwer am So, 28. September 2014 um 19:07 #

                Du verwendest ja sicherlich auch /bin/bash und nicht /bin/sh als Login-Shell.

                Es verwenden alle Nutzer automatisch /bin/bash als login-Shell, wenn man dies nicht manuell umstellt (siehe /etc/passwd).

                Für Scripte ohne shebang oder "#!/bin/sh" wird dash verwendet, für "#!/bin/bash" natürlich weiterhin bash. Es sind also nur Skripte angreifbar, die explizit die bash anfordern und darüber eine privilege escalation ermöglichen, also nicht mit den gleichen Nutzerrechten von einer interaktiven (lokalen) Shell aufgerufen werden.

                [
                | Versenden | Drucken ]
                • 0
                  Von abcdefg am So, 28. September 2014 um 20:06 #

                  Das mag sein. Es handelt sich hierbei aber um eine Wheezy-LXDE-Standardinstallation, die ich nachträglich nicht verändert habe.

                  Das Gleiche habe ich gerade mit einer Debian Squeeze-Gnome-Standardinstallation getestet, und zwar im Gnome-Terminal. Ergebnis: "vulnerable". Auch bei dieser Squeeze-Installation habe ich keine manuellen Änderungen an irgendwelchen Terminalprogrammen vorgenommen.

                  Was ich damit sagen möchte: Der Verweis darauf, dass Dash nicht betroffen sei, wiegt Debian-Nutzer wie mich, die keine Ahnung von Linux haben, unter Umständen in trügerischer Sicherheit. Von daher ist das, gemessen an der tatsächlichen Desktop-Realität, eine eher nicht so relevante Diskussion.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von irgendwer am So, 28. September 2014 um 20:15 #

                    Eigentlich ist es umgekehrt: Die Diskussionen um die Lücke schrecken Desktop-Nutzer auf, die sowieso nicht betroffen sind. :-P

                    Denn welchen (zusätzlichen) Angriffsweg bietet die Lücke? So real am Desktop keinen, wenn der Angreifer nicht eh schon irgendwie auf der Kiste drauf ist.

                    Gefährlich ist es für Maschinen, auf denen externe Angreifer Skriptaufrufe manipulieren können. Zum Beispiel das berühmte Apache-cgi, welches via GET/POST mit Env-Parametern gefüttert werden kann. Und besagtes cgi-Skript läuft unter Debian (im Gegensatz zur interaktiven shell) per default via dash, wenn es sich überhaupt um ein Shellscript und keine sonstige ausführbare Datei handelt.

                    [
                    | Versenden | Drucken ]
      0
      Von blubbermal am Do, 25. September 2014 um 15:54 #

      yum update und nun

      ~ $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
      bash: Warnung: x: ignoring function definition attempt
      bash: Fehler beim Importieren der Funktionsdefinition für `x'.
      this is a test

      [
      | Versenden | Drucken ]
0
Von HMEDW am Do, 25. September 2014 um 15:57 #

Ich habe gerade eine Aktualisierung aud Debian 7.6 gemacht.
Iceweasel wurde erneuert, aber bash? Fehlanzeige.

[
| Versenden | Drucken ]
  • 0
    Von hjb am Do, 25. September 2014 um 16:55 #

    Probiere es doch später nochmal. Die Updates scheinen nicht an alle User gleichzeitig rauszugehen. Oder es haben noch nicht alle Server die Updates. Die Interna kenne ich nicht...

    [
    | Versenden | Drucken ]
    0
    Von Spätschicht am Do, 25. September 2014 um 17:54 #

    Ich habe gerade eine Aktualisierung aud Debian 7.6 gemacht.Iceweasel wurde erneuert, aber bash? Fehlanzeige.

    vermutlich haste das schon am 23. oder 24. gemacht ;)
    guck mal hier: /var/cache/apt/archives

    ansonsten gibbet diese netten Optionen zu apt:
    apt-cache policy bash
    mit diesem Befehl wird dir die installierte Version und der Kandidat angezeigt.

    mit apt-cache madison bash
    kannste dir alle verfügbaren Versionen angucken....

    [
    | Versenden | Drucken ]
    0
    Von Spätschicht am Do, 25. September 2014 um 17:54 #

    Ich habe gerade eine Aktualisierung aud Debian 7.6 gemacht.Iceweasel wurde erneuert, aber bash? Fehlanzeige.

    vermutlich haste das schon am 23. oder 24. gemacht ;)
    guck mal hier: /var/cache/apt/archives

    ansonsten gibbet diese netten Optionen zu apt:
    apt-cache policy bash
    mit diesem Befehl wird dir die installierte Version und der Kandidat angezeigt.

    mit apt-cache madison bash
    kannste dir alle verfügbaren Versionen angucken....

    [
    | Versenden | Drucken ]
    • 0
      Von HMEDW am Do, 25. September 2014 um 18:36 #

      Hast Recht, ich habe mir die History angeschaut (so wie du es empfohlen hast) und siehe da: Am 24. war der Update. Aber dennoch Danke. Es wird wohl noch die Tage ein paar Updates geben. Spiegel und Stern lassen gerade zu diesem Thema die Welt untergehen.

      [
      | Versenden | Drucken ]
0
Von aNdileinchen am Do, 25. September 2014 um 17:19 #

Kaum ist sie bemerkt, ist sie schon gefixt, das sind Sicherheitslücken wie sie sein müssen.

[
| Versenden | Drucken ]
  • 0
    Von bash user am Do, 25. September 2014 um 19:19 #

    Nur dass der Fix das Problem nur grob geflickt hat, das Problem besteht weiterhin.

    [
    | Versenden | Drucken ]
    0
    Von i.MX515 am Do, 25. September 2014 um 22:54 #

    Blöd nur wenn Sicherheitslücken nicht mehr an die Entwickler gemeldet werden sondern das Wissen um diese Sicherheitslücke für viel Geld(mindestens 100000$) exklusiv verkauft werden

    [
    | Versenden | Drucken ]
1
Von Pffft... am Do, 25. September 2014 um 19:53 #

dürften in den seltensten Fällen bash nutzen, sondern ash oder dash. Bash ist einfach zu fett.

[
| Versenden | Drucken ]
  • 1
    Von Martin1991zab am Fr, 26. September 2014 um 07:39 #

    Wenn du die bash schon fett nennst willst du nicht in meine zsh config sehen :)
    (ok wird nur für locale Rechner verwendet auf dem Server hab ich was anderes)

    [
    | Versenden | Drucken ]
0
Von tntnet am Fr, 26. September 2014 um 09:23 #

Ich verstehe, dass man über CGI Umgebungsvariable setzen kann. Mich wundert allerdings, dass es so viele CGI-Skripte gibt. Ich habe schon seit Ewigkeiten kein CGI mehr verwendet. Und selbst damals habe ich perl und nicht bash benutzt. Und aus perl rufe ich auch kein system oder so auf.

Bei ssh ist es was anderes. Aber wer sich per ssh einloggen kann, braucht nicht über Umgebungsvariablen Code einzuschleusen.

Sicher ist das eine Sicherheitslücke. Aber sie ist doch lange nicht so gefährlich wie Heartbleed.

Sind die Linux-User wirklich so wenig Sicherheitsbewusst oder habe ich da was verpasst?

[
| Versenden | Drucken ]
  • 0
    Von hjb am Fr, 26. September 2014 um 10:55 #

    Sicher gibt es viele CGI-Skripte. Aber es dürften nicht so viele sein, die in Bash geschrieben und öffentlich zugänglich sind. Bei meinen Servern weiß ich von einem solchen Skript, und das ist geschützt.

    [
    | Versenden | Drucken ]
    • 0
      Von tntnet am Fr, 26. September 2014 um 11:32 #

      Umso mehr wundert mich die Einstufung der Ernsthaftigkeit.

      Wobei die Skripte ja nicht direkt in Bash geschrieben werden müssen. Das Problem tritt ja auch auf, wenn ich z.B. aus einem Perl-CGI mit system irgendwas aufrufe. Genau so etwas versuche ich immer wieder zu verhindern.

      Leider sehe ich zu oft so etwas wie my $d = `ls *.txt`. Schon hier wird eine bash aufgerufen. Als ob Perl nicht selbst Verzeichnisse lesen kann.

      Für diejenigen, die so was benutzen: richtig wäre: my $d = . Viel effizienter, keine Probleme mit Leerzeichen in Dateinamen und keine Probleme mit dem aktuellen Bash-Problem.

      [
      | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung