Mirror/zeek
1
0
Fork 0
mirror of https://github.com/zeek/zeek.git synced 2025-10-02 14:48:21 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 2

Merge remote-tracking branch 'security/topic/awelzel/195-ieee802-heap-buffer-overflow'

Browse source 
* security/topic/awelzel/195-ieee802-heap-buffer-overflow:
  IEEE802_11: Fix buffer-overflow due to not accounting for the amsdu header
This commit is contained in:
Tim Wojtulewicz 2023-10-27 11:04:16 -07:00
commit 7852463b2f
3 changed files with 46 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

44
CHANGES
View file

@ -1,3 +1,47 @@
6.2.0-dev.74 | 2023-10-27 11:04:16 -0700
* IEEE802_11: Fix buffer-overflow due to not accounting for the amsdu header (Arne Welzel, Corelight)
The fuzzer generated input where data length left was 14 and the amsdu_len
field set to 14. That caused buffer overread due not taking into account
the amsdu header length of 14.
* ssl: Prevent unbounded ssl_history growth (Arne Welzel, Corelight)
The ssl_history field may grow unbounded (e.g., ssl_alert event). Prevent this
by capping using a configurable limit (default 100) and raise a weird once reached.
* ssl: Cap number of alerts parsed from SSL record (Arne Welzel, Corelight)
Limit the number of events raised from an SSL record with content_type
alert (21) to a configurable maximum number (default 10). For TLS 1.3,
the limit is set to 1 as specified in the RFC. Add a new weird cases
where the limit is exceeded.
OSS-Fuzz managed to generate a reproducer that raised ~660k ssl_plaintext
and ssl_alert events given ~810kb of input data. This change prevents this
with hopefully no negative side-effect in the real-world.
* ftp: Do not base seq on number of pending commands (Arne Welzel, Corelight)
Previously, seq was computed as the result of |pending_commands|+1. This
opened the possibility to override queued commands, as well as logging
the same pending ftp reply multiple times.
For example, when commands 1, 2, 3 are pending, command 1 may be dequeued,
but the incoming command then receives seq 3 and overrides the already
pending command 3. The second scenario happens when ftp_reply() selected
command 3 as pending for logging, but is then followed by many ftp_request()
events. This resulted in command 3's response being logged for every
following ftp_request() over and over again.
Avoid both scenarios by tracking the command sequence as an absolute counter.
* X509Common/SCT parsing: Fix memory leak in error case (Arne Welzel, Corelight)
Failed to free the copy of the OCSP extension's value the inner
octet string couldn't be parsed.
6.2.0-dev.64 | 2023-10-27 19:19:55 +0200
* fuzzers: Add DTLS fuzzer (Arne Welzel, Corelight)

2
VERSION
View file

@ -1 +1 @@
6.2.0-dev.64
6.2.0-dev.74

2
src/packet_analysis/protocol/ieee802_11/IEEE802_11.cc
View file

@ -105,7 +105,7 @@ bool IEEE802_11Analyzer::AnalyzePacket(size_t len, const uint8_t* data, Packet*
// This is the length of everything after the A-MSDU subframe header.
size_t amsdu_len = (data[12] << 8) + data[13];
if ( len < amsdu_len )
if ( len < amsdu_len + 14 )
{
Weird("truncated_802_11_amsdu_packet", packet);
return false;