Feature #7848
openrules: extend pcrexform for use outside of existing suricata buffers
Description
As far as I am aware, pcrexform can only be applied to buffers that already exist in Suricata. So for example, we can carve a piece out of http.uri; and http.header; by applying the pcrexform to that buffer.
Extending pcrexform for use anywhere, without the prerequisite of it needing an existing Suricata buffer/keyword would allow us to begin writing signatures for scenarios such as custom protocols over TCP in which we know where certain buffers are located.
ex.
Assume the custom protocol over TCP has a field of interest at offset 5 and has a field marker of 0xf3. This field is dynamic in size but will terminate with 0x00 before beginning the next field with a marker of 0xf2. We could do the following:
pcrexform:"^.{4}\xf3(.*?)\x00\xf2"; content:"|07 02 07|";
Admittedly you can achieve the above with existing keywords in Suricata however the concept is there and in more complex scenarios where fields may move around, may not have field markers, may have incredibly dynamic sizes, this feature would really shine and allow us to drill down deeper and start carving our own buffers out of these custom protocols.
Happy to elaborate more if needed.
Updated by Victor Julien 9 days ago
Frames also support transforms. There is a generic per protocol `stream` frame for example:
alert tcp any any -> any any (flow:to_server; frame:http1.stream; pcrexform:"^([a-zA-Z]+)"; content:"POST"; startswith; endswith; sid:5;) alert http1 any any -> any any (flow:to_server; frame:stream; pcrexform:"^([a-zA-Z]+)"; content:"POST"; startswith; endswith; sid:6;)
Frames have some limitations though, currently they can't be mixed with other app-layer keywords (#5640, #7092).
It's also tricky to discover the available frames at this time (#8174).
Updated by Victor Julien 8 days ago
- Subject changed from extend pcrexform for use outside of existing suricata buffers to rules: extend pcrexform for use outside of existing suricata buffers
I think this won't get implemented the way it is requested, instead we'll probably create the missing sticky buffers for the parts of the traffic that currently just use direct content statements.
I imagine we need 'payload' and 'stream' here.