On Mon, Feb 10, 2020 at 8:27 PM Richard Hipp <d...@sqlite.org> wrote:
> On 2/10/20, Digital Dog <digitald...@gmail.com> wrote: > > > > Nobody bothered to actually show the downside of increasing this value to > > e.g. 10 thousands but everybody immediately proceeded to grumble. > > What is the justifiable rationale to not change the default? > > The maximum number of variables used to be unlimited (or, at least, > only limited by the ability of a 32-bit integer to count them). But > that was shown to facilitate a DOS attack. Anyone who could inject > SQL could do "SELECT ?2147483647;". This would cause SQLite to > allocate an array of 2147483648 elements, each of which is 72 bytes in > size, in which to store all of the parameters, potentially using up > all available memory in the process. Even ?32767 uses a big chunk of > heap memory - more than embedded systems people are comfortable giving > up - especially if the attacker can trick the system into creating > multiple prepared statements with ?32767 in them. The allocated array > lives for the life of the prepared statement. > Thanks, that makes a lot of sense. However maybe this needs rearchitecting, so that only used keys are allocated, not all up to the one specified in "SELECT ?2147483647".In this case I think SQLite should only allocate space for this single parameter. Maybe they should be treated as a dictionary/hashtable/linked list or similar? _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
