/golang-CVE-2023-44487

Primary LanguageGoApache License 2.0Apache-2.0

Golang CVE-2023-44487 testing

This repository contains testing resources and results for the CVE-2023-44487. It uses a modified version of https://github.com/secengjeff/rapidresetclient to test against various Golang server configs.

Testing against a normal server

go run server.go
go run attacker.go -requests 500000

Results

go 1.21.0

350% CPU load

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Total time: 7.99 seconds (62562 rps)

go 1.21.3

75% CPU load (just for a short time at the begin of the attack)

--- Summary ---
Frames sent: HEADERS = 74767, RST_STREAM = 74767
Total time: 3.57 seconds (20921 rps)

starts to fail pretty fast with
62->[::1]:8443: write: connection reset by peer[999995] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999997] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999997] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999999] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999999] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[1000001] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[1000001] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer

Testing against a GRPC server

go run grpcserver.go
go run attacker.go -requests 500000

Results

go 1.21.0, golang.org/x/net v0.16.0, google.golang.org/grpc v1.58.0

150-200% CPU load

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Frames received: 499998
Total time: 10.23 seconds (48898 rps)

go 1.21.3, golang.org/x/net v0.17.0, google.golang.org/grpc v1.59.0

150-200% CPU load

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Frames received: 499993
Total time: 8.25 seconds (60639 rps)

The attacker does not really call GRPC endpoints, so there seems to be no difference in behaviour with "normal" http2 calls. Not super sure if this is good or bad, but the server manages to keep up with the traffic.

Testing against a httputil.ReverseProxy server

# use nginx as target
sudo nginx -c $PWD/nginx/vulnerable_8444.conf -g daemon\ off\;
go run revproxyserver.go
go run attacker.go -requests 500000

Results

go 1.21.0

200% CPU load during the full attack

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Frames received: 25
Total time: 9.43 seconds (53014 rps)

go 1.21.3

150% CPU load (just for a short time at the begin of the attack)

--- Summary ---
Frames sent: HEADERS = 100194, RST_STREAM = 100193
Total time: 4.36 seconds (22955 rps)

starts to fail pretty fast with
62->[::1]:8443: write: connection reset by peer[999995] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999997] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999997] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999999] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[999999] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[1000001] Failed to send HEADERS: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer[1000001] Failed to send RST_STREAM: write tcp [::1]:60762->[::1]:8443: write: connection reset by peer

Server log now contains 😎
2023/10/25 14:45:54 http2: server connection error from [::1]:60762: connection error: ENHANCE_YOUR_CALM

Testing against nginx

sudo nginx -c $PWD/nginx/vulnerable.conf -g daemon\ off\;
go run attacker.go -requests 500000

Results

With vulnerable config

100% CPU load

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Frames received: 478609
Total time: 8.13 seconds (61484 rps)

With default config

34% CPU load

--- Summary ---
Frames sent: HEADERS = 500000, RST_STREAM = 500000
Frames received: 1432
Total time: 7.62 seconds (65588 rps)

Nginx just stops to respond to a lot of frames