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

Reply via email to