AIOps 一场颠覆传统运维的盛筵
637
2022-09-24
序列化必须灭亡！（什么时候用到序列化）
本站部分文章、图片属于网络上可搜索到的公开信息，均用于学习和交流用途，不能代表睿象云的观点、立场或意见。我们接受网民的监督，如发现任何违法内容或侵犯了您的权益，请第一时间联系小编邮箱jiasou666@gmail.com 处理。
序列化必须灭亡！（什么时候用到序列化）
水中鱼儿何其多
Kryo 令人惊异之处在于，你可以用它来序列化或反序列化任何 Java 类型，未必只能是那些标记有 java.io.Serializable 的类型。在很多情况下，这大大简化了开发，例如对已有特征或无法控制的特征进行序列化。
// serializingKryo kryo = new Kryo();AcmeMessage message = buildAcmeMessage(); // some domain objectOutput out = new Output(response.getOutputStream())kryo.writeObject(out, myObject);// deserializingInput in = new Input(request.getInputStream());AcmeMessage message = kryo.readObject(in, AcmeMessage.class);
偷梁换柱
这一陷阱其实较易避开。在现实生活中，人们反复发送的任何域对象都具有集合 - 映射、列表、数组或类似数据。考虑一下以下示例对象：
/* AcmeMessage.java */private List
要紧之处便不会存在 这段代码。唯一要紧的是编译时间。攻击发生时，我正处在运行环境中。这意味着，对我们而言，应当转而按照这种方式来理解代码：
/* AcmeMessage.java */private List
因此，如果我们的目标应用程序反序列化了某个 AcmeMessage 类型，我们就可以将一些意料之外的任意类型填入接收字段，因为所有类型都扩展自 Object。这样，就像序列盛会攻击的情况一样，攻击者使用的类型必须仍然位于受害人应用程序、函数库或服务器的类路径之上。
驾驭类型集市
我们可以发送任意类型。那么，是否有限制条件呢？经典的序列化的规则并不多 - 只需要一个标记为 java.io.Serializable 的类便足矣。细查代码后，我们似乎只发现一个规则：类必须具备一个无参构造函数。现在感受到了吗？
Kryo 在较高的层面上反序列化了这一模型：
*1. 获取指定类型的零参构造函数
如果是私有构造函数，将其标为可访问调用此构造函数对于类型中的每一个字段：
反序列化消息中传递的字段（递归）将字段分配给第 3 步创建的新类型*
有很多方法将这一行为重写为更加滥用的行为，但我们先重点看看默认设置吧。我之前其实已经提到了漏洞，各位发现了吗？
几乎已成序列盛会
序列盛会的发起人们希望人们明白这一点：问题并不在于这四五个类。模型的根基已断。我们是怎样在 MD5 完全遭到破坏前便得知 MD5 已损，各位想必是知道的。这里也是一样的原理。
如果你让开发人员在其类型的 Serializable#readObject() 方法中指定任意行为，就可以将这些行为的副作用串联起来，给隐藏的火种火上浇油。这就是事情的真相。
此处也并无甚区别。
我可以提交位于你的类路径之上的任意类，你（受害人应用程序）也可以调用其构造函数。开发人员可以在其构造函数中放置任意数据。但这并不能保证避开副作用。
下面来分析一些攻击策略和我们将要用到的相应工具。
在构造函数中滥用静态副作用
下面是 ColdFusion 的一个类，能够极大地打击你可以控制的单例。
package coldfusion.syndication;import com.sun.syndication.io.impl.CFDateParser;public class FeedDateParser implements CFDateParser { private FeedDateParser() { DateParser.registerCFDateParser(this); } ...}
显然这一方法仅可调用一次。如果我给你发送一个经过 Kryo 序列化且拥有空白字段的 FeedDateParser，会有什么后果？答案：超级有效的应用程序 DoS 攻击。我会用自己的恶意单例来重写这一单例，并在其中填入各种空白字段成员。由于所有人都在使用，于是会导致各处触发 NullPointerExceptions 异常。仅仅一个 HTTP 请求便可让你毫无招架之力。
构造函数还可造成其他多种破坏性影响。尽管我确定有一种影响，但利用我所能找到的策略却未能发现致命远程执行代码。
滥用 finalize() 清理工具
如果某个类实现了Object#finalize()方法，Java 会在对象被作为垃圾回收之前调用此方法。开发人员利用这一方法来清理一直未得到恰当清理的所有非 JVM 资源。由于是自动调用，这一方法中可能发生的所有副作用都可能遭到滥用，而应用程序根本无需在你的恶意对象上运行！事实上，在利用漏洞的过程中必须将其抛开。
你可以利用一些类型来玩些花样。
1 号攻击：删除任意文件 (org.jpedal.io.ObjectStore)
到目前为止，finalize() 中最常被滥用的策略就是扰乱文件。这确实有些用处；类型在某种程度上有模板文件“撑腰”，而 finalize() 是一个表明文件可被清理的明确信号。
我借此发现的第一个类型恰巧也是在 ColdFusion 10 之中：org.jpedal.io.ObjectStore。对类进行分析以确定潜在的 Kryo finalize() 利用工具时，只需查看两件事：零参构造函数和 finalize() 方法。这些是唯一会发生的事情。只要字段也是可以用零参构造函数创建的对象，你就可以控制字段。以下是构造函数：
public ObjectStore() { init(); }
下面这张截图表明，在 Kryo 调用 readObject() 期间，默认构造函数被调用：
其实也没做什么。无论如何，其所做作为都已撤销，因为一旦构造函数执行完毕，Kryo 就在其状态之上复制了我们的状态。然后就是 finalize()：
protected void finalize() { ... flush(); ...}protected void flush() { .../** * flush any image data serialized as bytes */ Iterator filesTodelete = imagesOnDiskAsBytes.keySet().iterator(); while(filesTodelete.hasNext()) { final Object file = filesTodelete.next(); if(file! = null){ final File delete_file = new File((String)imagesOnDiskAsBytes.get(file)); if(delete_file.exists()) { delete_file.delete(); } } } ...}
2 号攻击：内存损坏（多个类型）
除此之外当然还有很多，但以上这些已经可用于众多常见平台。下面我们来看看 com.sun.jna.Memory#finalize() 调用：
我要在此重申：若读取的 Kryo 对象来自不受信任的资源且具备其中任一工具，就容易受单次激发应用破坏的影响。
3 号攻击：关闭所有文件描述符 (java.net.DatagramSocket)
protected void finalize() { close();}/** * Close the socket. */protected void close() { if (fd != null) { datagramSocketClose(); …}
int os::close(int fd) { return ::close(fd);}int os::socket_close(int fd) { return ::close(fd);}
总结
可以让 Kryo 调用其他方法，比如 compareTo()、entrySet()、toString()，等等，总之，能找出的小玩意多得很。
底线应当是，任何现代应用程序在其类路径上都可能存在一个能够删除文件、关闭文件描述符或使 JVM 完全崩溃的工具。这意味着，人们应当普遍意识到：允许 Kryo 操作不受信任的数据流是不安全的。
可能有人会极力反驳，如果让默认对象实例化策略不调用类型的构造函数，Kryo 就会安全得多。采用 JVM 技巧便可实现这一目标，我们会在下一篇文章中细细解析序列化程序这一问题。利用这一构造函数较少的实例化，可以防止副作用波及构造函数及其 finalize() 方法。
但如果你确实这么做了，Kryo 再也不需要零参构造函数便可创建新的对象 - 这样攻击者就能够实例化更多类型！这一权衡之道将导致大量工具可为攻击者所用，但在这些工具上执行方法的机会却少了 - 不再有构造函数，也不再有定型化方法。
下次，我们会对一家尝试过相同办法但仍然身处困境的企业进行分析 - XStream！
相关文章
发表评论
暂时没有评论，来抢沙发吧~