Bug 1212357 (CVE-2015-3416)

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