Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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 (bressers@redhat.com) 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 <wad@google.com> Google Security Team
CC'ing reporter.
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.
Stable marking handled on bug #194812.
unrestricting on reporter's request.
(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.
(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.
(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.
