[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CALx_OUB0_WpPPBWzPfyxgARKfuhx7MJ3dEbqV2wRm-PXyOUvig@mail.gmail.com>
Date: Tue, 14 Apr 2015 11:33:50 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: "fulldisclosure@...lists.org" <fulldisclosure@...lists.org>
Cc: bugtraq <bugtraq@...urityfocus.com>
Subject: several issues in SQLite (+ catching up on several other bugs)
SQLite is probably the most popular embedded database in use today; it
is also known for being very well-tested and robust.
Because of its versatility, SQLite sometimes finds use as the
mechanism behind SQL-style query APIs that are exposed between
privileged execution contexts and less-trusted code. One example of
this is the WebDB / WebSQL mechanism available in some browsers; in
this setting, vulnerabilities in the SQLite parser can open up the
platform to attacks.
Anyway, long story short, I recently reported around 22 bugs in the
query parser, including the use of uninitialized memory when parsing
collation sequences:
https://www.sqlite.org/src/info/eddc05e7bb31fae7
...and bad free():
https://www.sqlite.org/src/info/02e3c88fbf6abdcf
...and a stack buffer overflow:
http://www.sqlite.org/src/info/c494171f77dc2e5e
Since all the fixes are already public and the issues are fixed in
3.8.9, but there's no upstream advisory, I figured I'd drop a note
here; if you're relying on SQLite in a way mentioned earlier on, you
may want to upgrade. There are no CVEs assigned for any of the above.
The aforementioned three bugs aside, the remaining 19 issues are
probably less interesting. They depend on "privileged" commands (e.g.,
ATTACH), only have DoS potential, or corrupt nominally boring areas of
memory (say, http://www.sqlite.org/src/info/0cdf502885ea7e58). Some of
them may matter for escalating SQL injection to RCE. If you are
curious, you can check out docs/vuln_samples/sqlite_* shipping with
afl-fuzz for a complete set.
All of the above bugs were found with http://lcamtuf.coredump.cx/afl/
after spending around 30 minutes to set up the job.
Peace out,
/mz
...
PS. Here's another, unrelated bug that may not have had a CVEs. It
affects browser <video> handling (H.264):
https://github.com/FFmpeg/FFmpeg/commit/e8714f6f93d1a32f4e4655209960afcf4c185214
PPS. I haven't posted about this before, but here are three
recently-fixed issues affect PNG, JXR, and TIFF handling in MSIE,
leaking values from browser memory:
http://lcamtuf.blogspot.com/2015/03/another-round-of-image-bugs-png-and.html
http://lcamtuf.blogspot.com/2015/02/bi-level-tiffs-and-tale-of-unexpectedly.html
PPPS. Since we're on the topic of catching up, I would strongly advise
against using jxrlib, a Microsoft-developed open source library for
parsing JXR / HDP / WDP files (JPEG XR), a new image format supported
in Internet Explorer and Adobe Flash. It appears to have many
exploitable memory corruption errors that are discoverable with AFL. I
pinged them in December, but the maintainers weren't very responsive.
The bugs do not affect MSIE, since the OSS implementation appears to
be completely separate (huh). That said, they will affect ImageMagick
and similar programs if they are built with jxrlib support compiled
in. Since the library has fairly minimal install base, this note is
about as much effort as I think it warrants.
/mz
Powered by blists - more mailing lists