Skip to content

Commit

Permalink
fuzzing nvi regex(3): nvi's regex(3) fails immediately with address s…
Browse files Browse the repository at this point in the history
…anitizer
  • Loading branch information
plusun committed Jul 22, 2018
1 parent 99b4551 commit b49e95e
Show file tree
Hide file tree
Showing 3 changed files with 69 additions and 0 deletions.
16 changes: 16 additions & 0 deletions tests/fuzz/regex/nvi/regcomp/bug/Makefile
Original file line number Diff line number Diff line change
@@ -0,0 +1,16 @@
# $NetBSD: Makefile,v 1.15 2007/05/28 12:06:25 tls Exp $
# @(#)Makefile 8.2 (Berkeley) 4/2/94

.include <bsd.own.mk>

PROG= main
.PATH: ..
SRCS= fuzz_regcomp.c
.PATH: ../../../../
SRCS+= main.c
.PATH: ${NETBSDSRCDIR}/external/bsd/nvi/dist/regex
SRCS+= regcomp.c regerror.c regexec.c regfree.c

CPPFLAGS+= -I${NETBSDSRCDIR}/external/bsd/nvi/usr.bin/nvi -I${NETBSDSRCDIR}/external/bsd/nvi/dist/regex -D__REGEX_PRIVATE -DUSE_WIDECHAR -D__REGEX_PRIVATE -DUSE_WIDECHAR -Dregcomp=__mkfuzzer_regcomp -Dregerror=__mkfuzzer_regerror -Dregexec=__mkfuzzer_regexec -Dregfree=__mkfuzzer_regfree -g

.include <bsd.prog.mk>
Empty file.
Original file line number Diff line number Diff line change
@@ -0,0 +1,53 @@
root@localhost % ./main crash-da39a3ee5e6b4b0d3255bfef95601890afd80709
=================================================================
==18866==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000031 at pc 0x0000004cb0c5 bp 0x7f7fffffddd0 sp 0x7f7fffffd578
READ of size 4 at 0x602000000031 thread T0
#0 0x4cb0c4 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x4cb0c4)
#1 0x41d8f2 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d8f2)
#2 0x41d0ea (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d0ea)
#3 0x41d273 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d273)
#4 0x41d4cb (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d4cb)
#5 0x41ceb0 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41ceb0)

0x602000000031 is located 0 bytes to the right of 1-byte region [0x602000000030,0x602000000031)
allocated by thread T0 here:
#0 0x54f243 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x54f243)
#1 0x41d17f (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d17f)
#2 0x41d4cb (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41d4cb)
#3 0x41ceb0 (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x41ceb0)
#4 0x7f7ff7ef8fff (<unknown module>)

SUMMARY: AddressSanitizer: heap-buffer-overflow (/public/src/tests/fuzz/regex/nvi/regcomp/bug/./main+0x4cb0c4)
Shadow bytes around the buggy address:
0x4c03ffffffb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x4c03ffffffc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x4c03ffffffd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x4c03ffffffe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x4c03fffffff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x4c0400000000: fa fa 01 fa fa fa[01]fa fa fa fa fa fa fa fa fa
0x4c0400000010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x4c0400000020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x4c0400000030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x4c0400000040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x4c0400000050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
Shadow gap: cc
==18866==ABORTING

7 comments on commit b49e95e

@krytarowski
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you add -g to CFLAGS+= and LDFLAGS+=, does it work better?

@krytarowski
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively, is the binary stripped from symbols? file(1) over the file should show it.

@plusun
Copy link
Owner Author

@plusun plusun commented on b49e95e Jul 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Adding -g to CFLAGS and LDFLAGS seems to be not working, either, there is no symbol. the result of file(1):
main: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 8.99.17, with debug_info, not stripped

@krytarowski
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please try to include MKDEBUG=yes in your mk.conf or command line argument passed to 'make'.

@plusun
Copy link
Owner Author

@plusun plusun commented on b49e95e Jul 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've added MKDEBUG=yes to /etc/mk.conf. And what's more, I observed that every compiling line has been added with "-g", but there was still no symbol.

@krytarowski
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose that we are using llvm-symbolizer. It has hardcoded paths to search for debug info like /usr/libdata/debug/.

Is there generated file name.debug somewhere? (PROG.debug). We can try to move it to the current directory.

@plusun
Copy link
Owner Author

@plusun plusun commented on b49e95e Jul 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I solved this by re-installing my llvm-symbolizer! Thanks for your hint!

Please sign in to comment.