| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| mariadb | ≥ 3.3.0, < 3.3.4≥ 3.4.0, < 3.4.7≥ 3.5.0-rc.0, < 3.5.4< 3.2.5 | 3.3.43.4.73.5.43.2.5 |
When escaping string and binary parameters for the text protocol, the connector always escaped the quote character with a backslash, without ever consulting the session's NO_BACKSLASH_ESCAPES SQL mode. The server status flag was declared (STATUS_NO_BACKSLASH_ESCAPES) but never read.
Under a server or session running with NO_BACKSLASH_ESCAPES, the backslash is an ordinary character and the quote must be escaped by doubling it. The escaped value produced by the connector therefore closed the string literal, and a value passed through a placeholder was interpreted as SQL.
All text-protocol escaping entry points were affected, including Connection.escape().
An attacker able to influence any value the application passes as a query parameter could execute arbitrary SQL with the privileges of the application's database user: read, modify or delete any data reachable by that connection.
Exposure requires a deployment where NO_BACKSLASH_ESCAPES is enabled — server-wide, through the connector's sessionVariables / initSql options, or by an application-issued SET sql_mode. It is not implied by the ANSI, ORACLE or TRADITIONAL compound modes on MariaDB 11.4, so it has to be set deliberately. Where it is enabled, no unusual application code is needed: the standard placeholder API is the injection point.
execute() and batch() are not affected: the binary prepared-statement and bulk protocols send parameter values out of band.
The escaping routines now branch on the session status flag, doubling the quote and leaving the backslash untouched when NO_BACKSLASH_ESCAPES is set
Use execute() or batch(), or do not enable NO_BACKSLASH_ESCAPES, until upgraded.
Reported by fg0x0.
これらの製品をお使いですか?サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン