[Bug 1756349] Re: Null pointer dereference on '.dump' or 'SELECT * FROM sqlite_master' on corrupted file

[Seth Arnold]

Use CVE-2018-8740.

Thanks Even and Richard.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-8740

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to sqlite3 in Ubuntu.
https://bugs.launchpad.net/bugs/1756349

Title:
  Null pointer dereference on '.dump' or 'SELECT * FROM sqlite_master'
  on corrupted file

Status in sqlite3 package in Ubuntu:
  Confirmed

Bug description:
  Starting with sqlite 3.7.10 and up to latest sqlite 3.22.0/master, the following on the attached database causes a segmentation fault.
  I can reproduce this on Ubuntu Xenial 16.04 with libsqlite3-0:amd64 3.11.0-1ubuntu1. Should also affect Ubuntu Trusty that ship with sqlite 3.8.2

  $ echo ".dump" | valgrind sqlite3 gdal_ossfuzz_6964.db

  ==12781== Memcheck, a memory error detector
  ==12781== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
  ==12781== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
  ==12781== Command: .libs/sqlite3 /home/even/gdal/trunk/gdal/gdal_ossfuzz_6964.db
  ==12781== 
  PRAGMA foreign_keys=OFF;
  BEGIN TRANSACTION;
  ==12781== Invalid read of size 8
  ==12781==    at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
  ==12781==    by 0x4EC129A: yy_reduce (sqlite3.c:109734)
  ==12781==    by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
  ==12781==    by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
  ==12781==    by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
  ==12781==    by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
  ==12781==    by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
  ==12781==    by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
  ==12781==    by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
  ==12781==    by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
  ==12781==    by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
  ==12781==    by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)
  ==12781==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
  ==12781== 
  ==12781== 
  ==12781== Process terminating with default action of signal 11 (SIGSEGV)
  ==12781==  Access not within mapped region at address 0x0
  ==12781==    at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
  ==12781==    by 0x4EC129A: yy_reduce (sqlite3.c:109734)
  ==12781==    by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
  ==12781==    by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
  ==12781==    by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
  ==12781==    by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
  ==12781==    by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
  ==12781==    by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
  ==12781==    by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
  ==12781==    by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
  ==12781==    by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
  ==12781==    by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)

  This is a bug of the library and not the shell since the same occurs
  on this trivial C file

  mytest.c:

  {{{
  #include <sqlite3.h>

  int main(int argc, char* argv[])
  {
      sqlite3* hDB = 0;
      int nRowCount = 0, nColCount = 0;
      char** papszResult = 0;
      sqlite3_open(argv[1], &hDB);
      if( !hDB )
          return 1;
      sqlite3_get_table( hDB, "SELECT * FROM sqlite_master",
                         &papszResult, &nRowCount, &nColCount,
                         0 );
      sqlite3_free_table(papszResult);
      sqlite3_close(hDB);
      return 0;
  }
  }}}

  $ gcc -Wall mytest.c -o mytest -lsqlite3

  $ valgrind ./mytest gdal_ossfuzz_6964.db
  ==24793== Memcheck, a memory error detector
  ==24793== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
  ==24793== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
  ==24793== Command: ./mytest /home/even/gdal/trunk/gdal/gdal_ossfuzz_6964.db
  ==24793== 
  ==24793== Invalid read of size 8
  ==24793==    at 0x4E9302B: sqlite3EndTable (sqlite3.c:82695)
  ==24793==    by 0x4EC129A: yy_reduce (sqlite3.c:109734)
  ==24793==    by 0x4EC4A2E: sqlite3Parser (sqlite3.c:110900)
  ==24793==    by 0x4EC5896: sqlite3RunParser (sqlite3.c:111737)
  ==24793==    by 0x4EA6FC2: sqlite3Prepare (sqlite3.c:94064)
  ==24793==    by 0x4EA731F: sqlite3LockAndPrepare (sqlite3.c:94156)
  ==24793==    by 0x4EA74B7: sqlite3_prepare (sqlite3.c:94219)
  ==24793==    by 0x4EA61C6: sqlite3InitCallback (sqlite3.c:93538)
  ==24793==    by 0x4EA1FDE: sqlite3_exec (sqlite3.c:90752)
  ==24793==    by 0x4EA68AB: sqlite3InitOne (sqlite3.c:93784)
  ==24793==    by 0x4EA6A96: sqlite3Init (sqlite3.c:93850)
  ==24793==    by 0x4EA6B94: sqlite3ReadSchema (sqlite3.c:93887)
  ==24793==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
  ==24793== 

  Based on the git clone at 
  https://github.com/mackyle/sqlite, I've bisected the first bad commit to be
  {{{
  fee0225c95052006f0776d837eeafd26b857db53 is the first bad commit
  commit fee0225c95052006f0776d837eeafd26b857db53
  Author: D. Richard Hipp <drh at hwaci.com>
  Date:   Wed Jan 11 15:47:42 2012 +0000

      Make the pager less vulnerable to problems caused by shifting sector sizes
      when rolling back a hot journal.

  :040000 040000 84229496991a77e9600cadd39237de4f48cc9180 b374865f1168e3832fbf3e54c61704ae3c03c27e M	src
  }}}

  This issue was initially found with oss-fuzz on GDAL per
  https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=6964 . Credit to
  OSS-Fuzz

  I'm emailing privately Richard Hipp <drh at sqlite.org> with this report.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sqlite3/+bug/1756349/+subscriptions