Project

General

Profile

Actions

Support #8534

open
JC

Lua detect rule: args["buffer"] is always empty in match() - buffer content inaccessible

Support #8534: Lua detect rule: args["buffer"] is always empty in match() - buffer content inaccessible

Added by jghs chha 8 days ago. Updated about 8 hours ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Affected Versions:
Label:

Description

In Suricata 8.0.0, when using a Lua script as a detect keyword (lua:buffer.lua) placed after a sticky buffer (e.g., base64_data;lua:buffer.lua;), the args table passed to match() is always empty. Setting needs["buffer"] = true in init() does not populate args["buffer"].

Looking at the source code (detect-lua.c), DetectLuaMatchBuffer() correctly pushes buffer data into the args table, but it appears to never be called. Only DetectLuaMatch() is invoked, which passes an empty table.

Steps to reproduce:

function init(args)
    return {["buffer"] = true}
end
function match(args)
    for k, v in pairs(args) do
        print(k .. "=" .. type(v))
    end
    return 1
end

With rule: alert http any any -> any any (...; base64_data;lua:test.lua; ...)

Output: empty (no keys in args table).

Question: Is this a known limitation or a bug? Will a future version restore the ability for Lua detect scripts to access the current inspection buffer via args["buffer"], similar to older Suricata versions?

Currently the only workaround is to use suricata.http / suricata.packet libraries, which always return the full transaction/packet data regardless of buffer position.

PA Updated by Philippe Antoine about 8 hours ago Actions #1

  • Status changed from New to Feedback

I think this is because of base64_data which is getting obsolete

Could you instead try more modern transform from_base64 ?
Are you working on raw tcp stream ? Or on a http sticky buffer ?

Actions

Also available in: PDF Atom