
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 を返すからです。
つまり、キーが一致していなくても、異なるキーの証明書や、操作がサポートされていない場合を検証してしまいます。
セッションを検証するためには、これら 2 つのオプションのいずれかを強制する必要があります。
この欠陥を悪用するために、TLS セッションを確立する必要があります。
これは、攻撃者と対象デバイスの両方が TLS を使用できる場合にのみ機能します。ただし、TLS を使用するかどうかの決定は対象デバイスのみが行います。
対象デバイスが TLS を許可する場合、TLS セッションを確立できます。
すべてはここで行われます :
動作させてみましょう