CVE-2020-15586: Gorouter is vulnerable to DoS Attack via Expect: 100-continue requests
search cancel

CVE-2020-15586: Gorouter is vulnerable to DoS Attack via Expect: 100-continue requests

book

Article ID: 298433

calendar_today

Updated On:

Products

VMware Tanzu Application Service for VMs

Issue/Introduction

On 2020-07-14, Golang released several security patches which included a fix for the issue described here: Expect: 100-continue panics in httputil.ReserveProxy #34902.

This security issue affects all reverse proxies implemented in Golang, including the Gorouter.

While this crash could occur with normal traffic using this header, a malicious attacker could exploit this vulnerability and cause Gorouter to panic and crash with a
SIGSEGV: segmentation violation code. 


Symptoms

This issue is evident when Gorouter panics and crashes. The logs will look similar to the following:

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x18 pc=0x55a4df]
goroutine 14198 [running]:
bufio.(*Writer).Available(...)
/var/vcap/data/packages/golang-1-linux/35728c99dee396168790fa71e82bd89827cf7dd0/src/bufio/bufio.go:610
bufio.(*Writer).WriteString(0x0, 0xb000e8, 0x19, 0x40dc26, 0x7ff1ba04f6d0, 0xb22a85) 
/var/vcap/data/packages/golang-1-linux/35728c99dee396168790fa71e82bd89827cf7dd0/src/bufio/bufio.go:691 +0x7f
net/http.(*expectContinueReader).Read(0xc006e324c0, 0xc00a5c8000, 0x8000, 0x8000, 0x7ff1ba04f6d0, 0x0, 0x79c)
/var/vcap/data/packages/golang-1-linux/35728c99dee396168790fa71e82bd89827cf7dd0/src/net/http/server.go:888 +0x13b
code.cloudfoundry.org/gorouter/handlers.(*countingReadCloser).Read(0xc006e32660, 0xc00a5c8000, 0x8000, 0x8000, 0x9f6ec0, 0x4d8b01, 0xc00a5c8000)


Environment

Product Version: Other

Resolution

Description

All versions of VMware Tanzu Application Service for VMs (TAS for VMs) and VMware Tanzu Isolation Segment prior to v2.7.20, v2.8.14, and v2.9.8 allow a malicious client to cause the Gorouter to crash by sending specially crafted HTTP requests that include the the “Expect: 100-continue” header.

The Gorouter is vulnerable due to an underlying vulnerability within the Go standard library. The issue has been assigned identifier CVE-2020-15586 and has been fixed in the security patches of Go v1.13.13 and v1.14.5.


Affected VMware Product and Versions

  • VMware Tanzu Application Service for VMs
    • All versions prior to v2.7.20, v2.8.14, and v2.9.8
  • VMware Tanzu Isolation Segment
    • All versions prior to v2.7.20, v2.8.14, and v2.9.8

Mitigations

This issue has been fixed in VMware Tanzu Application Service for VMs v2.7.20, v2.8.14, and v2.9.8 and VMware Tanzu Isolation Segment versions v2.7.20, v2.8.14, and v2.9.8. This fix will not be backported for versions prior to 2.7.

Note: Given this is a DOS vulnerability (not a data confidentiality/integrity vulnerability), we are not making an exception on backports.

 If you are on an affected version, we recommend you to upgrade. If it is not possible to upgrade immediately, you may consider the following alternative mitigations.

  • Configure an HTTP load balancer in front of the Gorouters to drop the “Expect 100-continue” header completely. 
Note: This may cause delays in HTTP clients that utilize the Expect: 100 continue behavior. However, this should not affect the correctness of HTTP applications.
 
  • Configure an HTTP load balancer in front of the Gorouters to drop the “Expect 100-continue” header and immediately respond with “100 Continue”. 
Note: This may cause HTTP clients to send the request body unnecessarily in some cases where the server would have responded with a final status code before requesting the body.  However, this should not affect the correctness of HTTP applications. Refer to the following article, K15164: HTTP POST requests to BIG-IP APM virtual sever may be delayed, for more information on configuring an iRule to implement this mitigation for F5 load balancers.


If you are using a TCP / L4 load balancer for your Gorouters instead of an HTTP load balancer, consider the following:

  • Add firewall rules to prevent traffic from any source making requests that are causing this panic.
Note: You may use the “HTTP headers to log” setting to enable logging of the “Expect” request header to help identify sources of this malicious traffic.


Security Fix Status

References