SQLite Forum

Potential use-after-free vulnerability

Potential use-after-free vulnerability

(1) By Jill McGowan (jill.mcgowan) on 2024-02-13 16:34:45 [source]

In sqlite 3.45.0, sqlite.c (amalagamated), line 154741: *pzErr = sqlite3MPrintf(db, zFormat, pTab->zName);

It looks like pTab->zName may have been deleted at line 154719 sqlite3DeleteTable(db, pTab);

I believe that line 154741 should be: *pzErr = sqlite3MPrintf(db, zFormat, zModuleName);

because zModuleName is duped from pTab->zName at the start of the function, and is not freed until the end of the function, and so will exist and have the correct value at line 154741. I believe this is the intended purpose of zModuleName.

(2) By Richard Hipp (drh) on 2024-02-13 17:24:19 in reply to 1 [link] [source]

Not a UAF; Not a vulnerability; Not a bug.

Check-in https://sqlite.org/src/info/4892440b93306e5a addresses the false positive. Using the line numbers on that check-in, the "pTab->nTabRef++" on line 612 prevents pTab->zName from being freed, unless there is an error, but if there is an error then code never reached lines 638 where the alleged UAF occurs. So the UAF is not possible and this is not a bug.

Nevertheless, your observation that we could use zModuleName in place of pTab->zName seems to be correct, so I went ahead and made that change to help out your static analyzer.

I also added two new assert() statements to help prove that the reference counter on pTab will not drop below one, and hence pTab->zName will not be freed, unless there is an error.

Note also that line 638 that contains the alleged UAF only executes if the application uses sqlite3_create_module() with a virtual table implementation that contains a bug: specifically one where sqlite3_declare_vtab() is never called by the xCreate or xConnect method of the sqlite3_module object. So there is no way to reach that line of code using SQL inputs and/or a corrupt database file - you must be able to link in a buggy extension. But if you can do that, you app is already pwned and it doesn't matter. So even if this had been a UAF, it would not have been a vulnerability.

Thanks for the report.

(3) By David Jones (vman59) on 2024-02-13 20:13:31 in reply to 2 [link] [source]

I assume the caveat about failing to call sqlite3_declare_vtab() in xCreate/xConnect only applies if it return SQLITE_OK. I have virtual tables that return SQLITE_ERROR (and set pzErr) if the input arguments for creating the table are invalid.

(4) By Richard Hipp (drh) on 2024-02-13 20:18:22 in reply to 3 [link] [source]

Correct. xCreate/xConnect are only required to call sqlite3_declare_vtab() if they return SQLITE_OK.

(5) By Jill McGowan (jill.mcgowan) on 2024-02-14 07:50:02 in reply to 2 [link] [source]

Thank you very much.