Fix/xinetd probe memory safety#2371
Conversation
edznux-dd
requested review from
Mab879,
jan-cerny and
matusmarhefka
as code owners
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
Mab879
left a comment
Mab879
left a comment
There was a problem hiding this comment.
Please review the finding from Sonar and GitHub security findings.
edznux-dd
force-pushed
the
fix/xinetd-probe-memory-safety
branch
from
38a411a to
68e1aff
Compare
| continue; | ||
| } | ||
|
|
||
| xiconf_add_cfile (xiconf, pathbuf, xifile->depth + 1); |
There was a problem hiding this comment.
False positive:
This path is used as an include in xinetd.... If you control a xinetd include directive, you can already run arbitrary code?
I'm not sure what would be a safe guardrail here.... Removing .. and all would break real configs?
| if (inctype == XICONF_INCTYPE_FILE) { | ||
| strncpy (pathbuf, inclarg, sizeof(pathbuf)-1); | ||
| dD("includefile: %s", pathbuf); | ||
| xiconf_add_cfile (xiconf, pathbuf, xifile->depth + 1); |
There was a problem hiding this comment.
False positive:
This path is used as an include in xinetd.... If you control a xinetd include directive, you can already run arbitrary code?
I'm not sure what would be a safe guardrail here.... Removing .. and all would break real configs?
edznux-dd
force-pushed
the
fix/xinetd-probe-memory-safety
branch
from
68e1aff to
23da35c
Compare
|
3 participants
Hi! this is another (and I believe last! 😅 ) followup of #2361
This time I tried to focus on the probe part. This was my focus after investigating a few more crashes (segfault) that we discovered internally.
Some of these parsers are quite complex, but i've tried to keep the change simple and minimal.
I've decided to invert the condition for
as otherwise, the
Skipping (name, protocol) translation for servicebranch would have needed agoto(because of the strcpy)I've added regression test + reproducer inputs for the fuzz harnesses as well.
A few fuzz harnesses have been added as a new commit of the PR #2365
I believe this covers a big part of the "probes" of openscap and should help with the reliability during the parsing of arbitrary data.
The fuzzers were compiled with multiple sanitizer, so it discovered a few uninitialized variable and other UB.
Note:
I am aware of #2349 but this supersedes that PR by fixing other bugs:
l_size = inlenon no-newline line -> heap-overflow memcpy (scanner, section)for(;;)unbounded read past inmem*strchr(buf,' ')NULL-deref on embedded-NUL content (two sites)xiconf_parse_sectionentry guard (inoff >= inlen reads past buffer)xiconf_service_free-> stack overflow (we made it iterative)scur->type = ""literal later free()'d -> invalid free + leakop_assign_strleak on repeated attributeHappy to collaborate if you believe the PR 2349 should be merged first.
Thank you!