SpringWebFlow远程代码执行漏洞分析

1.漏洞描述

• 漏洞编号： CVE-2017-4971
• 漏洞简述： 由于Spring的框架越来越多，而且后面引入了SpringEl作为默认的表达式解析方式，所以一旦引入了类似于OGNL的表达式，很可能会带来一些安全问题，本次漏洞就是由于Spring WebFlow的数据绑定问题带来的表达式注入，从而导致任意代码执行。
• 影响版本： Spring Web Flow 2.4.0 to 2.4.4

2.?漏洞简介

??该漏洞在2017年5月31号被提交到https://pivotal.io/security/cve-2017-4971平台，官方并没有详细的信息，通过官方描述和补丁的对比，我们可以大致推断应该是Spring WebFlow在Model的数据绑定上面，由于没有明确指定相关model的具体属性导致从表单可以提交恶意的表达式从而被执行，导致任意代码执行的漏洞，这个漏洞利用除了版本的限制之外还有两个前置条件，这两个前置条件中有一个是默认配置，另外一个就是编码规范了，漏洞能不能利用成功主要就取决于后面的条件。

??整体来说这个漏洞危害应该还是有一些的，如果满足2个前置条件，那么直接RCE是没什么问题的。在分析这个漏洞之前需要一些Spring Webflow的基础知识，给大家推荐这篇文章https://www.ibm.com/developerworks/cn/education/java/j-spring-webflow/index.html。

3.?漏洞原理分析

3.1 ?源码补丁分析

??首先我们可以从Spring Web Flow官网找到Spring Web Flow源码github地址，然后通过找到补丁提交的源代码主要在spring-webflow/src/main/java/org/springframework/webflow/mvc/view/AbstractMvcView.java文件中修改，查看和上一个版本的源码比较：

3.2 源码分析

??我们发现这里对 addEmptyValueMapping(DefaultMapper mapper, String field, Object model) 这个方法里面表达式解析的实现类进行了替换，直接使用了BeanWrapperExpressionParser来解析，关于这个类我们后面再详细说，那么知道触发漏洞的函数后，我们就可以用MyEclipse来跟踪下函数调用栈，具体如下：

??通过调用关系我们可以发现一共有一下两个函数调用了addEmptyValueMapping方法

• addDefaultMappings(DefaultMapper mapper, Set parameterNames, Object model)
• addModelBindings(DefaultMapper mapper, Set parameterNames, Object model)

??这里通过调用关系我们可以大概的搞明白Spring WebFlow的执行顺序和流程，由flowcontroller决定将请求交给那个handler去执行具体的流程，这里我们需要知道当用户请求有视图状态处理时，会决定当前事件下一个执行的流程，同时对于配置文件中我们配置的view-state元素，如果我们指定了数据的model，那么它会自动进行数据绑定，xml结构如下(这里以官方的example中的book项目为例子):

??本次漏洞出现的原因就是在view-state节点中数据绑定上，我们继续跟踪addEmptyValueMapping方法的调用过程，这里通过eclipse我们可以发现bind方法间接的调用了addEmptyValueMapping函数，

到这里我们知道了addEmptyValueMapping函数存在表达式执行的点，我们现在来详细看下这个addEmptyValueMapping函数，如下图

??这里我们可以看见，只有控制了field参数才能出发漏洞，所以我们重点是找到有没有点我们可以控制从而控制field参数来进行任意代码执行，这里明确目标后，我们回过头来看addDefaultMappings和addModelBindings这两个函数，既然这两个函数都调用了存在缺陷的函数，那么我们看看这两个函数的区别是什么，而且那个函数能能能控制field参数，两个函数的区别如下

addDefaultMapping函数

    /**
     * Adds a {@link DefaultMapping} between the given request parameter name and a matching model field.
     *
     * @param mapper the mapper to add the mapping to
     * @param parameter the request parameter name
     * @param model the model
     */
    protected void addDefaultMapping(DefaultMapper mapper, String parameter, Object model) {
        Expression source = new RequestParameterExpression(parameter);
        ParserContext parserContext = new FluentParserContext().evaluate(model.getClass());
        Expression target = expressionParser.parseExpression(parameter, parserContext);
        DefaultMapping mapping = new DefaultMapping(source, target);
        if (logger.isDebugEnabled()) {
            logger.debug("Adding default mapping for parameter '" + parameter + "'");
        }
        mapper.addMapping(mapping);
    }

addModelBindings函数

    /**
         * <p>
         * Adds a {@link DefaultMapping} for every configured view {@link Binding} for which there is an incoming request
         * parameter. If there is no matching incoming request parameter, a special mapping is created that will set the
         * target field on the model to an empty value (typically null).
         * </p>
         *
         * @param mapper the mapper to which mappings will be added
         * @param parameterNames the request parameters
         * @param model the model
         */
        protected void addModelBindings(DefaultMapper mapper, Set<String> parameterNames, Object model) {
            for (Binding binding : binderConfiguration.getBindings()) {
                String parameterName = binding.getProperty();
                if (parameterNames.contains(parameterName)) {
                    addMapping(mapper, binding, model);
                } else {
                    if (fieldMarkerPrefix != null && parameterNames.contains(fieldMarkerPrefix + parameterName)) {
                        addEmptyValueMapping(mapper, parameterName, model);
                    }
                }
            }
        }

??这里比较明显的区别就是addModelBindings函数中 for (Binding binding : binderConfiguration.getBindings()) 存在这样一个循环，而且就是这个循环的控制决定了field参数的值，经过进一步分析，这里控制field的参数的决定性因素就是binderConfiguration这个变量所控制的值，这里经过源码的跟踪我们可以发现，binderConfiguration函数的值就是webflow-*.xml中view-state中binder节点的配置，所以这个函数的值来源于配置文件，所以这个函数我们无法控制，从而无法触发漏洞，所以我们重点来看看addDefaultMappings这个函数，我们发现addDefaultMappings中我们可以控制field参数，所以我们重点来看看如何去触发这个函数。

??现在我们基本上可以确定了addDefaultMappings函数是我们触发漏洞的关键点，那么如上图所示，bing函数中调用了这两个函数，那么我们可以看出只有当binderConfiguration为空的时候才能触发我们的漏洞，那么我们刚才也说了binderConfiguration这个值是由配置文件中是否有binder节点来控制的（这里需要注意的是程序执行到bind方法的前置条件是view-state节点中是否配置了model属性，即绑定的javabean对象是什么），而且addDefaultMappings函数中paramete