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

151–160 of 161 posts

Re: Remote code execution vulnerability in SQLite

#151

Post by cyan_pencil »

Drdrdrq wrote: post #142
SQLite wrote: post #112

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

There is ASAN, the address sanitizer. You can enable it by passing some flags to gcc. It will make your program crash as soon as there is an out of bounds read / undefined behaviour. If debug symbols are enabled, it will also tell you which line of code was responsible. It can save you countless hours of debugging

Re: Remote code execution vulnerability in SQLite

#152

Post by nedbat »

mholt wrote: post #42
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.

This is exactly why I don't find code coverage tools useful. Now, a tool that can show what the tests assert against? THAT would be useful.

That would be interesting. In what form would you express the result?

Re: Remote code execution vulnerability in SQLite

#154

Post by mwhicks1 »

SQLite wrote: post #138
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…

Hopefully 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

Re: Remote code execution vulnerability in SQLite

#155

Post by tptacek »

tlrobinson wrote: post #128
tptacek wrote: post #114

Earlier quoted context omitted.

If what you're observing is that industry lingo is suboptimal, you'll get no argument from me. Consider for instance "XSS" and "CSRF", which are just manifestly silly names. But the names mean what they mean; try as I might, I can't get people to accept "Javascript injection".

I’m observing there are reasonable terms for both the vulnerability in SQLite ( https://en.m.wikipedia.org/wiki/Arbitrary_code_execution ) and the vulnerability in Chrome due to the vulnerability in SQLite ( https://en.m.wikipedia.org/wiki/Remote_code_execution ) and wondering why we can’t just use those?

I don't know what to tell you. Try this: Google [browser rce], and then [browser ace] (or [browser ace vulnerability] or whatever). It'll be immediately apparent what the term of art for drive-by code execution vulnerabilities in browsers is.

I sort of intellectually in the back of my head know that "arbitrary code execution" is a term that has been coined and used in the past, but I don't offhand know of anyone that uses it (among other things, it's kind of redundant). "Local only" code execution vulnerabilities aren't "LCE", but rather (usually) "privilege escalation".

Re: Remote code execution vulnerability in SQLite

#156

Post by archgoon »

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?

  int returns_less_than_twelve(int input1, int input2) {
    int sum = 0;
    if (input >= 5) {
       sum += 5;
    } 
    if (input2 >= 5) {
      sum += 8;
    }
    return sum;
  }
The following test cases will pass and achieve 100% branch coverage.

  int x = returns_less_than_twelve(5,0);
  test_assert(x
However, this does not cover the entire input space so

  returns_less_than_twelve(5,5);
  test_assert(x
Will fail. However, branch coverage won't tell you that there's a hole in your test coverage.

Generally however, writing full branch coverage will find a lot of issues, and also cause you to really think through how your code works; but still, it doesn't guarantee correctness. If you want that you need to start bringing tools that either exhaust your input space (a function which takes 5 booleans can be exhaustively tested for correctness in trivial amounts of time), or you start modeling your chosen language well enough that you can use a mathematical prover to demonstrate that your program or function is safe on all inputs.

This of course requires you to come up with a definition of 'correct' or 'safe'. For the above program, it's clear how to define correctness. For things like "Don't let an unauthorized individual access this data or data that is derived from it in a way contrary to the desires of the owner of said data" it gets 'tricky' ;).

Re: Remote code execution vulnerability in SQLite

#157

Post by jwatte »

tonyg wrote: post #150
whyonearth wrote: post #104

Earlier quoted context omitted.

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

C isn't one of those languages, though.

Re: Remote code execution vulnerability in SQLite

#158

Post by tlrobinson »

tptacek wrote: post #155
tlrobinson wrote: post #128

Earlier quoted context omitted.

I’m observing there are reasonable terms for both the vulnerability in SQLite ( https://en.m.wikipedia.org/wiki/Arbitrary_code_execution ) and the vulnerability in Chrome due to the vulnerability in SQLite ( https://en.m.wikipedia.org/wiki/Remote_code_execution ) and wondering why we can’t just use those?

I don't know what to tell you. Try this: Google [browser rce], and then [browser ace] (or [browser ace vulnerability] or whatever). It'll be immediately apparent what the term of art for drive-by code execution vulnerabilities in browsers is. I sort of intellectually in the back of my head know that "arbitrary code execution" is a term that has been coined and used in the past, but I don't offhand know of anyone that…

In both my comments I explicitly said that vulnerabilities in browsers can and should be called RCEs. I was only arguing about what to call vulnerabilities in the underlying libraries (like SQLite) which aren't inherently exposed to "remote" data/manipulation.

Say for some reason someone used an exploitable version of SQLite in a program that had the setuid bit set. You wouldn't say SQLite had a privilege escalation vulnerability, would you?

Re: Remote code execution vulnerability in SQLite

#159

Post by paulie_a »

jcden wrote: post #65
paulie_a wrote: post #52

Earlier quoted context omitted.

That is why I like using random data generators for tests. You can input some static data and then the rest is random. Every once in a while a bug pops out when you see a test fail that was previously passing.

None of the above methods are used for testing. You use boundary testing, branch testing, equivalence partitioning etc. Random data is not a good method of testing.

Sorry, I strongly disagree. Random data with a few static arguments is an incredibly great way to test. Adding in some chaos finds bugs. "why did that test fail after 100 times...ohhhh"

I try to only use random data when possible, less and smaller tests to write with a proper setup. End result: more bugs found.

Random data is a great method of testing.

Re: Remote code execution vulnerability in SQLite

#160

Post by tonyg »

jwatte wrote: post #157
tonyg wrote: post #150

Earlier quoted context omitted.

It's perfectly possible in languages with ordinary ADTs. data Nat = Z | S Nat data NonZeroNat = OnePlus Nat data NonZeroInt = Negative NonZeroNat | Positive NonZeroNat

C isn't one of those languages, though.

The analogous would be the Go-style represent-a-sum-badly-as-a-product,

  struct nonzero_t {
    int is_negative;
    unsigned int one_less_than_the_absolute_value;
  };
which, under interpretation, ranges from -(2^32) to -1 and +1 to +(2^32).
Post reply on HN