Stack buffer overflow was fixed in SQLite 3.8.9: http://www.sqlite.org/src/info/c494171f77dc2e5e More information about this issue can be found in the links below: http://www.securityfocus.com/archive/1/535269 http://lcamtuf.blogspot.fr/2015/04/finding-bugs-in-sqlite-easy-way.html
Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1212360]
spatialite-tools-4.2.0-10.fc21, sqlite-3.8.9-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
spatialite-tools-4.2.0-10.fc22, sqlite-3.8.9-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
spatialite-tools-4.1.1-12.fc20, sqlite-3.8.9-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
Common Vulnerabilities and Exposures assigned an identifier CVE-2015-3416 to the following vulnerability: Name: CVE-2015-3416 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3416 Assigned: 20150424 Reference: http://www.sqlite.org/src/info/c494171f77dc2e5e04cb6d865e688448f04e5920 The sqlite3VXPrintf function in printf.c in SQLite before 3.8.9 does not properly handle precision and width values during floating-point conversions, which allows context-dependent attackers to cause a denial of service (integer overflow and stack-based buffer overflow) or possibly have unspecified other impact via large integers in a crafted printf function call in a SELECT statement.
Created attachment 1045827 [details] Backported upstream patch for RHEL7 Backported compound patch from upstream [1], including new automated tests for the issues. [1] https://www.sqlite.org/src/info/aeca95ac77f6f320
Created attachment 1055707 [details] Backported upstream patch for RHEL6
Comment on attachment 1055707 [details] Backported upstream patch for RHEL6 Backport of upstream patch: https://www.sqlite.org/src/info/aeca95ac77f6f320 The added tests had to be modified, because the expected values weren't in line with the functionality of sqlite-3.6.20. However, the memory buffer overflows do get fixed. Without the patch, the tests don't finish or end with a segmentation fault. After the patch, the tests always produce an output. After communication with upstream on sqlite-users.org, these changes were justified by their response. Quote: On 7/24/15, Viktor Jancik <vjancik> wrote: > What about these tests? > > do_test printf-1.17.1 { > sqlite3_mprintf_int {abd: %2147483647d %2147483647x %2147483647o} 1 1 1 > } {} > do_test printf-1.17.2 { > sqlite3_mprintf_int {abd: %*d %x} 2147483647 1 1 > } {} > do_test printf-1.17.3 { > sqlite3_mprintf_int {abd: %*d %x} -2147483648 1 1 > } {abd: 1 1} > do_test printf-2.1.2.10 { > sqlite3_mprintf_double {abc: %*.*f} 2000000000 1000000000 1.0e-20 > } {abc: } > do_test printf-3.7 { > sqlite3_mprintf_str {%d A String: (%*s)} 1 2147483647 {This is the > string} > } [] > do_test printf-3.8 { > sqlite3_mprintf_str {%d A String: (%*s)} 1 -2147483648 {This is the > string} > } {1 A String: (This is the string)} > do_test printf-3.9 { > sqlite3_mprintf_str {%d A String: (%.*s)} 1 -2147483648 {This is the > string} > } {1 A String: (This is the string)} > do_test printf-13.7 { > sqlite3_mprintf_hexdouble %2147483648.10000f 4693b8b5b5056e17 > } {/100000000000000000000000000000000.00/} > > Why are 1.17.3, 3.8, 3.9, 13.7 not getting shot down, while the rest are? > The behavior with oversized precisions and widths is arbitrary. I think the point of the tests is to show that there are no memory errors or assertion faults. -- D. Richard Hipp drh
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:1634 https://rhn.redhat.com/errata/RHSA-2015-1634.html
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:1635 https://rhn.redhat.com/errata/RHSA-2015-1635.html