Community
Participate
Working Groups
I've opened this bug on behalf of a community member. The bug is marked for "committers only". Matthew, please describe your issues as comments here and we'll move them to the right place.
Created attachment 274007 [details] node.js script that performs the attach and hosts it's own server
Created attachment 274008 [details] sysv semaphore c code called by js script
NCC Group Security Advisory https://www.nccgroup.trust -------------------------------------------- IBM/Eclipse OpenJ9 - Multiple Vulnerabilities in Attach API Vendor: IBM, Eclipse Foundation Vendor URL: https://github.com/eclipse/openj9/ Versions affected: 687c3129 and likely all other versions Systems Affected: Linux/Unix, Windows (partially), possibly others Author: Jeff Dileo <jeff.dileo[at]nccgroup[dot]trust> Advisory URL / CVE Identifier: TBD Risk: High (Local Privilege Escalation) Summary: -------- OpenJ9 is a Java Virtual Machine developed by IBM and the Eclipse Foundation powering several IBM software products. As a JVM that supports the Java "Attach API," OpenJ9 implements a custom underlying protocol for debuggers and other analysis and instrumentation tooling to connect to a running JVM. Unlike HotSpot, this particular implementation appears to be fairly cross-platform. The design and implementation of the attach protocol suffer from several weaknesses enabling arbitrary other process on the same system to inject arbitrary Java agents (native shared libraries and Java JARs) into any running OpenJ9 JVM process that has not explicitly disabled the Attach API. Locations: --------- * jcl/src/jdk.attach/share/classes/com/ibm/tools/attach/attacher/OpenJ9VirtualMachine.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/WaitLoop.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/AttachHandler.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/Attachment.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/Reply.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/TargetDirectory.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/CommonDirectory.java * jcl/src/java.base/share/classes/com/ibm/tools/attach/target/IPC.java * runtime/jcl/common/attach.c * runtime/port/sysvipc/j9shsem.c Impact: High ------- Details: -------- The Linux/Unix OpenJ9 attach implementation, which is based on a globally accessible shared directory (/tmp by default) and System V semaphores, is susceptible to several races conditions due to weak access controls, and insufficient and incorrect file path validation. These enable a malicious process running under a different user (the Attach API in general allows same-UID processes to inject arbitrary code into a running JVM) to inject or otherwise control the "replyInfo" file. This file specifies a shared secret that is used to authenticate a JVM to the "attaching" process, and the local port that the attaching process is listening on. Following the generation of this file within a process specific directory (/tmp/.com_ibm_tools_attach/<pid>/), the attaching process will obtain and post to a System V semaphore for the world-RW /tmp/.com_ibm_tools_attach/_notifier file. This will signal all JVM processes to check their attach directories for the "replyInfo" and connect via TCP to the attaching process. Once connected to the command server, the attaching process may send several administrative commands to the JVM process that execute arbitrary code with powerful capabilities within the JVM. Among a general lack of enforced permission checks, this implementation is extremely susceptible to: - Pre-created /tmp/.com_ibm_tools_attach/<pid>/ directories, enabling an attacker to write an arbitrary replyInfo file at any moment after an OpenJ9 JVM has started - A pre-created /tmp/.com_ibm_tools_attach directory, enabling a complete replacement of the /tmp/.com_ibm_tools_attach/<pid>/ during a handshake - Links manipulating /tmp/.com_ibm_tools_attach/<pid>/ directories - Links manipulating the global /tmp/.com_ibm_tools_attach directory It should be noted that the above issues do not affect OpenJ9 on Windows, which uses a non-world accessible per-user temporary directory (C:\Users\<username>\AppData\Local\Temp\.com_ibm_tools_attach). Additionally, the handshake itself suffers from a design flaw, whereby any process that can cause a legitimate attaching client to terminate during the handshake can interpose itself in that process' place. The shared key used to connect to it is also insufficient to validate the target JVM process as it is not cryptographically secure, as it is based on the java.util.Random RNG seeded with the current time. Recommendation: --------------- Due to the systematic lack of access control checks and file permission enforcement, it is unlikely that attempts to patch in such checks will be fruitful. Instead, stronger permissioning checks based on platform-specific APIs should be introduced. Where possible, use APIs that provide the capability to uniquely identify and validate processes. For example, Unix hosts supporting Unix domain sockets can validate the identity of peers through SCM_CREDENTIALS ancillary messages. Short Term Mitigation: ---------------------- OpenJ9 users should configure their `java` commands to disable the Attach API listener with the following command-line flag: * -Dcom.ibm.tools.attach.enable=no Alternatively, an alternate non-global attach directory may be configured with the following command-line flag: * -Dcom.ibm.tools.attach.directory=/path/to/priv/dir However, it should be noted that using an alternative directory will not prevent exploitation via forcibly terminated attaching processes. About NCC Group: -------------------- NCC Group is a global expert in cyber security and risk mitigation, working with businesses to protect their brand, value and reputation against the ever-evolving threat landscape. Our Security Consulting services leverage our extensive knowledge of current security vulnerabilities, penetration testing techniques and software development best practices to enable organizations to secure their applications against ever-present threats. At NCC Group we can boast unrivaled talent and recognized world-class security expertise. Bringing together best in class security consultancies iSEC Partners, Intrepidus Group, Matasano, NCC Group and NGS we have created one of the largest, most respected security consultancies in the world.
(In reply to Wayne Beaton from comment #0) > I've opened this bug on behalf of a community member. The bug is marked for > "committers only". Matthew, please describe your issues as comments here and > we'll move them to the right place. This bug is currently open to the public and indexed on Google, can you please restrict access to it?
(In reply to Jeff Dileo from comment #4) > This bug is currently open to the public and indexed on Google, can you > please restrict access to it? I've moved it back to "Community/Vulnerability Reports". It looks like OpenJ9's Bugzilla product isn't configured for "Committers only". I'll connect with Webmaster to fix that.
Matthew, thanks for raising this issue. We're looking into it and will keep this bug updated. A couple of process questions as this is the first security-defect reported against the open project: * The lead developer for Attach API works at the same company as me (IBM) but isn't yet a committer on the OpenJ9 project. Am I able to share the details of this bug with that developer to enable them to work on the fix? * Does Eclipse support private repos for projects to develop security fixes at github without having the world see the fix before it's merged? * Is there a timeline we're working against for this fix? ie: Is there a disclosure date we need to have it fixed by or will be made public (again)? Wayne, are you able to help with process questions?
(In reply to Dan Heidinga from comment #6) > * The lead developer for Attach API works at the same company as me (IBM) > but isn't yet a committer on the OpenJ9 project. Am I able to share the > details of this bug with that developer to enable them to work on the fix? Anybody that you add to the CC list should be able to see the bug. > * Does Eclipse support private repos for projects to develop security fixes > at github without having the world see the fix before it's merged? No. Frankly, we conciously make a habit of doing everything in the open, so the notion of a private repository is actually a little weird. I've opened Bug 534968 to start a conversation about how we might go about this. In the meantime, I don't have a good answer for you. > * Is there a timeline we're working against for this fix? ie: Is there a > disclosure date we need to have it fixed by or will be made public (again)? The timing of disclosure it a project decision. You're the experts. Having said that, if the bug is left in this state for more than a month or so, I'll start badgering you.
We've reproduced the problem and have a potential fix under going review now.
Wayne, how do we get a CVE # assigned to this vulnerability?
(In reply to Dan Heidinga from comment #9) > Wayne, how do we get a CVE # assigned to this vulnerability? Ask nicely. :-) I've assigned CVE-2018-12539 to this issue. When you're ready remove the confidentiality flag and push a disclosure to Mitre, let me know and provide: 1) A paragraph description of the issue 2) Versions affected 3) CWE category (http://cwe.mitre.org) I'll use this information to form a record to push to the CVE list. Note that I have to turn the committers-only flag off on this bug record before I can push. e.g. https://github.com/CVEProject/cvelist/blob/master/2017/7xxx/CVE-2017-7654.json FWIW, now that our process is stabilizing, we'll update the handbook with this information (see Bug 496426)
Not ready to remove the confidentiality flag just yet, as the fix isn't yet delivered to Eclipse OpenJ9. However, find the requested information below. 1) A paragraph description of the issue Users other than the process owner may be able to use Java Attach API to connect to an Eclipse OpenJ9 or IBM JVM on the same machine and use Attach API operations, which includes the ability to execute untrusted native code. Attach API is enabled by default on Windows, Linux and AIX JVMs and can be disabled using the command line option -Dcom.ibm.tools.attach.enable=no 2) Versions affected Eclipse OpenJ9 0.8 IBM Java 6, 6.01, 7, 7.1, 8 3) CWE category (http://cwe.mitre.org) CWE-419: Unprotected Primary Channel https://cwe.mitre.org/data/definitions/419.html
(In reply to Peter Shipton from comment #11) > IBM Java 6, 6.01, 7, 7.1, 8 We need to focus on Eclipse products. You'll have to file IBM product-related CVEs via IBM.
The fix has been delivered and is in the Eclipse OpenJ9 0.9.0 release. The release branches have their final tags and binaries will be available from AdoptOpenJDK shortly. @Wayne, I think we're ready to publish this.
I've sent a pull request to the CVE List: https://github.com/CVEProject/cvelist/pull/933
Can we mark this FIXED?
Fix has been released in the 0.9.0 release.
