On Thursday, 27 July, 2017 11:03, petern <peter.nichvolo...@gmail.com> wrote:
>Richard. Were you aware of this paper? >http://www.cs.vu.nl/~herbertb/download/papers/anc_ndss17.pdf >Are you able to put two facts together? >What prevents stack busting or other code injection attacks on an >otherwise valid pseudo-null pointer by simply decoding the address >space and observing where strcmp() loads a register to one of the >pointer "keys" you've insisted be conveniently published for >hackers in the data segment? Absolutely nothing prevents it. However, this would be an application problem and not an SQLite problem. The purpose of using the pointer interface is to disable the ability of "unsanitized user created SQL" (aka Johhny Tables) from being able to pass pointers into and out of the SQLite3 library via crafted SQL. The application developer must specifically code the ability to send and receive pointers. This can no longer be done and will no longer return meaningful results. It does nothing to secure the application code from exploitation by "other means". In other words, if a "badly written application" were subject to any sort of machine code injection attack, there is nothing to whatsoever to prevent the injected code from accessing the SQLite engine functions (or the OS kernel or anything else), binding pointers using the new interface, and extracting pointers. Nothing except that if the application already has this vulnerability (code injection via whatever means) there are much easier (not to mention smaller and simpler) methods to retrieve the same data which does not depend on using the database engine. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
