On Tue, Dec 18, 2018 at 3:14 PM Simon Slavin <slav...@bigfraud.org> wrote:
> On 18 Dec 2018, at 9:00pm, Peter da Silva <res...@gmail.com> 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 > of nasty things in Chrome extensions. It's difficult for the developers of > Chrome to both prevent exploits by webmaster and extension writers, and > also allow those people to do wonderful, entirely legitimate, things. At > the level of making an API call it's not possible for the called function > to work out whether it's being used legitimately or not without a lot of > extra processing which would make it so slow nobody would use it. > > The tencent.com report is not entirely straightforward about precisely > where the problem lies, and what an exploit could do. It would be just as > useful a report if it mentioned the problem in Chrome and avoided all > mention of SQLite. And implying that SQLite ever had a remote code > execution problem is incorrect. > > Simon. > > 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 applications might be also be vulnerable. It's not hard to conceive of exploiting an application with a "restore from backup" feature. How "remote" the RCE is depends on the application architecture. I'm thankful that SQLite works really well for my use cases, and also that I have sandboxed all of my code to run in unprivileged accounts. Nathan _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
