On 2018/06/29 9:00 PM, Warren Young wrote:
The following is an answer to your challenge, not a feature request//....
4. The application uses the value as an index into an array. If the
application passes int* to sqlite3_column_int() to avoid compiler complaints,
they’ll get a negative index. If they pass unsigned* instead, casting it to
int* to placate the compiler, they get UINT_MAX on a 2’s complement machine,
which will certainly crash the program when used as an array index. Either
way, a security exploit is probably available.
I agree this demonstrates very well that SQLite can be one of the tools
that touches data along a gauntlet of horribly bad programming practices
that ends in a possible security loophole. However, it in no way
demonstrates duck-typing to have a causal relationship to the
vulnerability. You may as well have argued that the programmer read the
value -7 from a file he expected would have a positive integer and then
massaged it into a bad array-pointer through the same programming steps
- this doesn't render fopen() a security risk.
Further to this, how is this different from reading a very valid integer
from, say MySQL, with a value of 722 when your array is only 120 long?
If you are not going to range-check it, there's an immediate security
risk right there[*]. Is this MySQL's fault?
It is of course possible to work around all of this. The application
programmer “just” has to write checks in layers closer to the end user, checks
which are not strictly necessary with other DBMSes. People coming from those
other DBMSes reasonably expect the data to be implicitly trustworthy once it is
finally at rest.
I think this statement is a great summation of the real problem, and I
have to agree, perhaps in an "Introduction to SQLite" section on the
website one can add/improve a "Types in SQLite" section that better
prepares such programmers coming from alternate engines. We often see
people posting here being confused by it in some way - so definitely an
important thing.
Cheers!
Ryan
[*] - Yes, the original demonstration hinged on the "unsigned" type
constraint being violated, but the end-result vulnerability proposed was
a range-check failure, not a sign failure.
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
