Login
Newsletter
Werbung

Thema: ShellShock: Bash unter Beschuss

29 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von milebrega am Mo, 29. September 2014 um 13:27 #

Die Sicherheit bei Open Source ist nicht zwingend höher als bei Closed Source, aber es lässt sich schnell und genau herausfinden, wie lange und in welchen Forks die Sicherheitslücke existiert und wer sie zu verantworten hat (ein langjähriger und prinzipiell vertrauenserweckender Entwickler oder aber ominöser "Unbekannter"?). Bei zum Beispiel Microsoft weiß man überhaupt nicht, welche Bugs inzwischen "heimlich" entdeckt und gefixt wurden, und wie viel Zeit im Schnitt dazwischen liegt.

[
| Versenden | Drucken ]
  • 0
    Von Ruediger am Mo, 29. September 2014 um 13:36 #

    Bei OpenSource hat wenigstens jeder die Möglichkeit, die Software zu untersuchen und Fehler zu finden. Weiterhin ist es z.B. bei Sicherheitssoftware möglich, die Tauglichkeit zu prüfen.

    Bei Closed Source ist das von Anfang an verboten oder eingeschränkt möglich.

    [
    | Versenden | Drucken ]
    0
    Von RipClaw am Mo, 29. September 2014 um 13:44 #

    Was viele vergessen ist das ein extremer Vorteil auch darin liegt das Fehler von Dritten behoben werden können unabhängig von den Entwicklern.
    Das ist wichtig wenn die Software entweder garnicht mehr weiterentwickelt wird oder die Entwickler aktuell nicht erreichbar sind.

    [
    | Versenden | Drucken ]
    0
    Von Herzlos am Mo, 29. September 2014 um 17:13 #

    Eine Sicherheitslücke in einem Microsoft Produkt, welche seit 25 Jahren nicht gefunden wurde, ist zwar theoretisch möglich, aber dafür bezahlt Microsoft Programmierer in Vollzeit um Code-Audits durchzuführen, so wie es auch der Artikel erwähnt hat.
    Allein das dürfte, wenn die Programmierer ihre Arbeit gut machen, die Dauer innerhalb der Supportzeit, die eine Sicherheitslücke in einem Code überleben kann, drastisch senken.
    Und ich denke schon, dass MS qualifiziertes Personal dafür einstellt.

    Das Problem ist eher, dass es nun als erwiesen gelten dürfte, dass das viele Augen Modell bei OSS nicht zeitnah funktioniert. 25 Jahre bei der Bash und 2 Jahre bei OpenSSL sind einfach zu lange.
    OSS bräuchte neben Entwicklern auch ganze Teams die sich nur um Code Audits kümmern.
    Und diese zwei schweren Sicherheitslücken wurden leider nur von Teams gefunden, die von irgendwelchen großen Konzernen dafür bezahlt wurden.
    Auch das zeigt, dass zu viele OSS Programmierer ohne dafür Geld zu bekommen nicht die notwendige Motivation haben, Code Audits durchzuführen.
    Denn entwickelt wird im Open Source Umfeld ja viel, jedes Jahr kommen tausende neue Zeilen Code hinzu, aber zu wenige schauen sie sich auch an.
    Das ist ein ernstzunehmendes Problem.

    [
    | Versenden | Drucken ]
    • 0
      Von LH_ am Mo, 29. September 2014 um 17:23 #

      "Eine Sicherheitslücke in einem Microsoft Produkt, welche seit 25 Jahren nicht gefunden wurde, ist zwar theoretisch möglich, aber dafür bezahlt Microsoft Programmierer in Vollzeit um Code-Audits durchzuführen, so wie es auch der Artikel erwähnt hat."

      Das ist zwar schön und gut, verhindert aber nicht, das dennoch oftmals neue Sicherheitslücken in Produkten von Microsoft gefunden werden.
      Nach deiner Vorstellung wäre dies ja nicht der Fall. Doch so ist es nicht.
      Zudem ist das Alter einer Sicherheitslücke in MS-Produkten oftmals als außenstehender nicht so leicht auszumachen.
      Allerdings zeugen die oftmals lange zurückreichenden Patches davon, das MS viele Fehler nicht oder nur sehr spät findet.
      Wäre es anders, müsste XP inzwischen Bugfrei sein. Doch dem ist nicht so, Firmen bezahlen viel Geld dafür, das auch weiterhin neu gefundene Lücken gefixt werden.

      Sicherheitslücken haben die unangenehme Eigenheit, dass man diese oftmals nicht nach Schema-F finden kann. Sie verlangen nicht selten die Kombination von Technologien, wie in diesem Fall. Ein reiner Audit wird da nichts finden, da die einzelnen Technologien im Grunde nichts falsches tun. Doch ein Audit findet nur selten Probleme aus ungewöhnlichen Kombinationen.

      Insofern sind Forderungen nach Code Audits oftmals wenig hilfreich. Mehr aktive Entwickler hingegen würden die Probleme eher finden, da solche Sicherheitslücken eher im Alltag auffallen, als durch gezielte Audits.

      [
      | Versenden | Drucken ]
      0
      Von squirrel am Mo, 29. September 2014 um 18:56 #

      Das Problem ist eher, dass es nun als erwiesen gelten dürfte, dass das viele Augen Modell bei OSS nicht zeitnah funktioniert. 25 Jahre bei der Bash und 2 Jahre bei OpenSSL sind einfach zu lange.

      Als erwiesen sehe ich das nicht an. Du kannst nicht so pauschal sagen, dass das "viele Augen Modell" nicht zeitnah funktioniert, ebensowenig wie andere behaupten können dass es immer und überall funktioniert. Das ist doch von Projekt zu Projekt und auch innerhalb eines Projekts von Problem zu Problem unterschiedlich. Wer die Entwicklung des ein oder anderen größeren Projekts mitverfolgt hat, der bekommt eben auch die Fälle zu sehen, bei denen dieses Prinzip eben doch funktioniert. Das sagt aber eben nicht aus, dass es automatisch überall funktioniert, wie auch die schlechten fälle nichts über die guten Fälle aussagen können.

      Es hat bei Bash nun 25 Jahre gedauert, ja das ist sehr schlecht, keine Frage. Und auf die Frage hin in wie vielen Projekten hin noch ungesehene Lücken klaffen, braucht man sicher keine Antwort geben. Aber es funktioniert in vielen Fällen auch zeitnah, nur bekommt man das eben nicht so öffentlich mit. Oder hast du schon Nachrichten von gefixten Lücken gelesen, die innerhalb von wenigen Stunden und auch noch lange vor dem Release der Software behoben wurden? Sicherlich höchst selten wenn gar überhaupt, da niemand eine News über so etwas schreibt. Das bekommt man nur mit wenn man die Entwicklung mitverfolgt. Und dort funktioniert dieses Prinzip dann eben doch.

      Und ganz ehrlich. Ich fühle mich wohler wenn ich weiß dass es an einigen funktioniert, als dass es überall gleich ganz ausgelassen wird. Und so viele Lücken wie Microsoft in ihren Proukten über all die Jahre gezeigt hat, sollte wohl deutlich genug sein, dass auch Firmen die sich Sicherheits-Audits leisten können, auch nicht vor Lücken gefeit sind. Und das sind nun über die Jahre ja schon wirklich sehr viele gewesen.

      [
      | Versenden | Drucken ]
0
Von tadaa am Mo, 29. September 2014 um 14:25 #

Auch OSX hat die Bash als Standard-Shell, jedoch in einer deutlich älteren Version als viele Linux-Distributionen. Mal gespannt wie Apple das Problem löst.

[
| Versenden | Drucken ]
1
Von Unerkannt am Mo, 29. September 2014 um 15:06 #

Man sollte darüber nachdenken die Bash zu entfernen. Scheinbar ist sie zu einem solchen Monster geworden, dass solche Fehler zu lange unentdeckt bleiben. Die Bash sollte einfach nicht den Status Standardshell haben. Dafür eignet sich etwas kleines und überschaubares besser. Wer mehr Komfort in seiner Login-Shell braucht, sollte diese Entscheidung bewusst treffen müssen.

[
| Versenden | Drucken ]
  • 0
    Von Ruediger am Mo, 29. September 2014 um 16:06 #

    Unter Ubuntu hat man für Skripte die dash als Standardshell. bash ist die Login Shell.

    [
    | Versenden | Drucken ]
    0
    Von ms123 am Mo, 29. September 2014 um 17:19 #

    Man sollte darüber nachdenken die Bash zu entfernen

    Du hast doch schon immer die Möglichkeit, die Shell oder auch jedes andere Detail zu verändern.

    [
    | Versenden | Drucken ]
    • 0
      Von Unerkannt am Mo, 29. September 2014 um 20:00 #

      Ja. Da hast schon teilweise recht. Leider zwingt mich das Basissystem meiner Distribution die Bash zu behalten. Die Login-Shell zu tauschen ist kein Problem, aber der Paketverwalter und das Initialisierungssystem erwarten Bash.

      [
      | Versenden | Drucken ]
    0
    Von Bert am Di, 30. September 2014 um 08:05 #

    Das Problem ist in zweierlei Hinsicht recht einfach zu lösen.

    Man installiere das Paket mksh. Dort findet man die /bin/mksh und /bin/lksh. lksh (Legacy Korn Shell) ist ähnlich klein wie die Dash, ist aber dafür gedacht, den Korn Shell Language Standard fürs Scripting umzusetzen. Also mksh als Bash-Ersatz, und Skripte grundsätzlich mit Shebang #!/bin/lksh.

    Beim Umbau von Bash (.bashrc) auf mksh (.mkshrc) bin ich derzeit auf das Problem gestoßen, die üblichen Darstellungen für den Prompt hinzubekommen. Ansonsten merke ich keinen Unterschied zwischen bash und mksh.

    Es geht dann vor allem darum, den Mut aufzubringen, den Default des Distributors zu brechen. Aber es geht auch anders: in Android ist mksh.

    [
    | Versenden | Drucken ]
    • 0
      Von Bert am Di, 30. September 2014 um 08:19 #

      Mit dem Editor in der /etc/passwd in der Zeile des Users "bash" nach "mksh" ändern; Neustart. Läuft out of the box. Im ersten Moment wundert man sich über den Prompt, aber den muss man eben in der .mkshrc eben anpassen. Die ganzen Voreinstellungen aus der .bashrc könnte man vielleicht übernehmen (vor Neustart 'cp .bashrc .mkshrc'). Beim Prompt gings bei mir nicht.

      [
      | Versenden | Drucken ]
0
Von honk am Mo, 29. September 2014 um 18:29 #

Wie schaut es bzgl. der Lücken eigentlich mit zsh, ksh, tcsh etc. pp aus?
Wenn der Fehler so alt ist, dann ist es doch nicht unwahrscheinlich dass sich dieser irgendwie vererbt hat, oder?

[
| Versenden | Drucken ]
1
Von Shelly Shelby am Di, 30. September 2014 um 08:39 #

Scriptprogrammierung in b(a)sh,... ist doch (pain in the ass)^2

Beschränkte Sprachfeatures, die ständig den Aufruf externer Tools zur Folge haben was das ganze lahm macht. Syntax sehr fehleranfällig was einen dauernd behindert und nervt. Soll es weitgehend kompatibel mit anderen Shells sein, muss man sich auf den kleinsten gemeinsamen Nenner einigen was noch weniger Features zur Folge hat, was wiederum noch mehr pita bedeutet.

Kurz: Shellprogrammierung ist einfach ein riesiger Krampf.

Produktiv und schnell ist was anderes. Deshalb nehme ich für Scripte Perl oder eine andere 'richtige' Scriptsprache und nicht so einen verkorksten Mist wie ihn die Shells bieten.

[
| Versenden | Drucken ]
  • 0
    Von Herzlos am Di, 30. September 2014 um 12:40 #

    Das kommt doch ganz auf die Größe deines Skripts bzw. die Aufgabe an, die du damit erledigen willst.
    Für den Umgang mit Dateien, ohne die Dateien direkt bearbeiten oder lesen zu müssen, ist die Bash gut geeignet.

    Und für nen Skript das aus 10-15 Zeilen besteht installiere ich keine Python oder Perl Umgebung oder mache die etwa bei Skripten, die auch andere Nutzen können sollen, zur Anforderung.
    Wenn dein Skript aus über 50 Zeilen besteht, du Dateien direkt bearbeiten musst oder du bestimmte Sprachfeatures benötigst, ja, dann macht es vielleicht Sinn auf eine richtige Skriptsprache zurückzugreifen, aber für einen 3 Zeiler doch nicht.

    Ich bin froh, das man unter Linux so eine flexible Shell, wie z.b. die Bash, hat.
    Das was du beschreibst, also das Gegenteil davon, dass ist im Prinzip so eine Umgebung wie bei Windows mit der command.exe Eingabeauforderung*, wo fast nichts ohne Nutzung von richtigen Skriptsprachen oder Programmiersprache geht.
    *Die Powershell mal ausgenommen.

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