[sqlite-dev] Please help reproduce an OSSFuzz problem

[Richard Hipp]

OSSFuzz (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/serebryany)
is telling us that the script at
https://sqlite.org/tmp/ossfuzz-5671.txt is causing an assertion fault
at https://www.sqlite.org/src/artifact/ac41c86b486f480b?ln=1994-1995

However, none of the core SQLite developers have been able to
reproduce this problem. We cannot get the assert() to fail with the
script above, or with any other script. Nor can we devise any other
mechanism to get that assert() to fail. We have been working on this
for days. Valgrind, ASAN, and UBSAN have given no help and no clues.

If you have any ideas on how to get the assert() to fail, please let
us know, either here on this mailing list or by private email.

Thanks.

--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-dev mailing list
sqlit...@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-dev

[Florian Weimer]

* Richard Hipp:

> OSSFuzz (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/serebryany)
> is telling us that the script at
> https://sqlite.org/tmp/ossfuzz-5671.txt is causing an assertion fault
> at https://www.sqlite.org/src/artifact/ac41c86b486f480b?ln=1994-1995
>
> However, none of the core SQLite developers have been able to
> reproduce this problem. We cannot get the assert() to fail with the
> script above, or with any other script. Nor can we devise any other
> mechanism to get that assert() to fail. We have been working on this
> for days. Valgrind, ASAN, and UBSAN have given no help and no clues.

Do you have the compiled binary that OSSFuzz used?

Thanks,
Florian

[Richard Hipp]

On 2/20/19, Florian Weimer <fwe...@redhat.com> wrote:
> * Richard Hipp:
>
>> OSSFuzz
>> (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/serebryany)
>> is telling us that the script at
>> https://sqlite.org/tmp/ossfuzz-5671.txt is causing an assertion fault
>> at https://www.sqlite.org/src/artifact/ac41c86b486f480b?ln=1994-1995
>>
>> However, none of the core SQLite developers have been able to
>> reproduce this problem. We cannot get the assert() to fail with the
>> script above, or with any other script. Nor can we devise any other
>> mechanism to get that assert() to fail. We have been working on this
>> for days. Valgrind, ASAN, and UBSAN have given no help and no clues.
>
> Do you have the compiled binary that OSSFuzz used?
>

No. All I have is the script that OSSFuzz uses to build:
https://github.com/google/oss-fuzz/blob/master/projects/sqlite3/build.sh

If you download the latest trunk version of SQLite you can do "make
sqlite3 ossshell" to build the tools. Then you can type "./sqlite3
<ossfuzz-5671.txt" or "./ossshell ossfuzz-5671.txt" to run the script.
Mess with the Makefile to change compile-time options, or whatever.

OSSFuzz uses the file "test/ossfuzz.c" linked against libFuzzer from
LLVM. It invokes the LLVMFuzzerTestOneInput() routine with the file
that I uploaded, and that apparently causes the assertion fault. The
"ossshell" program should do the same thing, except it is not causing
an assertion fault (nor ASAN, UBSAN, or Valgrind warnings).

--
D. Richard Hipp
d...@sqlite.org

[Bernardo Ramos]

Hi Richard!

Are the assertions enabled in the release mode?

I made the following:

wget https://www.sqlite.org/src/tarball/sqlite.tar.gz
tar zxvf sqlite.tar.gz
cd sqlite
./configure
make sqlite3 ossshell
wget https://sqlite.org/tmp/ossfuzz-5671.txt
./sqlite3 < ossfuzz-5671.txt

On MacOSX the result was:

sqlite bernardo$ ./sqlite3 < ossfuzz-5671.txt
Error: near line 3: near "VaCUU": syntax error

On Ubuntu 18.04:

~/dev/sqlite$ make sqlite3 ossshell
...
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status
Makefile:648: recipe for target 'sqlite3' failed

Bernardo Ramos

[Richard Hipp]

On 2/20/19, Bernardo Ramos <be...@gensis.com.br> wrote:
> Hi Richard!
>
> Are the assertions enabled in the release mode?

No. There are many assert() statements in SQLite, many inside of
critical loops. Enabling assert() causes SQLite to run about 3x
slower. So assert() is disabled for release builds.

But assert() is enabled for debugging. OSSFuzz enables assert(). All
of our tests enabled assert().

>
> I made the following:
>
> wget https://www.sqlite.org/src/tarball/sqlite.tar.gz
> tar zxvf sqlite.tar.gz
> cd sqlite
> ./configure

Add --enable-debug to ./configure in order to turn assert() statements on.

> make sqlite3 ossshell
> wget https://sqlite.org/tmp/ossfuzz-5671.txt
> ./sqlite3 < ossfuzz-5671.txt
>
> On MacOSX the result was:
>
> sqlite bernardo$ ./sqlite3 < ossfuzz-5671.txt
> Error: near line 3: near "VaCUU": syntax error
>

Right. We can get that. What we are unable to do is get the assert()
to fail. OSSFuzz sends me bug reports saying that the assert() fails
for it. But nobody here is able to reproduce that behavior.

[Florian Weimer]

* Richard Hipp:

> On 2/20/19, Florian Weimer <fwe...@redhat.com> wrote:
>> * Richard Hipp:
>>
>>> OSSFuzz
>>> (https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/serebryany)
>>> is telling us that the script at
>>> https://sqlite.org/tmp/ossfuzz-5671.txt is causing an assertion fault
>>> at https://www.sqlite.org/src/artifact/ac41c86b486f480b?ln=1994-1995
>>>
>>> However, none of the core SQLite developers have been able to
>>> reproduce this problem. We cannot get the assert() to fail with the
>>> script above, or with any other script. Nor can we devise any other
>>> mechanism to get that assert() to fail. We have been working on this
>>> for days. Valgrind, ASAN, and UBSAN have given no help and no clues.
>>
>> Do you have the compiled binary that OSSFuzz used?
>>
>
> No. All I have is the script that OSSFuzz uses to build:
> https://github.com/google/oss-fuzz/blob/master/projects/sqlite3/build.sh
>
> If you download the latest trunk version of SQLite you can do "make
> sqlite3 ossshell" to build the tools. Then you can type "./sqlite3
> <ossfuzz-5671.txt" or "./ossshell ossfuzz-5671.txt" to run the script.
> Mess with the Makefile to change compile-time options, or whatever.
>
> OSSFuzz uses the file "test/ossfuzz.c" linked against libFuzzer from
> LLVM. It invokes the LLVMFuzzerTestOneInput() routine with the file
> that I uploaded, and that apparently causes the assertion fault. The
> "ossshell" program should do the same thing, except it is not causing
> an assertion fault (nor ASAN, UBSAN, or Valgrind warnings).

Well, it could simply be a bug in their toolchain. I guess this
wouldn't be the first time SQLite testing exposed such a bug.

Thanks,
Florian