Potential Bug (Record Leaking)
(1.1) Originally by anonymous with edits by Richard Hipp (drh) on 2021-03-16 11:33:01 from 1.0 [link] [source]
So I was playing around and found something interesting. By modifying the records within a database file, you can cause it so by querying one record, you leak data in subsequent records. For more documentation checkout the github link below. This is for version 3.35.1.
(2) By Rowan Worth (sqweek) on 2021-03-16 08:12:36 in reply to 1.0 [link] [source]
It's a curious observation but I'm struggling to appreciate its applicability as any sort of attack. If you have the ability to manipulate the database's underlying record structure, why don't you just read the data of interest directly? From the operating system's perspective you must have the ability to read the entire file by definition, otherwise sqlite wouldn't be able to read it...
I'd be interested to know whether the integrity_check or quick_check PRAGMAs notice that the records overlap after munging them like this.
(3) By Gunter Hick (gunter_hick) on 2021-03-16 08:22:19 in reply to 1.0 [link] [source]
Back in ancient computer times (1983), a coworker installed ad DnD Game called Moria. This was played on a standard text console. Looking at the executable, I found a list of plain text with names of weapons, followed by expressions like 1D6. So I patched the string after "Katana" to read "9D9", which made playing the game very much easier. Never in my mind would I have thought to report this as a "bug". You are doing something quite similar here. You already have read and write access to the SQLite db file and could decode every single record it contains. Your hack does not expose anything you do not already have access to. If you want to have SQLite db files that are resistant against file level access, you should consider buying a SEE license. Or writing your own VFS that encrpyt/decrypts pages between disk and memory.
(4.1) By Ryan Smith (cuz) on 2021-03-16 14:28:49 edited from 4.0 in reply to 1.0 [link] [source]
I'm with the other posters that it is hard to imagine it being used in an "attack" of any sort, but just posting cause I get the feeling they also downplay it's bug status.
EDIT: Revising my statements after reading Gunter's reply:
It IS a BUG, and a very important one. It causes input to the DB to have unwanted/inaccurate data as a consequence, where you put in X and get back Y - The very definition of a Bug.
It definitely isn't a bug.
Whether it is an Attack vector... well, I can't see it. For that it has to tweak/open/access something that was not accessible/tweak-able/open-able before - which it doesn't.
Nice write-up though, and if I may ask, how did you find this bug? It seems like there might be an interesting story there.
(5) By Gunter Hick (gunter_hick) on 2021-03-16 11:30:26 in reply to 4.0 [link] [source]
It would be a bug if you could repro the case with the SQLite shell, SQL statements and documented API calls.
This case is none of the above. It is bypassing SQLite altogether and changing the database file directly. This is as much a bug as deleting the database file and then complaining that SQLite cannot open it any more. Or like Windows doing its sandbox-virus-protection-stuff and whisking away the database file out from underneath an application.
As stated earlier, if you want a database file that is resistant to casual direct manipulation, you need to checksum and encrypt the page in the VFS layer. And even then, a clever guy with a debugger may still be able to perform the same chicanery with the memory image of the page.
(6) By anonymous on 2022-02-24 15:10:41 in reply to 1.1 [link] [source]
I work at a large company and in our daily monitoring this "vulnerability" popped up for impact triage. It seems like RedHat has yesterday assigned CVE-2021-45346 for it, see links below:
https://nvd.nist.gov/vuln/detail/CVE-2021-45346 https://bugzilla.redhat.com/show_bug.cgi?id=2054793
Please add this CVE to your "Vulnerabilities" page and state more prominently that this is considered "not a bug". Thanks for maintaining SQLite!
(7.2) By Richard Hipp (drh) on 2022-02-24 18:21:40 edited from 7.1 in reply to 6 [source]
This is what CVE-2021-45346 is saying:
Corrupt a database file such that two different rows are assigned overlapping storage space. Call those two rows X and Y.
Trick the application into writing sensitive information into X.
Read out the sensitive information by querying Y.
Yes, you can do that in SQLite. You can also do it in just about every other RDBMS and every filesystem ever invented. Calling this a "vulnerability" is stretching the meaning of the word "vulnerability".
Note that SQLite will detect and report the corruption, unfailingly, if you ask it (using "PRAGMA quick_check)
Note that if you have sufficient write access such that you can corrupt the database file to cause storage space for two rows to overlap, then you could (with far less effort) just install a new trigger into the schema that causes content written into SENSITIVE_TABLE to be mirrored into PUBLIC_TABLE, and accomplish the same data exfiltration. Indeed, a similar attack will also work on any RDBMS.
The claim in the CVE title that this is a "memory leak" is false, at least according to any definition of "memory leak" that I'm aware of. Perhaps the CVE author meant to say that this is a data exfiltration attack, but just doesn't know the difference between data exfiltration and a memory leak.
The implication in the CVE that the content of memory elsewhere in the application might be exfiltrated is false. The only exfiltration possible here is data which has been explicitly written into the database. You don't necessarily have to COMMIT the data, but it has to be written to the database in order to be exfiltrated.
CVE-2021-45346 is a premier example of a useless CVEs and why you should critically examine CVEs before believing that they are real vulnerabilities.
(8) By anonymous on 2022-02-24 17:30:04 in reply to 7.0 [link] [source]
Thanks for this long post. I am fully aware that this one is a stupid one and there is nothing which can be done. I wouldn't not even bothered to post it here if there wouldn't be this this statement on your homepage:
If you notice new CVEs associated with SQLite that are not in the table below, please bring them to the attention of the developers on the SQLite Forum so they can be added.
(10) By anonymous on 2022-02-25 21:25:21 in reply to 8 [link] [source]
I think that the description in that table should mention that you can use PRAGMA quick_check to mitigate it if you are worried about it.