| Summary: | There is a stack overflower in ash of busybox. Here is asan report. | ||
|---|---|---|---|
| Product: | Busybox | Reporter: | focus <79167666> |
| Component: | Standard Compliance | Assignee: | unassigned |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | busybox-cvs |
| Priority: | P5 | ||
| Version: | 1.35.x | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: |
./busybox_unstripped < poc
shell: avoid segfault on ${0::0/0~09J}. Closes 15216 |
||
|
Description
focus
2022-12-28 08:54:16 UTC
Created attachment 9446 [details]
shell: avoid segfault on ${0::0/0~09J}. Closes 15216
This has been fixed by a different approach in https://git.busybox.net/busybox/commit/?id=d417193cf This issue started being reported as CRITICAL by security tools such as snyk https://security.snyk.io/vuln/SNYK-DEBIANUNSTABLE-BUSYBOX-5853744 For what I see the fix is not released in any version yet. What are the plans for releasing it? I am still getting a segault on busybox 1.36.1 running the expression "echo ${0::0/0~09J}" on busybox ash built on Linux (e.g. Centos 7) with the following configuration MATH variables turned off and the other MATH variables turned on:
CONFIG_FEATURE_SH_MATH_64 is not set
CONFIG_FEATURE_SH_MATH_BASE is not set
It seems that perhaps the fix is not comprehensively complete. If these MATH variables are turned on along with the other MATH variables, there is no problem.
We seem to be claiming that CVE-2022-48174 does not exist in 1.36.1 (fixed in 1.35). But this does not seem to be necessarily true.
It seems that 1.36.1 did not have the patch that fixes the problem even though the bug was marked as resolved fixed. I suspect that the various symbol definitions just moved things on the stack to sometimes cause problems with the incorrect allocation size. So I wonder why the CVE was marked as fixed in 1.35. |