11 ms·
Remote code execution vulnerability in SQLite
- saagarjha 8y agoUnfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
- devy 8y agoYeah, I was hoping to find a CVE number but couldn't
- saagarjha 8y agoHas there been a CVE number assigned yet?
- dorianm 8y agoI don't see any: https://www.cvedetails.com/vulnerability-list/vendor_id-9237/Sqlite.html https://www.cvedetails.com/vulnerability-list/vendor_id-9237... Edit: it's "To be allocated": "[$TBD][900910] High To be allocated: Multiple issues in SQLite via WebSQL. Reported by Wenxiang Qian of Tencent Blade Team on 2018-11-01" (from https://chromereleases.googleblog.com/2018/12/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2018/12/stable-channel...)
- deleted 8y ago[deleted]
- cdelsolar 8y agoThey say to update to this SQLite version: https://www.sqlite.org/releaselog/3_26_0.html https://www.sqlite.org/releaselog/3_26_0.html Skimming that log doesn't give me any ideas.. maybe the diff would help elucidate?
- Serow225 8y agoMaybe related to this, as a guess? https://www.sqlite.org/c3ref/c_dbconfig_defensive.html#sqlitedbconfigdefensive https://www.sqlite.org/c3ref/c_dbconfig_defensive.html#sqlit... SQLITE_DBCONFIG_DEFENSIVE The SQLITE_DBCONFIG_DEFENSIVE option activates or deactivates the "defensive" flag for a database connection. When the defensive flag is enabled, language features that allow ordinary SQL to deliberately corrupt the database file are disabled. The disabled features include but are not limited to the following: The PRAGMA writable_schema=ON statement. Writes to the sqlite_dbpage virtual table. Direct writes to shadow tables.
- schlarpc 8y agoThe 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/+/c368e30ae55600a1c3c9cb1710a54f9c55de786e%5E%21/#F10 https://chromium.googlesource.com/chromium/src/+/c368e30ae55...
- btilly 8y agoReading through https://www.sqlite.org/releaselog/3_26_0.html 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.
- blattimwind 8y ago> 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. Chromium still supports WebSQL, though, which gives you essentially free reign on a SQLite database. This is quite different from the way most applications expose SQLite to untrusted data (i.e. only through parameter binding).
- SayoYasuda 8y agoFrom what some others have posted, I suspect the underlying bug here is that a database corrupted in the right way can cause arbitrary code execution. Since Sqlite suggests use cases that require loading untrusted databases, this is a bug in its own right. Then, the rest is "to be safe" measures, because it was possible for carefully crafted SQL to intentionally corrupt the database in controllable ways, including triggering the former bug. This isn't really the bug fix, but rather a measure to reduce the attack surface against similar undiscovered bugs. This is speculation, though.
- jdright 8y agoThey 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 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?
- EvanAnderson 8y agoI think it relates to "ALTER TABLE" too-- specially: https://www.sqlite.org/src/info/6e1330545e7b74fe https://www.sqlite.org/src/info/6e1330545e7b74fe The comments in checkin a61ed147 for "renameColumnFunc()" give me the willies.
- testplzignore 8y agoMaybe related to https://www.sqlite.org/src/info/8576ccb479fc4b76 https://www.sqlite.org/src/info/8576ccb479fc4b76 ? Edit: Yes, this is probably it.
- deleted 8y ago[deleted]
- chx 8y agoNo way, this commit is Windows only.
- tedivm 8y agoThat 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.
- robocat 8y ago"Google Home" is either: the app installed on your phone to control say a Chromecast, or a smart speaker.
- deleted 8y ago[deleted]
- klarrimore 8y agoWelcome to the security apparatus hype machine.
- wglb 8y agoSee https://news.ycombinator.com/item?id=18687184 https://news.ycombinator.com/item?id=18687184
- miketery 8y agoPretty sparse on details. I presume local SQLite files for backend systems are unaffected, can anyone confirm?
- rhexs 8y ago"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 SQLite, then found various applications that expose this functionality remotely?
- sebazzz 8y agoProbably 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 sanitized (assuming SQLite provides that, I never programmed against the C API).
- ronsor 8y agoWebKit; worse off, WebKit and Chromium expose SQLite almost directly through WebSQL! Drive-by malware!
- jakeogh 8y agoIf I understand correctly, it requires JS to be enabled (which it is usually). (Edit: wrong term, it's not "HTML5 Local Storage", it's "HTML5 Database" thanks): Chromium (EDIT: idk yet) Webkit2: https://webkitgtk.org/reference/webkit2gtk/stable/WebKitSettings.html#WebKitSettings--enable-html5-database https://webkitgtk.org/reference/webkit2gtk/stable/WebKitSett...
- ronsor 8y agoDrive-by malware used to require Flash or Java... which used to always be enabled. Edit: don't disable local storage! you'll break lots of things that way, and I don't think that includes WebSQL.
- blattimwind 8y agoAn 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).
- JaRail 8y agoThey 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.
- 21 8y agoJavaScript code has access to SQLite. So any webpage where the attacker controls/can inject JavaScript is vulnerable.
- blattimwind 8y agoFirefox has never supported WebSQL...
- tptacek 8y agoDrive-by code execution from a page in a web browser is almost the textbook example of "RCE" in its modern sense.
- GalacticDomin8r 8y agoYeah, of the browser or plugin. SQLite is neither although does have a local exploit.
- simonw 8y agoPython 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?
- blattimwind 8y ago> 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.
- ronsor 8y agoDoes 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.
- Kipters 8y agoWindows 10 ships a copy of sqlite3 since version 1511, I don't know which version it's shipping in the latest updates though.
- sdinsn 8y agoBut does the sqlite3 module actually contain SQLite with it, or just a library to interface with it? The fix does not change any interface library code.
- armitron 8y agoOn Windows, a complete sqlite3 DLL (~1MB) is included with the Python distribution. On Linux/macos, the Python extension (usually) links dynamically to a shared sqlite3 system library.
- akvadrako 8y agoIt's only an issue if you allow untrusted code to run arbitrary SQL statements, which should never be done.
- deleted 8y ago[deleted]
- modeless 8y agoSQLite 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 https://www.sqlite.org/testing.html
- blattimwind 8y agoSQLite can by principle not suffer from a RCE.
- deleted 8y ago[deleted]
- coleifer 8y agoNot sure why this is being downvoted, but you're correct. Now, a networked application that exposes some level of access to sqlite? That's another story. The question I think we all are asking is just how much "leg" does sqlite have to show to be vulnerable?
- tptacek 8y agoIt'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.
- schoen 8y agoI assume people making this distinction are thinking about "network services that the public can compromise by interacting with them over the Internet" vs. "software that someone can compromise by getting it to accept a malicious input". But I agree that "RCE" is commonly used for both; otherwise we would have to maintain that browsers don't suffer RCE vulnerabilities because a malicious document is no longer "remote" once the browser has downloaded it.
- 8y ago
- libdjml 8y agoRemote implies it can be accessed remotely, is that true, or did they mean “remote if an attacker can remotely send data to SQLite”?
- haney 8y agoSounds like they mean “remote” because chromium uses SQLite and JavaScript loaded into your machine comes from a remote source. So because a website can run JS that can exploit chromium they’re calling it an RCE.
- libdjml 8y agoYeah it seems like RCE in the context of Chromium, but not SQLite? I know it’s pedantic but if this is RCE in SQLite because it’s exposed to the network via other software, every vulnerability is “remote” because you may expose it via other software.
- coleifer 8y agoMy 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 some sqlite changes that seem to prevent meddling with virtual table shadow tables (eg inverted index for the fts3 extension). The question I think everyone is asking is how much sqlite needs to be exposed by an application in order to be vulnerable? Just my thoughts. Eager to learn more.
- tptacek 8y agoNot so much as a guess as a documented fact: https://chromereleases.googleblog.com/2018/12/stable-channel-update-for-desktop.html https://chromereleases.googleblog.com/2018/12/stable-channel... The Chromium exposure is through Web SQL.
- tedunangst 8y agoThat doesn't really answer the question about other applications. What SQLite function do I need to not call with network input?
- wglb 8y agoSee https://news.ycombinator.com/item?id=18687184 https://news.ycombinator.com/item?id=18687184
- OnlyRepliesToBS 8y agolol there's a bug but we're not telling you
- zzo38computer 8y agoThe question are: Where is the vulnerability? By executing user-specified SQL statements (with or without setting an authorizer callback; I have once reported a bug causing SQLite to segfault in some cases when the authorizer callback denies something)? By downloading a corrupt database? In some extension (if so, in what extension)? In the VFS? What circumstances are needed to exploit this?
- nneonneo 8y agoIt 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 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.
- tptacek 8y agoA nit: it's not necessarily just applications that accept arbitrary queries, but also applications that use sqlite as a file format.
- nneonneo 8y agoYes - good point. Programs accepting SQLite databases as input (as opposed to just queries) are also vulnerable. The exploit is probably somewhat harder if you don’t have interactivity, since it would depend on exactly how the corrupt database gets used.
- cheeze 8y agoIf tencent is sharing that with everyone, I wonder what exploits they've only shared with the Chinese govt...
- craftoman 8y agoWhen people will start realizing how fragile is actually every project from Google. In the end it's built by humans, remember past week about kubernetes and consider the fact that Google pays thousands of dollars to white hackers who helped them in the past.
- klarrimore 8y agoPretty light on the details here.
- rasz 8y agoAncient and long dead Opera 12.xx let you set all HTML5 Offline Storage quotas/features globally and per domain. Afaik Chrome and its derivatives lack any form of user control over local storage. No Quota mechanisms, no domain black/white listing, no feature toggle. localStorage, webSql, IndexedDB, Filesystem API, all forced on with no limits under user control. In a better world this would be an easy fix for Chrome users unable to upgrade their browser, flip one config setting to disable webSql and you are done, alas Google wont let you do that. Cant wait for first worm using this vuln.
- sat_nam 8y agoZhuowei Zhang (@zhuowei) published a proof of concept that crashes Chrome 70: https://worthdoingbadly.com/sqlitebug/ https://worthdoingbadly.com/sqlitebug/
- Buge 8y agoHuh, so Tencent Blade is like Google Project Zero? Ideally all companies would start attacking each other, and improve everyone's security.
- jondubois 8y agoThis is surprising considering that SQLite is very heavily tested. It shows that ridiculous amounts of testing with 100% coverage of every code path and "millions and millions" of test cases still doesn't guarantee that the program always works as intended. I think that this is an important lesson about testing. We should have fewer tests but we should try to get the most value possible out of each one and for developers that means actively seeking out unusual edge cases that are likely to break things. Source: https://www.sqlite.org/testing.html https://www.sqlite.org/testing.html
- SQLite 8y agoTwo points: (1) The coverage testing used by SQLite is very good at finding problems that occur when the system is used as it was intended. Fuzz testing is better for finding vulnerabilities that can be exploited by a hacker. The 100% MC/DC testing in SQLite is very useful in ensuring that the code does what is intended for sane inputs. And 100% MC/DC helps prevent us from breaking things as we evolve and enhance the code. But the MC/DC testing is less useful at fending off attackers. (2) The magellan vulnerability exploits a bug in an SQLite extension, FTS3, which while very well tested, is not testing to 100% MC/DC. (See the second sentence at https://www.sqlite.org/testing.html#test_coverage https://www.sqlite.org/testing.html#test_coverage) Hence my takeaways from this episode include that I need to extend 100% MC/DC testing to all commonly used extensions in SQLite, including FTS3, FTS5, and RTREE, and I need to improve fuzz testing throughout SQLite but especially in extensions. Advocates of "safe" language correctly observe that this particular problem would not have happened if SQLite were written in (say) Rust. Rewriting SQLite in Rust in not (yet) a viable solution. (See https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html) But I can start moving SQLite in that direction, and perhaps make use of techniques taken from safe languages to improve its resistance to attack.
- mwhicks1 8y agoHopefully soon, “moving in that direction” can be done by slowly porting to Checked C, while always retaining an executable artifact. https://github.com/Microsoft/checkedc https://github.com/Microsoft/checkedc
- jared0x90 8y agoI casually thumbed through a few of the commits they posted and came across this https://chromium.googlesource.com/chromium/src/+/c368e30ae55600a1c3c9cb1710a54f9c55de786e%5E%21/#F48 https://chromium.googlesource.com/chromium/src/+/c368e30ae55... for(i=0; i<nChar; i++){ if( n>=nByte ) return 0; /* Input contains fewer than nChar chars */ if( (unsigned char)p[n++]>=0xc0 ){ - while( (p[n] & 0xc0)==0x80 ) n++; + while( (p[n] & 0xc0)==0x80 ){ + n++; + if( n>=nByte ) break; + } } } return n; Looks like there may have been an issue in parsing malformed multibyte unicode characters properly.
- jared0x90 8y agoconst secondStatements = [ "SELECT quote(root) from ft_segdir;", "UPDATE ft_segdir SET root = X'0005616261636B03010200FFFFFFFF070266740302020003046E646F6E03030200';", "SELECT * FROM ft WHERE ft MATCH 'abandon';" ]; Just saw the proof of concept page. Looks like they are building quite the usual string in hex... Starting with a null terminator? Mmmhmmm
- deleted 8y ago[deleted]
- odc 8y agoAny news about Firefox? Are they also impacted?
- fbender 8y agoApparently not since they resisted implementing WebSQL.