abraxas/mysql-mysqlbinlog-raw-pathMySQL Community Server 26.7.0 – Hoch – mysqlbinlog --raw Rotate-Pfad-Rest – Client-Dateischreibzugriff
abraxaslabs.tech · github.com/abraxas · @abraxas_null · [email protected] · mysql-mysqlbinlog-raw-path
Klasse: Dateischreiben (Client) Reichweite: Remote (UI:R)
MySQL Community Server mysqlbinlog 26.7.0 (06a5c1c) - Oracle
mysqlbinlog --raw --read-from-remote-server kopiert eine Rotate-Event-new_log_ident in log_file_name, ohne den Basisnamen zu prüfen. Das nächste FORMAT_DESCRIPTION-Event my_fopent diesen Pfad und schreibt BINLOG_MAGIC plus das Event. Ein feindseliger Dump, der eine echte Rotate-Ident mit / sendet, schreibt diese Datei mit der Client-UID.
--raw ist die dokumentierte Remote-Binlog-Datei-Kopie. Der Fehler besteht darin, die Ident als Pfad zu behandeln.
| ID | noch keine CVE |
| Klasse | Dateischreiben (Client --raw BINLOG_MAGIC) |
| Reichweite | Remote (Opfer führt mysqlbinlog --raw -R gegen einen Angreifer-Dump aus; UI:R) |
| CWE | CWE-22 |
| CVSS | Hoch: 8.1 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N |
| Produkt | MySQL Community Server mysqlbinlog |
| Betroffen | 26.7.0 (06a5c1c99c377fc41b2eba1ea244e8b220bdc3c8) |
| Auth | Opfer führt mysqlbinlog --raw -R gegen einen Angreifer-Dump aus |
| Lizenz | GNU Affero GPL v3.0 |
| Lab | nur 127.0.0.1. Witness-Datei mit BINLOG_MAGIC. Dateischreiben, kein RCE. |
Einen MySQL-Protokoll-Server aufsetzen. COM_BINLOG_DUMP sprechen. Ein passendes gefälschtes Rotate senden (Timestamp 0, Ident entspricht dem angeforderten Log-Namen), damit der Dump nicht stoppt. Ein echtes Rotate senden (Timestamp != 0), dessen Ident /abs/path ist. Ein FORMAT_DESCRIPTION-Event senden.
Der Operator, der mysqlbinlog --raw -R ... mysql-bin.000001 ausgeführt hat, schreibt /abs/path mit der Client-UID. Der Inhalt sind Binlog-Bytes (\xfebin plus das FD-Event), keine beliebige Nutzlast. Jeden Pfad überschreiben, den die UID erstellen kann.
Ein echtes mysqld wird keine Rotate-Ident mit / ausgeben. Der Fehler liegt im Client.
Dieselbe 26.7.0-Jagd wie mysqldump SHOW TABLES overflow und mysqldump --tab path. Der Standard-Daemon war leer. Client-Tools vertrauten weiterhin Remote-Namen.
if (raw_mode) {
if (output_file != nullptr) {
snprintf(log_file_name, sizeof(log_file_name), "%s%s", output_file,
rev->new_log_ident);
} else {
my_stpcpy(log_file_name, rev->new_log_ident);
}
}
Ein gefälschtes Rotate (when.tv_sec == 0), dessen Ident nicht mit dem angeforderten Log übereinstimmt, stoppt den Dump. Ein passendes gefälschtes Rotate wird nach der Kopie übersprungen (continue). Ein echtes Rotate stoppt nicht. Nächstes FD:
if (!(result_file = my_fopen(
log_file_name, O_WRONLY | MY_FOPEN_BINARY, MYF(MY_WME)))) {
error("Could not create log file '%s'", log_file_name);
LOAD DATA-Temps bleiben SQL_LOAD_MB unter tmpdir. Geschlossen. Die Ident-Länge ist auf FN_REFLEN-1 begrenzt. / wird nicht entfernt.
Bereits dokumentierte Irrwege: Senden eines gefälschten Rotate, dessen Ident der Pfad ist (Dump stoppt); Verwenden von --result-file (Ident wird zum Präfix, anderer Fehler); ein echtes mysqld als Orakel; Checksums eingeschaltet gelassen.
cd lab
./run.sh
Image mysql:26.7.0. Binary /usr/libexec/mysqlsh/mysqlbinlog Ver 26.7.0 (in diesem Image nicht im PATH). Control-Stub: gefälschtes Rotate mysql-bin.000001 plus FD schreibt work/mysql-bin.000001. Traversal-Stub: passendes gefälschtes Rotate, echtes Rotate-Ident /work/oracle/MYSQL-BINLOG-RAW-WITNESS, FD schreibt diesen Pfad (BINLOG_MAGIC). Veröffentlicht 127.0.0.1:18620 / 18621. An Loopback binden. Dateischreiben von Binlog-Bytes, kein RCE. Kein --result-file.
control-basename=yes
traversal-outside=yes
SUCCESS mysql-mysqlbinlog-raw-path ... MYSQL-BINLOG-RAW-WITNESS
basename von new_log_ident nehmen, bevor my_stpcpy / snprintf in log_file_name erfolgt. --raw sollte unter cwd oder dem --result-file-Präfix schreiben, nicht unter einer Ident mit /.
06a5c1c99c377fc41b2eba1ea244e8b220bdc3c8)client/mysqlbinlog.cc dump_remote_log_entries