Should we audit enabling loading of sqlite3 extensions (shared libraries)?

TL;DR: sqlite3.Connection.enable_load_extension enables loading third party shared libraries. Should there be an audit event for this?

Background

If Python is configured with --enable-loadable-sqlite-extensions, it is possible to load third party SQLite extensions (shared libraries/DLL’s) via the sqlite3 extension module. This is probably not a very much used feature, as it is disabled by default. When enabled, the sqlite3.Connection.enable_load_extension() class method will enable the loading of third party extensions via SQL queries, using the SQL function load_extension(). (It also enables loading extension via C, using the sqlite3.Connection.load_extension() class method.) Quoting from the SQLite docs:

" It is recommended that extension loading be enabled using the SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION method rather than this interface, so the load_extension() SQL function remains disabled. This will prevent SQL injections from giving attackers access to extension loading capabilities."

SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION is an SQLite option that must be set before opening a database connection. Using this option, one can choose to only enable loading extensions via the C API, and to keep the SQL function disabled.

I know that PEP 578 don’t try to sandbox Python, but I still think it would be nice to add an audit hook for the sqlite3.Connection.enable_load_extension method.

See also

SGTM!

Thanks for the detailed explanation. Since the feature loads external code, it makes sense to add audit events for enable_load_extension and load_extension.

2 Likes

Would it make sense to use the same event name for these? I’d guess no, but keeping the event list as compact as possible also has a value.

EDIT: Answering myself. It does not make sense to reuse the event name, IMO :slight_smile: I’ll create an issue / PR.

1 Like

We should also migrate to using the SQLITE_DBCONFIG_ENABLE_LOAD_EXTENSION interface iso. sqlite3_enable_load_extension, but that will require altering the behaviour of the current API. I’ll file that as a separate issue. It would be nice to get this in before the 3.10 beta.

Can I just clarify this latter point? Will it still be possible to load extensions dynamically? Specifically, will the Python APIs load_extension and enable_load_extension remain?

Disclaimer: I’ve not used these APIs “for real” in the past, but I’m doing some work where I was considering using them. The loss of the APIs wouldn’t be a disaster for me, but I would need to rethink a few things.

Yes, the Python API will remain. What I’m proposing is to use sqlite3_db_config iso. sqlite3_enable_load_extension, which implies that the SQL API only is disabled.

1 Like