A heap overflow could occur when loading a hand-crafted compiled rules file. If the used field is less than sizeof(void) an integer overflow occurs that bypasses the file validation and causes heap overflow later on.
String sets like ($s*) always removed the STRING_FLAGS_SINGLE_MATCH flag, but only some operators (e.g. 1 of ($s*) at 0) actually mandated this.
In practice, the most common use case of string sets is n of ($s*), which does not necessitate removing STRING_FLAGS_SINGLE_MATCH.
Add logic to the operators to only remove this flag where it is necessary.
There was a possible (and trivial to trigger) infinite loop in yara that can be caused by quiting an application while we're enumerating its memory regions. When this happens, vm_region_64 will start returning an error (that isn't KERN_INVALID_ADDRESS), which yr_process_get_next_memory_block reacted to by infinite looping.
Generally speaking, the loop in that function seems completely unnecessary, and as such was removed to make the control flow easier to reason about.
This can be reproduced easily by running sudo yara test.yar <pid> on a large application, and quitting the app while the scan is running. This isn't 100% consistent, but more often than not I would end up with the infinite loop.
Bazel was the build system used by VirusTotal. Now that VirusTotal has moved to YARA-X, maintaining the Bazel infrastructure working is painful, specially with the backward incompatible changes introduced in recent versions of Bazel.
After #2119 `yara` is consuming a large amount of memory while parsing 9bddb45c44d9c25a4f97ef800cb110de5e6a15349bac05d389c8bda37902f25a. That's because after the change it doesn't limit the total number of imported functions, only the total number of parsing attempts, but the count is reset with each import entry. This file has a large number of entries and a large number of functions per entry, the total number of functions is very high.
It turns out that we must limit both the total number of correctly parsed functions (for cases like this one), and the total number of parsing attempts (for cases like the one #2119 was aiming to solve).
There is a bug when parsing [1] which turns out to be incorrectly checking the
number of successfully parsed imported functions and not the number of parsed
attempts. This particular sample is badly malformed and is causing excessive
loops in the parser while attempting to parse invalid data. With this fix it
will finish in a few seconds on my laptop.
[1]: 9c8e4dfa84b1ce7e919964978d33eada266d58b2aacdbef44b0618cc178ea421
One section entry was being ignored while parsing file b200f89fe313b6311e444e37725cae95127797ddb430e711c788c264acf92eb0 because we were forcing every resource entry to be shorter than the PE itself.
Although this sanity check makes sense, with truncated files this can lead to resource entries that are ignored. Here we make the sanity check more permissive, allowing entries that are larger than the PE file, but rejecting entries with ridiculously large sizes.
PR #1848 caused build issues with some "unusual" build configurations
– apparently we can't rely on linux/magic.h being present when
cross-building for musl libc.
Defining PROC_SUPER_MAGIC should not cause a problems since it should
be considered part of the Linux kernel/user API and it is unlikely to
change.
For some reason in MacOS 14 the build fails because the `configure` script is unable to find the Jansson library, even thought it is correctly installed by `brew`.
Victor M. Alvarez