Suricata

Thanks for the report @alexey

Would you be able to create a Suricata-verify test/PR ?
https://github.com/OISF/suricata-verify/

Hi @Philippe Antoine,

Thanks for creating the PRs and merging the fix!

Regarding your comment on the test expecting 1 alert instead of 2 for SID 2: I agree that this is definitely the correct behavior according to Suricata's current implementation. Since the rule lacks the any_frag modifier, Suricata's code strictly requires the PFC_FIRST_FRAG bit to be set on the BIND PDU to trigger a match.

However, I wanted to point out a slight discrepancy between the implementation and the documentation/protocol spec that this test highlighted:

1. The dcerpc.iface documentation states: "If it's not [given], the match shall only happen on the first fragment." It doesn't explicitly mandate the PFC_FIRST_FRAG flag itself.
2. According to the DCE 1.1 specification for minor version 0, "the run-time assumes no fragmentation." Therefore, a BIND PDU with pfc_flags=0x00 is a complete, unfragmented PDU. Conceptually, it is the first (and only) fragment.

Because Suricata's implementation strictly checks the PFC_FIRST_FRAG bit (0x01), it treats a valid, unfragmented minor version 0 BIND as if it's not the first fragment. This means a rule writer's expectation (that a rule without any_frag will match a standard, unfragmented BIND) isn't met if the client omits the optional flag.

This is perfectly fine for the scope of this bug fix (the false positive is resolved!), but I wanted to raise this observation in case you think the any_frag logic should eventually be updated to treat pfc_flags=0x00 as a first fragment, or if the documentation should be clarified.

As a side note, the documentation is also unclear about which PDU is checked for the presence of the flag. Because the interface UUID list is only confirmed upon receiving the BIND_ACK, a rule using dcerpc.iface never matches on the BIND PDU itself; it matches on subsequent PDUs (like the REQUEST). However, the implementation strictly checks the PFC_FIRST_FRAG flag of the BIND PDU (saving it to DCERPC_UUID_ENTRY_FLAG_FF during parsing), rather than the flag of the PDU that actually triggers the match.

Thanks for the feedback @alexey

unixia what do you think ?
I find this @any_frag a bit weird...
Should we consider an unfragmented PDU like a first fragment ?

Do we want the following patch ?

diff --git a/rust/src/dcerpc/dcerpc.rs b/rust/src/dcerpc/dcerpc.rs
index 01296c0cb5..efab37388a 100644
--- a/rust/src/dcerpc/dcerpc.rs
+++ b/rust/src/dcerpc/dcerpc.rs
@@ -543,7 +543,8 @@ impl DCERPCState {
                 let pfcflags = hdr.pfc_flags;
                 // Store the first frag flag in the uuid as pfc_flags will
                 // be overwritten by new packets
-                if pfcflags & PFC_FIRST_FRAG > 0 {
+                // pfcflags == 0 means unfragmented, so we consider it a first fragment
+                if pfcflags & PFC_FIRST_FRAG > 0 || pfcflags == 0 {
                     uuidentry.flags |= DCERPC_UUID_ENTRY_FLAG_FF;
                 }
                 for uuid in self.interface_uuids.iter_mut() {

Then, I think we should have a new (documentation ? ) ticket about this

Thank you for the detailed analysis, Alexey!

According to the DCE 1.1 specification for minor version 0, "the run-time assumes no fragmentation."

Correct.

Therefore, a BIND PDU with pfc_flags=0x00 is a complete, unfragmented PDU. Conceptually, it is the first (and only) fragment.

Curious about this. While I do find the docs saying "the run-time assumes no fragmentation.", I also find the following a bit later.

Each fragment is labelled as such using the PFC_FIRST_FRAG and PFC_LAST_FRAG flags in the header pfc_flags field. If a service request needs only a single fragment, that fragment will have both the PFC_FIRST_FRAG and PFC_LAST_FRAG flags set to TRUE. Since the connection-oriented transport guarantees sequentiality, the receiver will always receive the fragments in order.

This is how I also see the data arrive in the pcaps we have and the one you shared. Please note that we do not have support for fragmentation and reassembly for dcerpc so just header is parsed and which is probably why most of our tests are for minor version 0. pfc_flags=0x00 sounds like an anomaly to me as per the above standard and existing pcaps.

However, I can also find implementation detail docs such as https://winprotocoldoc.z19.web.core.windows.net/MS-RPCE/%5BMS-RPCE%5D-240708-diff.pdf that state:

If a server implementation receives a request PDU without the PFC_FIRST_FRAG flag and there is no
active call for the connection, it SHOULD compare the call_id field from the PDU to the Current
call_id on the Server Connection. If the call_id field is smaller by less than 150, the server
SHOULD ignore the packet. If the call_id field is smaller by 150 or more, the server SHOULD treat
this as a protocol error

So, maybe there are certain implementations where this is possible indeed but as per this detail, the server should deal with such a packet by either ignoring it or erroring out so I am again feeling inclined to this being an anomalous case. Please lmk wdyt?

As a side note, the documentation is also unclear about which PDU is checked for the presence of the flag. Because the interface UUID list is only confirmed upon receiving the BIND_ACK, a rule using dcerpc.iface never matches on the BIND PDU itself; it matches on subsequent PDUs (like the REQUEST). However, the implementation strictly checks the PFC_FIRST_FRAG flag of the BIND PDU (saving it to DCERPC_UUID_ENTRY_FLAG_FF during parsing), rather than the flag of the PDU that actually triggers the match.

Very fair. We must update the docs about this. @Philippe Antoine a new doc ticket indeed makes sense to me.
In the protocol specs, I'm reading that fragmentation can only happen on bind, bind_ack, alter_context, alter_context_response PDUs, so the match should only happen for these but it should be clear as to which PDU if there were multiple in a state.

Philippe, what do you propose we do about any_frag?

Philippe, what do you propose we do about any_frag?

I was asking you, and you bounce back to me :-p

I think we should start by better documentation, and add maybe new options like "first_frag", "unfrag"...
I would also expect a match on default behavior with flags=0

@Shivani Bhardwaj

Hi Shivani,

Thanks for looking into this!

1. DCE 1.1 Documentation

The Fragmentation and Reassembly section opens with three paragraphs. The first addresses authentication data fragmentation for association PDUs (bind, bind_ack, alter_context, alter_context_response):

"If the PDU has a minor version number of 0 (zero), the run-time assumes no fragmentation. If the minor version number is 1 and the PFC_LAST_FRAG flag is not set, the PDU is fragmented. [...] Only bind, bind_ack, alter_context and alter_context_response PDUs will be fragmented."

The second introduces stub data fragmentation for request and response PDUs. The third — the one you quoted — says:

"Each fragment is labelled as such using the PFC_FIRST_FRAG and PFC_LAST_FRAG flags in the header pfc_flags field. If a service request needs only a single fragment, that fragment will have both the PFC_FIRST_FRAG and PFC_LAST_FRAG flags set to TRUE."

The documentation is genuinely ambiguous here. The first paragraph's conditional — "if the minor version number is 1 and PFC_LAST_FRAG is not set, the PDU is fragmented" — is probably meant to imply that for minor version 0, not setting PFC_LAST_FRAG is not enough to make the PDU fragmented. But that is never stated explicitly. And the third paragraph's opening "each fragment" is broad enough to apply to all PDU types, while "service request" is not a defined term of art that unambiguously excludes bind.

2. [MS-RPCE] Documentation

The MS-RPCE passage you quoted:

"If a server implementation receives a request PDU without the PFC_FIRST_FRAG flag..."

is describing a specific edge case: a server receiving a request PDU fragment for which there is no active call — i.e. a stale or out-of-order packet. The guidance (ignore or treat as protocol error) is about dropping such orphaned packets, not about the general validity of unfragmented PDUs.

3. Practical perspective for an IDS/IPS

Beyond spec interpretation, there is a dimension that is particularly important from an IDS/IPS standpoint: for a detection system, what matters most is how real-world implementations actually behave on live networks.

I have confirmed empirically — in the PCAP with live Windows port 135 traffic attached to this issue — that Windows endpoints accept BIND requests with pfc_flags=0x00 and respond with a valid BIND_ACK. Samba's dcesrv_bind() passes required_flags=0 to its header verification, suggesting it likewise does not enforce the fragment flags.

If Suricata's default behavior requires PFC_FIRST_FRAG to be present in the BIND PDU for dcerpc.iface to match, any client can evade every default dcerpc.iface-based detection rule (i.e. any rule without any_frag) by simply zeroing out pfc_flags. The server still accepts the connection, the interface is bound, and RPC calls proceed normally — but Suricata stops matching the interface UUID. An attacker does not need to know which interface UUIDs are being monitored — zeroing out pfc_flags on every BIND blindly evades all such rules at once.

thank you very much, Alexey!

I have confirmed empirically — in the PCAP with live Windows port 135 traffic attached to this issue — that Windows endpoints accept BIND requests with pfc_flags=0x00 and respond with a valid BIND_ACK. Samba's dcesrv_bind() passes required_flags=0 to its header verification, suggesting it likewise does not enforce the fragment flags.

that's great! Are you able to provide a PCAP/suricata-verify test for that? Please upload it at https://redmine.openinfosecfoundation.org/issues/8577
thanks a lot!

Shivani Bhardwaj wrote in #note-16:

I have confirmed empirically — in the PCAP with live Windows port 135 traffic attached to this issue — that Windows endpoints accept BIND requests with pfc_flags=0x00 and respond with a valid BIND_ACK. Samba's dcesrv_bind() passes required_flags=0 to its header verification, suggesting it likewise does not enforce the fragment flags.

Are you able to provide a PCAP/suricata-verify test for that?

The PCAP I attached to the original report is exactly that:

Attached PCAP: repro_remote.pcapng — live capture against a Windows endpoint on port 135. Contains two connections: one where the BIND has pfc_flags=0x00 (frames 28-33; triggers the false positive) and one where the BIND has pfc_flags=0x03 (frames 38-43; control, no false positive).