Oracle Weblogic 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0 prior to the April 2023 security update are vulnerable to an unauthenticated remote code execution vulnerability due to a post deserialization vulnerability via IIOP/T3. The bug has been described in detail in a writeup by 14m3ta7k of the company GobySec at https://github.com/gobysec/Weblogic/blob/main/WebLogic_CVE-2023-21931_en_US.md, though as of the time of writing no PoC is available.

The bug is fairly similar to CVE-2023-21839 so if you haven’t read that assessment over at https://attackerkb.com/assessments/6a410f31-83c5-416b-92fd-986f2b9b2c61, I’d recommend reading that one first and then coming back here.

When receiving a request, Weblogic will parse incoming data using BasicServerRef’s invoke() method, which will in turn call _invoke(), which then calls resolve_any() based on the passed in method name of resolve_any.

In resolve_any(), the incoming binding name is resolved using resolveObject(), which will then call lookup() based on the context information.

Based on the context information, further lookup() calls are made in several classes such as WLContextImpl, WLEventContextImpl, RootNamingNode, ServerNamingNode and BasicNamingNode. All of this will eventually lead to a resolveObject() call in BasicNamingNode class.

At this point the resolveObject() method will realize the obj parameter passed into it is not an instance of the BasicnamingNode class and the mode parameter passed in will be 1 so it will call getObjectInstance() in WLNamingManager.

Finally getObjectInstance() in WLNamingManager will call getReferent() method inside the passed in object based on the object interface type, as can be seen in the screenshot below, taken from the writeup.

For CVE-2023-21931 we specifically are interested in the LinkRef interface type, instead of the OpaqueReference interface that is used by CVE-2023-21839. In particular the following code will be called when WLNamingManager’s getObjectInstance() method finds an object that is an implementation of the LinkRef interface. Code was taken from the writeup at https://github.com/gobysec/Weblogic/blob/main/WebLogic_CVE-2023-21931_en_US.md.

package weblogic.jndi.internal;
public final class WLNamingManager {
    public static Object getObjectInstance(Object boundObject, Name name, Context ctx, Hashtable env) throws NamingException {
        if (boundObject instanceof ClassTypeOpaqueReference) {
						......
        } else if (boundObject instanceof LinkRef) {
            String linkName = ((LinkRef)boundObject).getLinkName();
            InitialContext ic = null;
            try {
                ic = new InitialContext(env);
                boundObject = ic.lookup(linkName);  // vulnerability trigger point
            } catch (NamingException var15) {
              ......
            } finally {......}
        }
    }
}

Basically if an object is passed in as the boundObject variable that is an instance of the LinkRef interface, then String linkName = ((LinkRef)boundObject).getLinkName(); is called to get the link name, before it is later passed on to a lookup call with the line boundObject = ic.lookup(linkName) where the remote JNDI loading occurs.

What is important to note is that the LinkRef interface contains a constructor that allows one to set the linkAddrType variable that the getLinkName() function will return, so the input string, aka linkName, in the remote JNDI loading operation boundObject = ic.lookup(linkName), is entirely attacker controlled.

For reference here is what the constructor for a LinkRef class looks like, taken from https://github.com/gobysec/Weblogic/blob/main/WebLogic_CVE-2023-21931_en_US.md

package javax.naming;
public class LinkRef extends Reference {
    static final String linkClassName = LinkRef.class.getName();
    static final String linkAddrType = "LinkAddress";

    public LinkRef(Name linkName) {
        super(linkClassName, new StringRefAddr(linkAddrType, linkName.toString()));
    }

    public LinkRef(String linkName) {
        super(linkClassName, new StringRefAddr(linkAddrType, linkName));
    }

    public String getLinkName() throws NamingException {
        if (className != null && className.equals(linkClassName)) {
            RefAddr addr = get(linkAddrType);
            if (addr != null && addr instanceof StringRefAddr) {
                return (String)((StringRefAddr)addr).getContent();
            }
        }
        throw new MalformedLinkException();
    }
}

The code shows that its possible to instantiate a new LinkRef class with a linkName string and that getLinkName() will return the contents of addr, aka the linkName that was passed in.

Whilst there is presently no in the wild exploitation of this vulnerability, given CVE-2023-21839 is almost identical to this vulnerability and is being exploited in the wild, I’d imagine that this vulnerability will likely also be exploited in the wild shortly, particularly given that this vulnerability was only recently patched in April 2023, whereas CVE-2023-21839 was patched back in January 2023.