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

71–80 of 161 posts

Re: Remote code execution vulnerability in SQLite

#71

Post by int_19h »

yzmtf2008 wrote: post #66
blattimwind wrote: post #34

Earlier quoted context omitted.

SQLite can by principle not suffer from a RCE.

It's no more "by principle" secure than any other SQL server bind to localhost only, so I'm not sure what you meant by it does not suffer from a RCE.

It is, actually. When something binds to localhost, there's still potential for privilege escalation vulnerability, since any process can connect to the port - so if there's an exploit, a low-privileged process could hijack a higher-privileged one. Localhost sockets are still a security boundary.

Since SQLite in and of itself is just a library, it doesn't have that problem. You have to expose it to untrusted inputs manually somehow (e.g. by setting up a socket).

Re: Remote code execution vulnerability in SQLite

#72

Post by qznc »

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.

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.

Re: Remote code execution vulnerability in SQLite

#73

Post by snaky »

paulie_a wrote: post #52
gcc_programmer wrote: post #48

Earlier quoted context omitted.

You test all possible executions of your program when you test with all possible data inputs, which is infinite.

That is why I like using random data generators for tests. You can input some static data and then the rest is random. Every once in a while a bug pops out when you see a test fail that was previously passing.

And the probability to find the corner case ('input = 0') for the simplest expression ('value = 1 / input') this way is not quite astounding.

Re: Remote code execution vulnerability in SQLite

#74

Post by Kipters »

ronsor wrote: post #19
simonw wrote: post #14

Python ships with a sqlite3 module in the standard library. Does this mean Python needs to ship a security path? What should Python users be doing about this?

Does python use it's own sqlite3 or system sqlite3? In the latter case, patches would be the package maintainers' responsibility. Of course, on Windows, it's going to have to use its own sqlite3.

Windows 10 ships a copy of sqlite3 since version 1511, I don't know which version it's shipping in the latest updates though.

Re: Remote code execution vulnerability in SQLite

#75

Post by tptacek »

ynniv wrote: post #69
tptacek wrote: post #53

Earlier quoted context omitted.

It's a pretty silly definition; it's like saying PDF or JPEG parsers can't be vulnerable to RCE, when they are in fact major vectors for RCE attacks.

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.

Re: Remote code execution vulnerability in SQLite

#76

Post by tptacek »

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.

Re: Remote code execution vulnerability in SQLite

#77

Post by ru999gol »

ronsor wrote: post #29
dragonwriter wrote: post #28

Earlier quoted context omitted.

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

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...

Re: Remote code execution vulnerability in SQLite

#78

Post by robocat »

tedivm wrote: post #27
testplzignore wrote: post #22

Earlier quoted context omitted.

Maybe related to https://www.sqlite.org/src/info/8576ccb479fc4b76 ? Edit: Yes, this is probably it.

That commit seems to imply that it's a bug when running on Windows, but the Tencent Blade folks have said they've exploited this on Google Home devices. My guess is that this commit is one of many that helped resolve the vulnerability.

"Google Home" is either:

the app installed on your phone to control say a Chromecast,

or a smart speaker.

Re: Remote code execution vulnerability in SQLite

#79

Post by jeklj »

modeless wrote: post #33

SQLite is the most thoroughly tested codebase I'm aware of [1]. It has seven times more test code than non-test code. 100% branch coverage. If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code. [1] https://www.sqlite.org/testing.html

To be a bit glib, unit tests don’t catch security vulnerabilities. Maybe I’d agree this can happen to any project, but my example might be something more like OpenBSD

Re: Remote code execution vulnerability in SQLite

#80

Post by seanwilson »

gcc_programmer wrote: post #48
yladiz wrote: post #44

Earlier quoted context omitted.

Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?

You test all possible executions of your program when you test with all possible data inputs, which is infinite.

You can do this with machine verified programs. It's like proving a maths theorem; you don't check it for all values but you create a robust argument that it must be true for all values.
Post reply on HN