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`.
File e77b007c9a964411c5e33afeec18be32c86963b78f3c3e906b28fcf1382f46c3 has a Rich header of only 8 bytes, which is smaller than the RICH_SIGNATURE structure. This was causing a crash when some of the `rich_xxx` functions were used with this file.
In regular expressions, repetition operators`{0,0}` and `{,0}` are valid, but they always match the zero-length string. For instance, `a{0,0}` and `[a-z]{0,0}` both match the zero-length string.
When the whole regular expression consists in one of these repetitions it caused a segfault during the evaluation of the regular expression because the `forward_code_ref` field for the root atom in the atom's tree was null.
Closes#2084.
When an included file contains an error that makes the parsing fail, the compiler must pop the file name from the stack before continuing parsing the original file, otherwise it will cause the confusing errors described in https://github.com/VirusTotal/yara-python/issues/260
For instance, `x{n, m}`, `x{n ,m}` and `x{n , m}` are all equivalent to `x{n,m}`. This is done for compatibility with YARA-X, but I've seen real-life regular expressions in that contain such spaces, for example:
```
/C:\\Users\\qqq\\.{30, 50}\.pdb/
```
Victor M. Alvarez