You have far more security vulnerabilities inherent in the (quite often 
mis-)design of the operating system, development tools and libraries; and 
idiotic decisions made by application designers themselves.  You don't want to 
put the cart in front of the horse.  Compromise in your (briefly stated) 
scenario is most likely via the vector of code injection into shared load 
library text (code) segments, including injection directly in the Operating 
System discontiguous saved segment itself.  Some Operating Systems (such as any 
version of Microsoft Windows) cannot be protected from these sorts of attacks, 
so if you are running Windows, then you probability of compromise is 100%, and 
the estimated lifetime of your "security barrier" is zero.  Your only 
mitigation measures are external.

Other Operating Systems have similar vulnerabilities that are varyingly more 
difficult to exploit.

Your question has nothing to do with SQLite but rather requires addressing the 
inherent design of your chosen Operating System, your Application, and the 
toolchains you choose to use to convert the human-readable expressions thereof 
into code executable in silicon.

---
()  ascii ribbon campaign against html e-mail
/\  www.asciiribbon.org


> -----Original Message-----
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Toby Dickenson
> Sent: Friday, 14 June, 2013 04:18
> To: sqlite-users@sqlite.org
> Subject: [sqlite] sqlite security
> 
> Hi all,
> 
> I have a question about security considerations for using sqlite.
> 
> Suppose I have two processes which communicate via a shared database.
> One process is internet-facing, and therefore carries a risk of being
> compromised. The second process is running under a different uid, and
> has access to other files which should be kept private. The database
> is a trust boundary.
> 
> 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.
> Obviously there is a need for both applications to handle the data
> retrieved from that database in a secure manner, but are there other
> risks/considerations from the sqlite library itself?
> 
> There are some obvious and maybe unavoidable denial-of-service risks:
> the first process might fill up the disk, or (Im guessing here) hold
> onto locks for too long. Any other considerations?
> 
> Thanks in advance,
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users



_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to