Multiple flaws were found in sqlite. An attacker having the ability to run arbitrary SQL commands could use this flaw to execute arbitrary code with the permission of the user running the sqlite application.
Multiple flaws were found in sqlite. An attacker who is able to run arbitrary SQL statements could use this flaw to corrupt the internal databases, which can lead to arbitrary code execution as the user running sqlite.
This issue was fixed via sqlite-3.25.3 release at:
Also sqlite-3.36 introduced SQLITE_DBCONFIG_DEFENSIVE option which when added to the config file, could prevent attackers for corrupting the internal database files. This could however break applications which require users to write these database files.
Created sqlite tracking bugs for this issue:
Affects: fedora-all [bug 1659677]
*** Bug 1659363 has been marked as a duplicate of this bug. ***
Notes on exploitation:
The attacker needs to be able to execute arbitrary SQL statements in order to corrupt the databases and run arbitrary code as the user running sqlite applications. This is uncommon in applications, normally only administrative users are allowed to run SQL statements.
Chromium however exposes sqlite via WebSQL. This issue was address by Chromium 71.0.3578.80 via https://access.redhat.com/errata/RHSA-2018:3803
Mozilla firefox uses sqlite only to store internal profile information, browsing history etc, therefore should not be exploitable remotely.
Also refer to: https://www.sqlite.org/security.html for sqlite >= 3.26.0
Created mingw-sqlite tracking bugs for this issue:
Affects: epel-7 [bug 1659907]
Affects: fedora-all [bug 1659908]
As a data point, the Magellan vulnerability may be applicable to the sqlite package in EL7 base too:
The "attacker having the ability to run arbitrary SQL commands" concept seems a bit short sighted.
EL7 ships the sqlite-devel package, which means customers and users can build their own applications, which may or may not include the FTS3 module this bug occurs in.
The safest bet for customers is probably to back port the (fairly simple) upstream patch which fixes the problem, and release a SQLite 3.7.17-9. :)
Note - I'm not aware if anyone has (yet) looked for the earliest affected SQLite version, so see where the bug was introduced. That would potentially be useful info too.
(In reply to Justin Clift from comment #27)
> As a data point, the Magellan vulnerability may be applicable to the sqlite
> package in EL7 base too:
> The "attacker having the ability to run arbitrary SQL commands" concept
> seems a bit short sighted.
Analysis of these kind of flaws, normally assumes that standard security practices are followed. For example if you look at browsers chromium/chrome is only affected because it exposes a vector ie WebSQL.
> EL7 ships the sqlite-devel package, which means customers and users can
> build their own applications, which may or may not include the FTS3 module
> this bug occurs in.
Again we assume that these applications are doing the right thing security wise. If insecure programming practices are followed, the underlying libraries cannot be blamed :)
> The safest bet for customers is probably to back port the (fairly simple)
> upstream patch which fixes the problem, and release a SQLite 3.7.17-9. :)
See https://bugzilla.redhat.com/show_bug.cgi?id=1659379#c29 . RHEL-7 isnt really affected.
Also if you look at the patch you mentioned below, it does not prevent corruption of internal databases, it just ensures that the corruption of databases cannot lead to arbitrary code execution.
> Note - I'm not aware if anyone has (yet) looked for the earliest affected
> SQLite version, so see where the bug was introduced. That would potentially
> be useful info too.
I hope this answers your questions, feel free to open a support ticket if you are Red Hat customer!
This was assigned CVE-2018-20346.
This flaw does not affect the versions of sqlite package shipped with Red Hat Enterprise Linux 5, 6 and 7. This flaw in sqlite can be exploited by attackers only if they are able to run arbitrary SQL statements on the sqlite database. For more information please see https://bugzilla.redhat.com/show_bug.cgi?id=1659379#c12