jeltz/hostap
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Fix TLS message processing if Flags field is not present

Browse source 
Previous version assumed that the Flags field is always present and
ended up reading one octet past the end of the buffer should the Flags
field be missing. The message length would also be set incorrectly
(size_t)-1 or (size_t)-5, but it looks like reassembly code ended up
failing in malloc before actually using this huge length to read data.

RFC 2716 uses a somewhat unclear description on what exactly is included
in the TLS Ack message ("no data" can refer to either Data field in 4.1
or TLS Data field in 4.2), so in theory, it would be possible for some
implementations to not include Flags field. However,
EAP-{PEAP,TTLS,FAST} need the Flags field in Ack messages, too, for
indicating the used version.

The EAP peer code will now accept the no-Flags case as an Ack message if
EAP workarounds are enabled (which is the default behavior). If
workarounds are disabled, the message without Flags field will be
rejected.

[Bug 292]
This commit is contained in:
Jouni Malinen 2008-12-30 12:28:02 +02:00 committed by Jouni Malinen
parent 805e6dc663
commit 3f732d1fc3
1 changed files with 15 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/eap_peer/eap_tls_common.c
View file

@ -749,8 +749,21 @@ const u8 * eap_peer_tls_process_init(struct eap_sm *sm,
ret->ignore = TRUE;
return NULL;
}
if (left == 0) {
wpa_printf(MSG_DEBUG, "SSL: Invalid TLS message: no Flags "
"octet included");
if (!sm->workaround) {
ret->ignore = TRUE;
return NULL;
}
wpa_printf(MSG_DEBUG, "SSL: Workaround - assume no Flags "
"indicates ACK frame");
*flags = 0;
} else {
*flags = *pos++;
left--;
}
wpa_printf(MSG_DEBUG, "SSL: Received packet(len=%lu) - "
"Flags 0x%02x", (unsigned long) wpabuf_len(reqData),
*flags);