Luckily, any SQL we generate is done by our own developers, and runs
through QA. Not only that, we've got a guy who likes to find exploits
for our backend software.
As for 'untrusted SQL' -- if you open your databases (or our clients'
databases) to unrestricted queries, you wouldn't need a malicious use of
full-text search to ruin everybody's day ;-)
On 10/06/2017 11:42 AM, Jens Alfke wrote:
Thanks for posting this — my adaptation of that sample code in my project had
the same bug.
I’m not sure how the SQL in your application gets generated, but if you allow
untrusted SQL, it’s still possible to create a query that can cause the rank
function to crash. For example (assuming I have my SQL blob-literal syntax
correct) a call to XRank(x’77777777’). The function assumes the blob passed to
it is valid output from matchinfo, where the initial 4 bytes are an array
count; but if you pass a custom blob you can specify an overly large count that
causes the function to read past the end of the blob … probably into unmapped
address space if the count is big enough.
—Jens
_______________________________________________
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
