I reviewed jitterentropy-library 3.6.3-1 as checked into stonking. This
shouldn't be considered a full audit but rather a quick gauge of
maintainability. I did read the whole of src/ and the two public headers,
but did not attempt to validate the SP800-90B entropy claims themselves,
which is a certification exercise rather than a code review.
jitterentropy-library is Stephan Müller's userspace "CPU Jitter RNG", the
userspace sibling of the kernel's crypto/jitterentropy.c: a noise source
designed for SP800-90B compliance that times a fixed workload with a
high-resolution counter and conditions the time deltas through an
in-tree SHA3-256, with the SP800-90B health tests and power-on
self-tests built in.
- CVE History
- None (UCT, NVD, Debian security tracker). The only "jitterentropy"
CVEs on record are against the Linux kernel's own implementation.
- Upstream has a SECURITY.md recording one issue (an RCT health-test
bug, fixed in 3.6.2 without a CVE; 3.6.3 has the fix).
- Build-Depends
- debhelper-compat (= 13) only; runtime NEEDED is libc.so.6 only. No
crypto library: the SHA3-256 conditioning hash is in-tree.
- pre/post inst/rm scripts
- None.
- init scripts
- None.
- systemd units
- None shipped. The one .service in tests/ (kernel boot-time raw entropy
recording) is not packaged.
- dbus services
- None.
- setuid binaries
- None.
- binaries in PATH
- None.
- sudo fragments
- None.
- polkit files
- None.
- udev rules
- None.
- unit tests / autopkgtests
- No build-time tests and no autopkgtest.
- cron jobs
- None.
- Build logs
- Clean, no compiler warnings; lintian on the .debs is clean.
- Upstream deliberately builds at -O0 (the entropy assessment depends
on the timed loops not being optimised), which makes
-D_FORTIFY_SOURCE inert. Acceptable here: no string handling, all
memcpy sizes are constant or bounded. Stack protector, RELRO/BIND_NOW
and CET are in place.
- Processes spawned
- None.
- Memory management
- Small and defensive: allocations are zeroed on alloc and wiped on
free, buffers are fixed-size or explicitly capped, and each copy to
the caller is at most the 32-byte digest block.
- File IO
- Read-only, fixed paths: /proc/sys/crypto/fips_enabled (FIPS
detection) and CPU cache sizes from sysfs in a fallback not compiled
on glibc. No writes. It never reads /dev/urandom or calls
getrandom(); it has no dependency on the kernel RNG.
- Logging
- None in the library. Errors are returned as codes.
- Environment variable usage
- None.
- Use of privileged functions
- None.
- Use of cryptography / random number sources etc
- This is a random number source, so this section is the package. The
in-tree SHA3-256 is straightforward, self-tested at init, and used
only to condition timing data. I would normally prefer a system
crypto library, but for a seed source that gets linked into
libcrypto itself, self-containment is a reasonable design choice.
- Use of temp files
- None.
- Use of networking
- None.
- Use of WebKit
- None.
- Use of PolicyKit
- None.
- Any significant cppcheck results
- 5 findings, all in tests/raw-entropy/*/extractlsb.c (unshipped
SP800-90B tooling): FILE* leaks on error exit and strtoul() on a
possibly-NULL strtok_r() result. Nothing in src/.
- Any significant Coverity results
- 2 RESOURCE_LEAK reports in the collector allocation path; I checked
them and both are false positives (the memory is owned by the
returned struct and freed on all paths).
- Any significant shellcheck results
- 170 notes/warnings, all quoting/backtick/unused-variable style issues
in tests/raw-entropy/**/*.sh. Not shipped.
- Any significant bandit results
- N/A.
- Any significant govulncheck results
- N/A.
- Any significant Semgrep results
- None. (flawfinder: nothing significant either; the library hits are
the fixed-size memcpy()s and /proc and /sys reads covered above.)
General comments:
1. Static linking is the real issue with this MIR. libjitterentropy.a is
already statically linked into libcrypto.so.4 in main (verified on
stonking's libssl4: no NEEDED entry or jent_* symbols, but the
library's constants are in the binary), and the promotion just lets
more things statically link it via libcrypto.a. Any security fix here
therefore needs a no-change rebuild of openssl (and of any other
static consumer); that coordination falls on the owning team, and
openssl should declare Static-Built-Using: on libjitterentropy.
2. The Maintainer (Eric Berry, also the Debian maintainer) has left
Canonical, so the package is effectively unmaintained in Debian too.
Ubuntu is one release behind upstream (3.6.3 vs 3.7.0, which changes
the output function). Since the copy inside libcrypto is what a FIPS
validation is done against, updates must be coordinated with the
certification team; canonical-security-certification as owner fits.
3. Upstream is a responsive single-maintainer project with a SECURITY.md
and a record of fixing issues. The code is small, with no parsers,
untrusted input, network, or privilege - about as low-exposure as a
crypto-adjacent library gets; the residual risk is in the entropy
claims, which are the FIPS team's domain.
4. Tests: the MIR team already requires a build-time test and an
autopkgtest. A smoke test that links the library, calls
jent_entropy_init() (which runs the built-in self-tests) and reads a
few KiB of entropy would be cheap and sufficient, but it must skip
rather than fail when init errors out (legitimate on builders/VMs
with coarse timers) to avoid flakiness.
5. On systems without a usable high-resolution timer the fallback spins
a thread, burning a CPU during reads - harmless, but worth knowing if
someone reports CPU burn from openssl on odd VMs.
Security team ACK for promoting jitterentropy-library to main, under the
following conditions:
- The Maintainer field is updated to a current Canonical person or team
and canonical-security-certification subscribes to the package.
- A build-time test and an autopkgtest are added (MIR team TODO #2); the
smoke test above is sufficient.
- Static linking is tracked: openssl (and any future static consumer)
must be rebuilt when this library receives a security update, and the
owning team acknowledges that responsibility. Adding
Static-Built-Using to openssl is strongly recommended.
- Updates to a new upstream version are coordinated with the FIPS
certification work, since the copy inside libcrypto is the one that is
validated.
** Changed in: jitterentropy-library (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: jitterentropy-library (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2162943
Title:
[MIR] jitterentropy-library
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/jitterentropy-library/+bug/2162943/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
