This script appeared in the rootfiles for Core Updates 65 and 66, being
released in late 2012 and early 2013. It is not used elsewhere, and
there is no sense in keeping it around on IPFire installations.
Should this patch be accepted, a corresponding 'rm' statement is
necessary in the update.sh script of the Core Update it will go into.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
https://dlcdn.apache.org/httpd/CHANGES_2.4.53
Short summary of the most important SECURITY changes:
"Changes with Apache 2.4.53
*) SECURITY: CVE-2022-23943: mod_sed: Read/write beyond bounds
(cve.mitre.org)
Out-of-bounds Write vulnerability in mod_sed of Apache HTTP
Server allows an attacker to overwrite heap memory with possibly
attacker provided data.
This issue affects Apache HTTP Server 2.4 version 2.4.52 and
prior versions.
Credits: Ronald Crane (Zippenhop LLC)
*) SECURITY: CVE-2022-22721: core: Possible buffer overflow with
very large or unlimited LimitXMLRequestBody (cve.mitre.org)
If LimitXMLRequestBody is set to allow request bodies larger
than 350MB (defaults to 1M) on 32 bit systems an integer
overflow happens which later causes out of bounds writes.
This issue affects Apache HTTP Server 2.4.52 and earlier.
Credits: Anonymous working with Trend Micro Zero Day Initiative
*) SECURITY: CVE-2022-22720: HTTP request smuggling vulnerability
in Apache HTTP Server 2.4.52 and earlier (cve.mitre.org)
Apache HTTP Server 2.4.52 and earlier fails to close inbound
connection when errors are encountered discarding the request
body, exposing the server to HTTP Request Smuggling
Credits: James Kettle <james.kettle portswigger.net>
*) SECURITY: CVE-2022-22719: mod_lua Use of uninitialized value of
in r:parsebody (cve.mitre.org)
A carefully crafted request body can cause a read to a random
memory area which could cause the process to crash.
This issue affects Apache HTTP Server 2.4.52 and earlier.
Credits: Chamal De Silva
..."
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The file has to be write-able for the WUI and update script, which both
are executed as nobody.
Fixes#12803.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
These rulefiles are used by various providers as a kind of reference and
to store rules which have been taken out for correctness, performance
reasons or because of other reasons.
Fixes#12794.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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>
These rulefiles are used by various providers as a kind of reference and
to store rules which have been taken out for correctness, performance
reasons or because of other reasons.
Fixes#12794.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
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>
Only extract rulefiles which are located in a rules directory and/or in the archive
root.
This prevents us from extracting experimental or binary rules etc. which
often are located in corresponding sub-directories.
Reference: #12794.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Only extract rulefiles which are located in a rules directory and/or in the archive
root.
This prevents us from extracting experimental or binary rules etc. which
often are located in corresponding sub-directories.
Reference: #12794.
Signed-off-by: Stefan Schantl <stefan.schantl@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The current setup can fail and block all traffic on RED if the RETURN
rules could not be created.
This can happen when the kernel fails to load the ipset module, as it is
the case after upgrading to a new kernel. Restarting the firewall will
cause that the system is being cut off the internet.
This design now changes that if those rules cannot be created, the
DROP_HOSTILE feature is just inactive, but it would not disrupt any
traffic.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Daniel Weismüller <daniel.weismueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The current setup can fail and block all traffic on RED if the RETURN
rules could not be created.
This can happen when the kernel fails to load the ipset module, as it is
the case after upgrading to a new kernel. Restarting the firewall will
cause that the system is being cut off the internet.
This design now changes that if those rules cannot be created, the
DROP_HOSTILE feature is just inactive, but it would not disrupt any
traffic.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Daniel Weismüller <daniel.weismueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This file contains our custom settings:
* Always load microcodes as early as possible
* We now compress the initrd using Zstandard which is substanstically
faster than XZ, but offers better compression ratios
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
dracut requires the cp command to be compiled with support for extended
attributes (xattr) which we didn't have due to the required libraries
not being available to coreutils at build time.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
To solve the behavior discribed in bug 12404 I added the path
/var/ipfire/cups to the backup.
Signed-off-by: Daniel Weismueller <daniel.weismueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
https://lists.gnu.org/archive/html/info-gnu/2022-02/msg00017.html
"This is a minor bugfix release.
...
* Noteworthy changes in release 1.21.3 (2022-02-26)
** Fix computation of total bytes downloaded during FTP transfers (#61277)
** Add option to select TLS 1.3 on the command line
** Fix HSTS build issues on some 64-bit big-endian systems
** Hide password during status report in --no-verbose
** Remove a spurious print statement that showed up even during --quiet
** Some more cleanups and bug-fixes"
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
https://lore.kernel.org/lkml/YhIwUEpymVzmytdp@casper.infradead.org/
ReiserFS is an old file system which has not been actively maintained in
the Linux kernel for a long time. It is potentially going to be removed
soon which is why we shouldn't encourage people to create new
installations with ReiserFS any more.
This patch removes support for ReiserFS from the installer.
We should keep it enabled in the kernel for as long as it is available,
but we will have to encourage users potentially to re-install on a
different file system.
Since ReiserFS isn't very popular any more, I don't think that there
will be many users left.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
- Update from 4.53 to 4.54
- Update of rootfile not required
- Changelog
4.54 2022-02-03
- fix use of cache when calling ->cookie (GH #252)
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
