Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Remote code execution vulnerability in SQLite

blade.tencent.com

Post reply on HN
Print view View original

81–90 of 161 posts

Re: Remote code execution vulnerability in SQLite

#81

Post by nneonneo »

It is very likely that this bug only affects systems which accept and run arbitrary SQLite3 queries. This includes Chromium, because Chromium ships with WebSQL. The Google Home is probably vulnerable because it can be coerced to load a webpage. I doubt that this bug affects systems that merely use SQLite as a database without providing external query access.

My best guess for the bug is that arbitrary SQLite queries, prior to 3.26.0, were permitted to write to the shadow tables used by various plugins to implement features. fts3/4, prior to 3.25.3, appear to contain an integer overflow bug which can be triggered by manually modifying the fts index data. A careful application of this integer overflow appears to make it possible to truncate a writable buffer, leading to a nice heap overflow condition that can be exploited by further crafted SQL queries.

The primary integer overflow bug was fixed in https://sqlite.org/src/info/940f2adc8541a838 "Add extra defenses against strategically corrupt databases to fts3/4.", committed as part of the 3.25.3 update (which is what Chromium updated to). Later, in 3.26.0, they further secure it by making shadow tables optionally read-only.

The worrying thing here is that SQLite3, in its default configuration, is still not convincingly secure. Being able to write arbitrary data to the shadow tables has the potential to break all sorts of assumed invariants, and it's pretty clear that the SQLite3 developers did not necessarily anticipate all the ways in which this could break. The "SQLITE_DBCONFIG_DEFENSIVE" option which was added does not appear to be on by default, and it breaks backwards compatibility (setting it causes SQL imports from .dump to fail because .dump assumes shadow tables are writable during import).

There may be more bugs lurking in this area - this would be an excellent opportunity to fuzz all the plugins in SQLite to see if any of them barf when their shadow tables are corrupted.

Re: Remote code execution vulnerability in SQLite

#82

Post by blattimwind »

tptacek wrote: post #75
ynniv wrote: post #69

Earlier quoted context omitted.

They're only vulnerable to RCE if image data can be supplied remotely. What's the analog here? Accessing the JavaScript API? Specifying a query string? Maliciously encoded data? Some of these are scarier than others.

This isn't, like, a real debate. Go here: https://pwnies.com/ Start with the 2018 nominations but feel free to check the archives. Drive-by browser vulnerabilities are RCEs.

> Drive-by browser vulnerabilities are RCEs.

I would never argue they aren't, but by this logic ("it's like saying PDF or JPEG parsers can't be vulnerable to RCE") virtually every code execution vuln in a library can be called RCE. I haven't noticed this to be the case with e.g. libtiff vulnerabilities (of which many make it into my inbox regularly), although image libraries are one of the cases were CE = RCE is still fairly reasonable.

Let's assume this SQLite bug is only exploitable if you can input arbitrary SQL. Almost no applications use it this way (except Chrome). I think it's clearly unreasonable to call it a RCE in SQLite then.

Re: Remote code execution vulnerability in SQLite

#83

Post by cjensen »

dragonwriter wrote: post #28
cjensen wrote: post #20

Earlier quoted context omitted.

Yeah, that's obvious nonsense. Merely using SQLite in your app does not open a port. How, exactly, are you going to be "vulnerable to remote code execution" when you don't use any network connections? And the phrase "uses SQLite or Chromium" is pretty close to gibberish. Those two things... are not really related.

Doesn't Chromium (like lots of other software) embed SQLite? So using Chromium would be (a potentially easily overlooked way) of using SQLite?

That would be "Chromium and SQLite", which is a combination that makes sense. "Or" doesn't make sense.

Re: Remote code execution vulnerability in SQLite

#84

Post by zaphar »

qznc wrote: post #72
RussianCow wrote: post #63

Earlier quoted context omitted.

That's not a branch; otherwise you would have an infinite (or impossibly large) number of branches for just that one line of code. A branch is when you execute one set of code upon a given condition, and another if that condition is not met.

It depends on the language. In C it is not a branch because division by zero is undefined and not a path you consider. In Java you can argue that there are two branches. One branch that throws an exception and one that does not.

No coverage reporting library will attempt to tell you that kind of coverage. You are essentially in violent agreement with the op but turning it into an argument by using different words for the same concept.

Re: Remote code execution vulnerability in SQLite

#85

Post by akvadrako »

RussianCow wrote: post #63
akvadrako wrote: post #59

Earlier quoted context omitted.

Not really - internally inputs 0 and 1 use different branches.

That's not a branch; otherwise you would have an infinite (or impossibly large) number of branches for just that one line of code. A branch is when you execute one set of code upon a given condition, and another if that condition is not met.

I didn't say every number is a different branch. But on many processors, divide by zero triggers an interrupt. That's semantically the same as a branch.

Re: Remote code execution vulnerability in SQLite

#87

Post by snaky »

nichochar wrote: post #57
snaky wrote: post #56

Earlier quoted context omitted.

Especially considering you could generate faster C code than written by hand. With Proofs, Without Compromises http://adam.chlipala.net/papers/FiatCryptoSP19/FiatCryptoSP1...

Have you seen the language Esterel?

My impression is it's rather low-level verification and modelling language comparing to the platforms like Kami (https://deepspec.org/entry/Project/Kami)

Re: Remote code execution vulnerability in SQLite

#88

Post by zaphar »

ru999gol wrote: post #77
ronsor wrote: post #29

Earlier quoted context omitted.

Yes it does, and it makes sense to mention it because Chrome and Chromium are very popular and widespread, but many may not know it uses SQLite.

Its a fairly special case where any website can execute arbitrary SQL due to WebDB. It should be mentioned that this is deprecated: https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...

Yeah and that deprecated feature will probably still be around failing to totally die a decade from now.

Re: Remote code execution vulnerability in SQLite

#89

Post by tedunangst »

tptacek wrote: post #76
coleifer wrote: post #40

My guess, for what it's worth, is that chromium is vulnerable because it exposes sqlite to web applications, which can then execute queries in such a way as to achieve code execution. I highly doubt this would affect, say, a blog running with a sqlite database. From the alarmist nature of this post, though, it's unclear. I see chromium, in their patch, switched to using new flags when opening the DB. There are also s…

Not so much as a guess as a documented fact: https://chromereleases.googleblog.com/2018/12/stable-channel... The Chromium exposure is through Web SQL.

That doesn't really answer the question about other applications. What SQLite function do I need to not call with network input?

Re: Remote code execution vulnerability in SQLite

#90

Post by Frizi »

jakevn wrote: post #68
jcden wrote: post #65

Earlier quoted context omitted.

None of the above methods are used for testing. You use boundary testing, branch testing, equivalence partitioning etc. Random data is not a good method of testing.

Except for the fact that it is exactly the method that has been used to discover a large number of critical bugs in the most popular OSS projects (including SQLite): http://lcamtuf.coredump.cx/afl/

Fuzzing isn't really practical if all you do is just generate a totally random bit stream for input. There are many much more clever and robust strategies to hit as many edge cases as possible. Check AFL[1] for some details on generating smart random input files. You can also combine that with pretty advanced dynamic execution analysis to fuzz against unknown processor instruction sets, like in sandsifter[2].

[1]: http://lcamtuf.coredump.cx/afl/

[2]: https://github.com/xoreaxeaxeax/sandsifter

Post reply on HN