Any news about Firefox? Are they also impacted?
Remote code execution vulnerability in SQLite
141–150 of 161 posts
Re: Remote code execution vulnerability in SQLite
#142Earlier quoted context omitted.
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Right. The actual standard is called "modified condition/decison coverage" or MC/DC. In languages like C, MC/DC and branch coverage, though not exactly the same, are very close. Achieving 100% MC/DC does not prove that you always get the right answer. All it means is that your tests are so extensive that you managed to get every machine-code branch to go in both directions at least once. It is a high standard and is…
Nicely written, and thank you for providing such a great peice of engineering!
A thought: would it help to have a modified C compiler that would crash the app whenever UB was encountered? It might help find some bugs where non-default C compiler was used (which I assume happens, given the large amount of platforms sqlite supports). Or am I missing something?
Re: Remote code execution vulnerability in SQLite
#143Re: Remote code execution vulnerability in SQLite
#144Earlier quoted context omitted.
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.
That doesn't really answer the question about other applications. What SQLite function do I need to not call with network input?
Re: Remote code execution vulnerability in SQLite
#145Unfortunately this announcement is light on details; does anybody know what the actual vulnerability was?
Re: Remote code execution vulnerability in SQLite
#146Earlier 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.
Sure, but I very frequently parse PDFs and JPEGs from untrusted sources, but almost never open untrusted .sqlite files. (This is still a serious security vulnerability)
> but almost never open untrusted .sqlite files
You may not notice that you do when apps use sqlite as their file format:
Re: Remote code execution vulnerability in SQLite
#147Earlier quoted context omitted.
100% branch, line coverage means nothing. It's about logical coverage. What are you testing for? You are not testing lines of code, but logic.
Right. The actual standard is called "modified condition/decison coverage" or MC/DC. In languages like C, MC/DC and branch coverage, though not exactly the same, are very close. Achieving 100% MC/DC does not prove that you always get the right answer. All it means is that your tests are so extensive that you managed to get every machine-code branch to go in both directions at least once. It is a high standard and is…
That 100% branch coverage does not include indirect calls via functional pointers or jumps to signal handlers caused by devision by zero or invalid memory access, right?
Re: Remote code execution vulnerability in SQLite
#148Earlier quoted context omitted.
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.
I think you're assuming the target is a browser, but my question was how this might affects servers. Does the attack use malicious SQL statements, API calls, or encoded data?
Re: Remote code execution vulnerability in SQLite
#149Earlier quoted context omitted.
Right. The actual standard is called "modified condition/decison coverage" or MC/DC. In languages like C, MC/DC and branch coverage, though not exactly the same, are very close. Achieving 100% MC/DC does not prove that you always get the right answer. All it means is that your tests are so extensive that you managed to get every machine-code branch to go in both directions at least once. It is a high standard and is…
Nicely written, and thank you for providing such a great peice of engineering! A thought: would it help to have a modified C compiler that would crash the app whenever UB was encountered? It might help find some bugs where non-default C compiler was used (which I assume happens, given the large amount of platforms sqlite supports). Or am I missing something?
I believe there's some things your have to do such aren't C compatible, e.g. store fat pointers of base+length+offset instead of raw pointers, to catch OOB accesses.
Re: Remote code execution vulnerability in SQLite
#150Earlier quoted context omitted.
Can't you just have a NonZeroInt type?
Only if your language supports dependent types.
It's perfectly possible in languages with ordinary ADTs.
data Nat = Z | S Nat
data NonZeroNat = OnePlus Nat
data NonZeroInt = Negative NonZeroNat | Positive NonZeroNat