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

2019-01-29 Thread 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?

2019-01-28 Thread 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