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

131–140 of 161 posts

Re: Remote code execution vulnerability in SQLite

#131

Post by gcc_programmer »

SQLite wrote: post #112
segmondy wrote: post #37

Earlier 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…

This is how a real developer speaks: no speculation, simple facts. All the rust fanboys/fangirls will just use this bug to justify using their language and will blame C for the existence of bugs instead of realising that bugs will be present in every program and in every language.

Re: Remote code execution vulnerability in SQLite

#132

Post by thaumasiotes »

yladiz wrote: post #44
segmondy wrote: post #37

Earlier 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.

Isn't that the definition of branch testing, to test all possible branches within code and also testing the logic in all of those branches?

Testing all possible branches (each considered individually) won't get you very far in terms of testing all possible logic flows.

Consider a function which checks 5 simple if-statements in a row, always in the same order. Getting each branch means you tested 10 things.

But there are 32 ways for 5 if-statements to jointly evaluate. If there is a logical dependency between the state checked by one if-statement and the state checked by another one, your perfect coverage may not pick up on that.

If the if-statements might be checked in an arbitrary order... there are 120 ways to order 5 things. But you'll still get perfect branch coverage by checking 10 of them.

Re: Remote code execution vulnerability in SQLite

#133

Post by jared0x90 »

I casually thumbed through a few of the commits they posted and came across this

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

   for(i=0; i=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.

Re: Remote code execution vulnerability in SQLite

#134

Post by jared0x90 »

jared0x90 wrote: post #133

I casually thumbed through a few of the commits they posted and came across this https://chromium.googlesource.com/chromium/src/+/c368e30ae55... for(i=0; i =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 parsin…

   const 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

Re: Remote code execution vulnerability in SQLite

#135

Post by IshKebab »

nneonneo wrote: post #81

It 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,…

Are you sure Google Home loads web pages? I can't think of a feature that requires that.

Re: Remote code execution vulnerability in SQLite

#137

Post by xtrapolate »

modeless wrote: post #33

SQLite 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

> "If even SQLite can have a RCE vulnerability, I'm convinced that it is not feasible for anybody to write safe C code."

This has much less to do with C, than it has to do with the fact that sqlite is a huge codebase.

Software can be vulnerable regardless of the programming languages used.

Re: Remote code execution vulnerability in SQLite

#138

Post by SQLite »

jondubois wrote: post #129

This 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 develo…

Two 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)

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) 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.

Re: Remote code execution vulnerability in SQLite

#139

Post by hyperman1 »

jeklj wrote: post #79
modeless wrote: post #33

SQLite 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

To be a bit glib, unit tests don’t catch security vulnerabilities. Maybe I’d agree this can happen to any project, but my example might be something more like OpenBSD

Why not?

In this specific case, a unit test that checked this integer overflow seeems to prevent the vulnerability.

To be clear: This is not to admonish sqlite. They have taken testing further than any other project i've heard of, except maybe the NASA software that might cost lives if it fails.

Re: Remote code execution vulnerability in SQLite

#140

Post by hashhar »

hyperman1 wrote: post #139
jeklj wrote: post #79

Earlier quoted context omitted.

To be a bit glib, unit tests don’t catch security vulnerabilities. Maybe I’d agree this can happen to any project, but my example might be something more like OpenBSD

Why not? In this specific case, a unit test that checked this integer overflow seeems to prevent the vulnerability. To be clear: This is not to admonish sqlite. They have taken testing further than any other project i've heard of, except maybe the NASA software that might cost lives if it fails.

Incidentally a lot of NASA tools use SQLite as well from what I have heard.
Post reply on HN