An OpenSSL TLS server may crash if sent a maliciously crafted renegotiation ClientHello message from a client. If a TLSv1.2 renegotiation ClientHello omits the signature_algorithms extension (where it was present in the initial ClientHello), but includes a signature_algorithms_cert extension then a NULL pointer dereference will result, leading to a crash and a denial of service attack. A server is only vulnerable if it has TLSv1.2 and renegotiation enabled (which is the default configuration). OpenSSL TLS clients are not impacted by this issue. All OpenSSL 1.1.1 versions are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1-1.1.1j).

The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a "purpose" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named "purpose" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verific…

Improper bounds checking of the obuf variable in the link_ntoa() function in linkaddr.c of the BSD libc library may allow an attacker to read or write from memory. The full impact and severity depends on the method of exploit and how the library is used by applications. According to analysis by FreeBSD developers, it is very unlikely that applications exist that utilize link_ntoa() in an exploitable manner, and the CERT/CC is not aware of any proof of concept. A blog post describes the functionality of link_ntoa() and points out that none of the base utilities use this function in an exploitable manner. For more information, please see FreeBSD Security Advisory SA-16:37.

The routed daemon in FreeBSD 9.3 before 9.3-RELEASE-p22, 10.2-RC2 before 10.2-RC2-p1, 10.2-RC1 before 10.2-RC1-p2, 10.2 before 10.2-BETA2-p3, and 10.1 before 10.1-RELEASE-p17 allows remote authenticated users to cause a denial of service (assertion failure and daemon exit) via a query from a network that is not directly connected.

Larry Wall's patch; patch in FreeBSD 10.2-RC1 before 10.2-RC1-p1, 10.2 before 10.2-BETA2-p2, and 10.1 before 10.1-RELEASE-p16; Bitrig; GNU patch before 2.2.5; and possibly other patch variants allow remote attackers to execute arbitrary shell commands via a crafted patch file.

The do_ed_script function in pch.c in GNU patch through 2.7.6, and patch in FreeBSD 10.1 before 10.1-RELEASE-p17, 10.2 before 10.2-BETA2-p3, 10.2-RC1 before 10.2-RC1-p2, and 0.2-RC2 before 10.2-RC2-p1, allows remote attackers to execute arbitrary commands via a crafted patch file, because a '!' character can be passed to the ed program.

The sys_amd64 IRET Handler in the kernel in FreeBSD 9.3 and 10.1 allows local users to gain privileges or cause a denial of service (kernel panic).

The inet module in FreeBSD 10.2x before 10.2-PRERELEASE, 10.2-BETA2-p2, 10.2-RC1-p1, 10.1x before 10.1-RELEASE-p16, 9.x before 9.3-STABLE, 9.3-RELEASE-p21, and 8.x before 8.4-STABLE, 8.4-RELEASE-p35 on systems with VNET enabled and at least 16 VNET instances allows remote attackers to cause a denial of service (mbuf consumption) via multiple concurrent TCP connections.

The telnetd service in FreeBSD 9.3, 10.1, 10.2, 10.3, and 11.0 allows remote attackers to inject arguments to login and bypass authentication via vectors involving a "sequence of memory allocation failures."

The Linux compatibility layer in the kernel in FreeBSD 9.3, 10.1, and 10.2 allows local users to read portions of kernel memory and potentially gain privilege via unspecified vectors, related to "handling of Linux futex robust lists."