概述

如果您的源代码是以Go语言编写的，并且它使用了单向或双向TLS身份验证，那么该程序将很容易受到CPU拒绝服务（DoS）攻击。攻击者可以通过某种特定的方式来格式化输入内容，使得Go的crypto/x509标准库中的验证算法，在尝试验证客户端提供的TLS证书链的过程中，占用了所有可用的CPU资源。

如果要保护您的服务，请立即升级到Go 1.10.6或更高版本，或者升级至1.11.3或更高版本。

背景

42Crunch的API安全平台的后端，已经使用了微服务的架构来实现。这一微服务使用Go语言编写，通过gRPC相互通信，并且具有用于外部调用的REST API网关。为了确保安全性，我们遵循着“能用TLS就尽量用”的宗旨，广泛依赖于双向TLS身份验证。

Go在其标准库中提供本地的SSL/TLS支持，以及用于操作连接、验证、身份验证和证书的大量x509及TLS原语。这一本地支持，通过使用标准、经过检查、定期维护的TLS实现，来避免外部依赖性，并降低风险。

那么自然，42Crunch就可能会受到影响。因此，我们必须认真分析这一TLS漏洞，以确保42Crunch平台的安全性。

42Crunch安全团队发布了关于这一漏洞的分析以及详细信息。

问题

TLS链验证中的拒绝服务漏洞，最初由Netflix发现并报告，如Golang的问题跟踪器中所述：

crypto/x509包负责解析并验证X.509编码的密钥和证书。该包在处理攻击者提供的证书链时，本应该进行使用资源是否合理的判断。crypto/x509包没有限制为每个链验证执行的工作量，这可能允许攻击者制作导致CPU拒绝服务的恶意输入。Go TLS服务器接受客户端证书，TLS客户端将验证证书是否受到影响。

这里的问题之处，在于调用路径crypto/x509 Certificate.Verify()函数，该函数负责授权控制和验证证书。

漏洞详细分析

为了简化这一部分内容，并且使读者能够清楚了解，我们仅以TLS客户端连接到验证客户端证书的TLS服务器为例，展现这一过程的具体细节。

TLS服务器持续监听TLS客户端的8080端口，并根据一个受信任的证书颁发机构（CA）对客户端的证书进行验证：

caPool := x509.NewCertPool() ok := caPool.AppendCertsFromPEM(caCert) if !ok {         panic(errors.New("could not add to CA pool")) }   tlsConfig := &tls.Config{         ClientCAs:  caPool,         ClientAuth: tls.RequireAndVerifyClientCert, }   //tlsConfig.BuildNameToCertificate() server := &http.Server{         Addr:      ":8080",         TLSConfig: tlsConfig, }   server.ListenAndServeTLS(certWeb, keyWeb)

在一个标准的TLS验证方案中，TLS客户端连接到TLS服务器的8080端口，并提供其“信任链”，其中包括客户端证书、根CA证书以及所有中间CA证书。TLS服务器处理TLS握手，并验证客户端证书，检查客户端是否可信（客户端证书是否由服务器信任的CA进行签名）。下图展现了TLS握手时的简化版流程：

通过Go的crypto/x509库，我们最终进入到x509/tls/handshake_server.go:doFullHandshake()，具体如下：

... if c.config.ClientAuth >= RequestClientCert {         if certMsg, ok = msg.(*certificateMsg); !ok {                 c.sendAlert(alertUnexpectedMessage)                 return unexpectedMessageError(certMsg, msg)         }         hs.finishedHash.Write(certMsg.marshal())           if len(certMsg.certificates) == 0 {                 // The client didn't actually send a certificate                 switch c.config.ClientAuth {                 case RequireAnyClientCert, RequireAndVerifyClientCert:                         c.sendAlert(alertBadCertificate)                         return errors.New("tls: client didn't provide a certificate")                 }         }           pub, err = hs.processCertsFromClient(certMsg.certificates)         if err != nil {                 return err         }           msg, err = c.readHandshake()         if err != nil {                 return err         } } ...

在这里，服务器处理其收到的客户端证书，并调用函数x509/tls/handshake_server.go:processCertsFromClient()。如果必须要验证客户端证书，那么服务器会创建一个包含以下内容的VerifyOptions结构：

1、根CA池，配置为验证客户端证书的受信任CA列表，由服务器控制。

2、中间CA池，接收的中间CA列表，由客户端控制。

3、签名的客户端证书，由客户端控制。

4、其他字段，可选。

if c.config.ClientAuth >= VerifyClientCertIfGiven && len(certs) > 0 {         opts := x509.VerifyOptions{                 Roots:         c.config.ClientCAs,                 CurrentTime:   c.config.time(),                 Intermediates: x509.NewCertPool(),                 KeyUsages:     []x509.ExtKeyUsage{x509.ExtKeyUsageClientAuth},         }           for _, cert := range certs[1:] {                 opts.Intermediates.AddCert(cert)         }           chains, err := certs[0].Verify(opts)         if err != nil {                 c.sendAlert(alertBadCertificate)                 return nil, errors.New("tls: failed to verify client's certificate: " + err.Error())         }           c.verifiedChains = chains }

要理解上述过程中哪里存在问题，我们需要首先了解证书池的组织方式，从而以有效的方式来验证证书。简而言之，证书池是一个证书列表，可以根据需要，通过三种不同的方式访问。下图展示了这一示例：池中分组的证书，可以通过索引数组（名为“Certs”）访问，并且由CN、IssuerName、SubjectKeyId进行哈希处理。

验证过程

服务器使用客户端证书上的VerifyOptions调用函数Verify()（链中的第一个证书：certs[0]）。

然后，Verify()将根据提供的链，验证客户端证书。但是，必须首先使用buildChains()函数来构建并检查验证链：

var candidateChains [][]*Certificate if opts.Roots.contains(c) {         candidateChains = append(candidateChains, []*Certificate{c}) } else {         if candidateChains, err = c.buildChains(make(map[int][][]*Certificate), []*Certificate{c}, &opts); err != nil {                 return nil, err         } }

buildChains()函数依次调用一些消耗CPU较高的函数，并在其找到的链的每个元素上递归调用其自身。

BuildChains()函数依赖于辅助函数findVerifiedParents()，该函数通过IssuerName或AuthorityKeyId，对证书池进行映射访问，从而标识父证书，并返回可选证书的索引，然后根据客户端控制的池，对其进行验证。

在正常情况下，IssuerName和AuthorityKeyId将会被填充，并且预计它们都是唯一的，只会返回一个证书来进行验证：

func (s *CertPool) findVerifiedParents(cert *Certificate) (parents []int, errCert *Certificate, err error) {        if s == nil {               return        }        var candidates []int          if len(cert.AuthorityKeyId) > 0 {               candidates = s.bySubjectKeyId[string(cert.AuthorityKeyId)]        }        if len(candidates) == 0 {               candidates = s.byName[string(cert.RawIssuer)]        }          for _, c := range candidates {               if err = cert.CheckSignatureFrom(s.certs[c]); err == nil {                      parents = append(parents, c)               } else {                      errCert = s.certs[c]               }        }          return }

BuildChains()函数在客户端发送到TLS服务器的整个证书链上调用以下内容：

1、根CA池（服务器端）上的findVerifiedParents(client_certificate)，用于查找已验证证书的签名机构（如果它是根CA），并检查证书的AuthorityKeyId（如果不为nil）或所有可能的原始颁发者的签名（如果为nil）。

2、中间CA池（客户端提供）上的findVerifiedParents(client_certificate)，用于查找已验证证书的签名机构（如果它是根CA），并检查证书AuthorityKeyId（如果不为nil）或所有可能的原始颁发者的签名（如果为nil）。

3、获取负责签名的父级中间CA。

4、使用新找到的父级中间CA，调用buildChains()，并重复前面所述的整套签名检查流程。

DoS攻击方式

针对主CPU的DoS攻击，将由buildChains()和findVerifiedParent()函数在未预期的情况下触发，其中所有中间CA证书使用相同的名称，并且具有为nil的AuthKeyId值。findVerifiedParent()函数返回与该名称匹配的所有证书，也就是整个池，然后检查所有证书的签名。完成后，再次为找到的父级证书调用buildChains()函数，直至到达根CA。其中，每一次检查都会验证中间CA池的全部证书，因此只需要一次TLS连接，就可能会消耗掉全部可用的CPU。

漏洞影响

攻击者可以构建证书链，使客户端证书验证过程消耗掉所有CPU资源，从而降低主机的响应速度。上述影响只需要使用一个连接就可以实现。根据Go调度程序的规则，只有两个CPU核心会受到影响，并以100%占用率使用，创建新的连接，会强制调度程序分配更多资源来处理签名检查，这样一来可以导致整个服务或者整个主机无响应。

安全建议

Go语言社区建议通过实施以下更改，来缓解这一漏洞：

1、将签名检查移出findVerifiedParent()证书池查找过程；

2、将签名检查的数量限定在最多100个中间CA（这是一个不切实际的信任链）。

要实现针对这一漏洞的修复，需要立即升级到Go 1.10.6或更高版本，或者1.11.3或更高版本。