Richard, Your description of the rational for the new pointer values is sound and quite reasonable. I believe that it meets all the requirements you have set out to prevent SQL from being used to either retrieve or set arbitrary internal use (that is internal to both the application and SQLite3) pointers that was not directly intended (and pre-coded) by the application developer. How much of a security risk being able to do so would present is not particularly relevant to the implementation and is difficult to estimate because it certainly varies considerably by host OS. Simply eliminating the possibility of vulnerability via this method is adequate and commendable.
It should be noted however that this does not in any way prevent or mitigate that a "malicious application" will in fact be able to access or set pointer values, however, this is not within the scope of the change. The scope of the change is to protect existing and future applications from being used to perform side channel pointer attacks via crafted SQL injections that were not intended by the application author. At this it will succeed brilliantly. --- The fact that there's a Highway to Hell but only a Stairway to Heaven says a lot about anticipated traffic volume. >-----Original Message----- >From: sqlite-users [mailto:sqlite-users- >boun...@mailinglists.sqlite.org] On Behalf Of Richard Hipp >Sent: Monday, 24 July, 2017 05:54 >To: General Discussion of SQLite Database >Subject: [sqlite] New draft document on the new pointer-passing >interfaces > >https://www.sqlite.org/draft/bindptr.html > >-- >D. Richard Hipp >d...@sqlite.org >_______________________________________________ >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
