PHP - ereg - und dessen Folgen!

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • PHP - ereg - und dessen Folgen!

    Da schau her:

    Das verfluchte Nullbyte – Teil 1 | burncycle

    ist ebenfalls wichtig zu erwähnen und so kann man alle eregs() umgehen :/

    Denn wer will schon, dieses Problem haben? Also es scheint, als hätte sich zum Beispiel "Wordpress" keinerlei Gedanken darüber gemacht

    Also -> immer eine Handbreit Puffer unterm Code


    Gruß Robert
    Immer eine Handbreit Puffer unterm Code

  • #2
    ich überleg mir auch mal n sec scanner zu schreiben ...
    mit allen mir bekannten Schwachstellen

    Mal schauen obs was wird

    greetz Robert
    Immer eine Handbreit Puffer unterm Code

    Kommentar


    • #3
      Jetzt finden wir bitte mal das Jahr raus, seit dem die ereg-Funktionen als deprecated markiert sind.

      Kommentar


      • #4
        Natürlich ist sie das. Aber denk mal an die 'veraltete' mysql Funktion ohne pdo :/ Wird trotzdem noch verwendet! Und okay es mag sein das ereg noch länger veraltet ist aber es wird immer noch verwendet! Und deswegen sollte man dies wissen. Gerade wenn man es mit einem älteren Script zu tun hat.

        Wie gesagt wollte ich nur einen weiteren Grund liefern, warum man niemals auf ereg vertrauen sollte

        Gruß Robert
        Zuletzt geändert von ibor; 15.01.2016, 08:15.
        Immer eine Handbreit Puffer unterm Code

        Kommentar


        • #5
          Übrigens: Die Issue, die der verlinkte Blogeintrag anspricht, existiert zwar, aber der Code dort zur Demonstration ist ungeeignet.

          PHP-Code:
          $var "stringpasst";
          $var2 "stringpasst\0üch";

          $wert ereg("[a-z]",$var); //ergibt true
          echo $wert;
          $wert ereg("[a-z]",$var2); //ergibt auch true
          echo $wert
          Beide ereg-Aufrufe ergeben nicht bool(true), sondern int(1). Das ist auch beim zweiten Aufruf zufällig die korrekte Rückgabe, weil das verwendete Pattern nur sicherstellt, dass ein Zeichen [a-z] irgendwo in der Eingabe auftaucht. Anders gesagt: Das Pattern liefert auch für Eingaben wie "123a456" den Wert int(1).

          Hier ist eine geeignetere Demonstration der NUL-Byte-Problematik:

          PHP-Code:
          var_dump(
              
          ereg('^[a-z]+$'"abc\x00123"// ergibt int(1)
          ); 
          "\x00" ist hier das NUL-Byte. Dieser Ausdruck sollte bool(false) liefern, liefert aber int(1), da ereg das NUL-Byte wahrscheinlich für das Eingabeende hält (Stichwort nullterminierte Strings).

          Dieses Problem tritt tatsächlich nur beim NUL-Byte auf:

          PHP-Code:
          <?php // ereg.php

          $pattern '^[a-z]+$';

          for (
          $i 0$i <= 255$i++) {
              
          $input 'a' chr($i) . '1'// Number in string. Pattern should never match

              
          if (false !== ereg($pattern$input)) {
                  
          printf("False positive for byte chr(%s)\n"$i);
              }
          }

          echo 
          "Done\n";
          Ausgabe:

          Code:
          $ php -f ereg.php 
          False positive for byte chr(0)
          Done
          Es scheint für dieses Problem mit ereg also eine Lösung zu sein, vorher NUL-Bytes aus der Eingabe zu filtern. Nutzen sollte man die ereg*-Funktionen natürlich dennoch nicht, da sie seit Mitte 2009 als deprecated gelten und in PHP 7 laut Doku gar nicht mehr existieren.

          Der Vollständigkeit halber ein Test für PCRE/preg*-Funktionen:

          PHP-Code:
          <?php // pcre.php

          $pattern '/\A[a-z]+\z/';

          for (
          $i 0$i <= 255$i++) {
              
          $input 'a' chr($i) . '1'// Number in string. Pattern should never match

              
          if (!== preg_match($pattern$input)) {
                  
          printf("False positive for byte chr(%s)\n"$i);
              }
          }

          echo 
          "Done\n";
          Code:
          $ php -f pcre.php 
          Done
          Zuletzt geändert von mermshaus; 16.01.2016, 12:58. Grund: Grammatik

          Kommentar


          • #6
            Bravo
            Immer eine Handbreit Puffer unterm Code

            Kommentar


            • #7
              Zitat von ibor Beitrag anzeigen
              eregs()...

              Denn wer will schon, dieses Problem haben? Also es scheint, als hätte sich zum Beispiel "Wordpress" keinerlei Gedanken darüber gemacht
              Gibts da einen Zusammenhang mit Wordpress? (Ich glaube zwar kaum, dass die da noch ereg_...() verwenden, aber man weiß ja nie ...)

              Die PCRE-Erweiterung gibts mindestens seit PHP 5.0.0. Seit dieser Zeit besteht also keine Veranlassung mehr, POSIX-Regex-Funktionen zu nutzen. Sie können nichts, was die PCRE nicht auch könnten. Und wer die POSIX-Syntax liebt, nimmt halt die MultiByte-Version. Die sollte per Definition NUL-Byte-sicher sein.
              Klingon function calls do not have “parameters”‒they have “arguments”‒and they always win them!

              Kommentar


              • #8
                Habe mir den Quellcode auch von wordpress Plugins angeschaut und habe dann diese Feststellung gemacht!

                Ob der Code auf GitHub noch aktuell ist weiss ich nicht aber ich habe was wordpress anbelangt auch was gefunden

                EDIT: Sorry habe nicht im repository gesucht :/

                Aber die Plugins sind wirklich teilweise betroffen - wenn man das so sagen kann :P

                Einfach hier her gehen: https://github.com/search?l=php&q=wo...utf8=%E2%9C%93

                Gruß Robert
                Zuletzt geändert von ibor; 16.01.2016, 12:50.
                Immer eine Handbreit Puffer unterm Code

                Kommentar


                • #9
                  WordPress-Core kann allerdings wenig für irgendwelche Plugins. Die kann ja jeder schreiben. Da die Software schon so lange existiert und so verbreitet ist, wird es eben entsprechend viele Plugins geben und auch etliche, die seit Jahren nicht mehr gepflegt werden, deren Code aber noch irgendwo rumgeistert. Zudem müsste man im Einzelfall schauen, ob die jeweilige Nutzung von ereg*-Funktionen tatsächlich problematisch in Bezug auf die in diesem Thread besprochene Sache ist oder ob es einfach nur alter, aber nicht unsicherer oder fehlerhafter Code ist. Das ist ansonsten auch nur ein einziger Programmierfehler, den man machen kann. Man könnte sich genauso gut zig andere Sachen herausgreifen und auch zig andere Software-Projekte. Ich sehe hier jedenfalls keinen Anlass für besondere WordPress-Kritik.

                  PS: Immerhin hast du es wenigstens inhaltlich versucht. Was man ansonsten teilweise liest, ist leider… Nun ja. (Edit: Auch wenn es in der Übertreibung natürlich auch als Witz gemeint sein soll.)
                  Zuletzt geändert von mermshaus; 16.01.2016, 23:43.

                  Kommentar


                  • #10
                    Großartig! Tolle Lösung!
                    phpGod

                    Kommentar

                    Lädt...
                    X