KL-001-2016-003 : SQLite Tempdir Selection Vulnerability

Title: SQLite Tempdir Selection Vulnerability
Advisory ID: KL-001-2016-003
Publication Date: 2016.07.01
Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2016-003.txt


1. Vulnerability Details

     Affected Vendor: SQLite/Hwaci
     Affected Product: SQLite
     Affected Version: All versions prior to 3.13.0
     Platform: UNIX, GNU/Linux
     CWE Classification: CWE-379: Creation of Temporary File in Directory
                         with Incorrect Permissions
     Impact: Data Leakage
     Attack vector: Local

2. Vulnerability Description

     Usually processes writing to temporary directories do not need to
     perform readdir() because they control the filenames they create, so
     setting /tmp/ , /var/tmp/ , etc. to be mode 1733 is a not uncommon
     UNIX hardening practice.

     Affected versions of SQLite reject potential tempdir locations if
     they are not readable, falling back to '.'.  Thus, SQLite will favor
     e.g. using cwd for tempfiles on such a system, even if cwd is an
     unsafe location.  Notably, SQLite also checks the permissions of '.',
     but ignores the results of that check.

     By itself, this is only a POLA (Principle of Least Astonishment)
     violation that may cause unexpected failures.  However, this might
     in turn cause software that uses SQLite libraries to behave in
     unsafe ways, leaking sensitive data, opening up SQLite libraries to
     attack by deliberately corrupted tempfiles, etc.


3. Technical Description

     SQLite creates tempfiles only under certain specific circumstances,
     and the behavior is tunable in various ways; see
     https://www.sqlite.org/tempfiles.html for more background.
     Generally speaking, the below does not apply for rollback journals,
     master journals, write-ahead log (WAL) files, or shared-memory
     (-shm) files.  They may apply for various other tempfile types.

     When a tempfile must be created, sanity checks are performed on
     candidate tempdir locations; these checks are flawed.

     src/os_unix.c (which is merged into sqlite3.c during the
     release-tarball preparation process) performs these checks when
     considering candidate temporary directory locations (quoted from
     commit 0064a8c77b, 2016-02-23):

       /*
       ** Return the name of a directory in which to put temporary files.
       ** If no suitable temporary file directory can be found, return NULL.
       */
       static const char *unixTempFileDir(void){
         static const char *azDirs[] = {
            0,
            0,
            "/var/tmp",
            "/usr/tmp",
            "/tmp",
            "."
         };
         unsigned int i;
         struct stat buf;
         const char *zDir = sqlite3_temp_directory;

         if( !azDirs[0] ) azDirs[0] = getenv("SQLITE_TMPDIR");
         if( !azDirs[1] ) azDirs[1] = getenv("TMPDIR");
         for(i=0; i<sizeof(azDirs)/sizeof(azDirs[0]); zDir=azDirs[i++]){
           if( zDir==0 ) continue;
           if( osStat(zDir, &buf) ) continue;
           if( !S_ISDIR(buf.st_mode) ) continue;
           if( osAccess(zDir, 07) ) continue;
           break;
         }
         return zDir;
       }

     osAccess is defined elsewhere as a wrapper around the access system
     call:

         { "access",       (sqlite3_syscall_ptr)access,     0  },
       #define osAccess    ((int(*)(const char*,int))aSyscall[2].pCurrent)

     So, a candidate directory will be rejected if it does not match mode
     07; that is to say it must be readable, writable, and executable.

     Furthermore, the comment that "If no suitable temporary file
     directory can be found, return NULL." is incorrect: in fact, if all
     directories including "." fail, then "." is returned, because zDir
     has already been assigned before the checks fail.  (Also,
     unixGetTempname, which calls unixTempFileDir, does not check if NULL
     was returned.)

     The specific lines of code embodying this check have subtly changed
     a dozen times over SQLite's history (and things like the NULL check
     might have been valid in some past version).  The first time a check
     for readability was included appears to have been in fossil commit
     e7b65e37fd, imported from this CVS commit:

       -** @(#) $Id: KL-001-2016-003.txt,v 1.1 2016/07/01 15:48:13 hlein Exp $
       +** @(#) $Id: KL-001-2016-003.txt,v 1.1 2016/07/01 15:48:13 hlein Exp $


          for(i=0; i<sizeof(azDirs)/sizeof(azDirs[0]); i++){
       -    if( stat(azDirs[i], &buf)==0 && S_ISDIR(buf.st_mode)
       -         && access(azDirs[i], W_OK) ){
       -       return azDirs[i];
       -    }
       +    if( stat(azDirs[i], &buf) ) continue;
       +    if( !S_ISDIR(buf.st_mode) ) continue;
       +    if( access(azDirs[i], 07) ) continue;
       +    return azDirs[i];
          }

     As seen here, prior to 2001.09.14 the only permission checked was
     W_OK, writability.  The commit message for e7b65e37fd does not call
     out this change; perhaps there was some problem that changing from
     W_OK to R_OK+W_OK+X_OK was intended to solve at the time.

     As stated above, this by itself is only a POLA violation: a
     developer or system administrator might not expect a candidate
     temporary directory to be rejected if it is not readable.  This
     would result in SQLITE_TMPDIR , TMPDIR , /var/tmp , /tmp , etc.
     being rejected by the above if they are mode 1733 or similar, and
     also cause sqlite to fail at runtime if cwd is not writable.

     SQLite does the right things when creating its tempfile, once the
     tempdir is chosen.  It randomly generates the filename (although
     weirdly, using a home-grown implementation instead of mkstemp,
     possibly for cross-platform purposes), uses file mode 600, with good
     file-open flags (O_CREAT|O_EXCL|O_NOFOLLOW|O_CLOEXEC), etc.  If
     possible (such as for 'TEMP' databases), the file is unlinked
     immediately.

     However, this could lead to insecure behavior by some application
     using SQLite under these conditions.  As a contrived example, a
     program which writes sensitive data to an sqlite database, and
     during execution chdir()'s to a directory in which it is not safe to
     write sensitive data even temporarily, such as an NFS or SMB network
     share (allowing network capture), or a removable device which will
     later leave the user's physical control (leaving on-disk residue,
     possibly mitigated by SQLite's SECURE_DELETE settings).

     It is also possible that the failure of unixTempFileDir to return
     NULL, and of unixGetTempname to check for that NULL, may lead to
     abrupt crashes or otherwise unexpected or undefined behavior by the
     calling program when "." is also not writable.

4. Mitigation and Remediation Recommendation

     The vendor released version 3.13.0 on 2016.05.18 in which the reported
     vulnerability was patched. Release notes available at:
     https://www.sqlite.org/releaselog/3_13_0.html

5. Credit

     This vulnerability was discovered by Hank Leininger of KoreLogic, Inc.

6. Disclosure Timeline

     2016.03.24 - KoreLogic sends vulnerability report and PoC to SQLite.
     2016.03.24 - SQLite acknowledges receipt of vulnerability report.
     2016.04.21 - KoreLogic asks for an update on the remediation effort.
     2016.04.21 - SQLite responds that the vulnerability has been patched
                  and will be public in the next update.
     2016.05.18 - SQLite 3.13.0 released.
     2016.07.01 - Public disclosure.

7. Proof of Concept

     ########################################################################
     #
     # Copyright 2016 KoreLogic Inc., All Rights Reserved.
     #
     # This proof of concept, having been partly or wholly developed
     # and/or sponsored by KoreLogic, Inc., is hereby released under
     # the terms and conditions set forth in the Creative Commons
     # Attribution Share-Alike 4.0 (United States) License:
     #
     #   http://creativecommons.org/licenses/by-sa/4.0/
     #
     #######################################################################*

     Reproduction using the sqlite3 binary (but an application linked
     against libsqlite would behave similarly):

patsy@foo ~/sqlite-test $ ls -la
total 16
drwxr-xr-x  4 root  root  4096 Feb 23 22:45 .
drwxr-xr-x 19 patsy root  4096 Feb 23 23:04 ..
drwx-wx-wt  2 root  patsy 4096 Feb 23 22:41 tmp
drwxrwxrwx  2 patsy patsy 4096 Feb 23 22:45 unsafe

patsy@foo ~/sqlite-test $ export TMPDIR=~/sqlite-test/tmp
patsy@foo ~/sqlite-test $ cd unsafe
patsy@foo ~/sqlite-test/unsafe $ sqlite3
SQLite version 3.10.2 2016-01-20 15:27:19
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
sqlite> CREATE TEMP TABLE testtemp(text);
sqlite>

foo ~ # ls -l /proc/$(pidof sqlite3)/fd/ | egrep /patsy/
lrwx------ 1 patsy patsy 64 Feb 23 23:04 3 -> /home/patsy/sqlite-test/unsafe/etilqs_1974c47b45a40cc9 (deleted)
lrwx------ 1 patsy patsy 64 Feb 23 23:04 4 -> /home/patsy/sqlite-test/unsafe/etilqs_81d3a73a2307205a (deleted)