[subTH]

Hallo,

ich versteh nicht ganz, warum die Änderungen des Patches auf 1.2.13 als "medium" bzw. "high" eingestuft sind:


OK,

PHP-Code:

$attachment['filename']


wird nicht auf Sonderzeichen geprüft aber darauf wird sowieso nur die Methode

PHP-Code:

get_extension()


angewandt, die aus inc/functions.php den String hinter dem "." ausliest.


Bei inc/datahandlers/user.php wurde versäumt den Sprachstring zu escapen. Aber angenommen jemand möchte eine SQL-Injection durchführen, würde das wahrscheinlich über ein Update seine Profils gemacht werden. Also schauen wir uns einmal usercp.php an:

Bei einer Profiländerung wird ein "action=do_options" als POST ausgeführt. Dabei wird das Array

PHP-Code:

$user['language']


gesetzt. Das Ganze wird noch über

PHP-Code:

validat_user()


validiert, also überprüft, ob die Sprache auch wirklich existiert. Das geschieht in inc/datahanders/user.php. Dort wird die Funktion

PHP-Code:

verfiy_language()


ausgeführt, welche wiederum

PHP-Code:

language_exists()


aufruft.

PHP-Code:

language_exists()


befindet sich in inc/class_language.php und führt ein

PHP-Code:

file_exists()


aus. Davor wurden mögliche / \\ .. ausgefiltert. Also auch nicht kritisch.

Ein SQL-Befehl wurde bis zu diesem Zeitpunkt nicht abgesetzt. Wo ist also das Risiko?


Grüße

subTH

[Michael]

Hallo,

das große Problem ist, dass verschiedene Erweiterungen ebenfalls auf die vom MyBB bereitgestellten Klassen und Funktionen zugreifen. In der Datei usercp.php werden die Eingaben zwar validiert, aber das muss bei Mods nicht ebenfalls so sein. MySQL-Injektion ist theoretisch möglich und immer ein großes Risiko.

[subTH]

Alles klar, ich benutze keine Mods und hatte es deshalb nicht bedacht

[StefanT]

Die Lücken betreffen ja nicht nur SQL-Injection:
Bei Änderung 1 und 2 (Zahlen wie in der manuellen Anleitung) ist XSS möglich. Diese Lücke ist für den Benutzer nicht ungefährlich, ist allerdings schon lange drin und wurde nicht benutzt. Daher wurde es als geringes Risiko eingeschätzt. Bei 3 ist SQL-Injection möglich. 4 dagegen erlaubt das Einbinden von falschen Dateien, was auch gefährlich sein kann.

Deine Argumente stimmen zwar im Bezug auf SQL-Injection, wie du aber siehst, trifft es hier nicht vollständig zu.