[VIM] vendor ack/clarification for CVE-2007-1888 (SQLite)
Steven M. Christey
coley at linus.mitre.org
Sun Apr 22 19:16:48 UTC 2007
key points: only version 2 is affected, which is an older version that
isn't used very much, except by PHP; and the relevant function was not
intended to handle attacker-controlled inputs.
---------- Forwarded message ----------
Date: Thu, 19 Apr 2007 16:00:26 +0000
I am the original author and the principal architect of
the SQLite embedded database engine referenced in CVS-2007-1888.
I have not been contacted about this alleged vulnerability.
I discovered it while doing a Google search.
I have investigated the bug and have the following findings:
* The alleged bug occurs in the source file "encode.c".
That file was removed from the SQLite source tree in
September of 2004. That file and the operations it
encodes are no longer a part of SQLite. Legacy versions
of SQLite that make use of this old file are still
available, but the use of those legacy versions is
discouraged. As far as we are aware, PHP is the
only software still using this archaic version of
* The vulnerability in question is arguably a case of
PHP misusing the sqlite_decode_binary() API. While it
is true that sqlite_decode_binary() might be made more
robust in the face of malformed inputs, sqlite_decode_binary()
was never intended to be used in that context.
This bug applies to SQLite version 2 only, and then only
to very specific and narrow uses of SQLite version 2. There
are countless users of SQLite in the wild, but apart from
PHP, they are almost all SQLite 3 users. This bug has
zero impact on the overwhelming majority of SQLite users.
In order to avoid unnecessarily alarming the many users of
SQLite version 3, in any official announcement of this
vulnerability, you should make it clear that the vulnerability
only applies to SQLite version 2 and then only to users who
make use of the sqlite_decode_binary() function with an unchecked
More information about the VIM