date:20170417

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Saurav Sarkar

Thanks Simon for the reply.

Can you please also let me know how this bug can be exploited in an
application.

I am just using Android API (SQLiteOpenHelper) for SQLite to access
SQLiteDB CRUD operations.

We don't have authorization feature built into our client side. Even
authentication is done from the server side.
End Users don't have access to db directly. No SQL injection is possible
too.

Just wanted to check if this bug can be exploited in our application.

Best Regards,
Saurav

On Mon, Apr 17, 2017 at 2:46 PM, Simon Slavin  wrote:

>
> On 17 Apr 2017, at 9:56am, Saurav Sarkar  wrote:
>
> > http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6607
> >
> > It mentions the escalation of privilege attack in Android due to an
> > internal bug in SQlite
> >
> > We use SQLite distributed with Android in our application and use the
> > normal Android APIs for SQLite Access .And use it for our CRUD
> operations.
> >
> > I did not find any more details about this bug so would like to know in
> > this list if this is a problem.
>
> SQLite 3.8.9, which according to the announcement fixed the relevant bug,
> was released in April 2015, which is now two years ago.
>
> As described in the report, if you’re still using a version of Android
> before 5.1.1 the bug will still effect the platform.
>
> > Would like to know if the same vulnerability applies for Windows
> universal
> > platform as well.
>
> SQLite is not built into that platform.  If you wish to use SQLite on WUP
> yourself, just make sure you include a current version, not a two year old
> version.
>
> Simon.
> ___
> 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] strange behaviour on sqlite shell output…

2017-04-17 Thread aotto


Am 17.04.2017 um 10:26 schrieb aotto:

Am 15.04.2017 um 09:49 schrieb aotto:
select Reporter, Partner, Year, PartnerCode from [EXEC-BtH0] where 
Reporter = 'AGO'


Hi,

I add the following code in shell.c
if( w<0 ){
  utf8_printf(p->out,"%*.*s%s",-w,-w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
}else{
  utf8_printf(p->out,"%-*.*s%s",w,w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
printC(azArg[i])
}
using "printC" (this is a macro end op with…
→ #define printC(var) MVP(MQ_FORMAT_C,var)
> #define MVP(f,v) fprintf(MQ_OUT,"%s(%s:%d:%d) -> %p:" #v "<" f 
">\n", __func__, __FILE__, __LINE__, mq_getpid(), \

  v,v);fflush(MQ_OUT);
→#define MQ_OUT p->out
→ is is just a "fprintf"…

I get the following lines…

AGO shell_callback(shell.c:1094:1) -> 0xa0b9c0:azArg[i]
AUT shell_callback(shell.c:1094:1) -> 0x9e7f88:azArg[i]
2000shell_callback(shell.c:1094:1) -> 0x5a9de78:azArg[i]<2000>
EO EU WE 342202
shell_callback(shell.c:1094:1) -> 0x9e7fab:azArg[i]
AGO shell_callback(shell.c:1094:1) -> 0xa0b9c0:azArg[i]
AUT shell_callback(shell.c:1094:1) -> 0x9e7f88:azArg[i]
2001shell_callback(shell.c:1094:1) -> 0x5a9de78:azArg[i]<2001>
EO EU WE 342202
shell_callback(shell.c:1094:1) -> 0x9e7fab:azArg[i]

summary: the default "fprintf" write the right "€" sign and the sqlite 
"utf8_printf"

seems to do something wrong.


mfg ao.

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



additional info… this is the code AFTER preprocessing…

  for(i=0; iactualWidth)/sizeof(p->actualWidth[0])) ){
   w = p->actualWidth[i];
}else{
   w = 10;
}
if( p->cMode==9 && azArg[i] && strlen30(azArg[i])>w ){
  w = strlen30(azArg[i]);
}
if( i==1 && p->aiIndent && p->pStmt ){
  if( p->iIndentnIndent ){
fprintf(p->out, "%*.s", p->aiIndent[p->iIndent], "");
  }
  p->iIndent++;
}
if( w<0 ){
  fprintf(p->out,"%*.*s%s",-w,-w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
}else{
  fprintf(p->out,"%-*.*s%s",w,w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
fprintf(p->out,"%s(%s:%d:%d) -> %p:" "azArg[i]" "<" "%s" ">\n", 
__func__, "shell.c", 1094, 1, azArg[i],azArg[i]);fflush(p->out);

}
  }

mfg a.o

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

[sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Saurav Sarkar

Dear SQLite Experts,

This is regarding SQlite vulnerability

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6607

It mentions the escalation of privilege attack in Android due to an
internal bug in SQlite

We use SQLite distributed with Android in our application and use the
normal Android APIs for SQLite Access .And use it for our CRUD operations.

I did not find any more details about this bug so would like to know in
this list if this is a problem.

Also we have a Universal Windows platform based application where we use
SQLite as external dependency and use for same CRUD operations.

Would like to know if the same vulnerability applies for Windows universal
platform as well.

Thanks and Best Regards,
Saurav
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] strange behaviour on sqlite shell output…

2017-04-17 Thread aotto


Am 15.04.2017 um 09:49 schrieb aotto:
select Reporter, Partner, Year, PartnerCode from [EXEC-BtH0] where 
Reporter = 'AGO'


Hi,

I add the following code in shell.c
if( w<0 ){
  utf8_printf(p->out,"%*.*s%s",-w,-w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
}else{
  utf8_printf(p->out,"%-*.*s%s",w,w,
  azArg[i] ? azArg[i] : p->nullValue,
  i==nArg-1 ? rowSep : "  ");
printC(azArg[i])
}
using "printC" (this is a macro end op with…
→ #define printC(var) MVP(MQ_FORMAT_C,var)
> #define MVP(f,v) fprintf(MQ_OUT,"%s(%s:%d:%d) -> %p:" #v "<" f ">\n", 
__func__, __FILE__, __LINE__, mq_getpid(), \

  v,v);fflush(MQ_OUT);
→#define MQ_OUT p->out
→ is is just a "fprintf"…

I get the following lines…

AGO shell_callback(shell.c:1094:1) -> 0xa0b9c0:azArg[i]
AUT shell_callback(shell.c:1094:1) -> 0x9e7f88:azArg[i]
2000shell_callback(shell.c:1094:1) -> 0x5a9de78:azArg[i]<2000>
EO EU WE 342202
shell_callback(shell.c:1094:1) -> 0x9e7fab:azArg[i]
AGO shell_callback(shell.c:1094:1) -> 0xa0b9c0:azArg[i]
AUT shell_callback(shell.c:1094:1) -> 0x9e7f88:azArg[i]
2001shell_callback(shell.c:1094:1) -> 0x5a9de78:azArg[i]<2001>
EO EU WE 342202
shell_callback(shell.c:1094:1) -> 0x9e7fab:azArg[i]

summary: the default "fprintf" write the right "€" sign and the sqlite 
"utf8_printf"

seems to do something wrong.


mfg ao.

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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Simon Slavin

On 17 Apr 2017, at 9:56am, Saurav Sarkar  wrote:

> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6607
> 
> It mentions the escalation of privilege attack in Android due to an
> internal bug in SQlite
> 
> We use SQLite distributed with Android in our application and use the
> normal Android APIs for SQLite Access .And use it for our CRUD operations.
> 
> I did not find any more details about this bug so would like to know in
> this list if this is a problem.

SQLite 3.8.9, which according to the announcement fixed the relevant bug, was 
released in April 2015, which is now two years ago.

As described in the report, if you’re still using a version of Android before 
5.1.1 the bug will still effect the platform.

> Would like to know if the same vulnerability applies for Windows universal
> platform as well.

SQLite is not built into that platform.  If you wish to use SQLite on WUP 
yourself, just make sure you include a current version, not a two year old 
version.

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

Re: [sqlite] strange behaviour on sqlite shell output…

2017-04-17 Thread aotto


Am 17.04.2017 um 10:34 schrieb aotto:
………
This is the isolated test case this shows the BUG

#include "stdio.h"

int
main ( int argc, char **argv ) {
 // code

int i=3;
int w=11; // → ??
int nArg=4;
char *rowSep="\n";
char *azArg[4]  = {NULL,NULL,NULL,"EO EU WE €O $H"};

fprintf(stdout,"%-*.*s%s",w,w,
  azArg[i] ? azArg[i] : NULL,
i==nArg-1 ? rowSep : "  ");

 return 0; // Indicates that everything went well.
}


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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Richard Hipp

On 4/17/17, Saurav Sarkar  wrote:
> Dear SQLite Experts,
>
> This is regarding SQlite vulnerability
>
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-6607

I don't know anything about this.  It is the first I've heard of it.
I could not figure out what it has to do with SQLite based on the link
above.  My assumption this is some kind of bug in the Android
interface to SQLite, not in SQLite itself.

-- 
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] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Simon Slavin

On 17 Apr 2017, at 10:35am, Saurav Sarkar  wrote:

> Can you please also let me know how this bug can be exploited in an
> application.

The problem was apparently spotted as a theoretical vulnerability and no 
demonstration code was submitted.  It was never reported to the SQLite 
development team, so the team has no record of what was wrong, what it did, or 
how to exploit it.

From what I can see, it affected only versions of Android before Android 5.1.  
It allowed an application with exploit code in, if given sufficient privilages, 
to modify certain system files.  I don’t know which files it could modify or 
what damage could be done that way.  If you can find discussion of the problem 
or demonstration code I think it would be welcome here.

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

Re: [sqlite] Database corruption, and PRAGMA fullfsync on macOS

2017-04-17 Thread Brendan Duddridge

Thanks Richard for your reply.

Sorry about the COLLATE problem. That's a Couchbase Lite thing.

I find it weird that a different WAL file is getting in there somehow when
a power failure occurs. I'm a bit stumped at how it can even write to the
file system the moment the power shuts down so I don't even understand how
the database file can get corrupted.  Unless the corruption happens when
the database file is opened up next and tries to use this improper WAL file.

In my main project I'm using SQLCipher as my SQLite layer. But in the demo
project I posted, I'm just using the built-in macOS Sierra SQLite library.
In both cases though I can cause SQLite file corruption by cutting the
power on my MacBook Pro.

I'm going to do further investigations to see if there's any misuse of
SQLite that I can find. Although the developers of Couchbase Lite are far
smarter than I and I'm sure they're doing things by the book.

Perhaps the only think I can think of that I'm doing that may be unorthodox
is by storing the SQLite files inside a macOS package. But at the unix
layer that's really just a directory, so I don't know how that could cause
a problem. Unless macOS treats the package in a way differently than a
normal folder and is causing things to get moved around or written when a
power failure occurs.

This problem has been plaguing me for quite a long time actually. I hope
that I can find a solution somehow.

Thanks,

Brendan

> I worked around the "COLLATE JSON" problem (by writing my own JSON
> collation).  That allows me to analyze your database and WAL file.
>
> It appears that the WAL file is not the correct WAL file for that
> database.  It is as if someone has taken an unrelated WAL file and
> renamed it to have the same base name as your database.  Or the other
> way around - someone has renamed your database to have the same base
> name as the WAL file.
>
> Your demonstration application does not call SQLite directly.  Instead
> it appears to use two libraries that in turn call SQLite:
> libsqlcrypt.a and the CouchbaseLite.framework.  You do not provide
> sources to these other libraries, so I am unable to deduce what they
> are doing.
>
> So, in the absence of further evidence, I am going to diagnose this as
> a misuse of SQLite by one of the two libraries that you are linking -
> probably a misuse in the form of trying to rename or unlink or
> otherwise modify the database file using ordinary operating system
> calls while a connection to the database is open.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] FTS5 query results different before/after MERGE command.

2017-04-17 Thread Dan Kennedy


On 04/18/2017 02:00 AM, Jonathan Gaillard wrote:

I have a db where I have a query returning results from something I believe is 
deleted already from a FTS5 table. This is a normal FTS5 table, not a 
contentless one so I used the normal DELETE.


Only after I run:

INSERT INTO MyFTSTable(MyFTSTable, rank) VALUES('automerge', 0);


INSERT INTO MyFTSTable(MyFTSTable, rank) VALUES('merge', 500);

Does the query then start returning the results without the deleted items.

Is this normal fts behavior?


Doesn't sound right. Can you share a database that demonstrates the problem?

Dan.


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

Re: [sqlite] potential bug

2017-04-17 Thread Dan Kennedy


On 04/17/2017 10:42 PM, Bernard Schurdevin wrote:

Hi,

I get weird results (false positive) to PRAGMA foreign_key_check on 
WITHOUT ROWID table depending on foreign key field position.


Thanks for reporting this. Should be fixed here:

  http://www.sqlite.org/src/info/690870bd7b2e607b

Dan.






Kind regards.


= 



-- tested with Window CLI, versions 3.8.5, 3.9.2, 3.14.1, 3.18.0

PRAGMA foreign_keys=ON;

-- bad case
CREATE TABLE masters_bad (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_bad (line INTEGER NOT NULL, 
quantity INTEGER NOT NULL, master INTEGER NOT NULL REFERENCES 
masters_bad(id), PRIMARY KEY(master, line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_bad (reference) VALUES ('this is a ref');
INSERT INTO details_bad (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- ok case 1 (fk in front of fields)
CREATE TABLE masters_ok1 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok1 (master INTEGER NOT NULL 
REFERENCES masters_ok1(id), line INTEGER NOT NULL, quantity INTEGER 
NOT NULL, PRIMARY KEY(master,line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok1 (reference) VALUES ('this is a ref');
INSERT INTO details_ok1 (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- ok case 2 (no more quantity field)
CREATE TABLE masters_ok2 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok2 (line INTEGER NOT NULL, master 
INTEGER NOT NULL REFERENCES masters_ok2(id), PRIMARY KEY(master, 
line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok2 (reference) VALUES ('this is a ref');
INSERT INTO details_ok2 (master, line) VALUES (last_insert_rowid(), 1);
COMMIT;

-- ok case 3 fields order changed
CREATE TABLE masters_ok3 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok3 (line INTEGER NOT NULL, master 
INTEGER NOT NULL REFERENCES masters_ok3(id), quantity INTEGER NOT 
NULL, PRIMARY KEY(master, line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok3 (reference) VALUES ('this is a ref');
INSERT INTO details_ok3 (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- checking
PRAGMA foreign_key_check;


___
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] FTS5 query results different before/after MERGE command.

2017-04-17 Thread Jonathan Gaillard

I have a db where I have a query returning results from something I believe is 
deleted already from a FTS5 table. This is a normal FTS5 table, not a 
contentless one so I used the normal DELETE.


Only after I run:

INSERT INTO MyFTSTable(MyFTSTable, rank) VALUES('automerge', 0);


INSERT INTO MyFTSTable(MyFTSTable, rank) VALUES('merge', 500);

Does the query then start returning the results without the deleted items.

Is this normal fts behavior?

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

[sqlite] potential bug

2017-04-17 Thread Bernard Schurdevin


Hi,

I get weird results (false positive) to PRAGMA foreign_key_check on 
WITHOUT ROWID table depending on foreign key field position.


Kind regards.


=

-- tested with Window CLI, versions 3.8.5, 3.9.2, 3.14.1, 3.18.0

PRAGMA foreign_keys=ON;

-- bad case
CREATE TABLE masters_bad (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_bad (line INTEGER NOT NULL, quantity 
INTEGER NOT NULL, master INTEGER NOT NULL REFERENCES masters_bad(id), 
PRIMARY KEY(master, line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_bad (reference) VALUES ('this is a ref');
INSERT INTO details_bad (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- ok case 1 (fk in front of fields)
CREATE TABLE masters_ok1 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok1 (master INTEGER NOT NULL 
REFERENCES masters_ok1(id), line INTEGER NOT NULL, quantity INTEGER NOT 
NULL, PRIMARY KEY(master,line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok1 (reference) VALUES ('this is a ref');
INSERT INTO details_ok1 (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- ok case 2 (no more quantity field)
CREATE TABLE masters_ok2 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok2 (line INTEGER NOT NULL, master 
INTEGER NOT NULL REFERENCES masters_ok2(id), PRIMARY KEY(master, line)) 
WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok2 (reference) VALUES ('this is a ref');
INSERT INTO details_ok2 (master, line) VALUES (last_insert_rowid(), 1);
COMMIT;

-- ok case 3 fields order changed
CREATE TABLE masters_ok3 (id INTEGER PRIMARY KEY AUTOINCREMENT, 
reference TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS details_ok3 (line INTEGER NOT NULL, master 
INTEGER NOT NULL REFERENCES masters_ok3(id), quantity INTEGER NOT NULL, 
PRIMARY KEY(master, line)) WITHOUT ROWID;


BEGIN;
INSERT INTO masters_ok3 (reference) VALUES ('this is a ref');
INSERT INTO details_ok3 (master, line, quantity) VALUES 
(last_insert_rowid(), 1, 999);

COMMIT;

-- checking
PRAGMA foreign_key_check;


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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Michael Falconer

Just amusing, and found while looking for above.

Researchers have disclosed a vulnerability in *Android's* SQLite that can
> leak sensitive information without an application having adequate
> privileges.
>
So when did DRH sell out to Android? :-)

From an old (2012) blog report HERE


Getting a sense that it's more about Android than sqlite, just as DRH
suggested.


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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Richard Hipp

On 4/17/17, Michael Falconer  wrote:
> These may enlighten a little..at least it appears to be related?
>
>  http://www.cvedetails.com/cve/CVE-2015-6607/
>
> IBM report 

Huh.  That's not much of a vulnerability.

If an attacker can execute arbitrary SQL (notice that they must
already be well inside the system to do this) then they can run a
query like this:

 SELECT printf('%10d', 0);

And that query does a malloc for a 1-billion-byte (plus 1) buffer in
which to write the result, which might cause problems elsewhere in the
system.  Or at least that is how I read the bug report.

We added the SQLITE_PRINTF_PRECISION_LIMIT compile-time option here
(http://sqlite.org/src/timeline?c=ecad75d69e0d5c83dd35) to deal with
that problem for the rare application that gives untrusted users the
ability to run unvetted SQL.
-- 
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] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Simon Slavin

On 17 Apr 2017, at 10:29pm, Michael Falconer  
wrote:

> From an old (2012) blog report HERE
> 

Your recent links appear to be for other problems.  This one, for instance, is 
from 2012.

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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Michael Falconer

These may enlighten a little..at least it appears to be related?

 http://www.cvedetails.com/cve/CVE-2015-6607/

IBM report 




On 17 April 2017 at 22:09, Simon Slavin  wrote:

>
> On 17 Apr 2017, at 10:35am, Saurav Sarkar 
> wrote:
>
> > Can you please also let me know how this bug can be exploited in an
> > application.
>
> The problem was apparently spotted as a theoretical vulnerability and no
> demonstration code was submitted.  It was never reported to the SQLite
> development team, so the team has no record of what was wrong, what it did,
> or how to exploit it.
>
> From what I can see, it affected only versions of Android before Android
> 5.1.  It allowed an application with exploit code in, if given sufficient
> privilages, to modify certain system files.  I don’t know which files it
> could modify or what damage could be done that way.  If you can find
> discussion of the problem or demonstration code I think it would be welcome
> here.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>



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

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

2017-04-17 Thread Richard Hipp

On 4/17/17, Simon Slavin  wrote:
>
> On 17 Apr 2017, at 10:29pm, Michael Falconer 
> wrote:
>
>> From an old (2012) blog report HERE
>> 
>
> Your recent links appear to be for other problems.  This one, for instance,
> is from 2012.

The 2012 report does not provide any details.  I have no idea what the
complaint is.

My guess is that it is another case of:  If you give untrusted users
unfettered SQL access, they can do harmful things.  My response to
this is "Duh!"

-- 
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] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] strange behaviour on sqlite shell output…

[sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] strange behaviour on sqlite shell output…

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] strange behaviour on sqlite shell output…

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] Database corruption, and PRAGMA fullfsync on macOS

Re: [sqlite] FTS5 query results different before/after MERGE command.

Re: [sqlite] potential bug

[sqlite] FTS5 query results different before/after MERGE command.

[sqlite] potential bug

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

Re: [sqlite] SQLite CVE-2015-6607 (Escalation of privilege issue )

18 matches

Site Navigation

Mail list logo

Footer information