AddressSanitizer: SEGV /build/glibc-5hggjy/glibc-2.31/string/../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:247

[shinibufa]

Describe the bug AddressSanitizer: SEGV /build/glibc-5hggjy/glibc-2.31/string/../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:247

To Reproduce 1, compile yara 4.1.0 with asan: ./configure CC=gcc CXX=g++ CFLAGS="-g -O0 -fsanitize=address" CXXFLAGS="-g -O0 -fsanitize=address" LDFLAGS="-g -O0 -fsanitize=address" 2, run this command: ./yara -C PoC binFile

Please note that I encountered this bug in version 4.1.0 of YARA. I attempted to reproduce this bug in version 4.3.2 by modifying the fifth byte of the yarac file from "12" to "14". However, I received an error message stating, "corrupt compiled rules file." I have identified several similar bugs and have decided to submit this one. If you believe it is still valid in the latest version, I would be happy to submit the others as well. I hope this information proves helpful.

Please complete the following information:

• OS: ubuntu 20.04
• YARA version: 4.1.0

Additional context Add any other context about the problem here.

==1856845==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7ff37ca70e9a bp 0x7ffea46d5ac0 sp 0x7ffea46d5258 T0) ==1856845==The signal is caused by a READ memory access. ==1856845==Hint: address points to the zero page.

0 0x7ff37ca70e9a /build/glibc-5hggjy/glibc-2.31/string/../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:247

#1 0x435c4e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) (/home/root/sp/Fuzz/aflpp_fuzz/OSmart_compare/Yara/yara/p_C/yara_1/yara+0x435c4e)
#2 0x435fc9 in __interceptor_memcmp (/home/root/sp/Fuzz/aflpp_fuzz/OSmart_compare/Yara/yara/p_C/yara_1/yara+0x435fc9)
#3 0x7ff37d07022b in yr_arena_ref_to_ptr /home/root/SP_Comparison/yara_aflpp/libyara/arena.c:447:7
#4 0x7ff37d072021 in yr_arena_load_stream /home/root/SP_Comparison/yara_aflpp/libyara/arena.c:593:18
#5 0x7ff37d14c6ab in yr_rules_load_stream /home/root/SP_Comparison/yara_aflpp/libyara/rules.c:374:3
#6 0x7ff37d14cba7 in yr_rules_load /home/root/SP_Comparison/yara_aflpp/libyara/rules.c:400:12
#7 0x4d073d in main /home/root/SP_Comparison/yara_aflpp/cli/yara.c:1362:14
#8 0x7ff37c910082 in __libc_start_main /build/glibc-5hggjy/glibc-2.31/csu/../csu/libc-start.c:308:16
#9 0x41d5fd in _start (/home/root/sp/Fuzz/aflpp_fuzz/OSmart_compare/Yara/yara/p_C/yara_1/yara+0x41d5fd)

AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV /build/glibc-5hggjy/glibc-2.31/string/../sysdeps/x86_64/multiarch/memcmp-avx2-movbe.S:247 ==1856845==ABORTING

[plusvic]

If you pass a file with corrupted compiled rules YARA will certainly crash. The reason is that YARA doesn't "parse" the compiled rules file and validate its structure, it simply maps the file in memory and assume its structure is correct for performance reasons.

Some people has reported similar issues in the past, and a few measures has been incorporated to prevent the exploitation of malicious crafted compiled rules. The -C is one of those measures, because you need to be aware that you are passing a file that contains compiled rules. In the past you didn't need the -C option, you simply passed the file name and YARA decided if it was a source file or a compiled rules file, so anyone could trick you and send you a file named foo.yar and make you think that it was a source file while it was a maliciously crafted compiled rules file.

However, messing up with the structure of compiled rules will cause crashes here and there and there's nothing YARA can do about it. The only guarantee that YARA can offer is that it won't crash if the file is produced by YARA and it is unmodified. Changing random bytes in the compiled rules file will cause crashes.

That's also the reason why loading compiled rules files from untrusted third-party is discouraged, this implies a security risk.

See another related thread: https://github.com/VirusTotal/yara/issues/891

[shinibufa]

Thank you very much.