由 emboss 于 2014 年 5 月 9 日发布
我们最近被告知一个可能存在的安全漏洞，该漏洞已发布为 CVE-2014-2734。然而，根据我们下面的详细分析，我们认为 Ruby 不存在此漏洞。
这个漏洞可能允许攻击者通过修改证书的签名来伪造任意根证书，从而有效地将证书的原始私钥替换为攻击者选择的私钥。
概念验证
以下是我们对 CVE-2014-2734 的分析，我们能够简化原始的 PoC（概念验证），我们认为它抓住了概念验证的本质
require 'openssl'
forge_key = OpenSSL::PKey::RSA.new(2048)
raw_certificate = File.read("arbitrary.cer")
cert = OpenSSL::X509::Certificate.new(raw_certificate)
resigned_cert = cert.sign(spoof, OpenSSL::Digest::SHA1.new)
resigned_cert.verify(key) #=> trueX509Certificate#verify 返回 true 可能会让人感到惊讶。原始证书可能包含一个指向原始公钥的 主题公钥信息，该公钥与 forge_key 的公钥不同。 显然，用于重新签名证书的公钥/私钥对不再与主题公钥信息中引用的原始公钥匹配。 为什么 #verify 返回 true？
密钥如何验证
X509Certificate#verify 内部使用 OpenSSL 的 X509_verify 函数，该函数委托给 ASN1_item_verify。这些函数根据提供的公钥来确定签名的有效性。然而，它们不会验证给定的密钥是否与证书中引用的任何主题公钥匹配。这意味着在这种情况下，X509Certificate#verify 返回 true 是预期的行为。省略此检查对 X.509 信任模型的整体安全性没有重大影响。
RFC 5280 的 4.1.1.3 节明确指出，通过计算证书的签名，CA 确认证书中包含的信息的正确性。虽然上述示例代码中违反了此原则，但它不会对安全性构成威胁。除非有人能够说服您明确信任违反此原则的证书，否则以这种方式伪造或修改的证书无法被利用。
潜在风险
需要考虑两种情况
重新签名根证书
作为用户，我们无条件地信任根证书。即使它们不包含有效信息，仅仅作为公开认可的根证书的地位也足以保持它们的原始状态。它们是我们浏览器或操作系统信任存储中的预配置值。简单地拥有它们就可以确立它们作为有效信任锚的地位。例如，OpenSSL 本身默认情况下不检查自签名根证书的签名，原因相同，参见 X509_V_FLAG_CHECK_SS_SIGNATURE 文档。
重新签名的根证书实际上变成了“自签名”证书（尽管主题公钥信息不正确）。这并不比普通的自签名根证书更危险。事实上，任何人都可以生成自签名根证书，这些证书可能与有效的根证书完全匹配——除了签名。由于我们仅仅通过拥有根证书来信任它们，因此在没有客户端主动同意信任的情况下，这种冒名顶替的证书是毫无意义的。
重新签名中间证书或叶子证书
此外，重新签名非根证书不会违反 X.509 信任模型的安全性。虽然我们通常不会提前拥有这些类型的证书，但在 路径验证过程中会检测到它们的伪造。在这里，任何非根证书的签名都使用颁发证书的公钥进行验证。在证书链的某个点，最终会以无效的证书签名值的形式检测到伪造。
结论
总之，我们认为 X509Certificate#verify 的运行符合预期。其他人也独立得出了 相同的结论，因此我们对 CVE-2014-2734 提出了异议，并要求撤销它。 您可以在 此处找到我们对 原始概念验证的完整分析，包括注释。