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

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

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

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

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

...@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 co

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

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

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

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

>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: >> >&

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 >

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

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

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

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

> 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

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

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

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

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.

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

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

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

> 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

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

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

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

qlite.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 i

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

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

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

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

Dominique Devienne wrote: > I'd like an official stance on SQLite itself please. Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org