On 6/14/2013 7:39 AM, Simon Slavin wrote:
On 14 Jun 2013, at 11:18am, Toby Dickenson <t...@tarind.com> wrote:
To what extent is this IPC mechanism a risk of privilege escalation,
whereby any malicious code injected into the first process might be
able to use the shared database to attack the second process.
The SQLite library does not store low-level executable code in any database
file, nor does it execute any code found in a database file. Putting
executable code in a SQLite database (presumably as a BLOB) does nothing unless
you have specially written your program to retrieve a BLOB, put it into memory
and execute it. Don’t do that. Unless you have a good reason to.
I'd be thinking of a different attack. Imagine there's a bug in SQLite
library itself - say, a buffer overrun - that manifests when handling a
malformed database file. The compromised process wouldn't use SQLite to
manipulate the database (create triggers or what not) but would write to
the file directly to craft a malformed database file specifically
designed to exploit that bug. When the second process opens the
database, it would trigger the exploit, whose effects would range from
denial of service at best (the second process simply crashes) to
arbitrary code execution/privilege escalation at worst.
And of course, the compromised process could simply wipe the database
(data loss, denial of service), write wrong data to the database (data
poisoning), and/or send it to some third party (information disclosure).
--
Igor Tandetnik
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
