I reviewed bpfcc 0.29.1+ds-1ubuntu2 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
- CVE History
- no CVEs tracked in UCT, initially
- searching for "bcc" CVEs finds false-positives
- Build-Depends
- nothing concerning
- pre/post inst/rm scripts
- typical dh_python3 for python3-bpfcc
- init scripts
- none
- systemd units
- none
- dbus services
- none
- setuid binaries
- none
- binaries in PATH
- numerous. +220.
- sudo fragments
- none
- polkit files
- none
- udev rules
- none
- unit tests / autopkgtests
- some added
- cron jobs
- none
- Build logs
- hardening-no-pie is not a concern in this case
- manual page warnings
- W: libbpfcc: package-name-doesnt-match-sonames libbcc-bpf0 libbcc0
- Processes spawned
- popen use looks okay
- system("clear") is fine
- memleak.c uses fork, etc
- Memory management
- extremely heavy use
- in context, I am not concerned with occult practices in this package
- File IO
- heavy use
- Logging
- extremely heavy use
- Environment variable usage
- none
- Use of privileged functions
- Security's MIR tooling finds many false-positives
- vmlinux headers are fine
- Use of cryptography / random number sources etc
- none
- vminux*.h sets certificate configs
- Use of temp files
- tmp race conditions possibly allow unauthenticated users to control unpacked kernel headers
- Resolved quickly by upstream! CVE-2024-2314
- see related issue in bpftrace MIR (LP#2052809)
- Use of networking
- heavy use
- Use of WebKit
- none
- Use of PolicyKit
- none
- Any significant cppcheck and Covreity results
- bugs found (memory leaks etc), but not concerned about these being vulnerabilities in context
- parsing untrusted data (e.g., network traffic) could possibly lead to exploitation
- coverity.txt attached
- Any significant shellcheck results
- not concerning
- Any significant bandit results
- none
- subprocess calls cannot be controlled without root access
- Any significant govulncheck results
- none
- Any significant Semgrep results
- none
- complaints about system() and strtok excused in context
There is 986,872 loc. Security's review is limited.
As with bpftrace, these are admin tools which require root access. It is unlikely that most bugs in bpfcc would cause a loss of security and become a vulnerability; root already has control. Parsing untrusted data with a root process can lead to trouble. This review expects that developers will want to use these tools and that system administrators will make wise choices.
Some binaries do not work out of box. This needs testings. e.g., /usr/sbin/tcptop-bpfcc from bpfcc-tools does not work, but /usr/sbin/tcptop from libbpfcc does.
Binaries from bpfcc-tools, libbpfcc, and bpftrace have redundant functions. Please consider which binaries should be made default. In particular, most bpftrace binaries are merely examples.
The bcc snap is published by Canonical and should be updated. See ./snap/README.md
Upstream was extraordinarily quick at addressing a potential security issue which was reported to them \o/
- CVE-2024-2314
Security team ACK for promoting bpfcc to main. Note that Security's ACK is for all packages generated by the bpfcc source package, the MIR Team's ACK may only be for a subset of binary packages.
I reviewed bpfcc 0.29.1+ds-1ubuntu2 as checked into noble. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
- CVE History name-doesnt- match-sonames libbcc-bpf0 libbcc0
- no CVEs tracked in UCT, initially
- searching for "bcc" CVEs finds false-positives
- Build-Depends
- nothing concerning
- pre/post inst/rm scripts
- typical dh_python3 for python3-bpfcc
- init scripts
- none
- systemd units
- none
- dbus services
- none
- setuid binaries
- none
- binaries in PATH
- numerous. +220.
- sudo fragments
- none
- polkit files
- none
- udev rules
- none
- unit tests / autopkgtests
- some added
- cron jobs
- none
- Build logs
- hardening-no-pie is not a concern in this case
- manual page warnings
- W: libbpfcc: package-
- Processes spawned
- popen use looks okay
- system("clear") is fine
- memleak.c uses fork, etc
- Memory management
- extremely heavy use
- in context, I am not concerned with occult practices in this package
- File IO
- heavy use
- Logging
- extremely heavy use
- Environment variable usage
- none
- Use of privileged functions
- Security's MIR tooling finds many false-positives
- vmlinux headers are fine
- Use of cryptography / random number sources etc
- none
- vminux*.h sets certificate configs
- Use of temp files
- tmp race conditions possibly allow unauthenticated users to control unpacked kernel headers
- Resolved quickly by upstream! CVE-2024-2314
- see related issue in bpftrace MIR (LP#2052809)
- Use of networking
- heavy use
- Use of WebKit
- none
- Use of PolicyKit
- none
- Any significant cppcheck and Covreity results
- bugs found (memory leaks etc), but not concerned about these being vulnerabilities in context
- parsing untrusted data (e.g., network traffic) could possibly lead to exploitation
- coverity.txt attached
- Any significant shellcheck results
- not concerning
- Any significant bandit results
- none
- subprocess calls cannot be controlled without root access
- Any significant govulncheck results
- none
- Any significant Semgrep results
- none
- complaints about system() and strtok excused in context
There is 986,872 loc. Security's review is limited.
As with bpftrace, these are admin tools which require root access. It is unlikely that most bugs in bpfcc would cause a loss of security and become a vulnerability; root already has control. Parsing untrusted data with a root process can lead to trouble. This review expects that developers will want to use these tools and that system administrators will make wise choices.
Some binaries do not work out of box. This needs testings. e.g., /usr/sbin/ tcptop- bpfcc from bpfcc-tools does not work, but /usr/sbin/tcptop from libbpfcc does.
Binaries from bpfcc-tools, libbpfcc, and bpftrace have redundant functions. Please consider which binaries should be made default. In particular, most bpftrace binaries are merely examples.
The bcc snap is published by Canonical and should be updated. See ./snap/README.md
Upstream was extraordinarily quick at addressing a potential security issue which was reported to them \o/
- CVE-2024-2314
Security team ACK for promoting bpfcc to main. Note that Security's ACK is for all packages generated by the bpfcc source package, the MIR Team's ACK may only be for a subset of binary packages.