CVE-2026-0073-Research

CVE-2026-0073 是一个 CVSS 严重性评分为 8.3 的 RCE 漏洞，这里我们将解释其工作原理。

第一部分：代码分析：

首先，唯一可能值得关注的事情是更深入地了解这个漏洞本身。

我的第一个来源是：https://www.tenable.com/cve/CVE-2026-0073

该来源告诉我们，auth.cpp 文件中有一个名为 adbd_tls_verify_cert 的函数，其流程允许未认证的 RCE。

现在的首要目标是获取 auth.cpp 的源代码。

由于我无法在任何官方仓库中找到它，我找到了 Project-Awaken 创建的仓库：https://github.com/Project-Awaken/android_packages_modules_adb/blob/12/daemon/auth.cpp

就是这里！我们神秘的函数：

int adbd_tls_verify_cert(X509_STORE_CTX* ctx, std::string* auth_key) {
    if (!auth_required) {
        // Any key will do.
        LOG(INFO) << __func__ << ": auth not required";
        return 1;
    }

    bool authorized = false;
    X509* cert = X509_STORE_CTX_get0_cert(ctx);
    if (cert == nullptr) {
        LOG(INFO) << "got null x509 certificate";
        return 0;
    }
    bssl::UniquePtr<EVP_PKEY> evp_pkey(X509_get_pubkey(cert));
    if (evp_pkey == nullptr) {
        LOG(INFO) << "got null evp_pkey from x509 certificate";
        return 0;
    }

    IteratePublicKeys([&](std::string_view public_key) {
        // TODO: do we really have to support both ' ' and '\t'?
        std::vector<std::string> split = android::base::Split(std::string(public_key), " \t");
        uint8_t keybuf[ANDROID_PUBKEY_ENCODED_SIZE + 1];
        const std::string& pubkey = split[0];
        if (b64_pton(pubkey.c_str(), keybuf, sizeof(keybuf)) != ANDROID_PUBKEY_ENCODED_SIZE) {
            LOG(ERROR) << "Invalid base64 key " << pubkey;
            return true;
        }

        RSA* key = nullptr;
        if (!android_pubkey_decode(keybuf, ANDROID_PUBKEY_ENCODED_SIZE, &key)) {
            LOG(ERROR) << "Failed to parse key " << pubkey;
            return true;
        }

        bool verified = false;
        bssl::UniquePtr<EVP_PKEY> known_evp(EVP_PKEY_new());
        EVP_PKEY_set1_RSA(known_evp.get(), key);
        if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
            LOG(INFO) << "Matched auth_key=" << public_key;
            verified = true;
        } else {
            LOG(INFO) << "auth_key doesn't match [" << public_key << "]";
        }
        RSA_free(key);
        if (verified) {
            *auth_key = public_key;
            authorized = true;
            return false;
        }

        return true;
    });

    return authorized ? 1 : 0;
}

但函数中真正有趣的部分是以下这段：

bool verified = false;
bssl::UniquePtr<EVP_PKEY> known_evp(EVP_PKEY_new());
EVP_PKEY_set1_RSA(known_evp.get(), key);
if (EVP_PKEY_cmp(known_evp.get(), evp_pkey.get())) {
  LOG(INFO) << "Matched auth_key=" << public_key;
  verified = true;
} else {
  LOG(INFO) << "auth_key doesn't match [" << public_key << "]";
}

为什么？因为 verified 被设置为一个决定是否允许连接的布尔值，并且它只通过 "if" 语句来改变。问题在于？EVP_PKEY_cmp(known_evp.get(), evp_pkey.get()) 并不总是返回 1 或 0，它还可能返回 -1 和 -2，因为 EVP_PKEY_cmp() 在密钥匹配时返回 1，不匹配时返回 0，密钥类型不同时返回 -1，操作不受支持时返回 -2。

因此，即使密钥不匹配，它也会验证不同类型的密钥或不受支持的操作。

为了验证我们的会话，我们将不得不强制触发这两种情况之一。

第二部分：POC 制作与 ADB 连接协议逆向

为了尝试利用这个漏洞，我们需要建立一个 TLS 会话。

这仅在攻击者和目标设备都能使用 TLS 时才有效，然而是否使用 TLS 的决定权完全在目标设备手中。

如果目标设备允许 TLS，你就可以建立 TLS 会话。

整个过程如下：

第一步：CNXN 数据包（连接数据包）
第二步：STLS 数据包（升级到 TLS 的数据包）
第三步：TLS 握手（使用 EC 密钥而非 RSA）

让我们开始尝试让它工作

CVE-2026-0073-Research

最受欢迎

CVE-2026-0073-Research

第一部分：代码分析：

第二部分：POC 制作与 ADB 连接协议逆向