os_regex: OSPcre2_Compile off-by-one heap overflow compiling empty regex.

[cpu]

In src/os_regex/os_pcre2_compile.c the OSPcre2_Compile function dereferences the const char *pattern variable at [0] and [pattern_len - 1] without checking pattern_len is >= 1.

ossec-hids/src/os_regex/os_pcre2_compile.c

Lines 64 to 65 in abb36d4

	first_char = pattern[0];
	last_char = pattern[pattern_len - 1];

This results in an out-of-bounds heap read at pattern[-1] when pattern_len is 0, e.g. with an empty regex (pattern = "").

This code was introduced in b6f1e14 when PCRE2 support was added on Jan 22nd, 2019. I believe it affects OSSEC v3.3.0+

I don't believe this is exploitable because no attacker controlled PCRE2 regular expressions are compiled by OSSEC.

As one example this bug is trigged when using an ossec-analysisd binary built with Address Sanitizer due to the empty regex in the <program_name_pcre2> element of the second "pam" decoder in rules/decoder.xml:

ossec-hids/etc/decoder.xml

Lines 53 to 56 in abb36d4

	<decoder name="pam">
	<program_name_pcre2></program_name_pcre2>
	<prematch_pcre2>^pam_unix|^\(pam_unix\)|^pam_succeed_if</prematch_pcre2>
	</decoder>

Likely the best fix is to have OSPcre2_Compile return an error when pattern_len == 0 before trying to optimize the empty pattern. If this is done the empty <program_name_pcre2> element in the PAM decoder will also need to be removed.