It is possible to craft SQLite databases that, when opened by an application expecting a specific SQL schema, could cause arbitrary code execution. The issue is in the handling of the fts3_tokenizer function: https://www.sqlite.org/mark/fts3.html?FTS+does+not&If+the+fts3*callback#mark Yum might be affected, but due to the use of HTTPS in RHEL, and in Fedora, the digest from the mirror list service should protect clients. The issue does not appear to be fixed upstream yet: https://www.sqlite.org/src/finfo?name=ext/fts3/fts3_tokenizer.c&ci=trunk External References: http://zerodayinitiative.com/advisories/ZDI-15-570/
Created sqlite2 tracking bugs for this issue: Affects: fedora-all [bug 1305823] Affects: epel-all [bug 1305825]
Created sqlite tracking bugs for this issue: Affects: fedora-all [bug 1305822]
This issue has been fixed in the 3.11.0 release of sqlite: https://www.sqlite.org/releaselog/3_11_0.html "Because of continuing security concerns, the two-argument version of the seldom-used and little-known fts3_tokenizer() function is disabled unless SQLite is compiled with the SQLITE_ENABLE_FTS3_TOKENIZER."
Statement: This issue did not affect the versions of sqlite as shipped with Red Hat Enterprise Linux 5 and 6. Red Hat Product Security has rated this issue as having Moderate security impact. This issue is not currently planned to be addressed in future updates. For additional information, refer to the Issue Severity Classification: https://access.redhat.com/security/updates/classification/.