Arbitrary module load leading to code execution in Perl DBI (DBD::DBM) before 1.653
AI analysis
Perl DBI versions before 1.653, which bundle the DBD::DBM driver, pass the dbm_type and dbm_mldbm connect attributes to Perl's require without validating that they name a module, enabling arbitrary module loading (CWE-470). An attacker who can influence either attribute, for example through a DSN fragment or an application parameter that selects a storage backend, can supply a path-shaped value that require treats as a literal filename (bypassing @INC), and the MLDBM::Serializer:: prefix prepended to dbm_mldbm does not stop traversal because only '::' separators are rewritten to '/'. Successful abuse runs the file-scope code of whatever file the value names, giving the attacker code execution on the host, typically by pointing the attribute at an attacker-controlled or pre-staged file. Any deployment of affected DBI versions that lets untrusted input set these attributes is at risk, with DBD::Gofer (which forwards connect attributes to the server side) and DBI::ProxyServer (which only checks that the DSN starts with a driver prefix) as notable exposure paths. No public proof-of-concept or in-the-wild exploitation is currently known.
What to do: Upgrade to DBI 1.653 or later, which validates the dbm_type and dbm_mldbm attributes. Until then, never set these connect attributes from untrusted input, allowlist the permitted values server-side, and audit DBI::ProxyServer and DBD::Gofer deployments plus any code that builds a dbi:DBM DSN from user-controlled data.
Affected
| Perl DBI project DBI (distribution includes the DBD::DBM driver) | all versions before 1.653 |
| Perl DBI project DBD::Gofer (attack surface: forwards client connect attributes to the server side) | as shipped with DBI before 1.653 |
| Perl DBI project DBI::ProxyServer (attack surface: validates only that a DSN starts with a driver prefix) | as shipped with DBI before 1.653 |
Estimated exposure
nichehundreds to a few thousand exploitable deployments (rarely used DBD::DBM driver bundled with the ubiquitous DBI) — DBI is present on millions of Perl installations, but DBD::DBM is a niche pure-Perl storage driver and exploitation additionally requires an untrusted party to control the dbm_type or dbm_mldbm connect attributes, so plausibly affected…
Order-of-magnitude estimate by the model from install counts, market share and public scan data it knows; verify before quoting.
Description
DBI versions before 1.653 for Perl load arbitrary modules via unvalidated dbm_type and dbm_mldbm attributes in DBD::DBM. DBD::DBM passes the dbm_type and dbm_mldbm connect attributes to require without checking that the value names a module. require treats a path-shaped string as a literal filename and does not consult @INC, so the attribute chooses the file that Perl loads and runs. The MLDBM::Serializer:: prefix that DBD::DBM prepends to dbm_mldbm is not a boundary: only the :: separators are rewritten to /, so a value containing / traverses out of the serializer directory. The value is also assigned to $MLDBM::Serializer, which MLDBM requires the same way when it ties the table. A caller that lets an untrusted party influence either attribute, for example through a DSN fragment or a parameter that selects a storage backend, runs the file-scope code of whatever module the value names. For example, my $dsn = "dbi:DBM:f_dir=/var/db;dbm_type=../../Untrusted.pm" my $dbh = DBI->connect( $dsn ); Note that DBD::Gofer forwards connect attributes to the server side, and DBI::ProxyServer checks only that a DSN starts with a driver prefix.