Ok, I reviewed the sources (utf.c) and I'd say that it's still
incorrect. Actually, it doesn't test for surrogates at all, the
problem I was experiencing was caused by the fact that SQLite reads
unallocated memory when there's an unpaired surrogate present as the
last character of string - see
> Re. that 0xE000 character, should I submit a bugreport somewhere?
You already did. Thanks.
http://www.sqlite.org/cvstrac/chngview?cn=4017
Ok, I reviewed the sources (utf.c) and I'd say that it's still
incorrect. Actually, it doesn't test for surrogates at all, the
problem I was
On Thu, 2007-05-17 at 16:54 +0200, Jiri Hajek wrote:
> > The Unicode standard is beside the point. There is lots of code
> > that does not handle charsets and encodings correctly, which can
> > open vulnerabilities to metacharacter injection. (Examples of
> > this class of problem are SQL
The Unicode standard is beside the point. There is lots of code
that does not handle charsets and encodings correctly, which can
open vulnerabilities to metacharacter injection. (Examples of
this class of problem are SQL injection, XSS and format string
exploits.)
I can't agree. SQLite itself
* Jiri Hajek <[EMAIL PROTECTED]> [2007-05-16 14:40]:
> As for security exploits, I don't see any, Unicode 4.0 standard
> allows applications to ignore such incorrect characters.
The Unicode standard is beside the point. There is lots of code
that does not handle charsets and encodings correctly,
5 matches
Mail list logo