Open pwnninja opened 4 years ago
Is there a PR that fixes this issue?
Did you find this by manual inspection or by creating a fuzz target for something like AFL or libfuzzer? https://github.com/google/fuzzing/blob/master/tutorial/libFuzzerTutorial.md
Should there be a CVE? It looks like this buffer overflow allows ~RCE~ LCE; hopefully no packages are running netperf as root.
Are there any (default or additional) build flags that can help prevent exploitation of the identified vulnerability? Note that different distros add different default build flags through default Make environment variables.
https://awesome-safety-critical.readthedocs.io/en/latest/#coding-guidelines
Is this a CWE-120 or a CWE-119 or similar?
"CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')" https://cwe.mitre.org/data/definitions/120.html
"CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer" https://cwe.mitre.org/data/definitions/119.html
Is there a FOSS static analysis tool that could be added to the build that would detect is it a strcpy
where it should pretty much always be a ~strncpy
~ strncpy_s
?
https://github.com/analysis-tools-dev/static-analysis/blob/master/README.md
"Secure Coding in C and C++: Strings and Buffer Overflows" describes use of strncpy_s
.
https://www.informit.com/articles/article.aspx?p=2036582&seqNum=5#
Would strncpy_s
fix this vuln or is there a better approach?
FWIW, you can monospace format code
```bash
$ echo "like this"
void main() {
sprint("like this");
}
And inline like this
and like this
```bash
$ echo "like this"
void main() {
sprint("like this");
}
And inline like this
and like this
And you can include code snippets by adding a link to the source blob followed by a line range: #L111-L117; which you can specify by clicking a line number and then shift-clicking an ending line number.
Pressing y
will change a branch/tag link into a commit hash link to stable source so that the line numbers will always point to the code you're transcluding.
You can also / instead click the line number and then select 'Copy permalink':
https://github.com/HewlettPackard/netperf/blob/bcb868bde7f0203bbab69609f65d4088ba7398db/src/netsh.c#L642-L650
hopefully no packages are running netperf as root.
In OpenWrt, typically used as single-user system, netperf's netserver runs as root. https://openwrt.org/packages/pkgdata/speedtest-netperf @guidosarducci
hopefully no packages are running netperf as root.
In OpenWrt, typically used as single-user system, netperf's netserver runs as root. openwrt.org/packages/pkgdata/speedtest-netperf @guidosarducci
https://openwrt.org/packages/pkgdata/netperf
- `podman run --rm --name=openwrtr1 -it -h routerr1 --cap-add NET_ADMIN -v $(readlink -e ./entrypoint.sh):/entrypoint.sh:ro openwrtorg/rootfs` - There's a procd-selinux now: - https://github.com/openwrt/openwrt/blob/openwrt-21.02/package/system/selinux-policy/Makefile - https://github.com/openwrt/openwrt/blob/master/package/system/selinux-policy/Makefile - https://github.com/openwrt/openwrt/blob/master/package/system/procd/Makefile lists: - procd-ujail - procd-seccomp - procd-selinux - https://git.openwrt.org/?p=project/procd.git;a=tree - jail/* - uxc.c - Note that to *correctly* use containers *AND* SELinux, there are special container labels like `container_file_t` which are defined in the container-selinux package: - https://github.com/containers/container-selinux - https://github.com/k3s-io/k3s/issues/1372#issuecomment-581797716 - Note that: - There's no good reason for netperf to be running as root. - And, to run a non-root process on a port lower than 1024, you can have the appropriately confined process attach to a non-root port > 1024 and then port forward to that non-root process. - OpenWRT now ships netperf > 2.6.0 (which should be patched for *this* vuln) but without advanced procd features (e.g. install a different procd package that `PROVIDES` procd), nothing would limit another such vuln in netperf (or other processes running as root) from [remotely] executing arbitrary unsigned code as root.
Netperf 2.6.0 s a benchmark tool than developed by Helett Packard that can be used to measure the performance of many different types of networking. It provides tests for both unidirectional troughput and end-to-end latency. Stack-based buffer overflow vulnerability in function scan_cmd_line() allows local attackers to cause a denial of service(application crash) or get a system shell(by ROP when canary protection disabled).
POC: root@iZp6mmjqib52f6Z:~# netperf -a `python -c 'print "A"*8220+"DCBA"'` stack smashing detected : netperf terminated Aborted (core dumped)
Vulnerability in src/netsh.c: line 633 in function scan_cmd_line(): ``
When command line argument starts with '-a', the string optarg is copied to arg1 and arg2 via function break_args(), causing a stack-based buffer overflow. When attackers try to exploit the vulnerability, if __stack_chk_fail is enabled, the program checks stack canary and exits. Otherwise, the program returns to constructed RIP(shellcode address or ROP address) and attackers may get a shell via system('/bin/sh').