OpenSSL Security Advisory [15 March 2022]
============================================
Infinite loop in BN_mod_sqrt() reachable when parsing certificates
(CVE-2022-0778)
==================================================================================
Severity: High
The BN_mod_sqrt() function, which computes a modular square root,
contains
a bug that can cause it to loop forever for non-prime moduli.
Internally this function is used when parsing certificates that contain
elliptic curve public keys in compressed form or explicit elliptic curve
parameters with a base point encoded in compressed form.
It is possible to trigger the infinite loop by crafting a certificate
that
has invalid explicit curve parameters.
Since certificate parsing happens prior to verification of the
certificate
signature, any process that parses an externally supplied certificate
may thus
be subject to a denial of service attack. The infinite loop can also be
reached when parsing crafted private keys as they can contain explicit
elliptic curve parameters.
Thus vulnerable situations include:
- TLS clients consuming server certificates
- TLS servers consuming client certificates
- Hosting providers taking certificates or private keys from customers
- Certificate authorities parsing certification requests from
subscribers
- Anything else which parses ASN.1 elliptic curve parameters
Also any other applications that use the BN_mod_sqrt() where the
attacker
can control the parameter values are vulnerable to this DoS issue.
In the OpenSSL 1.0.2 version the public key is not parsed during initial
parsing of the certificate which makes it slightly harder to trigger
the infinite loop. However any operation which requires the public key
from the certificate will trigger the infinite loop. In particular the
attacker can use a self-signed certificate to trigger the loop during
verification of the certificate signature.
This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was
addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022.
OpenSSL 1.0.2 users should upgrade to 1.0.2zd (premium support customers
only)
OpenSSL 1.1.1 users should upgrade to 1.1.1n
OpenSSL 3.0 users should upgrade to 3.0.2
This issue was reported to OpenSSL on the 24th February 2022 by Tavis
Ormandy
from Google. The fix was developed by David Benjamin from Google and
Tomáš Mráz
from OpenSSL.
Note
====
OpenSSL 1.0.2 is out of support and no longer receiving public updates.
Extended
support is available for premium support customers:
https://www.openssl.org/support/contracts.html
OpenSSL 1.1.0 is out of support and no longer receiving updates of any
kind.
It is affected by the issue.
Users of these versions should upgrade to OpenSSL 3.0 or 1.1.1.
References
==========
URL for this Security Advisory:
https://www.openssl.org/news/secadv/20220315.txt
Note: the online version of the advisory may be updated with additional
details
over time.
For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Full changelog as per https://gitweb.torproject.org/tor.git/plain/ChangeLog?h=tor-0.4.6.10 :
Changes in version 0.4.6.10 - 2022-02-04
This version contains minor bugfixes but one in particular is that relays
don't advertise onion service v2 support at the protocol version level.
o Minor features (fallbackdir):
- Regenerate fallback directories generated on February 04, 2022.
o Minor features (geoip data):
- Update the geoip files to match the IPFire Location Database, as
retrieved on 2022/02/04.
o Minor bugfix (logging):
- Update a log notice dead URL to a working one. Fixes bug 40544;
bugfix on 0.3.5.1-alpha.
o Minor bugfix (relay):
- Remove the HSDir and HSIntro onion service v2 protocol versions so
relay stop advertising that they support them. Fixes bug 40509;
bugfix on 0.3.5.17.
o Minor bugfixes (MetricsPort, Prometheus):
- Add double quotes to the label values of the onion service
metrics. Fixes bug 40552; bugfix on 0.4.5.1-alpha.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
There seems to be some problem where Cargo deadlocks during the build
when running on mutliple cores simulteneously.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
riscv64 does not return any value on our machine (maybe because it is
emulated?). "undefined" is however seen as a valid value, which makes
the build fail.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This kernel configuration is a copy of our kernel configuration for
x86_64 on which I ran "make olddefconfig" which will set any unknown
values to their defaults.
This exists so that we have some kernel (which I did not try to boot) to
complete the build process.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
GCC can use ZSTD to compress debugging/LTO information in binary
objects. However, on riscv64, compiling zstd requires libatomic which is
not available at this point.
In order to make the build work, we explicitely disable ZSTD in GCC and
build ZSTD after libatomic is available.
Although ZSTD offers great compression, we won't have any disadvantages
through this change since we do not ship any debugging information and
at this point in time to not use LTO.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The host might not have the correct tools to strip a foreign
architecture, therefore we need to use the cross tools.
The crosstools might be built in an architecture that they
cannot strip themselves and since they are not being part of the
packaged toolchain, we will just skip them.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from 2.4.4 to 2.4.6
- Update of rootfile
- Changelog
Release 2.4.6 Sun February 20 2022
Bug fixes:
#566 Fix a regression introduced by the fix for CVE-2022-25313
in release 2.4.5 that affects applications that (1)
call function XML_SetElementDeclHandler and (2) are
parsing XML that contains nested element declarations
(e.g. "<!ELEMENT junk ((bar|foo|xyz+), zebra*)>").
Release 2.4.5 Fri February 18 2022
Security fixes:
#562 CVE-2022-25235 -- Passing malformed 2- and 3-byte UTF-8
sequences (e.g. from start tag names) to the XML
processing application on top of Expat can cause
arbitrary damage (e.g. code execution) depending
on how invalid UTF-8 is handled inside the XML
processor; validation was not their job but Expat's.
Exploits with code execution are known to exist.
#561 CVE-2022-25236 -- Passing (one or more) namespace separator
characters in "xmlns[:prefix]" attribute values
made Expat send malformed tag names to the XML
processor on top of Expat which can cause
arbitrary damage (e.g. code execution) depending
on such unexpectable cases are handled inside the XML
processor; validation was not their job but Expat's.
Exploits with code execution are known to exist.
#558 CVE-2022-25313 -- Fix stack exhaustion in doctype parsing
that could be triggered by e.g. a 2 megabytes
file with a large number of opening braces.
Expected impact is denial of service or potentially
arbitrary code execution.
#560 CVE-2022-25314 -- Fix integer overflow in function copyString;
only affects the encoding name parameter at parser creation
time which is often hardcoded (rather than user input),
takes a value in the gigabytes to trigger, and a 64-bit
machine. Expected impact is denial of service.
#559 CVE-2022-25315 -- Fix integer overflow in function storeRawNames;
needs input in the gigabytes and a 64-bit machine.
Expected impact is denial of service or potentially
arbitrary code execution.
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Reviewed-by: Michael Tremer <michael.tremer@ipfire.org>
Bumping across one of our scripts with very long trailing whitespaces, I
thought it might be a good idea to clean these up. Doing so, some
missing or inconsistent licence headers were fixed.
There is no need in shipping all these files en bloc, as their
functionality won't change.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
In theory, logging of dropped packets classified by conntrack as being
INVALID should never be disabled, since one wants to have a paper trail
of what his/her firewall is doing.
However, conntrack seems to drop a lot of (at the first glance
legitimate) packets, hence bloating the logs, making spotting the
important firewall hits more difficult.
This patch therefore adds the option to disable logging of packets being
dropped by conntrack due to INVALID state.
Please note:
- This patch does not add this category to the firewall hits graph.
- The variables in this patch ("LOGDROPCTINVALID") should make it clear
that it is about toggling _logging_, not the actual _dropping_. Other
variables are still in need of being renamed to clarify this, which
will be done in a dedicated patch.
- Also, the changes made to update.sh need to take place in
config/rootfiles/core/164/update.sh for "master", since this patch has
been developed against "next". Kindly cherry-pick the necessary
changes.
Partially fixes: #12778
Reported-by: Arne Fitzenreiter <arne.fitzenreiter@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
