[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

sqlite3 package and debdiff [new-ish contributor, second attempt]



Hello all,

As the ICU package was perhaps a bit much to try as a first attempt (I
am still waiting for feedback from upstream on the patches as I am
unable to test them), I have decided to tackle a less challenging
package for my training run: sqlite3.

Based on the security tracker, this CVE is recently made public:

https://security-tracker.debian.org/tracker/CVE-2016-6153

Based on the notes there, I worked from these three upstream commits:

http://www.sqlite.org/cgi/src/info/67985761aa93fb61
http://www.sqlite.org/cgi/src/info/b38fe522cfc971b3
http://www.sqlite.org/cgi/src/info/614bb709d34e1148

I read the exploit details and a proof of concept here:

https://www.korelogic.com/Resources/Advisories/KL-001-2016-003.txt

The debdiff of the changes I made is attached to this mail and I have
uploaded the complete source package here:

https://people.debian.org/~roberto/

Following the steps in the proof of concept (at the bottom of the
korelogic.com page), I installed the vulnerable version of sqlite3 in a
wheezy Docker image.

After following the steps, I found that sqlite3 had ignored the
directory I specified in TMPDIR:

miami:~#  ls -l /proc/$(pidof sqlite3)/fd/ |egrep tmp
lrwx------ 1 nobody nogroup 64 Jul  2 23:32 3 -> /var/tmp/etilqs_gtsvCDCYTxqchTi (deleted)
lrwx------ 1 nobody nogroup 64 Jul  2 23:32 4 -> /var/tmp/etilqs_hECZPuVuLGwZJIV (deleted)

I installed the newly build sqlite3 (3.7.13-1+deb7u3) and follwed the
same steps again, finding that this time sqlite correctly allowed
temporary file creation in a directory without read permissions for the
creating user:

miami:~#  ls -l /proc/$(pidof sqlite3)/fd/ |egrep tmp
lrwx------ 1 nobody nogroup 64 Jul  2 23:34 3 -> /tmp/safe/etilqs_qIv0PwmhyswdIUF (deleted)
lrwx------ 1 nobody nogroup 64 Jul  2 23:34 4 -> /tmp/safe/etilqs_Jtmaahr2v0UXa2I (deleted)

If I understand the workflow correctly, then at this point I stil need
run the gen-DLA script, mail the DLA announcement, and upload the
package.

This change seemed very straightforward and I am confident that it is
ready for upload.  I would appreciate it if someone could review my work
and confirm that I have the next steps correct.

Regards,

-Roberto

-- 
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
diff -Nru sqlite3-3.7.13/debian/changelog sqlite3-3.7.13/debian/changelog
--- sqlite3-3.7.13/debian/changelog	2015-06-14 05:23:43.000000000 -0400
+++ sqlite3-3.7.13/debian/changelog	2016-07-02 23:30:43.000000000 -0400
@@ -1,3 +1,11 @@
+sqlite3 (3.7.13-1+deb7u3) wheezy-security; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * CVE-2016-6153: Allow temporary directory without read permission as
+    long as it has write and execute permissions.
+
+ -- Roberto C. Sanchez <roberto@debian.org>  Sat, 02 Jul 2016 23:00:45 -0400
+
 sqlite3 (3.7.13-1+deb7u2) wheezy-security; urgency=high
 
   * Properly handle precision and width values during floating-point
diff -Nru sqlite3-3.7.13/debian/patches/42-CVE-2016-6153.patch sqlite3-3.7.13/debian/patches/42-CVE-2016-6153.patch
--- sqlite3-3.7.13/debian/patches/42-CVE-2016-6153.patch	1969-12-31 19:00:00.000000000 -0500
+++ sqlite3-3.7.13/debian/patches/42-CVE-2016-6153.patch	2016-07-02 23:30:21.000000000 -0400
@@ -0,0 +1,62 @@
+Description: Allow temporary directory without read permission as long as it has write and execute permissions.
+Origin: upstream, http://www.sqlite.org/cgi/src/info/67985761aa93fb61 http://www.sqlite.org/cgi/src/info/b38fe522cfc971b3 http://www.sqlite.org/cgi/src/info/614bb709d34e1148
+--- sqlite3-3.7.13.orig/src/os_unix.c
++++ sqlite3-3.7.13/src/os_unix.c
+@@ -4787,20 +4787,24 @@
+      "/tmp",
+      0        /* List terminator */
+   };
+-  unsigned int i;
++  unsigned int i = 0;
+   struct stat buf;
+-  const char *zDir = 0;
++  const char *zDir = sqlite3_temp_directory;
+ 
+-  azDirs[0] = 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;
++  while(1){
++    if( zDir!=0
++     && osStat(zDir, &buf)==0
++     && S_ISDIR(buf.st_mode)
++     && osAccess(zDir, 03)==0
++    ){
++      return zDir;
++    }
++    if( i>=sizeof(azDirs)/sizeof(azDirs[0]) ) break;
++    zDir = azDirs[i++];
+   }
+-  return zDir;
++  return 0;
+ }
+ 
+ /*
+@@ -4820,10 +4824,11 @@
+   ** using the io-error infrastructure to test that SQLite handles this
+   ** function failing. 
+   */
++  zBuf[0] = 0;
+   SimulateIOError( return SQLITE_IOERR );
+ 
+   zDir = unixTempFileDir();
+-  if( zDir==0 ) zDir = ".";
++  if( zDir==0 ) return SQLITE_IOERR_GETTEMPPATH;
+ 
+   /* Check that the output buffer is large enough for the temporary file 
+   ** name. If it is not, return SQLITE_ERROR.
+--- sqlite3-3.7.13.orig/src/sqlite.h.in
++++ sqlite3-3.7.13/src/sqlite.h.in
+@@ -450,6 +450,7 @@
+ #define SQLITE_IOERR_SHMLOCK           (SQLITE_IOERR | (20<<8))
+ #define SQLITE_IOERR_SHMMAP            (SQLITE_IOERR | (21<<8))
+ #define SQLITE_IOERR_SEEK              (SQLITE_IOERR | (22<<8))
++#define SQLITE_IOERR_GETTEMPPATH       (SQLITE_IOERR | (25<<8))
+ #define SQLITE_LOCKED_SHAREDCACHE      (SQLITE_LOCKED |  (1<<8))
+ #define SQLITE_BUSY_RECOVERY           (SQLITE_BUSY   |  (1<<8))
+ #define SQLITE_CANTOPEN_NOTEMPDIR      (SQLITE_CANTOPEN | (1<<8))
diff -Nru sqlite3-3.7.13/debian/patches/series sqlite3-3.7.13/debian/patches/series
--- sqlite3-3.7.13/debian/patches/series	2015-06-14 05:23:43.000000000 -0400
+++ sqlite3-3.7.13/debian/patches/series	2016-07-02 22:35:53.000000000 -0400
@@ -8,3 +8,4 @@
 31-increase_SQLITE_MAX_DEFAULT_PAGE_SIZE_to_32k.patch
 40-use_fchmod_instead_of_umask.patch
 41-CVE-2015-3416.patch
+42-CVE-2016-6153.patch

Attachment: signature.asc
Description: Digital signature


Reply to: