SQLite Multiple Vulns.

2015.04.16
Risk: High
Local: Yes
Remote: No
CVE: N/A
CWE: N/A

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

References:

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
https://www.sqlite.org/src/info/eddc05e7bb31fae7
https://www.sqlite.org/src/info/02e3c88fbf6abdcf
http://www.sqlite.org/src/info/c494171f77dc2e5e


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top