hlua_httpclient_table_to_hdrs() declares a VLA of size
global.tune.max_http_hdr (default 101) on the stack but never checks
hdr_num against that bound. A Lua script that supplies a header table
with more than 101 values writes struct http_hdr entries (two ist =
two heap pointers + two lengths) past the end of the VLA, smashing
the stack frame.
Trigger from any Lua action/task/service:
local hc = core.httpclient()
local v = {}
for i = 1, 300 do v[i] = "x" end
hc:get{ url = "http://127.0.0.1/";, headers = { ["X"] = v } }
Each out-of-bounds entry writes a heap pointer (controllable
allocation contents via istdup) plus an attacker-chosen length onto
the stack, overwriting the saved return address. With no stack
canary, this is direct RCE; with a canary, it requires a leak first.
Reachable from any deployment that loads Lua scripts. While Lua
scripts are nominally trusted, this turns "can edit Lua" into "can
execute arbitrary native code", which is a meaningful boundary in
many setups (Lua sandbox escape).
This must be backported as far as the httpclient Lua API exists.
---
src/hlua.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/src/hlua.c b/src/hlua.c
index 6e56583df21a..c66849c48e8f 100644
--- a/src/hlua.c
+++ b/src/hlua.c
@@ -8069,6 +8069,11 @@ struct http_hdr *hlua_httpclient_table_to_hdrs(lua_State
*L)
goto next_value;
}
+ if (hdr_num >= global.tune.max_http_hdr) {
+ lua_pop(L, 2);
+ goto skip_headers;
+ }
+
v = lua_tolstring(L, -1, &vlen);
value = ist2(v, vlen);
name = ist2(n, nlen);
--
2.53.0
