On Mon, May 04, 2009 at 07:27:25PM -0400, D. Richard Hipp wrote:
> So, even though we can honestly claim that each version of SQLite is
> backwards compatible, because of issues such as the above, it is
> normally a good idea to retest everything when changing SQLite
> versions. If SQLite is a shared library that dozens of applications
> use, upgrading it might break one or more of those apps. Is that
> really something you want to do?
Yes. Applications breaking because they have bugs is a good thing,
because it means that the bugs will have to be fixed. Leaving such
bugs unfixed can cause more harm than the breakage endured while
the bug has been fixed in the library but not yet in the application.
> I hear your point about wanting to do security updates quickly and
> efficiency. But consider that zlib and xpdf (and libpng, and libjpeg,
> etc) are libraries that are usually handed untrusted and unchecked
> inputs for processing. So a bug in them can easily lead to an
> exploit. It is much, much less common to feed untrusted and unchecked
> inputs into your SQL database engine on the other hand.
I would say that this is a very dangerous assumption to make.
> There is usually (hopefully) several layers of application in between the
> database engine and the black-hat hacker, and those intervening layers
> go a long way toward mitigating any potential for exploits.
And they go a long way towards adding more security problems, too.
Because more code generally means more bugs.
And what if there is no input checking done by the application?
In security, people tend to assume the worst-case scenario, and
there are good reasons for doing so. Programmers using a library
will often tend to assume that the library implicitly handles certain
tasks for them, because it saves them from doing extra work.
That's human nature.
The recent advisories in OpenSSL and Debian's apt, both of which were
due to failures in checking values returned from library code properly,
are good examples of this pattern:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5077
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1358
In both cases, it was assumed that safety checks on certificates by the
library were working correctly, but they were not. The libraries even
indicated errors, but not in ways that the applications were programed
to handle. What guarantees that users of sqlite won't make similar errors,
possibly on the input data path (the examples I gave were on the output
data path)?
Here is a recent example of a different SQL database (mysql) not
doing proper input validation, leading to problems:
http://debian.org/security/2009/dsa-1783
So it happens all the time. Assuming it won't happen because it
will be caught by "higher layers" is dangerous.
> So I argue that a vulnerability in SQLite is unlikely to effect most
> application and most applications need not be recompiled for
> security. Hence it is not really necessary to factor out SQLite into
> a single shared library.
I would hope most people will go the route that makes it easier
to fix security problems quickly. Nevertheless, we provide the
option of embedding sqlite in Subversion to our users, so they
can decide for themselves. But I would not recommend doing so
in builds that are used in production, and especially not in
environments were some amount of security is required.
I embed sqlite in builds I use for Subversion development,
but just because it is a very convenient way of compiling.
sqlite is a very important piece of software, thank you for making
it and ensuring that it is of good quality. It helps us a lot, since
it is a core part of our new working copy library. Thanks :)
Stefan
Received on 2009-05-05 15:53:30 CEST