Use After Free in yr_parser_lookup_loop_variable()

[fumfel]

Use After Free in yr_parser_lookup_loop_variable()

Tested on latest Git HEAD: 779b9a7

Payload

To reproduce: yara yara_uaf.yar strings

ASAN output:

==17551==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000ed50 at pc 0x000000425ff6 bp 0x7fff57ebe190 sp 0x7fff57ebd920
READ of size 1 at 0x60200000ed50 thread T0
    #0 0x425ff5 in __interceptor_strcmp /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:284:3
    #1 0x5a85cf in yr_parser_lookup_loop_variable XYZ/yara/libyara/parser.c:282:9
    #2 0x57536e in yara_yyparse XYZ/yara/libyara/grammar.y:569:25
    #3 0x50c3d0 in yr_lex_parse_rules_file XYZ/yara/libyara/lexer.l:815:3
    #4 0x4f097e in yr_compiler_add_file XYZ/yara/libyara/compiler.c:357:12
    #5 0x4ee0c4 in main XYZ/yara/yara.c:1124:17
    #6 0x7fe78bf2982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #7 0x41a408 in _start (/usr/local/bin/yara+0x41a408)

0x60200000ed50 is located 0 bytes inside of 2-byte region [0x60200000ed50,0x60200000ed52)
freed by thread T0 here:
    #0 0x4b88cb in __interceptor_free /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:47:3
    #1 0x580ac8 in yydestruct XYZ/yara/libyara/grammar.y:202:9
    #2 0x50c3d0 in yr_lex_parse_rules_file XYZ/yara/libyara/lexer.l:815:3

previously allocated by thread T0 here:
    #0 0x4a59f6 in __strdup /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:578:3
    #1 0x4ff501 in yara_yylex XYZ/yara/libyara/lexer.l:438:22
    #2 0x573528 in yara_yyparse XYZ/yara/libyara/grammar.c:1573:16
    #3 0x50c3d0 in yr_lex_parse_rules_file XYZ/yara/libyara/lexer.l:815:3

SUMMARY: AddressSanitizer: heap-use-after-free /home/development/llvm/3.9.0/final/llvm.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:284:3 in __interceptor_strcmp
Shadow bytes around the buggy address:
  0x0c047fff9d50: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff9d70: fa fa fa fa fa fa fa fa fa fa 02 fa fa fa 00 fa
  0x0c047fff9d80: fa fa 01 fa fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x0c047fff9d90: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 02 fa
=>0x0c047fff9da0: fa fa 00 00 fa fa fd fa fa fa[fd]fa fa fa fd fa
  0x0c047fff9db0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x0c047fff9dc0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa fd fd
  0x0c047fff9dd0: fa fa fd fa fa fa 00 fa fa fa 01 fa fa fa 00 00
  0x0c047fff9de0: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x0c047fff9df0: fa fa 00 00 fa fa fd fa fa fa 00 fa fa fa 00 00
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
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  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
==17551==ABORTING

[plusvic]

Fixed in 890c3f8

[fgeek]

CVE-2016-10211 has been assigned for this issue.