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

11–20 of 161 posts

Re: Remote code execution vulnerability in SQLite

#11

Post by blattimwind »

An RCE in a non-networked component is interesting (in other words, obvious hyperbole). Either this is your usual corruption bug/vuln triggerable in some/many programs using SQLite, or an actual bug in SQLite itself, e.g. query preparation (a fix/workaround being committed to SQLite doesn't necessarily imply one or the other). Whether the RCE hyperbole is justified remains to be seen.

Edit: Apparently the exploit vector is due to WebSQL.

And my guess as for the vulnerability area are "strategically corrupt databases", because there have been numerous commits related to this in the relevant SQLite releases and some seem like they were added relatively late in the process (e.g. after changing the VERSION file but before releasing).

Re: Remote code execution vulnerability in SQLite

#12

Post by ronsor »

sebazzz wrote: post #10
rhexs wrote: post #6

"If you use a device or software that uses SQLite or Chromium, it will be affected." If I write a hello world C program that does some sort of IO with SQLite, it will be vulnerable to remote code execution? (if this turns out to be true, that will be quite impressive!) Guessing something was lost in translation there. Sounds more like someone found a way to get code execution if you can inject certain data into SQLit…

Probably they found the vulnerability through Chromium, then extended that to "everything that uses SQLite". Hard to tell anything without more details though. But if that is the case this is huge . SQLite is used in many places nowadays: Websites, browsers (Chromium and Firefox, I know of), various software including some Android apps. That also probably means the attack vector is some procedure where input is sanit…

WebKit; worse off, WebKit and Chromium expose SQLite almost directly through WebSQL! Drive-by malware!

Re: Remote code execution vulnerability in SQLite

#13

Post by JaRail »

blattimwind wrote: post #11

An RCE in a non-networked component is interesting (in other words, obvious hyperbole). Either this is your usual corruption bug/vuln triggerable in some/many programs using SQLite, or an actual bug in SQLite itself, e.g. query preparation (a fix/workaround being committed to SQLite doesn't necessarily imply one or the other). Whether the RCE hyperbole is justified remains to be seen. Edit: Apparently the exploit vec…

They mention the example of browsing to a web page. Not quite a fully fledged remote execution bug but close enough. I think what they're really saying is they're aware of remote execution cases. An example of that might be a web services that's backed by a SQLite query.

Re: Remote code execution vulnerability in SQLite

#15

Post by btilly »

saagarjha wrote: post #2

Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?

Reading through https://www.sqlite.org/releaselog/3_26_0.html which they linked to, I'm presuming that it is tied to items 3 and 4. Which is highly suggestive that the problem is that ordinary SQL is able to write to internal virtual tables in a way that corrupts the database. And presumably from there, once you can introduce corruption you can get it to exploit a payload that you provide.

The fact that Chromium also saw fit to patch this suggests further that there was likely some way that it could be tricked into issuing queries that did this, allowing some compromise of the browser. If this could have been triggered by a web page, then that explains why they are light on details.

It should be noted that a lot of applications embed SQLite internally. If one as well studied as Chromium could be tricked in this way, I'm sure that others can as well. And since the upgrade has to happen to an embedded component, we're probably going to hear about this one for a while.

Please note, this is all educated guesswork from knowing the software ecosystem and reading release notes. I have absolutely no knowledge of the vulnerability.

Re: Remote code execution vulnerability in SQLite

#16

Post by blattimwind »

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 this mean Python needs to ship a security path?

Python binaries (e.g. the Windows installers) may need to be updated. For Linux distros Python would depend on a system package.

Re: Remote code execution vulnerability in SQLite

#17

Post by jdright »

saagarjha wrote: post #2

Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?

They are giving time to more SQLite users to patch and waiting the CVE to be assigned. Looking at the chromium patch, this has something to do with ALTER TABLE. Looking at SQLite release notes they clearly are hiding the real nature of the issue there. For instance, see this: https://www.sqlite.org/lang_altertable.html

"Compatibility Note: The behavior of ALTER TABLE when renaming a table was enhanced in versions 3.25.0 (2018-09-15) and 3.26.0 (2018-12-01) in order to carry the rename operation forward into triggers and views that reference the renamed table. This is considered an improvement. Applications that depend on the older (and arguably buggy)..."

A problem that (well tailored) enables a RCE is just "arguably buggy" in their view?

Re: Remote code execution vulnerability in SQLite

#18

Post by schlarpc »

cdelsolar wrote: post #8
saagarjha wrote: post #2

Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?

They say to update to this SQLite version: https://www.sqlite.org/releaselog/3_26_0.html Skimming that log doesn't give me any ideas.. maybe the diff would help elucidate?

The Chrome update only bumped to 3.25.3, so it's likely a commit between 3.24.0 and 3.25.3:

https://chromium.googlesource.com/chromium/src/+/c368e30ae55...

Re: Remote code execution vulnerability in SQLite

#19

Post by ronsor »

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.

Re: Remote code execution vulnerability in SQLite

#20

Post by cjensen »

rhexs wrote: post #6

"If you use a device or software that uses SQLite or Chromium, it will be affected." If I write a hello world C program that does some sort of IO with SQLite, it will be vulnerable to remote code execution? (if this turns out to be true, that will be quite impressive!) Guessing something was lost in translation there. Sounds more like someone found a way to get code execution if you can inject certain data into SQLit…

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.

Post reply on HN