Bug 192094 – dev-db/sqlite < 3.4.0 Possible issues

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Sune Kloppenborg Jeppesen (RETIRED) 2007-09-11 09:58:25 UTC]

If you are interested in patching sqlite for these, I do not believe
there is an embargo (given the response on the list).  Feel free to
post this to a publicly available bug. I believe Josh Bressers
([e-mail]) is willing to supply CVEs if desired.  He has
recommended the following categorizations:


* Integer overflow
   [=] Integer overflow / heap overflow in strftime()
   [=] Integer overflow / buffer overflow in quote()
   [=] Integer overflow / heap overflow in ORDER BY expressions
   [=] Signedness error / heap overflow in select (sqlite3VdbeSetNumCols)
   [=] Integer overflow / heap overflow in ALTER
   [=] crash in replace()

* Divide by zero crash
   [=] Divide by zero
   [=] Arithmetic overflow in the modulus operator

* Unchecked Error Condition
   [=] Infinite loop in replace()
   [=] Out of bound read in sqlite_rename_trigger  / sqlite_rename_table
   [=] Schema corruption possible with malformed unicode
   [=] Multiple parser bugs resulting in NULL pointer dereferences, bad
       free()s, and assertions

* Stack recursion
   [=] Stack exhaustion in glob recursion along two different code paths
   [=] Stack exhaustion in glob recursion
   [=] Large select statements result in recursion induced stack overflow

* Null Dereference
   [=] NULL pointer dereference on allocation failure in randomblob()
   [=] NULL pointer dereference with pathological detach queries
   [=] NULL pointer dereference with pathological SQL

* Improper bounds checking
   [=] Multiple issues with zeroblob()
   [=] Signedness issue/ out of band read in substr()


Please let me know if you're uninterested or if you'd like to discuss
this further.  I can help clarify any versioning or patching issues.
I know that the associated changelists on trac aren't always so
useful. :-/

Thanks!!
will

---
Hi vendor-sec:

The Google Security team was recently working with the SQLite authors.  During
this collaboration, multiple vulnerabilities were discovered and patched.
Please find below a detailed listing of the vulnerabilities and links to the
author supplied fixes in CVStrac.  Upgrading to version 3.4.0 is the
recommended path to avoid these vulnerabilities.


* The following vulnerabilities were discovered by Dean McNamee:

[=] Integer overflow / heap overflow in strftime()
[-] This bug is caused by wrapping "int n" around to 0 during the space
   calculation first pass.  I used %J since it will increment n the most
   (50).
[+] http://www.sqlite.org/cvstrac/chngview?cn=3943
[?] An example query can be created with the following ruby snippet:
   puts 'select strftime("%s", 1);' % ('%J' * 84215046)


[=] Infinite loop in replace()
[-] The replace() function did not check if the second argument was NULL
   resulting in an infinite loop.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3877
[?] select replace("", "", "");


[=] Divide by zero / crash in replace()
[-] Supplying arguments of specific length to the replace function
   allowed for memory allocation to be abused through an integer overflow.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3877
[?] If you have one valid table, the following query should reproduce the
   condition:
   select * from sqlite_master where name = replace(randomblob(65537), "a",
     randomblob(65536));


[=] Stack exhaustion in glob recursion along two different code paths
[-] The patternCompare function will recurse based on user input.  This
   allows an attacker to cause deep recursion and possibly exhaust the
   allocated stack space.
[+] The authors limited the maximum length of glob and like to avoid this bug:
   http://www.sqlite.org/cvstrac/chngview?cn=3950
   http://www.sqlite.org/cvstrac/chngview?cn=3962
[?] The following query when extending significantly in length will
   reproduce these bugs:
     select"AAAAA..." GLOB "*[A]*[A]..."
     select"AAAAA..." GLOB "*A*A..."


[=] Stack exhaustion in glob recursion
[-] Similar to the bug above, this follows a different code path.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3950
   http://www.sqlite.org/cvstrac/chngview?cn=3962


[=] Signedness issue/ out of band read in substr()
[-] Overly large values supplied to substr() result in an out of band
   read.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3943
[?] select substr("aaaa", 99999999, 2147483647);


[=] Integer overflow / buffer overflow in quote()
[-] If the target system can allocate 2 gigs of memory, an integer
   overflow is possible in the allocation: malloc(size*2 + 4)
[+] http://www.sqlite.org/cvstrac/chngview?cn=3943
[?] If you have one valid table and enough available memory, the
   following query should reproduce the condition:
   select * from sqlite_master where name = quote(randomblob(2147483647));


[=] NULL pointer dereference on allocation failure in randomblob()
[-] If the system cannot allocate 2 gigs of memory, it will fail and crash with
   a NULL pointer dereference.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3940
[?] select randomblob(2147483647);




* The following vulnerabilities were discovered by Will Drewry:

[=] Integer overflow / heap overflow in ALTER
[-] If a table contains around 214748364 columns, and the alter command is
   called, a malloc() will occur with a size of 0.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
   http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] (Test case is waay to time consuming.)


[=] Signedness error / heap overflow in select (sqlite3VdbeSetNumCols)
[-] The function sqlite3VdbeSetNumCols takes the column count and multiplies it
   by 5 and then by 64 prior to an allocation call.  A query with the number of
   columns of 13421772 or greater will result in an overflow.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
   http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1,1,1,1........,1;


[=] Large select statements result in recursion induced stack overflow
[-] The function walkExprTree() in expr.c makes recursive calls to handle each
   of the conditional tests.  Extremely large queries result in stack
exhaustion.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3968
   http://www.sqlite.org/cvstrac/chngview?cn=3954
   http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1 where 1==1 and 1==1 and ...... and 1 == 1;


[=] Integer overflow / heap overflow in ORDER BY expressions
[-] Similarly to the other column count overflows, memory is allocated for a
   size derived from the multiplication of the number of expressions by several
   fixed sizes: sqliteMalloc( sizeof(*pInfo) + nExpr*(sizeof(CollSeq*)+1) ).
[+] http://www.sqlite.org/cvstrac/chngview?cn=3954
   http://www.sqlite.org/cvstrac/chngview?cn=3956
[?] select 1 order by 1,1,1,1,1,......,1


[=] Arithmetic overflow in the modulus operator
[-] The division and modulus code check for a divisor of 0 but neglected to
   check for the LLONG_MIN/-1 case.  Due to the type handling in
sqlite, -2**31 is
   treated as a 32 bit integer but treats -9223372036854775808 as a
real.  In the
   case of division, doubles are used, but in the case of modulo, the value is
   cast down to a 32 bit integer.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3945
[?] select (-9223372036854775808 % -1);
   select (-2147483648.0 % -1);


[=] Out of bound read in sqlite_rename_trigger  / sqlite_rename_table
[-] Two internally used functions, sqlite_rename_trigger and
   sqlite_rename_table do not properly check for terminal tokens when
parsing the
   arguments.  This results in out of band reads.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3944
[?] select sqlite_rename_table(0, 0);
   select sqlite_rename_trigger(0,0);


[=] NULL pointer dereference with pathological detach queries
[-] If unexpected SQL follows the DETACH command, NULL pointer derefencing
   occurs in the parsing code.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3965
[?] DETACH RAISE ( IGNORE ) IN ( SELECT "AAAAAA" . * ORDER BY REGISTER LIMIT
     "AAAAAA" . "AAAAAA" OFFSET RAISE ( IGNORE ) NOT NULL );


[=] NULL pointer dereference with pathological SQL
[-] This is similar to the earlier bug with DETACH but takes a different code
   path.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3965
[?] DETACH DATABASE ( NOT ( SELECT * ) IN ( ) );


[=] Multiple parser bugs resulting in NULL pointer dereferences, bad free()s,
   and assertions
[-] Register tokens are used internally for tracking internal stack state in
   sqlite.
[+] http://www.sqlite.org/cvstrac/chngview?cn=3980
[?] SELECT + #100;
[!] Note: assert() statements are automatically removed in most sqlite
   builds through the definition of NDEBUG. This may increase the impact of
   any reachable assertions.


[=] Schema corruption possible with malformed unicode
[-] Due to a mismatch in string length during processing (alter table and
   substr()), malformed unicode can be used to corrupt the schema.  This would
   allow for memory exhaustion attacks as well as general table damage.
[+] http://www.sqlite.org/cvstrac/chngview?cn=4003
   http://www.sqlite.org/cvstrac/chngview?cn=4033
[?] E.g.,
   echo -e 'create table bar ("\xc6\xc6");' | ./sqlite3 db
   echo "alter table bar add column aaa;"   | ./sqlite3 db
   echo "alter table bar add column aaa;"   | ./sqlite3 db
   echo "alter table bar add column aaa;"   | ./sqlite3 db
   echo ".schema bar"                       | ./sqlite3 db
   # Shows the broken schema


[=] Multiple issues with zeroblob()
[-] The zeroblob function creates empty structures with a claimed size
   that is the supplied argument.  Due to a lack of checking, bitwise ORs
   would occur on null values.  In addition, bad free()s occurred when
   zeroblob was supplied a negative value.
[+] http://www.sqlite.org/cvstrac/chngview?cn=4048
[?] select hex(zeroblob(1) | x'01');
   select zeroblob(-1);


Thanks,
will

--
Will Drewry <[e-mail]>
Google Security Team

[Comment 1 Sune Kloppenborg Jeppesen (RETIRED) 2007-09-11 20:48:16 UTC]

CC'ing reporter.

[Comment 2 Pierre-Yves Rofes (RETIRED) 2007-10-06 23:05:55 UTC]

any news here? maybe this could be made public? The advisory recommends to upgrade to 3.4.0, and we have 3.4.1 in the tree keyworded ~arch, is it ok to call arches for stabilization? please advise.

[Comment 3 Sune Kloppenborg Jeppesen (RETIRED) 2007-10-14 07:48:43 UTC]

Stable marking handled on bug #194812.

[Comment 4 Pierre-Yves Rofes (RETIRED) 2007-11-05 19:27:14 UTC]

unrestricting on reporter's request.

[Comment 5 Petteri Räty (RETIRED) 2007-12-07 18:15:49 UTC]

(In reply to comment #2)
> any news here? maybe this could be made public? The advisory recommends to
> upgrade to 3.4.0, and we have 3.4.1 in the tree keyworded ~arch, is it ok to
> call arches for stabilization? please advise.
> 

Security: 3.4.1 is nowadays stable on all security supported arches so you probably should continue with your magic here.

[Comment 6 Pierre-Yves Rofes (RETIRED) 2007-12-08 18:00:40 UTC]

(In reply to comment #5)
> (In reply to comment #2)
> > any news here? maybe this could be made public? The advisory recommends to
> > upgrade to 3.4.0, and we have 3.4.1 in the tree keyworded ~arch, is it ok to
> > call arches for stabilization? please advise.
> > 
> 
> Security: 3.4.1 is nowadays stable on all security supported arches so you
> probably should continue with your magic here.
> 
ACK. Thanks for the reminder, we've been overwhelmed by sec bugs recently and we just can't check after all of them :(
We'll try to push the related glsa ASAP.

[Comment 7 Pierre-Yves Rofes (RETIRED) 2007-12-10 21:21:58 UTC]

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #2)
> > > any news here? maybe this could be made public? The advisory recommends to
> > > upgrade to 3.4.0, and we have 3.4.1 in the tree keyworded ~arch, is it ok to
> > > call arches for stabilization? please advise.
> > > 
> > 
> > Security: 3.4.1 is nowadays stable on all security supported arches so you
> > probably should continue with your magic here.
> > 
> ACK. Thanks for the reminder, we've been overwhelmed by sec bugs recently and
> we just can't check after all of them :(
> We'll try to push the related glsa ASAP.
> 

After further analysis, it seems that no one cared enough to request CVE ids and to make a public advisory for this, probably considering that exploitation was unlikely. so, we'll just stick with the others distros, and close this without glsa. Feel free to reopen if you disagree.