[sqlite] Deference of Unitialized Pointer in shell_dbinfo_command in the sqlite shell (3.9.2)
On 11/17/15, Jonathan Metzman wrote: > > Thanks for the tip, I did get a bunch of garbage files that were written to > the directory I was fuzzing from. What do you recommend doing instead? > https://www.sqlite.org/afl/doc/trunk/README.md -- D. Richard Hipp drh at sqlite.org
[sqlite] Deference of Unitialized Pointer in shell_dbinfo_command in the sqlite shell (3.9.2)
Great! Thanks for the tip, I did get a bunch of garbage files that were written to the directory I was fuzzing from. What do you recommend doing instead? (I think I saw an sqlite_shell designed specifically for fuzzing somewhere on your site) On Tue, Nov 17, 2015 at 3:20 PM, Richard Hipp wrote: > On 11/17/15, Jonathan Metzman wrote: > > When fuzzing sqlite with American Fuzzy Lop, I believe I found the > > following bug in the sqlite shell: > > > > Thanks for the report. Joe has checked in a fix. > > Be careful about running AFL on the "sqlite3" command-line shell. AFL > might discover that it can run commands like: ".shell rm -rf ~" > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] Deference of Unitialized Pointer in shell_dbinfo_command in the sqlite shell (3.9.2)
On 11/17/15, Jonathan Metzman wrote: > When fuzzing sqlite with American Fuzzy Lop, I believe I found the > following bug in the sqlite shell: > Thanks for the report. Joe has checked in a fix. Be careful about running AFL on the "sqlite3" command-line shell. AFL might discover that it can run commands like: ".shell rm -rf ~" -- D. Richard Hipp drh at sqlite.org
[sqlite] Deference of Unitialized Pointer in shell_dbinfo_command in the sqlite shell (3.9.2)
When fuzzing sqlite with American Fuzzy Lop, I believe I found the
following bug in the sqlite shell:
In shell.c:2563-2571 (in the amalgamated version), in the function
shell_dbinfo_command:
1. pFile is declared (2563): sqlite3_file *pFile;
2. Its address is passed to sqlite3_file_control
(2570): sqlite3_file_control(p->db, zDb, SQLITE_FCNTL_FILE_POINTER, );
3. pFile is checked to see if it is equal to NULL, and if not, it is
dereferenced (2571): if( pFile==0 || pFile->pMethods==0 ||
pFile->pMethods->xRead==0 ){
When I input the following commands into the sqlite shell:
create table t1(one small);
.d table
sqlite3_file_control() does not set pFile, so pFile remains unitialized
after the function returns.
By my understanding, this behavior is safe only if pFile is initialized to
0, which is not always the case.
When I compiled sqlite (with the following options, using either gcc or
clang: "shell.c sqlite3.c -lpthread -ldl -o sqlite3") with glibc 2.6.18,
pFile is initialized to 0x77df18f5 (it is some other nonzero value with
clang). As a result, given the input I mentioned above, the program will
dereference pFile on line 2571 and segfault. On later versions of glibc I
have found that this bug does not always present itself (since pFile
happens to be initialized to 0) but I have also reproduced this segfault
with glibc 2.6.32 (again, using the amalgated source from the main download
page and the instructions provided on how to compile it).
If your compiler fails to produce a binary vulnerable to this bug, you can
(probably) use the -fsanitize=memory flag that clang supports or the
-fsanitize=address flag that both clang and gcc support to reproduce the
crash.
I believe explicitly initializing pFile like so:
sqlite3_file *pFile = NULL;
Would fix this problem.
Thank you,
Jonathan Metzman
