sscanf() can apparently read beyond the end of the buffer even if the
maximum length of the integer is specified in the format string. Replace
this parsing mechanism with helper functions that use sscanf() with NUL
terminated string to avoid this.
Credit to OSS-Fuzz: https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15158
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
If none of the supported name attributes are present, the name string
was nul terminated only at the end. Add an explicit nul termination at
the end of the last written (or beginning of the buffer, if nothing is
written) to avoid writing uninitialized data to debug log.
Signed-off-by: Jouni Malinen <j@w1.fi>
This leads to cleaner code overall, and also reduces the size
of the hostapd and wpa_supplicant binaries (in hwsim test build
on x86_64) by about 2.5 and 3.5KiB respectively.
The mechanical conversions all over the code were done with
the following spatch:
@@
expression SIZE, SRC;
expression a;
@@
-a = os_malloc(SIZE);
+a = os_memdup(SRC, SIZE);
<...
if (!a) {...}
...>
-os_memcpy(a, SRC, SIZE);
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This extends multi-OCSP support to verify status for intermediate CAs in
the server certificate chain.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This adds the next step in completing TLS client support for OCSP
stapling. The BasicOCSPResponse is parsed, a signing certificate is
found, and the signature is verified. The actual sequence of OCSP
responses (SignleResponse) is not yet processed in this commit.
Signed-off-by: Jouni Malinen <j@w1.fi>
If the server/client certificate includes the extKeyUsage extension,
verify that the listed key purposes include either the
anyExtendedKeyUsage wildcard or id-kp-serverAuth/id-kp-clientAuth,
respectively.
Signed-off-by: Jouni Malinen <j@w1.fi>
This commit adds support for validating certificates with SHA384 and
SHA512 hashes. Those certificates are now very common so wpa_supplicant
needs support for them.
SHA384 and SHA512 hash functions are included in the previous commit.
Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
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>
This makes the implementation less likely to provide useful timing
information to potential attackers from comparisons of information
received from a remote device and private material known only by the
authorized devices.
Signed-off-by: Jouni Malinen <j@w1.fi>
Verify that there is no extra data after the hash field. This is needed
to avoid potential attacks using additional data to construct a value
that passes the RSA operation and allows the hash value to be forged.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The current position pointer was not updated when issuerUniqueID or
subjectUniqueID were present. This could result in extensions being
ignored.
Signed-off-by: Jouni Malinen <j@w1.fi>
There are quite a few places in the current implementation where a nul
terminated string is generated from binary data. Add a helper function
to simplify the code a bit.
Signed-hostap: Jouni Malinen <j@w1.fi>
This phase1 parameter for TLS-based EAP methods was already supported
with GnuTLS and this commit extends that support for OpenSSL and the
internal TLS implementation.
There may be more than one attribute of same type (e.g., multiple DC
attributes), so the code needs to be able to handle that. Replace the
fixed structure with an array of attributes.
In addition, start ordering header file includes to be in more
consistent order: system header files, src/utils, src/*, same
directory as the *.c file.
These could, at least in theory, be used to generate unexpected common
name or subject alternative name matches should a CA sign strings with
NUL (C string termination) in them. For now, just reject the certificate
if an embedded NUL is detected. In theory, all the comparison routines
could be made to compare these strings as binary blobs (with additional
X.509 rules to handle some exceptions) and display NUL characters
somehow. Anyway, just rejecting the certificate will get rid of
potential problems with the C string getting terminated and it should
not really be used in certificates, so this should not break valid use
cases.
