Need to clear the pac pointer for the first error case to avoid freeing
the previous PAC entry if the following entry has an invalid header.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
clang started warning about the use of || with constants that came from
PCSC_FUNCS not being enabled in the build. It seems to be easier to just
ifdef this block out completely since that has the same outcome for
builds that do not include PC/SC support.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If the final Phase 2 message needed fragmentation, EAP method decision
was cleared from UNCOND_SUCC or COND_SUCC to FAIL and that resulted in
the authentication failing when the EAP-Success message from the server
got rejected. Fix this by restoring the EAP method decision after
fragmentation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Free the allocated structure in error cases to remove need for each EAP
method to handle the error cases separately. Each registration function
can simply do "return eap_peer_method_register(eap);" in the end of the
function.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This function can fail at least in theory, so check its return value
before proceeding. This is mainly helping automated test case coverage
to reach some more error paths.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was reported to fail with Windows 2012r2 with "Invalid Compound_MAC
in cryptobinding TLV". It turns out that the server decided to go
through inner EAP method (EAP-MSCHAPv2 in the reported case) even when
using PEAP fast-reconnect. This seems to be against the [MS-PEAP]
specification which claims that inner EAP method is not used in such a
case. This resulted in a different CMK being derived by the server (used
the version that used ISK) and wpa_supplicant (used the version where
IPMK|CMK = TK without ISK when using fast-reconnect).
Fix this interop issue by making wpa_supplicant to use the
fast-reconnect version of CMK derivation only when using TLS session
resumption and the server having not initiated inner EAP method before
going through the cryptobinding exchange.
Signed-off-by: Jouni Malinen <j@w1.fi>
The data->state == WAIT_FRAG_ACK case is already handling all cases
where data->out_buf could be non-NULL, so this additional check after
the WAIT_FRAG_ACK steps cannot be reached. Remove the duplicated dead
code.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, a fixed 1300 fragment_size was hardcoded. Now the EAP
profile parameter fragment_size can be used to override this.
Signed-off-by: Jouni Malinen <j@w1.fi>
ocsp=3 extends ocsp=2 by require all not-trusted certificates in the
server certificate chain to receive a good OCSP status. This requires
support for ocsp_multi (RFC 6961). This commit is only adding the
configuration value, but all the currently included TLS library wrappers
are rejecting this as unsupported for now.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Instead of using default list of methods, reject a configuration with an
unsupported EAP method at the time the main TLS method is being
initialized.
Signed-off-by: Jouni Malinen <j@w1.fi>
eap_peap_parse_phase1() returned 0 unconditionally, so there was no need
for that return value or the code path that tried to address the error
case.
Signed-off-by: Jouni Malinen <j@w1.fi>
This patch fixes an issue with an invalid phase2 parameter value
auth=MSCHAPv2 getting interpreted as auth=MSCHAP (v1) which could
degrade security (though, only within a protected TLS tunnel). Now when
invalid or unsupported auth= phase2 parameter combinations are
specified, EAP-TTLS initialization throws an error instead of silently
doing something.
More then one auth= phase2 type cannot be specified and also both auth= and
autheap= options cannot be specified.
Parsing phase2 type is case sensitive (as in other EAP parts), so phase2
parameter auth=MSCHAPv2 is invalid. Only auth=MSCHAPV2 is correct.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
[Use cstr_token() to get rid of unnecessary allocation; cleanup]
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds support for optional functionality to validate server
certificate chain in TLS-based EAP methods in an external program.
wpa_supplicant control interface is used to indicate when such
validation is needed and what the result of the external validation is.
This external validation can extend or replace the internal validation.
When ca_cert or ca_path parameter is set, the internal validation is
used. If these parameters are omitted, only the external validation is
used. It needs to be understood that leaving those parameters out will
disable most of the validation steps done with the TLS library and that
configuration is not really recommend.
By default, the external validation is not used. It can be enabled by
addingtls_ext_cert_check=1 into the network profile phase1 parameter.
When enabled, external validation is required through the CTRL-REQ/RSP
mechanism similarly to other EAP authentication parameters through the
control interface.
The request to perform external validation is indicated by the following
event:
CTRL-REQ-EXT_CERT_CHECK-<id>:External server certificate validation needed for SSID <ssid>
Before that event, the server certificate chain is provided with the
CTRL-EVENT-EAP-PEER-CERT events that include the cert=<hexdump>
parameter. depth=# indicates which certificate is in question (0 for the
server certificate, 1 for its issues, and so on).
The result of the external validation is provided with the following
command:
CTRL-RSP-EXT_CERT_CHECK-<id>:<good|bad>
It should be noted that this is currently enabled only for OpenSSL (and
BoringSSL/LibreSSL). Due to the constraints in the library API, the
validation result from external processing cannot be reported cleanly
with TLS alert. In other words, if the external validation reject the
server certificate chain, the pending TLS handshake is terminated
without sending more messages to the server.
Signed-off-by: Jouni Malinen <j@w1.fi>
Do not override the parsing error with the "PAC block not terminated
with END" message if the reason for the END line not yet being seen is
in failure to parse an earlier line.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was possible to hit a NULL pointer dereference if Session-Id
derivation failed due to a memory allocation failure.
Signed-off-by: Jouni Malinen <j@w1.fi>
If init_for_reauth fails, the EAP-SIM peer state was not freed properly.
Use eap_sim_deinit() to make sure all allocations get freed. This could
be hit only if no random data could be derived for NONCE_MT.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the Confirm message is received from the server before the Identity
exchange has been completed, the group has not yet been determined and
data->grp is NULL. The error path in eap_pwd_perform_confirm_exchange()
did not take this corner case into account and could end up
dereferencing a NULL pointer and terminating the process if invalid
message sequence is received. (CVE-2015-5316)
Signed-off-by: Jouni Malinen <j@w1.fi>
All but the last fragment had their length checked against the remaining
room in the reassembly buffer. This allowed a suitably constructed last
fragment frame to try to add extra data that would go beyond the buffer.
The length validation code in wpabuf_put_data() prevents an actual
buffer write overflow from occurring, but this results in process
termination. (CVE-2015-5315)
Signed-off-by: Jouni Malinen <j@w1.fi>
While this is not part of RFC 4137, the way m.check(eapReqData) is
implemented in wpa_supplicant allows an EAP method to not update the
ignore value even though each such call is really supposed to get a new
response. It seems to be possible to hit a sequence where a previous EAP
authentication attempt terminates with sm->ignore set from the last
m.check() call and the following EAP authentication attempt could fail
to go through the expected code path if it does not clear the ignore
flag. This is likely only hit in some error cases, though. The hwsim
test cases could trigger this with the following sequence:
eap_proto_ikev2 ap_wps_m1_oom
Signed-off-by: Jouni Malinen <j@w1.fi>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, the EAP-WSC peer state machine ended up just ignoring an
error and waiting for a new message from the AP. This is not going to
recover the exchange, so simply force the connection to terminate
immediately.
Signed-off-by: Jouni Malinen <j@w1.fi>
The new CONFIG_NO_RC4=y build option can be used to remove all internal
hostapd and wpa_supplicant uses of RC4. It should be noted that external
uses (e.g., within a TLS library) do not get disabled when doing this.
This removes capability of supporting WPA/TKIP, dynamic WEP keys with
IEEE 802.1X, WEP shared key authentication, and MSCHAPv2 password
changes.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 94f1fe6f63 ('Remove master key
extraction from tls_connection_get_keys()') left only fetching of
server/client random, but did not rename the function and structure to
minimize code changes. The only name is quite confusing, so rename this
through the repository to match the new purpose.
Signed-off-by: Jouni Malinen <j@w1.fi>
FIPS builds do not include support for MD4/MD5, so disable
EAP-TTLS/CHAP, MSCHAP, and MSCHAPV2 when CONFIG_FIPS=y is used.
Signed-off-by: Jouni Malinen <j@w1.fi>
MD5 is not available in CONFIG_FIPS=y builds, so use SHA1 for the EAP
peer workaround that tries to detect more robustly whether a duplicate
message was sent.
Signed-off-by: Jouni Malinen <j@w1.fi>
If there is only zero-length buffer of output data in error case, mark
that as an immediate failure instead of trying to report that
non-existing error report to the server. This allows faster connection
termination in cases where a non-recoverable error occurs in local TLS
processing, e.g., if none of the configured ciphers are available.
Signed-off-by: Jouni Malinen <j@w1.fi>
EAP-TLS was already doing this, but the other TLS-based EAP methods did
not mark methodState DONE and decision FAIL on local TLS processing
errors (instead, they left the connection waiting for a longer timeout).
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds a new STATUS command field "eap_tls_version" that shows the
TLS version number that was used during EAP-TLS/TTLS/PEAP/FAST exchange.
For now, this is only supported with OpenSSL.
Signed-off-by: Jouni Malinen <j@w1.fi>
The new phase1 config parameter value tls_disable_tlsv1_0=1 can now be
used to disable use of TLSv1.0 for a network configuration. This can be
used to force a newer TLS version to be used. For example,
phase1="tls_disable_tlsv1_0=1 tls_disable_tlsv1_1=1" would indicate that
only TLS v1.2 is accepted.
Signed-off-by: Jouni Malinen <j@w1.fi>
The only time the PIN should fail is when we initialize the TLS
connection, so it doesn't really make sense to get rid of the PIN just
because some other part of the handshake failed.
This is a followup to commit fd4fb28179
('OpenSSL: Try to ensure we don't throw away the PIN unnecessarily').
Signed-off-by: Mike Gerow <gerow@google.com>
Use explicit typecasting to avoid implicit conversion warnings in cases
where enum eap_erp_type is used in functions taking an EapType argument.
Signed-off-by: Jouni Malinen <j@w1.fi>
If key derivation fails, there is no point in trying to continue
authentication. In theory, this could happen if memory allocation during
TLS PRF fails.
Signed-off-by: Jouni Malinen <j@w1.fi>
While RFC 6124 does not define how Session-Id is constructed for
EAP-EKE, there seems to be consensus among the authors on the
construction. Use this Type | Nonce_P | Nonce_S construction based on
the following email:
From: Yaron Sheffer <yaronf.ietf at gmail.com>
To: ietf at ietf.org
Date: Wed, 17 Nov 2010 13:13:42 +0200
Expanding on my previous response, I suggest to resolve Bernard's
concern by adding the following text:
5.6 EAP Key Generation
EAP-EKE can be used for EAP key generation, as defined by [RFC 5247].
When used in this manner, the values required to establish the key
hierarchy are defined as follows:
- Peer-Id is the EAP-EKE ID_P value.
- Server-Id is the EAP-EKE ID_S value.
- Session-Id is the concatenated Type | Nonce_P | Nonce_S, where Type is
the method type defined for EAP-EKE in [Sec. 4.1], a single octet.
Thanks,
Yaron
Signed-off-by: Jouni Malinen <j@w1.fi>
The cleanup code will handle this, but it is more robust to make sure
this is cleared to zero when allocating a new buffer.
Signed-off-by: Jouni Malinen <j@w1.fi>
The L (Length) and M (More) flags needs to be cleared before deciding
whether the locally generated response requires fragmentation. This
fixes an issue where these flags from the server could have been invalid
for the following message. In some cases, this could have resulted in
triggering the wpabuf security check that would terminate the process
due to invalid buffer allocation.
Signed-off-by: Jouni Malinen <j@w1.fi>
The remaining number of bytes in the message could be smaller than the
Total-Length field size, so the length needs to be explicitly checked
prior to reading the field and decrementing the len variable. This could
have resulted in the remaining length becoming negative and interpreted
as a huge positive integer.
In addition, check that there is no already started fragment in progress
before allocating a new buffer for reassembling fragments. This avoid a
potential memory leak when processing invalid message.
Signed-off-by: Jouni Malinen <j@w1.fi>
The length of the received Commit and Confirm message payloads was not
checked before reading them. This could result in a buffer read
overflow when processing an invalid message.
Fix this by verifying that the payload is of expected length before
processing it. In addition, enforce correct state transition sequence to
make sure there is no unexpected behavior if receiving a Commit/Confirm
message before the previous exchanges have been completed.
Thanks to Kostya Kortchinsky of Google security team for discovering and
reporting this issue.
Signed-off-by: Jouni Malinen <j@w1.fi>
This was previously checked as part of the eap_sim_parse_attr()
processing, but it is easier to review the code if there is an
additional explicit check for confirming that the Reserved field is
present since the pos variable is advanced beyond it.
Signed-off-by: Jouni Malinen <j@w1.fi>
