What is going on here?

Two whats are what.

First, the purpose of --safe is to permit somebody who got a CLI script somewhere to run it without worrying about whether it will modify the environment and without having to examine it to avoid such worries. Allowing readfile('secrets or whatever else') does not pose a modification threat.¹

Second, the CLI has no more permission or privilege than the user whose shell process was used to start it. The hazard you mention is no more than that people using the CLI would be exposed to their own secrets.

1. ^{^} This not wholly true. Last access time could be modified, and one can imagine a special device whose name should be /dev/explode_upon_access . That last is not a SQLite problem.

writefile() also works. I updated the original question.

Thanks for the clarification. Now, having looked into an unsafe capability of the "sqlite3 -safe" process, I agree that this is a bug (as your posts imply.)

This bug is fixed on trunk.

Hello, when is the next release of sql-lite planned and will it have the fix mentioned above? Thanks!

You are aware that this fix does not affect SQLite3 core -- it only affects the debugging CLI. You can compile a copy of the CLI at any time you wish.

The release schedule is most likely determined by the core SQLite3 and not by the debugging CLI, so it will probably be several months before there is a new core release.

Keith's prediction on the next release timing is about right, or maybe not. Releases are always dependent upon satisfactory testing, branch coverage results, and a trial period where interested users can try pre-release versions.

The fix mentioned above is on the trunk branch and will therefore appear in the next release. And, as mentioned, it is always available from the repository.

As others have mentioned, this is not considered a serious bug. The intention behind the feature, which was not quite met due to that bug, is to allow people who get CLI scripts from others, who may not fully trust those others, to run the scripts without having to study them for untoward side-effects.

There are few, if any, people outside of the SQLite development team who have reason to be running strange CLI scripts. The -safe feature arose for their convenience. It was nearly an unpublished feature. Those who run strange CLI scripts, or any other kind of code from outside, non-vetted sources, assume the risk flowing from do so. This is a very different sort of risk than is presented by exploitable malfunctions in the core SQLite library. Calling this one a "CVE" is yet another degradation of the CVE system's value.

The sqlite documentation (as referenced in the OP) does explicitly claim that readfile() is disabled though, irrespective of whether this is or is not a viable attack vector.

Hello Team,

Could you please confirm the remote code execution or local privilege escalation of CVE-2022-46908?

Thanks,

Questions:

1. Are you using the "sqlite3" or "sqlite3.exe" command-line utility programs that provide human operators with raw access to SQLite databases?

2. Are you passing scripts into "sqlite3/sqlite3.exe" of unknown and possibly hostile origin?

3. Are you invoking "sqlite3/sqlite3.exe" using the --safe command-line option.

If you answer "no" to one or more of the above questions, then CVE-2022-46908 does not apply to you. Ignore it.

Mischief can be accomplished using the bug described by CVE-2022-46908 (assuming that the victim answers "yes" to all of the above questions), but I am not aware of any specific RCE or privilege escalation attacks.