21–30 of 161 posts
Earlier quoted context omitted.
Has there been a CVE number assigned yet?
I don't see any: 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... )
Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
Edit: Yes, this is probably it.
Earlier quoted context omitted.
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!
(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/WebKitSett...
Earlier quoted context omitted.
WebKit; worse off, WebKit and Chromium expose SQLite almost directly through WebSQL! Drive-by malware!
If 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/WebKitSett...
Edit: don't disable local storage! you'll break lots of things that way, and I don't think that includes WebSQL.
Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
Maybe related to https://www.sqlite.org/src/info/8576ccb479fc4b76 ? Edit: Yes, this is probably it.
"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.
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?
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…
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).