Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1686467 - openscap crashes when scanning using textfilecontent54 probe
Summary: openscap crashes when scanning using textfilecontent54 probe
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: openscap
Version: 8.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: rc
: 8.1
Assignee: Jan Černý
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 1682522
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-07 14:03 UTC by Matus Marhefka
Modified: 2019-03-17 19:22 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Description Matus Marhefka 2019-03-07 14:03:48 UTC
Description of problem:
When scanning a rule using textfilecontent54 probe oscap process segfaults with:

#17446 0x00007ffff7b642dd in get_substrings (substrings=<synthetic pointer>, want_substrs=1, re=0x7fffc4024fa0, ofs=<synthetic pointer>, 
    str=0x7fffc4025670 "## The purpose of these rules is to meet the requirements for Operating\n## System Protection Profile (OSPP)v4.2. These rules depends on having\n## 10-base-config.rules, 11-loginuid.rules, and 43-module"...) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/independent/textfilecontent54_probe.c:72
#17447 process_file (over=..., arg=0x7fffae68f7a0, file=0x7fffc404a840 "30-ospp-v42.rules", path=0x7fffc4024520 "/etc/audit/rules.d", prefix=0x0)
    at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/independent/textfilecontent54_probe.c:263
#17448 textfilecontent54_probe_main (ctx=ctx@entry=0x7fffae68fa80, arg=<optimized out>) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/independent/textfilecontent54_probe.c:436
#17449 0x00007ffff7b558bc in probe_worker (probe=<optimized out>, msg_in=<optimized out>, ret=0x7fffae68faf4) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/probe/worker.c:1055
#17450 0x00007ffff7b54d34 in probe_worker_runfn (arg=0x7fffe4075ed0) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/probe/worker.c:62
#17451 0x00007ffff6bb72de in start_thread () from /usr/lib64/libpthread.so.0
#17452 0x00007ffff4e96a63 in clone () from /usr/lib64/libc.so.6


Version-Release number of selected component (if applicable):
openscap-1.3.0-7.el8.x86_64
scap-security-guide-0.1.42-9.el8.noarch


How reproducible:
always


Steps to Reproduce:
# cp /usr/share/doc/audit/rules/30-ospp-v42.rules /etc/audit/rules.d/
# oscap xccdf eval --rule xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open_by_handle_at_rule_order --profile ospp /usr/share/xml/scap/ssg/content/ssg-rhel8-ds.xml
Title   Ensure auditd Unauthorized Access Attempts To open_by_handle_at Are Ordered Correctly
Rule    xccdf_org.ssgproject.content_rule_audit_rules_unsuccessful_file_modification_open_by_handle_at_rule_order
Segmentation fault (core dumped)


Actual results:
Segmentation fault


Expected results:
No segmentation fault

Comment 1 Jan Černý 2019-03-07 15:28:10 UTC
The segmentation fault is due to match() function 

#0  0x00007ffff706fc74 in match () from /usr/lib64/libpcre.so.1
#1  0x00007ffff706ff07 in match () from /usr/lib64/libpcre.so.1
#2  0x00007ffff707f038 in match () from /usr/lib64/libpcre.so.1
......
......
#17441 0x00007ffff706ff07 in match () from /usr/lib64/libpcre.so.1                                                                                                                                                
#17442 0x00007ffff707f038 in match () from /usr/lib64/libpcre.so.1                                                                                                                                                
#17443 0x00007ffff706ff07 in match () from /usr/lib64/libpcre.so.1
#17444 0x00007ffff70714c6 in match () from /usr/lib64/libpcre.so.1
#17445 0x00007ffff7082229 in pcre_exec () from /usr/lib64/libpcre.so.1                                                                                                                                            
#17446 0x00007ffff7b642dd in get_substrings (substrings=<synthetic pointer>, want_substrs=1, re=0x7fffcc01a970, ofs=<synthetic pointer>, str=0x7fffcc0535f0 "## The purpose of these rules is to meet the requirements for Operating\n## System Protection Profile (OSPP)v4.2. These rules depends on having\n## 10-base-config.rules, 11-loginuid.rules, and 43-module"...) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/pr
obes/independent/textfilecontent54_probe.c:72
#17447 process_file (over=..., arg=0x7fffc1ff87a0, file=0x7fffcc05c480 "30-ospp-v42.rules", path=0x7fffcc05bbd0 "/etc/audit/rules.d", prefix=0x0) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/independent/textfilecontent54_probe.c:263                                                                                                                                                                            
#17448 textfilecontent54_probe_main (ctx=ctx@entry=0x7fffc1ff8a80, arg=<optimized out>) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/independent/textfilecontent54_probe.c:436                   
#17449 0x00007ffff7b558bc in probe_worker (probe=<optimized out>, msg_in=<optimized out>, ret=0x7fffc1ff8af4) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/probe/worker.c:1055                   
#17450 0x00007ffff7b54d34 in probe_worker_runfn (arg=0x7fffe400b630) at /usr/src/debug/openscap-1.3.0-7.el8.x86_64/src/OVAL/probes/probe/worker.c:62
#17451 0x00007ffff6bb72de in start_thread () from /usr/lib64/libpthread.so.0
#17452 0x00007ffff4e96a63 in clone () from /usr/lib64/libc.so.6

The regular expression that causes this problem is:

"-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&0100 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccesful-create(?:[^.]|\\.\\s)*-a always,exit -F arch=b32 -S openat,open_by_handle_at -F a2&01003 -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccesful-modification(?:[^.]|\\.\\s)*-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -F auid>=1000 -F auid!=unset -F key=unsuccesful-access"

The code in textfilecontent54 probe should in theory work in any regular expression. However, we're probably hitting the limitations of PCRE library. The used regular expression seems to contain a lot of branch points in the pattern that match() function needs to store on stack in order to backtrack.

The way PCRE uses stack to save execution branches can be found http://regexkit.sourceforge.net/Documentation/pcre/pcrestack.html.

It seems we cannot do anything about it on OpenSCAP side because the segfault is in correctly used pcre_exec from PCRE library.
The solution is to use a different regular expression in the SCAP content.

Comment 2 Jan Černý 2019-03-07 16:30:47 UTC
We can probaly mitigate the problem by setting match_limit and match_limit_recursion fields pcre_extra argument of pcre_exec. See man pcreapi.
If this mitigation works, the user will get an error message instead of a segfault.

However, the advice to use better regular expressions in SCAP content is still valid. For example, you can put anchors to match beginning and end of the lines.

Comment 3 Jan Černý 2019-03-13 07:50:14 UTC
We have worked around the bug by using a different regular expression in OVAL content. The patch for content has been merged upstream in https://github.com/ComplianceAsCode/content/pull/4065.

However, we should fix OpenSCAP because the content that triggered this bug was valid OVAL content and OpenSCAP should be able to process any valid OVAL content without any segmentation fault.

I propose that we set a recursion limit in pcre_exec and we show an error message if the limit is reached. Please see comment 2 for an implementation hint.


Note You need to log in before you can comment on or make changes to this bug.