破坏 java.lang.String英国猫头鹰人事件,半人半鹰的怪异生物,疑似外星人
【编者按】本文展示了如何利用 Java 的一个 bug 来制造一些奇怪的字符串,包括字符串相等性的条件、创建损坏字符串的方法以及利用该 bug 在另一个类中远程破坏字符串的示例。并提出了一个挑战,要求读者创建一个满足特定条件的损坏空字符串,最终揭晓了网友提供的多种实现方法。
原文链接:https://wouter.coekaerts.be/2023/breaking-string
讨论链接:https://news.ycombinator.com/item?id=36687970
未经允许,禁止转载!
作者 | Wouter Coekaerts 译者 | 明明如月责编 | 夏萌出品 | CSDN(ID:CSDNnews)本文将展示如何利用 java.lang.String 中的一个 bug 来制造一些奇怪的字符串。
我们将使 “hello world” 不以“hello”开头, 并展示并不是所有的空字符串都相等。
介绍:字符串之间的相等的条件在我们开始之前,我们看一下 JDK 中两个字符串相等需要什么。
为什么 "foo".equals("fox") 的结果是 false?
因为字符串是逐字符比较的,这两个字符串的第三个字符不同。
为什么 "foo".equals("foo") 的结果是 true?
你可能会认为在这种情况下,字符串也是逐字符比较的。但是字符串字面量是 intern 的,当相同的字符串在源代码中出现多次作为常量时,它不是具有相同内容的另一个字符串,这些字符串是同一个实例。
String.equals 的第一件事就是 if (this == anObject) { return true; }, 这里的判断甚至都不会去看里面的内容。
为什么 "foo!".equals("foo!?") 的结果是 false?
从 JDK 9 开始(自从 JEP 254: 紧凑字符串),字符串在内部表示其内容为字节数组。"foo!" 只包含简单的字符,代码点小于 256。字符串类在内部使用 latin-1 编码来编码这样的值,每个字符一个字节。"foo!?" 包含一个不能用 latin-1 表示的字符(!?),所以它使用 UTF-16 来编码整个字符串,每个字符两个字节。String.coder 字段跟踪使用了两种编码中的哪一种。当比较两个使用不同 coder 的字符串时,String.equals 总是返回 false。它甚至不去看内容,因为如果一个字符串可以用 latin-1 表示,而另一个字符串不可以,那么它们就不能相同。难到,你会认为可以相等?
注意: 紧凑字符串(Compact Strings)特性可以禁用,但默认是启用的。本文假定它是启用的。
创建一个损坏的字符串
字符串是如何创建的? java.lang.String 是如何选择使用 latin-1 还是不使用它的?
可以通过多种方式创建字符串,我们将关注接受 char[] 的字符串构造函数。它首先尝试使用 StringUTF16.compress 将字符编码为 latin-1。如果失败,返回 null,构造函数退回到使用 UTF-16。这里是它的实现的简化版本。(为了可读性,我从实际实现中删除了不相关的间接调用、检查和参数,实际实现在这里(https://github.com/openjdk/jdk/blob/b3f34039fedd3c49404783ec880e1885dceb296b/src/java.base/share/classes/java/lang/String.java#L277-L279)和这里(https://github.com/openjdk/jdk/blob/b3f34039fedd3c49404783ec880e1885dceb296b/src/java.base/share/classes/java/lang/String.java#L4757-L4772))
/** * 分配一个新的 {@code String} 以表示字符数组参数当前所包含的字符序列。 * 复制字符数组的内容;后续修改字符数组不会影响新创建的字符串。 */ public String(char value[]) { byte[] val = StringUTF16.compress(value); if (val != null) { this.value = val; this.coder = LATIN1; return; } this.coder = UTF16; this.value = StringUTF16.toBytes(value);}这里有个 bug。这段代码并不总是保持 String.equals 的语义,我们之前讨论过。你看出来了吗?
javadoc 指出“对字符数组的后续修改不会影响新创建的字符串”。但是并发修改呢?在尝试将其编码为 latin-1 和将其编码为 UTF-16 之间,value 的内容可能已经改变了。这样我们就可以拥有只包含 latin-1 字符的字符串,但编码却为 UTF-16。
我们可以通过下面的方式触发这个竞争条件:
/** * 给定一个 latin-1 字符串,创建一个错误编码为 UTF-16 的副本。 */static String breakIt(String original) { if (original.chars().max().orElseThrow() > 256) { throw new IllegalArgumentException( "只能打断 latin-1 字符串"); } char[] chars = original.toCharArray(); // 在另一个线程中,反复将第一个字符在可作为 latin-1 编码和不可作为 latin-1 编码之间切换 Thread thread = new Thread(() -> { while (!Thread.interrupted()) { chars[0] ^= 256; } }); thread.start(); // 同时调用字符串构造函数,直到触发竞争条件 while (true) { String s = new String(chars); if (s.charAt(0) 256 && !original.equals(s)) { thread.interrupt(); return s; } }}我们可以使用这种方法创建的“损坏字符串”具有一些有趣的特性。
String a = "foo";String b = breakIt(a);// 它们不相等System.out.println(a.equals(b));// => false// 它们确实包含相同的一系列字符System.out.println(Arrays.equals(a.toCharArray(), b.toCharArray())); // => true// compareTo 认为它们相等(尽管它的 javadoc// 指定“当且仅当 equals(Object) 方法返回 true 时,// compareTo 返回 0”)System.out.println(a.compareTo(b));// => 0// 它们有相同的长度,一个是另一个的前缀,// 但反过来不是(因为如果它没有被破坏,// 一个 latin-1 字符串不能以一个非 latin-1 // 子串开头)。System.out.println(a.length() == b.length());// => trueSystem.out.println(b.startsWith(a));// => trueSystem.out.println(a.startsWith(b));// => false没想到这样一个基础的 Java 类会有这种奇怪的行为。
神秘的远程作用我们不仅可以创建一个“损坏的字符串”,我们还可以在另一个类中远程破坏一个字符串。
class OtherClass { static void startWithHello() { System.out.println("hello world".startsWith("hello")); }}如果我们在 IntelliJ 中编写这段代码,那么它会警告我们 Result of "hello world".startsWith("hello") is always true。这段代码甚至不需要任何输入,但我们仍然可以通过注入一个损坏的 "hello" 来使其打印 false,通过 interning:我们在任何其他代码字面量提及或显式 intern 它之前就破坏一个包含 hello 的字符串,并 intern 该损坏版本。这样,我们就破坏了JVM 中的每个 "hello" 字符串字面量。
breakIt("hell".concat("o")).intern();OtherClass.startWithHello(); // 打印 false挑战:空或非空?使用我们的 breakIt 方法,我们可以创建任何 latin-1 字符串的等价但不相等的字符串。但是它对空字符串不起作用,因为空字符串没有任何字符来触发竞争条件。然而,我们仍然可以创建一个损坏的空字符串。我将这个作为一个挑战给读者。
具体来说:你能创造一个 java.lang.String 对象,对于该对象,以下是真的 :s.isEmpty() && !s.equals("")。不要作弊:你只允许使用公共 API 来做这件事,如,不允许使用 .setAccessible 访问私有字段,也不允许使用 instrumentation 相关的类(因为 Instrumentation 提供了一种机制,使得开发者可以在不修改原始代码的情况下,通过代理、注入代码和监视器等方式对应用程序进行动态修改和扩展)。
如果你挑战成功,请在这里告诉我。我会在以后更新这篇文章,添加你提交的答案。
揭晓答案
创建一个 "损坏的" 空字符串最简单的方法是使用 breakIt(" ").trim()。这是因为 trim 方法正确地假定,如果原始字符串包含 latin-1 字符,那么去除 latin-1 字符后的结果仍应包含非 latin-1 字符。这个答案是由:Zac Kologlu、Jan、ichttt、Robert(他正确地指出了我对 "> 256" 检查的偏差)给出。
我还收到了两个原创的只能在 JDK 19 上运行的 StringBuilder 解决方案。Ihor Herasymenko 提交了这段代码,该代码通过 StringBuilder 的 deleteCharAt 触发了一个竞态条件。
Ihor 使用 deleteCharAt :
public class BrokenEmptyStringChallenge { public static void main(String[] args) { String s = breakIt(); System.out.println("s.isEmpty() && !s.equals(\"\") = " + (s.isEmpty() && !s.equals(""))); } static String breakIt() { String notLatinString = "\u0457"; AtomicReference sb = new AtomicReference<>(new StringBuilder(notLatinString)); Thread thread = new Thread(() -> { while (!Thread.interrupted()) { sb.get().deleteCharAt(0); sb.set(new StringBuilder(notLatinString)); } }); thread.start(); while (true) { String s = sb.get().toString(); if (s.isEmpty() && !s.equals("")) { thread.interrupt(); return s; } } }}最后,Xavier Cooney 提出了这个绝妙的解决方案,它甚至不涉及任何并发操作。它从 CharSequence.charAt 抛出一个异常,从而导致 StringBuilder 的状态不一致来实现这个效果。这看起来像是另一个 JDK 的 bug。
Xavier 给出的从 CharSequence.charAt 抛出异常的方案:
// 要求 Java 19+class WatSequence implements CharSequence { public CharSequence subSequence(int start, int end) { return this; } public int length() { return 2; } public char charAt(int index) { // 无需并发处理! if (index == 1) throw new RuntimeException(); return ⁉; } public String toString() { return "wat"; }}class Wat { static String wat() { if (Runtime.version().feature() < 19) { throw new RuntimeException("本示例在 java-19 之前的版本无法运行 :("); } StringBuilder sb = new StringBuilder(); try { sb.append(new WatSequence()); } catch (RuntimeException e) {} return new String(sb); } public static void main(String[] args) { String s = wat(); System.out.println(s.isEmpty() && !s.equals("")); }}我已经将这个 bug 提交到 Java Bug 数据库中。
本文引发了网友的激烈讨论,不同的网友发表了不同的看法。
有些网友认为这不是 bug,Java 中的一些类除非特殊说明否则本身就不是线程安全的,采用非线程安全的方式来破坏它,本身符合预期。
作者则坚称这就是 bug,因为人们通常会认为核心类库的不可变类是线程安全的。通无论用户如何去破坏,都不能破坏内部的结构。而且这个 bug 已经提交到 Java 的 bug 数据库中,预计未来版本中将会被修复。
有些网友甚至认为这不仅是 String 的 bug ,还是 JVM 的安全漏洞。也有网友认为,加一些防御性编程代码就可以解决这个问题。
同时,也有一些网友称,Java 内存模型是一个伟大的创造,如果你遵循它的规范,就能够以其他语言难以实现的简易度编写高性能的多线程应用程序。如果你不遵循 Java 内存模型的规范,就可能出乱子。
你是否曾经认为 JDK 是不会有 bug 的?你是否发现过JDK 的 bug? 你认为 Java 语言有哪些缺点?欢迎在留言区交流讨论。
相关文章
- 2月23日克来机电涨停分析:自动刹车,人形机器人,机器人概念热股
- 机器人公司Figure融资6.75亿美元:贝索斯微软英伟达OpenAI联合投资
- 优必选人形机器人“入职”车企
- 格力电器公布国际专利申请:“机器人脱困方法及装置、处理器和机器人”
- 光大证券:英伟达将发布的机器人领域成果 有望带来人形机器人板块催化终于有老板接得住00后的离职信了,霸气回应尽显格局,网友:牛!
- 黄强主持召开研究人工智能和机器人产业发展专题会议 加快抢占人工智能和机器人产业发展新赛道她是孙红雷亲妹妹,孙俪都恭敬她3分,演技高却永远捧不红!
- 国泰君安:国内外人形机器人厂商纷纷推出各自产品 推动产业化进程周润发赵雅芝时隔40年再同框!许文强已白发苍苍,冯程程依旧甜
- 贝佐斯和英伟达将加入OpenAI投资人形机器人初创公司Figure明星最想删除的艺考照片:娜扎发际线高,杨幂土气,看到周冬雨笑了
- 硅谷大佬们都向这家初创投了钱!类人型机器人是下一个风口?她因长得太漂亮2岁出道,演“小芈月”红遍全国,如今长成厌世脸
- 人形机器人,上班了!
发表评论
评论列表
- 这篇文章还没有收到评论,赶紧来抢沙发吧~