一种普遍存在于java系统的缺陷 - Memory DoS (include CVE-2021-2344, CVE-2021-2371, CVE-2021-2376, CVE-2021-2378)

一、什么是DoS?

DoS是Denial of Service的简称,即拒绝服务,造成DoS的攻击行为被称为DoS攻击,其目的是使计算机或网络无法提供正常的服务。拒绝服务存在于各种网络服务上,这个网络服务可以是c、c++实现的,也可以是go、java、php、python等等语言实现。

二、Java DoS的现状

在各种开源和闭源的java系统产品中,我们经常能看到有关DoS的缺陷公告,其中大部分都是耗尽CPU类型或者业务卸载类型的DoS。耗尽CPU类型的DoS大体上主要包括“正则回溯耗尽CPU、代码大量重复执行耗尽CPU、死循环代码耗尽CPU”等。而业务卸载DoS这一类型的DoS则和系统业务强耦合,一般情况下并不具备通用性。下面用几个简单例子对其进行简单描述。

  • 正则回溯耗尽CPU

    1
    Pattern.matches(controllableVariableRegex, controllableVariableText)
  • 代码大量重复执行耗尽CPU

    1
    2
    3
    for(int i = 0; i < controllableVariable; i++) {
    //do something,e.g. consume cpu
    }
  • 死循环耗尽CPU

    1
    2
    3
    while(controllableBoolVariable) {
    //do something,e.g. consume cpu
    }
  • 业务卸载DoS(当任意用户可访问到uninstall方法的情况下,业务就可能会被恶意卸载,导致正常用户的服务被拒绝)

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    private final Set<String> availables = new HashSet();

    public void service(String type, String name) {
    if (availables.contains(type)) {
    //do service
    } else {
    //reject service
    }
    }

    public void uninstall(String type) {
    availables.remove(type)
    }

我曾经在挖掘XStream反序列化利用链的时候,也找到过可以发起“正则回溯耗尽CPU、死循环耗尽CPU”类型DoS攻击的利用链,并且最终获得了XStream的多个CVE编号标记和署名。

难道Java系统中,只存在这些类型的DoS吗?我不认为是这样的,我认为Java系统中,必然存在着大量其他类型的DoS缺陷,只是我们还没发现。当我在某一天审计一个Java系统时,灵光一闪,突然发现了一个和这些DoS类型都不一样的缺陷,并且,在通过对其他大量的Java系统审计时,它普遍存在,我知道了这是一个具有普遍性存在的缺陷 - Memory DoS

三、Java异常机制

在c、c++等语言实现的网络服务中,可能存在空指针DoS、CPU耗尽DoS等等各种各样类型的DoS,为什么在Java中,DoS的类型却少得可怜?这又不得不说起Java中的异常机制了。

Java异常在JRE源码实现中,主要分为了java.lang.Exception和java.lang.Error,它们都有一个共同的实现java.lang.Throwable。经常写Java代码的程序员,可能最不喜欢就是遇到这样的麻烦了。


(关于异常的描述,简单参考了一下runoob)

异常是程序中的一些错误,但并不是所有的错误都是异常,并且错误有时候是可以避免的。

比如说,你的代码少了一个分号,那么运行出来结果是提示是错误 java.lang.Error;如果你用System.out.println(11/0),那么你是因为你用0做了除数,会抛出 java.lang.ArithmeticException 的异常。

异常发生的原因有很多,通常包含以下几大类:

  • 用户输入了非法数据。
  • 要打开的文件不存在。
  • 网络通信时连接中断,或者JVM内存溢出。

这些异常有的是因为用户错误引起,有的是程序错误引起的,还有其它一些是因为物理错误引起的。-
要理解Java异常处理是如何工作的,你需要掌握以下三种类型的异常:

  • 检查性异常:最具代表的检查性异常是用户错误或问题引起的异常,这是程序员无法预见的。例如要打开一个不存在文件时,一个异常就发生了,这些异常在编译时不能被简单地忽略。
  • 运行时异常: 运行时异常是可能被程序员避免的异常。与检查性异常相反,运行时异常可以在编译时被忽略。
  • 错误: 错误不是异常,而是脱离程序员控制的问题。错误在代码中通常被忽略。例如,当栈溢出时,一个错误就发生了,它们在编译也检查不到的。

关于Java异常机制的描述,上述已经说得很清楚了,当出现异常的时候,往往大部分是可以被捕获处理的,但是,当出现错误的时候,意味着程序已经不能正常运行了。也就是说,我们在Java系统中产生的大部分异常,是没办法导致DoS的,只有造成了错误,才会使程序不能正常运行,导致DoS,这就是为什么在Java中,DoS的类型相对少的原因了。

翻看JRE中关于错误java.lang.Error的实现,可以看到非常非常之多,而今天的主角是java.lang.OutOfMemoryError,也就是说,我们如果能让程序产生java.lang.OutOfMemoryError错误,就可以实现DoS。大多数java程序员应该都很熟悉它,抛出java.lang.OutOfMemoryError错误,一般都出现在jvm内存不足,或者内存泄露导致gc无法回收中。

四、一种普遍存在的Memory DoS

上一节说到了,我们如果能让程序产生java.lang.OutOfMemoryError错误,就可以实现DoS,它叫Memory DoS,一种耗尽内存,导致程序抛出错误的DoS攻击。

那么,如何让一个Java系统产生java.lang.OutOfMemoryError错误呢?答案必然是“耗尽内存”!

我曾经通过简单的代码扫描工具,对多个java系统、组件进行了扫描,其中发现了大量可利用的Memory DoS缺陷,是的,这意味着我能让这些系统产生java.lang.OutOfMemoryError错误。而这些系统、组件中包含了Java SE、WebLogic、Spring、Sentinel、Jackson、xstream等等比较著名的系统和组件。

0x01 Java SE

我在对Java SE的扫描中,发现了有三个class在反序列化的时候,可以导致系统产生java.lang.OutOfMemoryError错误,对系统进行Memory DoS攻击。我马上报告给了Oracle,最终在Java SE 8u301中得到修复,并且我在2021.07的安全通知中https://www.oracle.com/security-alerts/cpujul2021.html,得到了”Security-In-Depth”的署名

image

让我们先看看Java SE 8u301的修复和修复前,它们之间的差异对比吧。

java.time.zone.ZoneRules#readExternal

修复前:

1
2
3
4
5
6
7
8
9
static ZoneRules readExternal(DataInput in) throws IOException, ClassNotFoundException {
int stdSize = in.readInt();
long[] stdTrans = (stdSize == 0) ? EMPTY_LONG_ARRAY
: new long[stdSize];
for (int i = 0; i < stdSize; i++) {
stdTrans[i] = Ser.readEpochSec(in);
}
...
}

修复后:

1
2
3
4
5
6
7
8
9
10
11
12
static ZoneRules readExternal(DataInput in) throws IOException, ClassNotFoundException {
int stdSize = in.readInt();
if (stdSize > 1024) {
throw new InvalidObjectException("Too many transitions");
}
long[] stdTrans = (stdSize == 0) ? EMPTY_LONG_ARRAY
: new long[stdSize];
for (int i = 0; i < stdSize; i++) {
stdTrans[i] = Ser.readEpochSec(in);
}
...
}

java.awt.datatransfer.MimeType#readExternal

修复前:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
String s = in.readUTF();
if (s == null || s.length() == 0) { // long mime type
byte[] ba = new byte[in.readInt()];
in.readFully(ba);
s = new String(ba);
}
try {
parse(s);
} catch(MimeTypeParseException e) {
throw new IOException(e.toString());
}
}

修复后:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public void readExternal(ObjectInput in) throws IOException,
ClassNotFoundException {
String s = in.readUTF();
if (s == null || s.length() == 0) { // long mime type
ByteArrayOutputStream baos = new ByteArrayOutputStream();
int len = in.readInt();
while (len-- > 0) {
baos.write(in.readByte());
}
s = baos.toString();
}
try {
parse(s);
} catch(MimeTypeParseException e) {
throw new IOException(e.toString());
}
}

com.sun.deploy.security.CredentialInfo#readExternal

修复前:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void readExternal(ObjectInput var1) throws IOException, ClassNotFoundException {
try {
this.userName = (String)var1.readObject();
this.sessionId = var1.readLong();
this.domain = (String)var1.readObject();
this.encryptedPassword = new byte[var1.readInt()];

for(int var2 = 0; var2 < this.encryptedPassword.length; ++var2) {
this.encryptedPassword[var2] = var1.readByte();
}
} catch (Exception var3) {
Trace.securityPrintException(var3);
}

}

修复后:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public void readExternal(ObjectInput var1) throws IOException, ClassNotFoundException {
try {
this.userName = (String)var1.readObject();
this.sessionId = var1.readLong();
this.domain = (String)var1.readObject();
int var2 = var1.readInt();
if (var2 > 4096) {
throw new SecurityException("Invalid password length (" + var2 + "). It should not exceed " + 4096 + " bytes.");
}

this.encryptedPassword = new byte[var2];

for(int var3 = 0; var3 < this.encryptedPassword.length; ++var3) {
this.encryptedPassword[var3] = var1.readByte();
}
} catch (Exception var4) {
Trace.securityPrintException(var4);
}

}

通过这三个例子,大家看出来了什么了吗?

是的,这是一种利用数组在初始化时,容量参数可控,从而存在的一种Memory DoS缺陷。当恶意用户控制了容量参数,把参数值大小设置为int最大值2147483647-2(2147483645是数组初始化最大限制),那么,在数组初始化时,JVM会因为内存不足,从而导致系统产生java.lang.OutOfMemoryError错误,实现Memory DoS。

0x02 WebLogic

我在对Weblogic的扫描中,发现了有几十个class在反序列化的时候,可以导致系统产生java.lang.OutOfMemoryError错误,对系统进行Memory DoS攻击。扫描虽然使用了几分钟,但我写报告却花了大量的时间:)。

image

image

在报告给了Oracle后,2021.07的安全通知中https://www.oracle.com/security-alerts/cpujul2021.html,我得知其被修复,并且得到了CVE-2021-2344, CVE-2021-2371, CVE-2021-2376, CVE-2021-2378四个CVE以及署名。

WebLogic中的Memory DoS和Java SE的没有太大的差别,就不一一列出来了。

com.tangosol.run.xml.SimpleDocument#readExternal(java.io.ObjectInput)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException {
int cch = in.readInt();
char[] ach = new char[cch];
Utf8Reader reader = new Utf8Reader((InputStream)in);

int cchBlock;
for(int of = 0; of < cch; of += cchBlock) {
cchBlock = reader.read(ach, of, cch - of);
if (cchBlock < 0) {
throw new EOFException();
}
}

XmlHelper.loadXml(new String(ach), this, false);
}

不过,前面WebLogic以及Java SE中,举的例子都是在数组初始化时进行的攻击的sink。实际上,还有另外一种,它就是java集合Collection,当一个Collection在初始化时,往往在其内部实现中,会初始化一个或多个数组,存储数据。那么,如果在Collection初始化时,我们可以控制它的容量参数,就能让JVM内存不足,从而导致系统产生java.lang.OutOfMemoryError错误,造成Memory DoS。

weblogic.deployment.jms.PooledConnectionFactory#readExternal

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public void readExternal(ObjectInput in) throws IOException {
int extVersion = in.readInt();
if (extVersion != 1) {
throw new IOException(JMSPoolLogger.logInvalidExternalVersionLoggable(extVersion).getMessage());
} else {
this.wrapStyle = in.readInt();
this.poolName = in.readUTF();
this.containerAuth = in.readBoolean();
int numProps = in.readInt();
this.poolProps = new HashMap(numProps);

for(int inc = 0; inc < numProps; ++inc) {
String name = in.readUTF();
String value = in.readUTF();
this.poolProps.put(name, value);
}

this.poolManager = JMSSessionPoolManager.getSessionPoolManager();
this.poolManager.incrementReferenceCount(this.poolName);
JMSPoolDebug.logger.debug("In PooledConnectionFactory.readExternal()[poolManager=" + this.poolManager + "]");
}
}

可以看到,代码中的这一行HashMap初始化,我们是可以控制它的构造参数值大小的。

1
this.poolProps = new HashMap(numProps);

现在HashMap的构造参数我们可控了,意味着,我们可以自由指定其初始化容量的大小,若其大小超过了JVM可用内存,将会导致系统产生java.lang.OutOfMemoryError错误,实现Memory DoS。

0x03 Spring

在Spring中,我对其mvc框架的源码进行了简单的审计,发现在一个HttpMessageConverter中,存在数组初始化容量参数可控的情况,当对http进行简单构造后,将能导致系统产生java.lang.OutOfMemoryError错误,实现Memory DoS。

我在报告给Spring官方后,他们认为这虽然是一个安全问题,但是理应由其他系统去对其进行限制,所以,不予修复。

image

我也向Spring开发者提供了修复的建议,但他们最终没有采纳,所以,这个安全问题依然存在,不过幸运的是,大家无需担心,因为这个漏洞的利用,需要一定的前提条件。

image

org.springframework.http.converter.ByteArrayHttpMessageConverter

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
@Override
public byte[] readInternal(Class<? extends byte[]> clazz, HttpInputMessage inputMessage) throws IOException {
long contentLength = inputMessage.getHeaders().getContentLength();
ByteArrayOutputStream bos =
new ByteArrayOutputStream(contentLength >= 0 ? (int) contentLength : StreamUtils.BUFFER_SIZE);
StreamUtils.copy(inputMessage.getBody(), bos);
return bos.toByteArray();
}

public ByteArrayOutputStream(int size) {
if (size < 0) {
throw new IllegalArgumentException("Negative initial size: "
+ size);
}
buf = new byte[size];
}

可以看到,当我们发起的http请求中,我们是可以利用Content-Length这个http header,控制byte数组的初始化容量,如果我们传入的Content-Length的大小为Long类型的最大值,将会导致系统产生java.lang.OutOfMemoryError错误,实现Memory DoS攻击。

不过想要利用这个漏洞,前提是需要开发者编写了某种实现的Controller,它需要Controller接收一个byte[]类型的参数,因为只有这样,Spring在http payload转换时,才是使用org.springframework.http.converter.ByteArrayHttpMessageConverter对其进行处理。

1
2
3
4
5
6
7
8
9
10
11
/**
* @author threedr3am
*/
@RestController
public class TestController {

@PostMapping(value = "/test")
public String test(@RequestBody byte[] bytes) {
return "ok";
}
}

0x04 Sentinel

github:https://github.com/alibaba/Sentinel

前面说了Java SE、WebLogic、Spring,但是所有无外乎都是针对数组初始化参数的攻击,那么,还有没有其他能造成系统产生java.lang.OutOfMemoryError错误的Memory DoS呢?

答案是“有”的,我在对Alibaba Sentinel进行审计的时候,发现了它的管控平台,也可以称之为注册中心(sentinel-dashboard),存在一个无需认证即可访问的http endpoint,稍加利用,就能导致系统产生java.lang.OutOfMemoryError错误。如果熟悉Sentinel的人都清楚,它是一个开源的限流熔断组件,在官方实现中,接入Sentinel的客户端,都会向注册中心进行服务注册,可能是为了降低使用、接入Sentinel的难度,这个服务注册的http endpoint是无需认证即可访问的。

这个http endpoint是/registry/machine

com.alibaba.csp.sentinel.dashboard.controller.MachineRegistryController#receiveHeartBeat

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
32
33
34
35
36
37
38
39
40
41
42
@ResponseBody
@RequestMapping("/machine")
public Result<?> receiveHeartBeat(String app,
@RequestParam(value = "app_type", required = false, defaultValue = "0")
Integer appType, Long version, String v, String hostname, String ip,
Integer port) {
if (StringUtil.isBlank(app) || app.length() > 256) {
return Result.ofFail(-1, "invalid appName");
}
if (StringUtil.isBlank(ip) || ip.length() > 128) {
return Result.ofFail(-1, "invalid ip: " + ip);
}
if (port == null || port < -1) {
return Result.ofFail(-1, "invalid port");
}
if (hostname != null && hostname.length() > 256) {
return Result.ofFail(-1, "hostname too long");
}
if (port == -1) {
logger.warn("Receive heartbeat from " + ip + " but port not set yet");
return Result.ofFail(-1, "your port not set yet");
}
String sentinelVersion = StringUtil.isBlank(v) ? "unknown" : v;

version = version == null ? System.currentTimeMillis() : version;
try {
MachineInfo machineInfo = new MachineInfo();
machineInfo.setApp(app);
machineInfo.setAppType(appType);
machineInfo.setHostname(hostname);
machineInfo.setIp(ip);
machineInfo.setPort(port);
machineInfo.setHeartbeatVersion(version);
machineInfo.setLastHeartbeat(System.currentTimeMillis());
machineInfo.setVersion(sentinelVersion);
appManagement.addMachine(machineInfo);
return Result.ofSuccessMsg("success");
} catch (Exception e) {
logger.error("Receive heartbeat error", e);
return Result.ofFail(-1, e.getMessage());
}
}

-> com.alibaba.csp.sentinel.dashboard.discovery.AppManagement#addMachine

1
2
3
4
@Override
public long addMachine(MachineInfo machineInfo) {
return machineDiscovery.addMachine(machineInfo);
}

-> com.alibaba.csp.sentinel.dashboard.discovery.SimpleMachineDiscovery#addMachine

1
2
3
4
5
6
7
8
9
private final ConcurrentMap<String, AppInfo> apps = new ConcurrentHashMap<>();

@Override
public long addMachine(MachineInfo machineInfo) {
AssertUtil.notNull(machineInfo, "machineInfo cannot be null");
AppInfo appInfo = apps.computeIfAbsent(machineInfo.getApp(), o -> new AppInfo(machineInfo.getApp(), machineInfo.getAppType()));
appInfo.addMachine(machineInfo);
return 1;
}

通过跟踪上述代码,可以看到,用户提交的数据,径直得往内存中存储。因为这个http endpoint支持GET、POST请求,所以当我们在发送http请求中使用POST方式,并且在body中添加非常大的数据,比如app参数,放一个1MBytes或者10MBytes,亦或者更大的数据,那么,将会导致服务端内存耗尽,而产生java.lang.OutOfMemoryError错误,实现Memory DoS。

0x05 注意之处

有的读者在测试数组初始化Memory DoS的时候,发现虽然可以使系统产生java.lang.OutOfMemoryError错误,但是系统并没有因此而崩溃,实现完整的Memory DoS,这是什么原因呢?

且看下面这三个例子:

  • 完整Memory DoS

    1
    2
    3
    4
    5
    6
    private byte[] bytes;

    public ? service(int size) {
    bytes = new byte[size];
    //do something
    }
  • 一定时间内的Memory DoS

    1
    2
    3
    4
    public ? service(int size) {
    byte[] bytes = new byte[size];
    //do 5s something
    }
  • 短暂的Memory DoS

    1
    2
    3
    4
    public ? service(int size) {
    byte[] bytes = new byte[size];
    //do 100ms something
    }

在看完这三个例子之后,我相信大部分熟悉JVM gc机制的人都能立马懂了,其实这就是共享变量引用对象和局部变量引用对象之间的区别。

因为JVM的gc机制是根据对象引用来确定对象内存是否需要被回收的,而这里,我们初始化的数组对象如果是局部变量引用,并且仅有局部变量引用,那么,这就意味着,当这个线程栈执行完成之后,如果引用已经不存在了,那么JVM在执行gc的时候就会回收这一块内存,所以,单独这样我们只能得到短暂时间内的Memory DoS,可能是5秒(已经比较优质了),也可能只有0.1秒,没办法完全实现Memory DoS,而只有让这个对象生命周期足够长,或者引用一直存在,那么,在其生命周期内,我们才能长时间占用JVM堆足够多的内存,让JVM无法回收这部分内存,从而实现Memory DoS。

还有一个最重要的点,JVM对应数组初始化的大小是有限制的,最大数组长度是2147483645,约等于2047.999997138977051MBytes,所以,如果遇到可控共享变量引用对象的场景,我们只能控制一个对象数组大小,一旦JVM最大可用堆内存远比其数组大的话,对于实现Memory DoS也是比较难的。

五、总结

  • java中只要能产生Error,大概率就能造成DoS
  • 通过控制数组Array、集合Collection初始化容量参数,可以实现Memory DoS
  • 往集合Collection中插入大量的垃圾数据,也可以实现Memory DoS

由于这篇文章实际上没什么硬核的东西,所以,就不写太多的例子了,以免又臭又长。