zeek/testing/btest/plugins/binpac-flowbuffer-frame-length.zeek
Jon Siwek 23ad81400b Rename aux/ to auxil/
Since "aux" is not an allowed file/dir name on Windows.
2020-06-04 15:18:44 -07:00

40 lines
1.5 KiB
Text

# This test exercises a previous bug in binpac flowbuffer frame length
# boundary checks:
# Incremental flowbuffer parsing sought to first parse the "minimum header
# length" required to get the full frame length, possibly from a record
# field, but generating the logic to parse that field could greedily
# bundle in additional boundary-checks for all subsequent fields of
# known-size.
#
# E.g. for flowunit parsing of this:
#
# type HDR = record {
# version: uint8;
# reserved: uint8;
# len: uint16;
# } &byteorder=bigendian;
#
# type FOO_PDU(is_orig: bool) = record {
# hdr: HDR;
# plen: uint8;
# ptype: uint8;
# something: bytestring &restofdata;
# } &byteorder=bigendian, &length=hdr.len;
# The flowbuffer was correctly seeking to buffer 4 bytes and parse the
# "hdr.len" field, but the generated parsing logic for "hdr.len" included
# a boundary check all the way up to include "plen" and "ptype".
# This causes out-of-bounds exceptions to be thrown for inputs that should
# actually be possible to incrementally parse via flowbuffer.
# @TEST-EXEC: ${DIST}/auxil/zeek-aux/plugin-support/init-plugin -u . Foo FOO
# @TEST-EXEC: cp -r %DIR/binpac-flowbuffer-frame-length-plugin/* .
# @TEST-EXEC: ./configure --zeek-dist=${DIST} && make
# @TEST-EXEC: ZEEK_PLUGIN_PATH=`pwd` zeek -r $TRACES/mmsX.pcap %INPUT >output
event Foo::foo_message(c: connection, is_orig: bool, len: count, plen: count, ptype: count)
{
print "foo_message", len, plen, ptype;
}