"Stranger Strings: An exploitable flaw in SQLite"

https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability-july-2022-library-api/

Effects SQLite 1.0.12 to 3.39.1, and is fixed in 3.39.2 and later.

Reportedly (potentially) exploitable. Patch your stuff.

--
Pure Personal Opinion | HoffmanLabs LLC

Note that the bug only applies if the application can generate a buffer larger than 2^31 bytes
as a printf argument, meaning it's practically not exploitable for 32-bit builds.

On 10/30/22 1:14 PM, John Dallman wrote:
> In article <193501bd-d3a4-4f9a-b05d-3fc7179cc9c4n@googlegroups.com>,
> osuvman50@gmail.com (David Jones) wrote:
>
>> Note that the bug only applies if the application can generate a
>> buffer larger than 2^31 bytes as a printf argument, meaning it's
>> practically not exploitable for 32-bit builds.
>
> Quite a lot of software has dropped its 32-bit builds, and nobody would
> want to have different versions of SQLite between their 32- and 64-bit
> builds. In the Linux and Windows worlds, there isn't all that much
> software left that's 32-bit-only. It's extinct on iOS and macOS, with
> Android heading that way quite fast.
>
> I checked on one of work's products that I remembered used SQLite, and
> was pleased to discover it has been removed two years ago.

I don't know what the pointer sizes are on the builds of SQLite for VMS,
but even with 64-bit pointers I'm pretty sure the size of a single
object is limited to 2GB on VMS. It would take some work to figure out
whether that in itself defeats the exploit or just creates a different
failure pattern.

On Sunday, October 30, 2022 at 5:57:49 PM UTC-4, Craig A. Berry wrote:
> I don't know what the pointer sizes are on the builds of SQLite for VMS,
> but even with 64-bit pointers I'm pretty sure the size of a single
> object is limited to 2GB on VMS. It would take some work to figure out
> whether that in itself defeats the exploit or just creates a different
> failure pattern.

The default VMS build is 32-bit but you do have the option to build 64-bit
versions of the images and libraries. The alternate versions have "64" appended
to the file name or type (e.g. sqlite3shr64.exe, sqlite3.olb64) so can co-exist
with the regular build.

On Sunday, October 30, 2022 at 9:12:07 PM UTC-4, osuv...@gmail.com wrote:
> On Sunday, October 30, 2022 at 5:57:49 PM UTC-4, Craig A. Berry wrote:
> > I don't know what the pointer sizes are on the builds of SQLite for VMS,
> > but even with 64-bit pointers I'm pretty sure the size of a single
> > object is limited to 2GB on VMS. It would take some work to figure out
> > whether that in itself defeats the exploit or just creates a different
> > failure pattern.
> The default VMS build is 32-bit but you do have the option to build 64-bit
> versions of the images and libraries. The alternate versions have "64" appended
> to the file name or type (e.g. sqlite3shr64.exe, sqlite3.olb64) so can co-exist
> with the regular build.

Not sure how much of the OpenVMS ecosystem is exposed to SQLite (I suspect it is very tiny) but SQLite exists almost everywhere else in the computer world including Linux, smart TVs, and smart phones (Android is a stripped-down version of Linux) to only name three. In fact, anyone who has ever worked with the dynamic duo of yum and rpm on Linux will know that SQLite is at their center where it keeps track of dependencies during an upgrade.

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net