Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Digital Dog]

On Mon, Jan 28, 2019 at 9:26 AM Vladimir Barbu <
vladimir.ba...@schneider-electric-dms.com> wrote:

> This vulnerability has been addressed in SQLite 3.26.0. When could we
> expect new version (official) of System.Data.SQLite which uses 3.26.0?
>

That would also make it much easier to use new features from .NET, such as
window functions and *a lot* of bugfixes since 3.24.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Simon Slavin]

Since we're on this subject anyway, today's release of Chrome (version 72 for 
Mac, Windows and Linux) blocks the vulnerability two ways, even if it is 
somehow using a vulnerable pre-
3.26.0 version of SQLite.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Vladimir Barbu]

We do use FTS3 and don't provide execution of arbitrary SQL in our product code 
(of course, SQL injection is also not possible), but clients could write their 
own customizations via plugins.


---
Vladimir



-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Warren Young
Sent: Monday, January 28, 2019 21:05
To: SQLite mailing list 
Subject: Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

On Jan 28, 2019, at 1:26 AM, Vladimir Barbu 
 wrote:
> 
> This vulnerability has been addressed in SQLite 3.26.0. When could we expect 
> new version (official) of System.Data.SQLite which uses 3.26.0?

Are you both using FTS3 *and* letting your users execute arbitrary SQL?

Most of the time, the latter is a vulnerability in and of itself.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Warren Young]

On Jan 28, 2019, at 1:26 AM, Vladimir Barbu 
 wrote:
> 
> This vulnerability has been addressed in SQLite 3.26.0. When could we expect 
> new version (official) of System.Data.SQLite which uses 3.26.0?

Are you both using FTS3 *and* letting your users execute arbitrary SQL?

Most of the time, the latter is a vulnerability in and of itself.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Vladimir Barbu]

Hi,

This vulnerability has been addressed in SQLite 3.26.0. When could we expect 
new version (official) of System.Data.SQLite which uses 3.26.0?


---
Vladimir
   



-Original Message-
From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On 
Behalf Of Keith Medcalf
Sent: Friday, December 21, 2018 06:45
To: SQLite mailing list 
Subject: Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?


Only if the application were so badly written as to permit the execution of 
untrusted code ...


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users- 
>boun...@mailinglists.sqlite.org] On Behalf Of Jens Alfke
>Sent: Thursday, 20 December, 2018 18:56
>To: SQLite mailing list
>Subject: Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?
>
>
>
>> On Dec 20, 2018, at 5:05 PM, Simon Slavin 
>wrote:
>>
>> Which would make it do what ?  I can imagine "crash with a memory
>fault".  I find it much harder to believe "execute code stored in the 
>database".  You would have to know a lot about a program to make it do 
>that, and an attack aimed at one program/library (e.g. Chromium) 
>wouldn't work on another with a different memory layout.
>
>It depends on the details of the vulnerability. Since it’s an FTS3 
>query that triggered the problem, there are probably multiple FTS3 and 
>SQLite stack frames active at the time the buffer overrun occurs, so it 
>may not depend so much on the application itself. (Of course it would 
>likely depend on the compiler, the optimization settings, and of course 
>CPU architecture.)
>
>Again, from Dr. Hipp’s statement:
>   By making malicious changes to the shadow tables that FTS3 uses and 
>then running
>   FTS3 queries that used those tables, an integer overflow could cause a
>   buffer overrun, which if carefully managed might lead to an RCE.
>   This is only a problem for application that enable FTS3 (using the
>   SQLITE_ENABLE_FTS3 or SQLITE_ENABLE_FTS4 compile-time options) and
>   which allow potential attackers to run arbitrary SQL.
>
>Anyway, my original question was: If an application opens untrusted 
>SQLite databases as documents, and if a trigger added to a database can 
>run arbitrary SQL, wouldn’t that make such an application vulnerable?
>
>—Jens
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Keith Medcalf]

Only if the application were so badly written as to permit the execution of 
untrusted code ...


---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Jens Alfke
>Sent: Thursday, 20 December, 2018 18:56
>To: SQLite mailing list
>Subject: Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?
>
>
>
>> On Dec 20, 2018, at 5:05 PM, Simon Slavin 
>wrote:
>>
>> Which would make it do what ?  I can imagine "crash with a memory
>fault".  I find it much harder to believe "execute code stored in the
>database".  You would have to know a lot about a program to make it
>do that, and an attack aimed at one program/library (e.g. Chromium)
>wouldn't work on another with a different memory layout.
>
>It depends on the details of the vulnerability. Since it’s an FTS3
>query that triggered the problem, there are probably multiple FTS3
>and SQLite stack frames active at the time the buffer overrun occurs,
>so it may not depend so much on the application itself. (Of course it
>would likely depend on the compiler, the optimization settings, and
>of course CPU architecture.)
>
>Again, from Dr. Hipp’s statement:
>   By making malicious changes to the shadow tables that FTS3 uses
>and then running
>   FTS3 queries that used those tables, an integer overflow could
>cause a
>   buffer overrun, which if carefully managed might lead to an RCE.
>   This is only a problem for application that enable FTS3 (using
>the
>   SQLITE_ENABLE_FTS3 or SQLITE_ENABLE_FTS4 compile-time options)
>and
>   which allow potential attackers to run arbitrary SQL.
>
>Anyway, my original question was: If an application opens untrusted
>SQLite databases as documents, and if a trigger added to a database
>can run arbitrary SQL, wouldn’t that make such an application
>vulnerable?
>
>—Jens
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 20, 2018, at 5:05 PM, Simon Slavin  wrote:
> 
> Which would make it do what ?  I can imagine "crash with a memory fault".  I 
> find it much harder to believe "execute code stored in the database".  You 
> would have to know a lot about a program to make it do that, and an attack 
> aimed at one program/library (e.g. Chromium) wouldn't work on another with a 
> different memory layout.

It depends on the details of the vulnerability. Since it’s an FTS3 query that 
triggered the problem, there are probably multiple FTS3 and SQLite stack frames 
active at the time the buffer overrun occurs, so it may not depend so much on 
the application itself. (Of course it would likely depend on the compiler, the 
optimization settings, and of course CPU architecture.)

Again, from Dr. Hipp’s statement:
By making malicious changes to the shadow tables that FTS3 uses and 
then running
FTS3 queries that used those tables, an integer overflow could cause a
buffer overrun, which if carefully managed might lead to an RCE.
This is only a problem for application that enable FTS3 (using the
SQLITE_ENABLE_FTS3 or SQLITE_ENABLE_FTS4 compile-time options) and
which allow potential attackers to run arbitrary SQL.

Anyway, my original question was: If an application opens untrusted SQLite 
databases as documents, and if a trigger added to a database can run arbitrary 
SQL, wouldn’t that make such an application vulnerable?

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Richard Hipp]

On 12/20/18, Peter da Silva  wrote:
> Sqlite is explicitly not designed to be secure
> against untrusted input or corrupt .

This is, perhaps, originally true.  But in more recent years we have
learned that people feed all kinds of malicious inputs into SQLite and
expect it to survive, and indeed to give a graceful and helpful
response.  And we are working hard to make sure that is always the
case.

As the magellan incident shows, we are not 100% there yet, but we are
getting closer every day.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Simon Slavin]

On 21 Dec 2018, at 12:40am, Jens Alfke  wrote:

> From what I’ve read, it sounds like any code using FTS3 was vulnerable to 
> maliciously crafted SQL statements messing with the shadow tables.

Which would make it do what ?  I can imagine "crash with a memory fault".  I 
find it much harder to believe "execute code stored in the database".  You 
would have to know a lot about a program to make it do that, and an attack 
aimed at one program/library (e.g. Chromium) wouldn't work on another with a 
different memory layout.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 20, 2018, at 4:46 PM, Peter da Silva  wrote:
> 
> Sqlite is explicitly not designed to be secure against untrusted input or 
> corrupt .

That was true a couple of years ago, but SQLite has been hardened since, mostly 
because of problems in Chromium.

"SQLite should never crash, overflow a buffer, leak memory, or exhibit any 
other harmful behavior, even with presented with maliciously malformed SQL 
inputs or database files. SQLite should always detect erroneous inputs and 
raise an error, not crash or corrupt memory. Any malfunction caused by an SQL 
input or database file is considered a serious bug and will be promptly 
addressed when brought to the attention of the SQLite developers. SQLite is 
extensively fuzz-tested to help ensure that it is resistant to these kinds of 
errors.”
https://www.sqlite.org/security.html

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

Programs that were written defensively from the start are more likely to
survive attack. Programs that have successfully been exposed to attack can
be treated as more secure. Sqlite is explicitly not designed to be secure
against untrusted input or corrupt .

This is OK. It's not a program that would be expected to be designed to be
secure against these kinds of attacks. It just means that you don't expose
it to untrusted input, like it's a shell or compiler or something.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 20, 2018, at 9:34 AM, Simon Slavin  wrote:
> 
> Yes, but you can't program the program which accesses the SQLite API. Your 
> app, or my app, retrieving that BLOB, wouldn't necessarily try to execute it, 
> or store the BLOB in exactly the right place in memory for it to do something 
> malicious.

Are you saying the exploit depends on something very specific that Chromium 
does in its SQLite API calls, which no other app would do? 

From what I’ve read, it sounds like any code using FTS3 was vulnerable to 
maliciously crafted SQL statements messing with the shadow tables.

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 20, 2018, at 9:30 AM, Peter da Silva  wrote:
> 
> Fuzz testing would be extremely unlikely to have caught the original
> attack. Nor would fuzz testing on input be likely to hit all corrupt
> database attacks. Fuzz testing using fuzzed corrupted databases might.

OK, but by those criteria, _no_ program is "immune to wandering through bad 
pointers”*, since no testing is 100.00% perfect, so I don’t know what your 
original point was…

—Jens

* Programs in ‘safe’ languages aren’t immune, because the interpreter/virtual 
machine/compiler that provides the safety isn’t immune to pointer bugs, by the 
same reasoning.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Simon Slavin]

On 20 Dec 2018, at 5:27pm, Jens Alfke  wrote:

> On Dec 19, 2018, at 10:32 AM, Simon Slavin  wrote:
> 
>> I'm not sure how you would do that purely inside a trigger.  You can't just 
>> specially craft a BLOB with bad content.  I think it would need 
>> participation from the software making the call to the API.
> 
> Can’t you put [nearly] any SQL statement in the body of a trigger? Including 
> one with an x’…’ blob literal?

Yes, but you can't program the program which accesses the SQLite API. Your app, 
or my app, retrieving that BLOB, wouldn't necessarily try to execute it, or 
store the BLOB in exactly the right place in memory for it to do something 
malicious.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

Fuzz testing would be extremely unlikely to have caught the original
attack. Nor would fuzz testing on input be likely to hit all corrupt
database attacks. Fuzz testing using fuzzed corrupted databases might.

On Thu., 20 Dec. 2018, 11:26 Jens Alfke 
>
> > On Dec 19, 2018, at 4:03 PM, Peter da Silva  wrote:
> >
> > sqlite is not immune to wandering through bad pointers, because code
> > coverage tests don't test for malicious data..
>
> Fuzz testing does, though [implicitly].
>
> https://www.sqlite.org/testing.html#sql_fuzz_using_the_american_fuzzy_lop_fuzzer
>
> —Jens
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 19, 2018, at 10:32 AM, Simon Slavin  wrote:
> 
> I'm not sure how you would do that purely inside a trigger.  You can't just 
> specially craft a BLOB with bad content.  I think it would need participation 
> from the software making the call to the API.

Can’t you put [nearly] any SQL statement in the body of a trigger? Including 
one with an x’…’ blob literal?

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 19, 2018, at 4:03 PM, Peter da Silva  wrote:
> 
> sqlite is not immune to wandering through bad pointers, because code
> coverage tests don't test for malicious data..

Fuzz testing does, though [implicitly]. 
https://www.sqlite.org/testing.html#sql_fuzz_using_the_american_fuzzy_lop_fuzzer

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

sqlite is not immune to wandering through bad pointers, because code
coverage tests don't test for malicious data... I found a null pointer
crash in sqlite earlier this year. I could see Mallory crafting a database
that had carefully corrupted structures in it that smashed the stack.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Simon Slavin]

On 19 Dec 2018, at 6:19pm, Jens Alfke  wrote:

> 2. Mallory uses something like the ’sqlite3’ tool to open the database and 
> execute a CREATE TRIGGER statement whose trigger SQL exploits a vulnerability 
> to do something nasty like remote code execution.

I'm not sure how you would do that purely inside a trigger.  You can't just 
specially craft a BLOB with bad content.  I think it would need participation 
from the software making the call to the API.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Jens Alfke]

> On Dec 18, 2018, at 2:13 PM, Richard Hipp  wrote:
> 
> I am not aware of any other applications that deliberately run SQL
> from anonymous sources

In applications that use SQLite databases as a file format, couldn’t a 
malicious document be created that uses a trigger to run SQL that triggers an 
exploit when the document/database is edited? In other words:

1. Mallory creates or obtains some innocuous document.
2. Mallory uses something like the ’sqlite3’ tool to open the database and 
execute a CREATE TRIGGER statement whose trigger SQL exploits a vulnerability 
to do something nasty like remote code execution.
3. Mallory passes the document to Alice.
4. Alice opens the document and makes a change that causes SQLite to update a 
table in a way that activates the trigger.
5. The malicious SQL runs in the application process on Alice’s computer and 
does its business.

—Jens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Dominique Devienne]

On Wed, Dec 19, 2018 at 11:14 AM Richard Hipp  wrote:

> > Could there be a way to make shadow tables off-limit to arbitrary SQL?
>
> That is one of the things that the new SQLITE_DBCONFIG_DEFENSIVE
> option does - it makes shadow tables read-only so that they cannot be
> corrupted by SQL.
>

May I please know how SQLite knows a table is a shadow table?
This is not something I've run across yet. Good to know BTW, of course.
Thanks.

Not knowing how this is done/known, I wonder whether this applies to other
"bits" of information about tables, notably "custom" ones from a given
application.
(answers seems to be no, given what's below).

Ah, I googled SQLITE_DBCONFIG_DEFENSIVE and found the 3.26 release notes,
which pointed me to [1] and then [2]. I had missed [2]. Sending anyway,
might be
useful to someone else too.

[1]
https://www.sqlite.org/draft/c3ref/c_dbconfig_defensive.html#sqlitedbconfigdefensive
[2] https://www.sqlite.org/draft/vtab.html#xshadowname


> However, it is off by default, since some application make use of the
> ability to write directly into shadow tables.  For example, when you
> restore a database using the output of the ".dump" command, that
> requires writing directly into shadow tables.
>

Good point. Didn't think of that. Thanks again, --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Richard Hipp]

>
> Could there be a way to make shadow tables off-limit to arbitrary SQL?

That is one of the things that the new SQLITE_DBCONFIG_DEFENSIVE
option does - it makes shadow tables read-only so that they cannot be
corrupted by SQL.

However, it is off by default, since some application make use of the
ability to write directly into shadow tables.  For example, when you
restore a database using the output of the ".dump" command, that
requires writing directly into shadow tables.


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Dominique Devienne]

On Tue, Dec 18, 2018 at 11:13 PM Richard Hipp  wrote:

> On 12/18/18, Dominique Devienne  wrote:
> > https://blade.tencent.com/magellan/index_en.html
> >
> > Sounds to me it's more related to a "remote callable" program like
> Chrome,
> > than SQLite proper, but I'd like an official stance on SQLite itself
> please.
>
> There was a bug in FTS3 (not in the SQLite core) that allowed an SQL
> Injection to escalate into a Remote Code Execution (RCE).


Thanks. Good to know. Understanding how it happened is as important
as knowing this is fixed in SQLite already (in due time of course, when it's
"safe" to share information). Much appreciated.


> By making malicious changes to the shadow tables that FTS3 uses and then
> running
> FTS3 queries that used those tables, an integer overflow could cause a
> buffer overrun, which if carefully managed might lead to an RCE.

[... more details]

We are hard at work on additional defense-in-depth measures now.
>

Could there be a way to make shadow tables off-limit to arbitrary SQL?
By explicitly taking them as such, and creating them with a "secret"
associated
to them, so that preparing a statement against them also needs that
"secret"?
The goal being to restrict access to those tables to only the
vtable-related code
that is the "front-end" to those shadow tables. Only that code should have
direct
access to those tables, at least on the write-side of them.

I understand that they are persistent, so what would be relatively "easy"
to do
at runtime for the connection, becomes harder w/o changing the file-format
or
introducing new sqlite_... reserved tables older versions of SQLite would
ignore.

I hope you can think of ways to persist more meta-data about tables in
general,
be it that FKs should be enforced by default on them when new connections
are
created by them, or to persist the fact a table is a shadow tables
associated to a
given virtual-table module, such that only that module (somehow) can write
them.

My $0.02. --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Keith Medcalf]

On Tuesday, 18 December, 2018 14:50, Nathan Green  wrote:

>Except the problem isn't just in Chrome. Apparently, any system that
>allows SQL injection is vulnerable. Since SQLite can be used as a file
>format to transport application data 
>(https://www.sqlite.org/appfileformat.html),
>other applications might be also be vulnerable. It's not hard to
>conceive of exploiting an application with a "restore from backup" 
>feature.

But this is not an SQLite3 problem.  This is a crap design of the application 
problem as the precondition "any system that allows SQL injection is 
vulnerable" is an absolute requirement.  If you prohibit that precondition, the 
issue cannot exist (though I suppose it would be possible for a malicious 
application to deliberately send malicious SQL, but again, this is an 
application problem, not an SQLite3 problem).

>How "remote" the RCE is depends on the application architecture. I'm
>thankful that SQLite works really well for my use cases, and also that I have
>sandboxed all of my code to run in unprivileged accounts.

Allāhu Akbar!  (Facing north cuz, well, some other people failed spherical 
geometry in grade school)

Hanging curtains (and closing them) on the bedroom windows to prevent the 
neighbours over the way from peeping in through the one-way glass and taking 
pictures of your naughty bits is the prudent thing to do.  You can giggle and 
"move along, nothing to see here" when the peeper over the way puts pictures of 
your neighbour in the local newspaper because he believed the glass vendors 
claim of the one-way-ness of the glazing and ignore all the kerfufle that 
ensues (with a nice glass of single malt and a bag of popcorn).

I have been told that it is "not fair" to implement proper security and protect 
oneself in advance and that one should follow the "Best Practice" and view the 
world though the fog of short-sightedness so induced in such a manner as to 
create the most "Oh Shit" moments possible and to avoid giggling when something 
that cannot possibly affect me affects my lesser prepared neighbours ...
 
---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.





___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Richard Hipp]

On 12/18/18, Dominique Devienne  wrote:
> https://blade.tencent.com/magellan/index_en.html
>
> Sounds to me it more related to a "remote callable" program like Chrome,
> than SQLite proper, but I'd like an official stance on SQLite itself please.
>

There was a bug in FTS3 (not in the SQLite core) that allowed an SQL
Injection to escalate into a Remote Code Execution (RCE).  By making
malicious changes to the shadow tables that FTS3 uses and then running
FTS3 queries that used those tables, an integer overflow could cause a
buffer overrun, which if carefully managed might lead to an RCE.

This is only a problem for application that enable FTS3 (using the
SQLITE_ENABLE_FTS3 or SQLITE_ENABLE_FTS4 compile-time options) and
which allow potential attackers to run arbitrary SQL.  Contrary to
published reports, there are probably *not* millions of application
that meet those circumstances.  In fact, I only know of one:  Chrome.
Chrome has FTS3 enabled, and allows arbitrary SQL through the WebSQL
interface.  On the other hand, Chrome only allows this within a
sandbox, so as far as I know, the problem did not lead to an exploit
even in Chrome.  Perhaps there were other techniques used for escaping
the sandbox after executing the RCE against FTS3, but if not then the
attack against Chrome was also benign, as far as I know.

I believe that Safari also enables WebSQL, but unless I am mistaken,
Safari has disabled FTS3 and so it is probably not vulnerable.

The Fossil Version Control System can be configured to allow anonymous
users to enter SQL to generate bug-report summaries.  However, that
SQL is very restricted.  Only SELECT statements are allowed, and they
are only allowed to access specific tables.  So Fossil is not
vulnerable.

I am not aware of any other applications that deliberately run SQL
from anonymous sources

In any application that enables FTS3 and also has an SQL Injection
bugs, the magellan problem allows those SQL Injection bugs to escalate
to an RCE bug.   And so, the FTS3 bug makes a preexisting SQL
Injection bug worse, but does not introduce any new bugs.

The bug in FTS3 was fixed in version 3.26.0.  So if you are using
SQLite 3.26.0, then you are not vulnerable to this RCE even if you do
enable FTS3 and do allow SQL Injections.

Our policy with respect to bugs is to try to not only fix the bug, but
also fix the process.  Hence, when this issue was discovered in FTS3,
we tried to figure out what we could have done differently from the
beginning to have prevented this bug in the first place, and what we
could do differently moving forward to prevent future similar bugs.
As part of that analysis, we came up with the new
SQLITE_DBCONFIG_DEFENSIVE option.  Applications that do deliberately
allow anonymously-sourced SQL can enable SQLITE_DBCONFIG_DEFENSIVE to
prevent the SQL from deliberately corrupting the database file.  By
preventing corrupt database files, the attack surface is reduced.  Had
this option been available before Magellan, and had Chrome used it
(the latest Chrome releases *do* use it, I am told) then the Magellan
bug would have never happened.  But SQLITE_DBCONFIG_DEFENSIVE is not
the "fix" for the bug.  It is defense-in-depth against similar future
bugs.

We are hard at work on additional defense-in-depth measures now.  I do
not know of any other exploits against FTS3 or SQLite or any other
common SQLite extensions.  But we are working to make sure no new ones
are discovered.

-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Nathan Green]

On Tue, Dec 18, 2018 at 4:00 PM Peter da Silva  wrote:

> On Tue, Dec 18, 2018 at 3:49 PM Nathan Green  wrote:
>
> > Except the problem isn't just in Chrome. Apparently, any system that
> allows
> > SQL injection is vulnerable.
> >
>
> That's kind of a tautology isn't it? Isn't there some kind of Godwin's Law
> variant for XKCD 327?
>
> I notice that the 12 points on https://www.sqlite.org/appfileformat.html
> don't include "secure".
>
> I mean, sure, we used to distribute software on Usenet as shell scripts
> (look up "shar archive") but it's not 1984 any more.
>
>
SQL injection in the generic sense isn't exactly RCE because SQL is
declarative. Arbitrarily messing up things in a database is not the same as
running any executable code that the database process might have permission
to execute.

Nathan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

On Tue, Dec 18, 2018 at 3:49 PM Nathan Green  wrote:

> Except the problem isn't just in Chrome. Apparently, any system that allows
> SQL injection is vulnerable.
>

That's kind of a tautology isn't it? Isn't there some kind of Godwin's Law
variant for XKCD 327?

I notice that the 12 points on https://www.sqlite.org/appfileformat.html
don't include "secure".

I mean, sure, we used to distribute software on Usenet as shell scripts
(look up "shar archive") but it's not 1984 any more.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Nathan Green]

On Tue, Dec 18, 2018 at 3:14 PM Simon Slavin  wrote:

> On 18 Dec 2018, at 9:00pm, Peter da Silva  wrote:
>
> > I have to say I'm pretty boggled that Chrome allows hostile users to
> feed code directly into an SQL interpreter that wasn't written from the
> ground up to be secure.
>
> Chrome has problems far more serious than that.  And one can do all sorts
> of nasty things in Chrome extensions.  It's difficult for the developers of
> Chrome to both prevent exploits by webmaster and extension writers, and
> also allow those people to do wonderful, entirely legitimate, things.  At
> the level of making an API call it's not possible for the called function
> to work out whether it's being used legitimately or not without a lot of
> extra processing which would make it so slow nobody would use it.
>
> The tencent.com report is not entirely straightforward about precisely
> where the problem lies, and what an exploit could do.  It would be just as
> useful a report if it mentioned the problem in Chrome and avoided all
> mention of SQLite.  And implying that SQLite ever had a remote code
> execution problem is incorrect.
>
> Simon.
>
>
Except the problem isn't just in Chrome. Apparently, any system that allows
SQL injection is vulnerable. Since SQLite can be used as a file format to
transport application data (https://www.sqlite.org/appfileformat.html),
other applications might be also be vulnerable. It's not hard to conceive
of exploiting an application with a "restore from backup" feature. How
"remote" the RCE is depends on the application architecture. I'm thankful
that SQLite works really well for my use cases, and also that I have
sandboxed all of my code to run in unprivileged accounts.

Nathan
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

Javascript was designed from the start to safely execute malicious code.
That doesn't mean it is safe, it just means it might be. There have been
all kinds of javascript-based exploits, after all.

But an interpreter that was not originally designed to be safe in the face
of malicious code? I can't understand the confusion in the mind that would
lead one to expect miracles of it. This is not a criticism of sqlite, by
any means. Safe languages are rare.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Keith Medcalf]

Why shocked?  

Chrome allows direct execution of untrusted and likely malicious code that it 
gets over the network.  It is called JavaScript.  That a new method for 
execution of untrusted remote malicious code has been created is completely 
unsurprising since the whole point of Chrome is to permit local execution of 
remotely obtained and possibly malicious code.

---
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.

>-Original Message-
>From: sqlite-users [mailto:sqlite-users-
>boun...@mailinglists.sqlite.org] On Behalf Of Peter da Silva
>Sent: Tuesday, 18 December, 2018 14:00
>To: SQLite mailing list
>Subject: Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?
>
>I have to say I'm pretty boggled that Chrome allows hostile users to
>feed
>code directly into an SQL interpreter that wasn't written from the
>ground
>up to be secure. Secure interpreters are *hard* even when you're
>designing
>them from scratch (see also, the whole history of web-based
>vulnerabilities). That seems to be dancing with the screwup fairy to
>me.
>___
>sqlite-users mailing list
>sqlite-users@mailinglists.sqlite.org
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users



___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Simon Slavin]

On 18 Dec 2018, at 9:00pm, Peter da Silva  wrote:

> I have to say I'm pretty boggled that Chrome allows hostile users to feed 
> code directly into an SQL interpreter that wasn't written from the ground up 
> to be secure.

Chrome has problems far more serious than that.  And one can do all sorts of 
nasty things in Chrome extensions.  It's difficult for the developers of Chrome 
to both prevent exploits by webmaster and extension writers, and also allow 
those people to do wonderful, entirely legitimate, things.  At the level of 
making an API call it's not possible for the called function to work out 
whether it's being used legitimately or not without a lot of extra processing 
which would make it so slow nobody would use it.

The tencent.com report is not entirely straightforward about precisely where 
the problem lies, and what an exploit could do.  It would be just as useful a 
report if it mentioned the problem in Chrome and avoided all mention of SQLite. 
 And implying that SQLite ever had a remote code execution problem is incorrect.

Simon.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Peter da Silva]

I have to say I'm pretty boggled that Chrome allows hostile users to feed
code directly into an SQL interpreter that wasn't written from the ground
up to be secure. Secure interpreters are *hard* even when you're designing
them from scratch (see also, the whole history of web-based
vulnerabilities). That seems to be dancing with the screwup fairy to me.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Clemens Ladisch]

Dominique Devienne wrote:
> I'd like an official stance on SQLite itself please.




Regards,
Clemens
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Claimed vulnerability in SQLite: Info or Intox?

[Dominique Devienne]

https://blade.tencent.com/magellan/index_en.html

Sounds to me it more related to a "remote callable" program like Chrome,
than SQLite proper, but I'd like an official stance on SQLite itself please.

Thanks, --DD
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users