I reviewed openjdk-25 25.0.4.1+1-1 as checked into stonking. This shouldn't be
considered a full audit but rather a quick gauge of maintainability.
openjdk-25 is the OpenJDK 25 LTS implementation of the Java SE platform. It
provides a C/C++ HotSpot JVM (C1/C2 server compiler and an interpreter-only
"zero" VM), the java launcher (libjli.so) and C support libraries (libjava.so,
libjvm.so, libawt.so, libj2gss.so, libj2pcsc.so, libj2pkcs11.so,
libfontmanager.so and others), plus the Java class library (java.base,
java.desktop and other modules). The runtime is a general purpose library: no
daemon, no privileged component, no default network service. It ships as
openjdk-25-jre-headless (JVM plus core class library), openjdk-25-jre (adds
AWT/Swing), openjdk-25-jdk-headless (javac and langtools), openjdk-25-jdk (full
JDK), plus openjdk-25-doc, openjdk-25-source, openjdk-25-dbg, openjdk-25-demo,
openjdk-25-testsupport and openjdk-25-jre-zero (s390x boot JDK). Tools are
exposed in /usr/bin via update-alternatives (java, javac, jar, keytool and the
rest of the JDK tooling).
- CVE History
- The changelog covers 34 upstream releases for openjdk-25 with 302 unique
CVEs listed (365 CVE mentions), all fixed by adopting upstream release
builds. Upstream (OpenJDK security group, coordinated by Oracle) publishes
quarterly security releases - the response model is the regular upstream
release cycle.
- Build-Depends
- debhelper, m4, lsb-release, zip, unzip, sharutils, gawk, cpio, procps,
wdiff, pkgconf, fastjar, time, strip-nondeterminism, debugedit, autoconf,
automake, ant, g++-16, a boot JDK (openjdk-25-jdk-headless:native |
openjdk-24-jdk-headless:native), test-only (nocheck) jtreg8,
libtestng7-java, xvfb, xauth, xfonts-base, xfwm4, dbus-daemon,
libasmtools-java and the development headers for the AWT stack: libxtst,
libxi, libxt, libxaw7, libxrender, libxinerama, libxrandr, libcups2-dev,
libasound2-dev, liblcms2-dev, libkrb5-dev, xsltproc, libpcsclite-dev,
libelf-dev, libfontconfig-dev, libfreetype-dev, libharfbuzz-dev, libffi-dev,
zlib1g-dev, libattr1-dev, libpng-dev, libjpeg-dev, libgif-dev,
systemtap-sdt-dev. Sensitive libraries: libkrb5 (Kerberos), libpcsclite
(smart cards), X11 and font stack (AWT 2D), cups (printing), alsa (audio).
Notably, no libssl/OpenSSL: ldd on the freshly built libjvm.so shows only
libstdc++, libm, libgcc_s and libc, so the package has no shared system
crypto dependency. The crypto stack is in-tree (JCA providers SUN, SunEC,
SunJSSE, SunJCE etc.).
- pre/post inst/rm scripts
- Present only in the jre, jre-headless, jdk and jdk-headless packages
jre-headless postinst: creates /etc/.java/.systemPrefs with mode 755 and the
.system.lock/.systemRootModFile files with mode 644 (with existence checks);
registers java/jpackage/keytool/rmiregistry and the JDK tools via
update-alternatives (priority 2511, man page slaves); registers the jexec
jar binfmt handler via update-binfmts with "|| true" (ignore errors); raises
the update-ca-certificates-java dpkg trigger. prerm removes the alternatives
and the binfmt entry; postrm (purge) removes the cached compiled classes
(classes.jsa). Scripts use set -e, all input is dpkg-provided or hardcoded,
no eval of untrusted input, no shell injection patterns and pre- and post-
operations are symmetric.
- init scripts
- None
- systemd units
- None
- dbus services
- None
- setuid binaries
- None
- binaries in PATH
- /usr/bin/java, jpackage, keytool, rmiregistry from openjdk-25-jre-headless;
/usr/bin/jconsole from openjdk-25-jdk; and the JDK tools from
openjdk-25-jdk-headless: javac, jar, jarsigner, javadoc, javap, jcmd, jdb,
jdeprscan, jdeps, jfr, jhsdb, jimage, jinfo, jlink, jmap, jmod, jnativescan,
jps, jrunscript, jshell, jstack, jstat, jstatd, jwebserver, serialver; plus
/usr/bin/jexec (jar binfmt launcher) via alternatives. All are root owned,
mode 755, no setuid or capabilities and all run as the invoking user.
- sudo fragments
- None
- polkit files
- None
- udev rules
- None
- unit tests / autopkgtests
- debian/tests runs the upstream jtreg suites: jdk-autopkgtest.sh,
hotspot-autopkgtest.sh, langtools, jaxp, jtdiff-autopkgtest.sh and
dependencies.sh, driven by jtreg-autopkgtest.in with jtreg8; known failures
are excluded via problems.csv and the suites are marked flaky/skippable
(xvfb and xfwm4 are required for the desktop tests). Upstream jtreg tests
also run during the build - in this build 24 tests failed, in the
gc/arguments (8, RAM dependent), gtest (NMTGtests and GTestWrapper),
java/lang (ProcessBuilder Basic, StackWalker), java/net (InetAddress
CheckJNI, Socket LinkLocal, httpclient ConnectTimeoutWithProxy),
runtime/CompressedOops (2), runtime/cds (DifferentHeapSizes) and tools/jlink
(AddOptionsTest) suites. Per the bug report, test failures do not fail the
build and the maintainer reviews the logs before a security upload - the
observed failures are attributed to the LP test infrastructure (sandboxed
network, RAM assumptions) etc.
- cron jobs
- None
- Build logs
- Hardening flags are in effect: -fstack-protector-strong,
-D_FORTIFY_SOURCE=3, -fcf-protection, -fstack-clash-protection and PIE.
Compiler warnings are benign: rehash warnings about ca-certificates.crt
containing more than one certificate, a Python SyntaxWarning in
debian/copyright-generator and a pandoc version warning (3.11 vs recommended
2.19.2). The "errors" section is mostly build command lines and test failure
entries matching "Error" in file names, plus one harmless CDS build-time
message (shared archive file processing error, falling back to non-optimized
module handling). dpkg_warnings are cosmetic metadata issues (unusual owner
of the build-deps resolver directory, dpkg-shlibdeps diversions and "cannot
extract name and version" notices for the unversioned libjli.so/ libjvm.so
style names and "could avoid a useless dependency" notices for libgcc_s and
libz). No gcc warnings indicating buffer overflows, format string problems
or uninitialized use in the shipped code.
- Processes spawned
- C: the runtime exec paths are os::fork_and_exec in
src/hotspot/os/posix/os_posix.cpp using posix_spawn("/bin/sh", ...), invoked
from vmError.cpp only on a VM fatal error to process the --ErrorFile command
(built from JVM flags, operator controlled) and childproc.c in libjava, the
native child process helper for the public java.lang.ProcessBuilder API
which executes the command supplied by the calling application with an
explicit argv (falling back to /bin/sh only when the requested program
cannot be exec'd). No system()/popen() in the runtime code paths and no
shell injection from untrusted input: exec uses explicit argv.
- Java: the documented Runtime.exec/ProcessBuilder API (tests and tools).
- Memory management
- Large C/C++ code base: Java objects are managed by the GC, native code uses
standard C library allocations plus VM resource areas (arena allocators for
G1, Shenandoah etc.). cppcheck memleak-family findings (9 memleak, 2
memleakOnRealloc, 5 resourceLeak) are concentrated in vendored third-party
code (libharfbuzz, libfreetype font scalers in java.desktop:
X11FontScaler_md.c, sunFont.c, awt_InputMethod.c), libzip zip_util.c
(realloc failure path) and libsleef test utilities (addSuffix.c), plus gtest
test code (arrayIndexOutOfBounds, integerOverflow), all long standing
upstream code.
- File IO
- Paths are determined by JVM configuration (jvm.cfg, java.home, system
properties), font file lookup and image decoding; user data file access goes
through the Java File API with access checks on the Java side. umask: the
postinst creates /etc/.java/.systemPrefs with -m 755 and the lock files with
mode 644; the per-user /tmp/hsperfdata\_<uid> directory is created by the
JVM with the default umask.
- Logging
- VM error output via tty/out::print with fixed format strings and the unified
-Xlog logging (src/hotspot/share/log). Java: java.util.logging (JUL) with
the packaged conf/logging.properties. No user controlled format strings in
src (sampled hits are fixed strings with arguments).
- Environment variable usage
- standard getenv/putenv for JAVA_HOME, TMPDIR, LANG etc. Java: System.getenv:
Values are used for path and locale configuration - env values are not
passed to exec and no shell interpolation of env input was observed in the
sampled hits.
- Use of privileged functions
- fchmod/chmod/chown in FileSystemPreferences (java.util.prefs),
attachListener (attach file) and cds filemap (standard user privileges),
SIOCGIF\* ioctls in NetworkInterface and spa ioctl wrappers in the pipewire
audio headers - no setuid/setgid calls (the only setuid hit in src is a
comment); no open of privileged device nodes. Java: FileSystemPreferences
chmod, ZipEntry external attribute handling and jline ioctl, all standard
user-level operations, not OS privilege escalation.
- Use of cryptography / random number sources etc
- The JCA/JCE crypto stack is in-tree (providers: SUN, SunRsaSign, SunEC,
SunJSSE, SunJCE, SunJGSS, SunSASL, XMLDSig, SunPCSC, JdkLDAP, JdkSASL,
SunPKCS11; conf/security/java.security in the jre-headless package). RNG:
securerandom.source=file:/dev/random and
securerandom.strongAlgorithms=NativePRNGBlocking:SUN, DRBG:SUN (NIST DRBG).
TLS defaults are conservative: jdk.tls.disabledAlgorithms disables SSLv3,
TLSv1, TLSv1.1, DTLSv1.0, RC4, DES and 3DES and the certpath property
disables MD2, MD5 and weak RSA. crypto.policy=unlimited is the standard
unlimited-strength JCE setting. No system OpenSSL linkage: libjvm.so links
only against libc/libm/libstdc++. PKCS11 is used via libj2pkcs11.so (dlopen
on demand). Native crypto C in the Linux build is minimal (mscapi is Windows
only, libsleef is a SIMD math library).
- Use of temp files
- C: get_temp_directory() returning /tmp and hsperfdata files named
/tmp/{PERFDATA_NAME_user} (perfMemory_posix.cpp, a predictable per-user name
in a per-user directory - standard JVM attach model).
- Java: File.createTempFile and friends under java.io.tmpdir - with unique
names.
- Use of networking
- C: HotSpot os_linux sockets/epoll and jdk.net native support
(java.net.Socket, DNS, jdk.httpserver). Java: the full java.net stack
(Socket, in-tree sun.security.ssl TLS with SAN/CN hostname verification,
SMTP, LDAP via the JdkLDAP provider). Received data is treated as untrusted
by the protocol implementations. It is not a web application: jwebserver is
an opt-in JDK test tool and rmiregistry is a user started RMI registry -
neither of which is a privileged service.
- Use of WebKit
- None
- Use of PolicyKit
- None
- Any significant cppcheck results
- 1139 warnings. Distribution: src/hotspot 625, src/java.desktop 302,
test/hotspot 71, googletest 58, src/java.base 22, src/jdk.incubator.vector
21, remainder in other trees. Top checks: unknownMacro 692 and syntaxError
101 (missing preprocessor definitions, mostly GTEST macros, false
positives), returnTempReference 61, uninitvar 43, nullPointer 12, memleak 9,
memleakOnRealloc 2 (zip_util.c and libsleef addSuffix.c realloc failure
paths), arrayIndexOutOfBounds and integerOverflow in gtest test code only.
The majority are false positives from running cppcheck without full macro
configuration over vendored third-party code (freetype, harfbuzz, sleef,
googletest) and test code.
- Any significant Coverity results
- 0 defects
- Any significant shellcheck results
- Top files: make/scripts/compare.sh (568), bin/idea.sh (109),
make/scripts/update_copyright_year.sh (85),
test/jdk/tools/launcher/MultipleJRE.sh (84),
make/devkit/createWindowsDevkit.sh (80), make/scripts/lic_check.sh (78),
test/jdk/com/sun/jdi/JdbReadTwiceTest.sh (55), make/autoconf/configure (51).
Top codes are SC2086 (1652, unquoted expansion in build/test scripts),
SC2006 (213), SC2317 (107), SC2034 (70) and SC2181 (39). All in build system
and test scripts.
- Any significant bandit results
- None
- Any significant govulncheck results
- N/A, no Go code
- Any significant Semgrep results
- None
The package builds with full hardening flags (-fstack-protector-strong,
-D_FORTIFY_SOURCE=3, -fcf-protection, -fstack-clash-protection, PIE) and the
runtime has no privileged component: no setuid binaries, no capabilities, no
daemons, no polkit/sudo/udev/cron and no D-Bus services, so the attack surface
is limited to user space processes started by the user. The crypto stack is
in-tree with no system OpenSSL linkage, keeping the shared library surface to
the core libc/libm/libstdc++ plus the X11, font, alsa and cups libraries used by
AWT. The residual risk is inherent to the product's purpose: parsing untrusted
input (class files, images, fonts, network protocol implementations, PKCS11),
which is somewhat mitigated by the GC and defensive design, the quarterly
upstream security release cycle and the large deployment base. Regarding the
previous MIR note on use of sudo and LD_LIBRARY_PATH: in this package sudo
appears only in jtreg test code (test/jdk permission tests) and LD_LIBRARY_PATH
only in the test/autopkgtest harness - the shipped runtime does not use sudo.
Security team ACK for promoting openjdk-25 to main.
** Changed in: openjdk-25 (Ubuntu)
Status: New => In Progress
** Changed in: openjdk-25 (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2138526
Title:
[MIR] openjdk-25 (non-blocking)
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openjdk-25/+bug/2138526/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
