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

121–130 of 161 posts

Re: Remote code execution vulnerability in SQLite

#121

Post by tptacek »

ATsch wrote: post #106
tptacek wrote: post #53

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

I think the reverse definition is just as silly... Calling a JPEG parser vulnerability an RCE just because some online service is using it in a way that can be exploited remotely. By that definition, any bug is an RCE, since I can just set up a web server to run that program. I think a better way of looking at it is that it's an ACE Vulnerability in the e.g. JPEG parser that causes an RCE in the Online Service. Or, i…

Sure, though what I'd say is silly is epistemological conceit of trying to pin down vulnerabilities as "remote" or "local". A lot of vulnerability research terms are silly (sillier than RCE). Either way: it's a "term of art", and it means what it means, and this is a clear and obvious instance of an RCE.

Re: Remote code execution vulnerability in SQLite

#124

Post by kd5bjo »

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

Excellent summary, nneonneo. I think everything you said here is correct. The vulnerability only exists in applications that allow a potential attacker to run arbitrary SQL. If an application allows that, it is usually called an "SQL Injection" vulnerability and is the fault of the application, not the database engine. The one notable exception to this rule is WebSQL in Chrome. I put up https://www.sqlite.org/securit…

If giving unrestricted database file access is “living on the edge,” maybe https://www.sqlite.org/appfileformat.html should be updated to reflect that?

Re: Remote code execution vulnerability in SQLite

#125

Post by weinzierl »

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

Excellent summary, nneonneo. I think everything you said here is correct. The vulnerability only exists in applications that allow a potential attacker to run arbitrary SQL. If an application allows that, it is usually called an "SQL Injection" vulnerability and is the fault of the application, not the database engine. The one notable exception to this rule is WebSQL in Chrome. I put up https://www.sqlite.org/securit…

What about Fossil? Is there a way for a potential attacker to run arbitrary SQL? I can't think of one but I'm only a light user.

Re: Remote code execution vulnerability in SQLite

#126

Post by zzo38computer »

kd5bjo wrote: post #124
SQLite wrote: post #94

Earlier quoted context omitted.

Excellent summary, nneonneo. I think everything you said here is correct. The vulnerability only exists in applications that allow a potential attacker to run arbitrary SQL. If an application allows that, it is usually called an "SQL Injection" vulnerability and is the fault of the application, not the database engine. The one notable exception to this rule is WebSQL in Chrome. I put up https://www.sqlite.org/securit…

If giving unrestricted database file access is “living on the edge,” maybe https://www.sqlite.org/appfileformat.html should be updated to reflect that?

I agree. If the file is one you might get elsewhere rather than only being your own files, then it is untrusted.

To me, "trusted" is: queries entered by the local user (or, for setuid programs, by the local system administrator instead of the local user), or that are built in to the program. Others are untrusted.

And yet, I have already considered these kind of vulnerability before even knowing about it.

Re: Remote code execution vulnerability in SQLite

#127

Post by zzo38computer »

weinzierl wrote: post #125
SQLite wrote: post #94

Earlier quoted context omitted.

Excellent summary, nneonneo. I think everything you said here is correct. The vulnerability only exists in applications that allow a potential attacker to run arbitrary SQL. If an application allows that, it is usually called an "SQL Injection" vulnerability and is the fault of the application, not the database engine. The one notable exception to this rule is WebSQL in Chrome. I put up https://www.sqlite.org/securit…

What about Fossil? Is there a way for a potential attacker to run arbitrary SQL? I can't think of one but I'm only a light user.

I think it depends on the permissions. If you do not allow users with those permissions to login remotely, then I would suppose it would not be a problem. (This is what I do: users with permission to enter SQL and TH1 codes cannot login remotely.)

Re: Remote code execution vulnerability in SQLite

#128

Post by tlrobinson »

tptacek wrote: post #114
tlrobinson wrote: post #102

Earlier quoted context omitted.

I don't know. I'd say PDF or JPEG parsers (and SQLite) can have arbitrary code execution vulnerabilities, which can in turn be responsible for remote code execution vulnerabilities when used in network-connected software. e.g. SQLite has an ACE. Chrome has a RCE (which is SQLite's fault).

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?

Re: Remote code execution vulnerability in SQLite

#129

Post by jondubois »

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 developers that means actively seeking out unusual edge cases that are likely to break things.

Source: https://www.sqlite.org/testing.html

Re: Remote code execution vulnerability in SQLite

#130

Post by burfog »

tptacek wrote: post #114
tlrobinson wrote: post #102

Earlier quoted context omitted.

I don't know. I'd say PDF or JPEG parsers (and SQLite) can have arbitrary code execution vulnerabilities, which can in turn be responsible for remote code execution vulnerabilities when used in network-connected software. e.g. SQLite has an ACE. Chrome has a RCE (which is SQLite's fault).

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

The actual industry term is just "code execution", or maybe "arbitrary code execution" if you want to get more specific than is typically worthwhile, not "RCE".

Usage example: "I got code execution!"

Post reply on HN