It was found that temporary directory search algorithm doesn't allow directories with only -wx permissions on Unix. Instead it falls back to '.' even if it's unsafe location. Although permissions of '.' are checked, result of that check is ignored.
Created sqlite2 tracking bugs for this issue:
Affects: fedora-all [bug 1352439]
Affects: epel-all [bug 1352443]
Created sqlite tracking bugs for this issue:
Affects: fedora-all [bug 1352438]
Created mingw-sqlite tracking bugs for this issue:
Affects: fedora-all [bug 1352440]
Affects: epel-7 [bug 1352442]
The impact of this issue is certainly low, if it can even be considered a security flaw.
The hard-coded temp dir search path follows:
1. temp_store_directory pragma (if defined)
2. SQLITE_TMPDIR environment var
3. TMPDIR env var
Only if all of these are exhausted is the cwd used. The impact of this bug is such that directories with permissions (relative to the user) of exactly -wx (writable, searchable but not readable) will be erroneously skipped. Finally, a randomly-generated filename is used, appropriate permissions (0600) and open(2) flags are used, and the file is unlinked once sqlite is finished with it.
RHEL ships by default with mode 1777 on /var/tmp, /usr/tmp and /tmp.
For this flaw to have any impact on a RHEL system:
- the sysadmin would need to have changed permissions on all three tmp directories
- the affected application would need to chdir() to a dangerous location: in particular, a network share with poor permissions management, or removable media
- the application would need to use VACUUM, a temp database, a materialized view, statement journals or transient indices involving sensitive data
- an attacker would need to race to access the file, or recover it from deleted blocks
RHEL's builds of sqlite do not override any default options nor patch the source in a way that impacts this issue.
sqlite-3.13.0-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.