mirror of https://github.com/OISF/suricata
ftp: mark truncation on the line, not the connection
The truncation flag lived in FtpState, where the line getter set it and the two callers cleared it once FtpLineState.lf_found said the line had ended. The callers reuse one FtpLineState for every line in a slice, and only the LF branch ever set lf_found, so a complete line left it set for whatever came after. An over-long line behind a complete one in the same slice therefore had its truncation state cleared, its remainder was parsed as ordinary traffic, and a "PASS s3cret" sitting in that remainder became a transaction of its own. The flag could just as easily be left set. The request loop reached its clear only for a line that matched an FTP command, continuing to the next line otherwise, so an over-long run of "Z" left the flag standing and the next command to arrive was discarded as that line's remainder. The response loop's clear sat three ifs deep, inside blocks entered only when the reply parsed, so a line that SCFTPParseResponseLine rejects -- a run of spaces is empty once trimmed -- left it standing too. The getter also raised the flag for a line whose LF it had just consumed. Nothing of that line remained to discard, so the caller had to clear it straight back. Truncation is a property of the line, so FtpLineState now carries it. The getter sets line.truncated for the line it hands back, and the FtpState flag stays set only where truncation genuinely spans slices: the over-long line that arrives without an LF. The callers read line.truncated and no longer touch the shared state, so lf_found goes away entirely. Issue: 8859pull/16213/head
parent
7564d4d5a9
commit
60dc5d0e75
Loading…
Reference in New Issue