1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Imagetragick: Bug in Bildverarbeitung…

root-rechte ?!?

  1. Thema

Neues Thema Ansicht wechseln


  1. root-rechte ?!?

    Autor: merodac 10.05.16 - 15:30

    Also ich bezweifle mal, dass das so einfach ist, wenn der webserver unter dem user www-data läuft ...

    edit:
    ich halte die Lücke überhaupt für sehr fragwürdig - wenn ein webserver imagemagick verwendet und die an imagemagick übergebenen Parameter nicht überprüft, dann ist nicht imagemagick schuld sondern der Programmierer des webservices.
    Und soweit ich informiert bin, basiert dieser angebliche bug darauf, dass imagemagick selbst die überprüfung der dateinamen nicht vornimmt, wodurch shell-injections möglich sind, die dann natürlich auch manipulierte dateien ausführen können.
    Aber das ist wie bei SQL-injections.
    Würde jemand auf die Idee kommen, die Schuld an der Existenz von SQL-injections dem jeweiligen SQL-Server unterzujubeln?

    edit2: typo

    edit3: aber die details kenne ich nicht, vor allem ist mir neu, dass imagemagick anders als eingebettet in einen "echten" webserver laufen kann...



    5 mal bearbeitet, zuletzt am 10.05.16 15:41 durch merodac.

  2. Re: root-rechte ?!?

    Autor: Mithrandir 10.05.16 - 15:43

    Du solltest dir das hier mal durchlesen, ab dem Teil "Detailed Vulnerability Information". Es ist zuviel, sonst hätte ich das gepastet.

    https://imagetragick.com/

    Fakt ist: Der Programmierer, der Imagemagick nutzt, kann nichts dafür.

  3. Re: root-rechte ?!?

    Autor: Andre S 10.05.16 - 15:49

    Der Header des Bildes/Mimetype kann korrekt sein und trotzdem kann es beim parsen der Bilddaten zu einem Bufferoverflow und dadurch zur Code execution oder sonstwas kommen wenn bei einigen Codecs (png, jpg usw, gibt ja viele und ImageMagick muss diese beim einlesen in ein verarbeitbares Format parsen). - Eine nicht overflow sichere string Funktion im Parser oder sowas verwendet und schon ist der Schadcode schneller geladen als du ImageMagick sagen kannst.

    Korrigiert mich wenn ich falsch liege, ich denke schon das man eine eindeutige Signatur per preg_match im Input String finden und validieren und ggf. den Upload verweigern kann bevor man ihn an ImageMagick übergibt.

    So weit okay aber jetzt sag mir welcher Webservice Entwickler denkt bitte daran? Das kann man ihm nicht wirklich zum Vorwurf machen wenn man sich auf Standard Libs und Tools nicht mehr verlassen kann....

    <sarcasm?>
    ...dann müsste man seine Image Parser selbst schreiben und auf externe Libs verzichen, am besten auch das ganze OS!
    </sarcasm?>



    5 mal bearbeitet, zuletzt am 10.05.16 15:52 durch Andre S.

  4. Re: root-rechte ?!?

    Autor: merodac 10.05.16 - 16:13

    https://imagetragick.com/ gelesen: check

    a) CVE-2016-3714 --> Insufficient filtering for filename passed to delegate's command allows remote code execution during conversion of several file formats.
    DIESER Teil darf m.M.n gar nicht bis zu ImageMagick vordringen. Das Filtern des filenamens auf ungültige Zeichen muss der caller durchführen.
    b) CVE-2016-3718 --> korrekt. Allerdings halte ich image-formate die skripte enthalten können nur in sehr speziellen szenarien für sinnvoll, definitiv nicht auf einem webserver.
    c) CVE-2016-3715 --> selbiges.
    d) CVE-2016-3716 --> selbiges.
    e) CVE-2016-3717 --> selbiges.

    b,c,d und e basieren darauf, dass ImageMagick skripte ausführt in dateien, die skripte beinhalten. wahnsinn. arg... oder so.
    1) eine ursache für das problem ist, dass imagemagick versucht, das dateiformat zu erraten, wodurch man ein jpg hochladen kann, dass in wirklichkeit ein svg mit skript ist und imagemagick führt das dann durch. ja, das ist mist und ein bug. wobei der bugfix m.M.n sich darin beschränkt, gewisse dateiformate einfach konfigurativ ausschalten zu können (was ich nicht weiss, ob das nicht eh schon geht)
    2) die aussage "kann root rechte erhalten" ist schmarrn. das geht nur, wenn imagemagick in einem root-kontext aufgerufen wird, und DAS ist dann definitiv die schuld des server-betreibers.

    Zusammengefasst sinds drei Dinge:
    a) nie imagemagick (oder einen webserver) als root laufen lassen. wer das tut ist echt so richtig selber schuld.
    b) der "einfach auszunutzende" teil des exploits beschränkt sich auf den teil mit den filenamen. das ist definitiv ein problem des programmierers des teils das imagemagick aufruft.
    c) imagemagick script support in svg/mvg/whatever muss per config deaktivierbar sein (alternativ das "format-erraten" ausschaltbar) das ist jetzt auch echt ein bug in imagemagick, aber für sich genommen definitiv NICHTS das root-rechte gibt.


    ... und den Satz "Fakt ist ..." sollte man m.M.n. nicht so leichtfertig verwenden. Vor allem wenn man dann ganz offensichtlich falsch liegt ...



    2 mal bearbeitet, zuletzt am 10.05.16 16:16 durch merodac.

  5. Re: root-rechte ?!?

    Autor: Itchy 10.05.16 - 16:13

    Auch in der "Detailed Vulnerability Information" steht nichts von einer Privilege Escalation zum Superuser. Natürlich kann die Schwachstellen zusammen mit einem anderen Kernel-Exploit zu root-Rechten führen. Alleine für sich genommen aber nicht, wenn nicht der Webserver bzw. der Prozess, der Imagemagick aufruft, bereits als root läuft.

  6. Re: root-rechte ?!?

    Autor: Niantic 10.05.16 - 16:44

    Itchy schrieb:
    --------------------------------------------------------------------------------
    > Auch in der "Detailed Vulnerability Information" steht nichts von einer
    > Privilege Escalation zum Superuser. Natürlich kann die Schwachstellen
    > zusammen mit einem anderen Kernel-Exploit zu root-Rechten führen. Alleine
    > für sich genommen aber nicht, wenn nicht der Webserver bzw. der Prozess,
    > der Imagemagick aufruft, bereits als root läuft.


    Problem dabei - wenigstens irgendein teil des webservers hat root rechte - denn das öffnen eines listen-sockets auf ports <1024 (http hat 80) erfordert root rechte

  7. Re: root-rechte ?!?

    Autor: merodac 10.05.16 - 16:50

    Niantic schrieb:
    --------------------------------------------------------------------------------
    > Problem dabei - wenigstens irgendein teil des webservers hat root rechte -
    > denn das öffnen eines listen-sockets auf ports <1024 (http hat 80)
    > erfordert root rechte

    das ist nicht ganz richtig, mal schnell googeln hilft, zB http://askubuntu.com/questions/694036/apache-as-non-root
    der apache-prozess der auf port 80 horcht ist zumindest auf _meinem_ server sehr wohl unter dem user www-data gestartet.
    Um da rauszukommen brauchts weitere zusätzliche sicherheitslücken.

    <sidekick please="dont-take-serious">
    ... oder klickibunti-windows-administratoren, die apache + imagemagick als administrator laufen lassen. soll ja auch ab und zu vorkommen ...
    </sidekick>



    1 mal bearbeitet, zuletzt am 10.05.16 16:53 durch merodac.

  8. Re: root-rechte ?!?

    Autor: smirg0l 10.05.16 - 16:54

    Niantic schrieb:
    --------------------------------------------------------------------------------
    > Itchy schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Auch in der "Detailed Vulnerability Information" steht nichts von einer
    > > Privilege Escalation zum Superuser. Natürlich kann die Schwachstellen
    > > zusammen mit einem anderen Kernel-Exploit zu root-Rechten führen.
    > Alleine
    > > für sich genommen aber nicht, wenn nicht der Webserver bzw. der Prozess,
    > > der Imagemagick aufruft, bereits als root läuft.
    >
    > Problem dabei - wenigstens irgendein teil des webservers hat root rechte -
    > denn das öffnen eines listen-sockets auf ports <1024 (http hat 80)
    > erfordert root rechte

    /Normalerweise/ gibt der Webserver die Rechte dann aber ab und läuft nur noch unter dem Webuser, www-data in der Regel.

    Ding ist aber, wenn ich damit Skripte ausführen kann, dann kann ich so verschiedenste Software auf deren Existenz und Version proben. Wenn ich etwas gefunden habe, wofür es einen Exploit gibt, dann kann ich den vermutlich auch über diesen Weg ausführen. Dann ist vieles möglich...

  9. Re: root-rechte ?!?

    Autor: Itchy 10.05.16 - 16:56

    Niantic schrieb:
    --------------------------------------------------------------------------------
    > Problem dabei - wenigstens irgendein teil des webservers hat root rechte -
    > denn das öffnen eines listen-sockets auf ports <1024 (http hat 80)
    > erfordert root rechte

    Ja, ein Prozess läuft als root. Der macht aber fast nichts. Die Arbeit (inkl. ImageMagick) erledigen aber (zumindest beim Apache) die Worker-Prozesse, die nur inital als root laufen und dann ganz schnell in einen normalen User-Kontext wechseln.

  10. Re: root-rechte ?!?

    Autor: Mithrandir 10.05.16 - 18:02

    merodac schrieb:
    --------------------------------------------------------------------------------
    > b) der "einfach auszunutzende" teil des exploits beschränkt sich auf den
    > teil mit den filenamen. das ist definitiv ein problem des programmierers
    > des teils das imagemagick aufruft.

    Wow - Dateiendung ändern ist also zu schwer? ;) Ungepatcht ist das Scheiße, und das sollte auch ich als Programmierer nicht filtern müssen. Dafür habe ich doch eine 3rd-Party-Bibliothek.
    Dass die Lib ungefragt Shell-Kommandos weiterleitet und selbst keinen Sanity-Check durchführt, ist ebenfalls ein Schwachpunkt. Und zwar in der Architektur der Bibliothek. Denn offensichtlich verlassen sich die Entwickler von Imagemagick ja auch darauf, dass das schon ok ist, was die da bekommen.

    > c) imagemagick script support in svg/mvg/whatever muss per config
    > deaktivierbar sein (alternativ das "format-erraten" ausschaltbar) das ist
    > jetzt auch echt ein bug in imagemagick, aber für sich genommen definitiv
    > NICHTS das root-rechte gibt.

    Da sind wir einer Meinung.

    > ... und den Satz "Fakt ist ..." sollte man m.M.n. nicht so leichtfertig
    > verwenden. Vor allem wenn man dann ganz offensichtlich falsch liegt ...

    In Teilen.

    //Edit: Typo & Formulierung



    1 mal bearbeitet, zuletzt am 10.05.16 18:03 durch Mithrandir.

  11. Re: root-rechte ?!?

    Autor: M. 10.05.16 - 18:59

    > a) CVE-2016-3714 --> Insufficient filtering for filename passed to
    > delegate's command allows remote code execution during conversion of
    > several file formats.
    > DIESER Teil darf m.M.n gar nicht bis zu ImageMagick vordringen. Das Filtern
    > des filenamens auf ungültige Zeichen muss der caller durchführen.
    Nein. Der Aufrufer weiss ja in der Regel gar nicht, was 'ungültige' Zeichen für ImageMagick nun genau sind. Dafür den Aufrufer verantwortlich zu machen ist genauso unsinnig wie PHP's magic_quotes_gpc, generell addslashes() oder gar strip_tags() auf alle Eingaben anzuwenden und ähnliches.
    Genauso wenig ist es bei SQL die Aufgabe des Aufrufers, dafür zu sorgen, dass bestimmte Zeichen nicht in die Datenbank gelangen können. Selbstverständlich ist er dafür verantwortlich, in jedem Fall ein gültiges Query zu bauen und Daten nicht als Teil des Querys zu interpretieren - wenn aber in
    ---
    $stmt = $mysqli->prepare("SELECT foo FROM bar WHERE baz=?");
    $stmt->bind_param("s", $input);
    $stmt->execute();
    ---
    ein beliebiger Wert von $input zu einer Lücke führt, ist das ein Bug in MySQL, den MySQLi-PHP-Bindings, oder PHP - aber kein Fehler des Aufrufers.

    Wenn natürlich jemand
    > system("convert '$input' out.png")
    ausführt, ist die offenslichtliche Shell-Injection ein Fehler das Aufrufers. Nicht aber, wenn er
    > system('convert '.escapeshellarg ($filename).' out.png')
    benutzt und ImageMagick dann meint, bestimmte Werte von $filename (die ein an sich gültiger Dateiname sind) gesondert behandeln zu müssen.

    There's no sense crying over every mistake,
    you just keep on trying 'till you run out of cake.

  12. Re: root-rechte ?!?

    Autor: merodac 11.05.16 - 08:10

    Ich denke, es wäre Zeit für einen Kompromiss.

    Filenamen kann man durchaus programmatisch auf gültige bzw ungültige Zeichen prüfen, oder noch besser randomisierte Namen verwenden. Fall 1 ist somit obsolet und durchaus vom Programmierer abzufangen.
    Das hilft nichts gegen Skripte in der Datei selbst, aber ist ein Anfang. Ich kann mir keinen Fall vorstellen, wo es zwingend notwendig wäre, den Namen zu verwenden, den der user angibt, korrigiere mich, wenn ich falsch liege.

    Und root rechte ohne zusätzliche andere Sicherheitslücke kann man bei korrekt konfigurierten Server nicht erhalten.

    Ergo - so einfach ist die Lücke dann doch nicht auszunutzen, aber mein erster impuls dass es alleine am Programmierer liegt war eindeutig falsch.

  13. Re: root-rechte ?!?

    Autor: dit 11.05.16 - 09:15

    merodac schrieb:
    --------------------------------------------------------------------------------
    > Also ich bezweifle mal, dass das so einfach ist, wenn der webserver unter
    > dem user www-data läuft ...

    Informiere dich. Erkenne alle Zusammenhänge. Verstehe das Problem.
    Und deine Zweifel werden sich in nichts Auflösen.

  14. Re: root-rechte ?!?

    Autor: freebyte 12.05.16 - 21:15

    Niantic schrieb:
    --------------------------------------------------------------------------------
    > Problem dabei - wenigstens irgendein teil des webservers hat root rechte -
    > denn das öffnen eines listen-sockets auf ports <1024 (http hat 80)
    > erfordert root rechte

    Das ist nicht wirklich ein Problem, der Prozess muss nur den von Dir erwähnten Listen-Socket eröffnen und kann das Filehandle dann an einen weniger priviligierten Prozess weiterleiten.

    Defacto ist das Procedere bei allen Webservern unter *nix aber selten dämlich: dass Userprozesse keine "Well Known Ports" < 1024 nutzen dürfen, ist lediglich eine Vereinbarung, die in einer der Headerfiles des Kernels festgeschieben wird.

    "ordentlich" wäre sowas wie eine /etc/privports in welcher der Prozess steht, der einen Port < 1024 nutzen darf.

    Oder (so mache ich es bei meinen selber programmierten Systemen): der Prozess greift sich 8080, 8025, 8110 und vorher läuft ein Port-Redirect via iptables - keine Schmerzen.

    fb

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Autostadt GmbH, Wolfsburg
  2. Schwarz Dienstleistung KG, Raum Neckarsulm
  3. Landis+Gyr GmbH, Nürnberg
  4. Total Deutschland GmbH, Berlin

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (-70%) 2,99€
  2. (-79%) 21,00€
  3. 3,74€
  4. (-80%) 7,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Alphakanal: Gimp verrät Geheimnisse in Bildern
Alphakanal
Gimp verrät Geheimnisse in Bildern

Wer in Gimp in einem Bild mit Transparenz Bildbereiche löscht, der macht sie nur durchsichtig. Dieses wenig intuitive Verhalten kann dazu führen, dass Nutzer ungewollt Geheimnisse preisgeben.


    Nasa: Boeing umging Sicherheitsprozeduren bei Starliner
    Nasa
    Boeing umging Sicherheitsprozeduren bei Starliner

    Vergessene Tabelleneinträge, fehlende Zeitabfragen und störende Mobilfunksignale sollen ursächlich für die Probleme beim Testflug des Starliner-Raumschiffs gewesen sein. Das seien aber nur Symptome des Zusammenbruchs der Sicherheitsprozeduren in der Softwareentwicklung von Boeing. Parallelen zur Boeing 737 MAX werden deutlich.
    Von Frank Wunderlich-Pfeiffer

    1. Nasa Boeings Starliner hatte noch einen schweren Softwarefehler
    2. Boeing 777x Jungfernflug für das größte zweistrahlige Verkehrsflugzeug
    3. Boeing 2019 wurden mehr Flugzeuge storniert als bestellt

    Galaxy Z Flip im Hands-on: Endlich klappt es bei Samsung
    Galaxy Z Flip im Hands-on
    Endlich klappt es bei Samsung

    Beim zweiten Versuch hat Samsung aus seinen Fehlern gelernt: Das Smartphone Galaxy Z Flip mit faltbarem Display ist alltagstauglicher und stabiler als der Vorgänger. Motorolas Razr kann da nicht mithalten.
    Ein Hands on von Tobias Költzsch

    1. Faltbares Smartphone Schutzfasern des Galaxy Z Flip möglicherweise wenig wirksam
    2. Isocell Bright HM1 Samsung verwendet neuen 108-MP-Sensor im Galaxy S20 Ultra
    3. Smartphones Samsung schummelt bei Teleobjektiven des Galaxy S20 und S20+

    1. Subdomain-Takeover: Hunderte Microsoft-Subdomains gekapert
      Subdomain-Takeover
      Hunderte Microsoft-Subdomains gekapert

      Ein Sicherheitsforscher konnte in den vergangenen Jahren Hunderte Microsoft-Subdomains kapern, doch trotz Meldung kümmerte sich Microsoft nur um wenige. Doch nicht nur Sicherheitsforscher, auch eine Glücksspielseite übernahm offizielle Microsoft.com-Subdomains.

    2. Defender ATP: Microsoft bringt Virenschutz für Linux und Smartphones
      Defender ATP
      Microsoft bringt Virenschutz für Linux und Smartphones

      Microsoft Defender ATP gibt es bereits für Windows 10 und MacOS. Anscheinend möchte Microsoft aber noch weitere Betriebssysteme bedienen - darunter Linux, Android und iOS. Entsprechende Previewversionen sollen kommen.

    3. Carsharing: Mit Share Now in der Tiefgarage gefangen
      Carsharing
      Mit Share Now in der Tiefgarage gefangen

      Bei Carsharing-Anbietern wie Share Now ist es wichtig, dass die Autos vernetzt sind und jederzeit geortet werden können. Doch das kann in Funklöchern zu unerwarteten Problemen führen.


    1. 19:04

    2. 18:13

    3. 17:29

    4. 16:49

    5. 15:25

    6. 15:07

    7. 14:28

    8. 14:13