Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OS_Regex / Analysisd segmentation fault hazard #14249

Open
nmkoremblum opened this issue Jul 14, 2022 · 0 comments
Open

OS_Regex / Analysisd segmentation fault hazard #14249

nmkoremblum opened this issue Jul 14, 2022 · 0 comments
Labels
feed/rules Rules related issues module/analysis Issues related to the Analysis daemon regex Issue related to regular expressions team/core type/bug/crash type/bug Something isn't working

Comments

@nmkoremblum
Copy link
Contributor

nmkoremblum commented Jul 14, 2022

Wazuh version Component Install type Install method Platform
<= 4.3.5 OS_Regex / Analysisd Manager any any

While working on Issue #13933, a segmentation fault hazard was found in the OS Regex code. Under specific conditions, a pointer may be decreased beyond its memory starting point, this drives the code to read outside of the pointer's memory segment.

Conditions to reproduce

This behavior occurs when an expression with the * modifier is used (i.e. \w*) and the expression does not match the log.

For example:

Test Configuration

  • Regex: \d*
  • Log: abcdefg

OSRegex_Execute_ex() return value:

  • Expected output:
    abcdefg (Pointer to the first character of the string)
  • Actual output:
    Xabcdefg (Pointer to a byte before the first character of the string)
    (where X can be any character)

Description

When inspecting the OSRegex_Execute_ex() function's return value, which should be either a pointer pointing to the last matched character in the log (in case the regex fully matched the log) or null in case the regex didn't match. In the testing case, the return value points to one position before the log starts , as can be seen in the following screenshot:

image

Log start at 0x602000001e50, meanwhile match return 1 byte before: 0x602000001e4f

This test has the particularity that the regex is a single token with an optional quantifier (cero or more occurrences), which produces the regex to match but there is no specific character matched. As it can be seen, when inspecting the match_retval variable it is pointing to one character before the actual log starts.

This hazard is produced in the following code lines, where no verification is made before decreasing the st pointer:

else if ((*(pt + 2) == '+') && (_regex_matched == 1)) {
pt += 3;
st--;
_regex_matched = 0;
continue;
}
/* We may not match with '*' */
else if (*(pt + 2) == '*') {
pt += 3;
st--;
r_code = st;
_regex_matched = 0;
continue;

@nmkoremblum nmkoremblum added type/bug Something isn't working module/analysis Issues related to the Analysis daemon regex Issue related to regular expressions team/core labels Jul 14, 2022
@nmkoremblum nmkoremblum linked a pull request Jul 14, 2022 that will close this issue
28 tasks
@juliancnn juliancnn added feed/rules Rules related issues type/bug/crash labels Jul 14, 2022
@juliancnn juliancnn removed a link to a pull request Jul 25, 2022
28 tasks
@vikman90 vikman90 linked a pull request Jul 26, 2022 that will close this issue
28 tasks
@vikman90 vikman90 removed a link to a pull request Jul 26, 2022
28 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feed/rules Rules related issues module/analysis Issues related to the Analysis daemon regex Issue related to regular expressions team/core type/bug/crash type/bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants