破坏 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());
// => true
System.out.println(b.startsWith(a));
// => true
System.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<StringBuilder> 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 语言有哪些缺点？欢迎在留言区交流讨论。

推荐阅读：

▶华为申请注册盘古大模型商标；英伟达 A800 一周涨价超 30%；Apache Tomcat 10.1.11 发布 |极客头条

▶模型生成训练数据：免费的午餐还是一场梦？

▶GPT-4 被曝“变蠢”！为了降本，OpenAI 偷偷搞“小动作”？