This package is only compiled on x86_64 and i586 and cannot
be packaged in any of the other architectures.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
SMT can be forced on.
By default, all systems that are vulnerable to RIDL/Fallout
will have SMT disabled by default.
Systems that are not vulnerable to that will keep SMT enabled.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
While being built with user/group set to "tor", the default
configuration still contains the old username.
This patch adjusts it to the correct value. The issue was
caused by insufficient testing, which I apologise for.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
CBC ciphers are vulnerable to a bunch of attacks (being
rather academic so far) such as MAC-then-encrypt or
padding oracle.
These seem to be more serious (see
https://blog.qualys.com/technology/2019/04/22/zombie-poodle-and-goldendoodle-vulnerabilities
for further readings) which is why they should be used
for interoperability purposes only.
I plan to remove AES-CBC ciphers for the WebUI at the
end of the year, provided overall security landscape
has not changed until that.
This patch changes the WebUI cipherlist to:
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
(AES-CBC + ECDSA will be preferred over RSA for performance
reasons. As this cipher order cannot be trivially rebuilt with
OpenSSL cipher stings, it has to be hard-coded.)
All working clients will stay compatible.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This is a feature that will filter adult content from search
engine's results.
The old method of rewriting the HTTP request no longer works.
This method changes the DNS response for supported search engines
which violates our belief in DNSSEC and won't allow these search
engines to ever enable DNSSEC.
However, there is no better solution available to this and this
an optional feature, too.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
An authenticated Stored XSS (Cross-site Scripting) exists in the
(https://192.168.0.241:444/cgi-bin/routing.cgi) Routing Table Entries
via the "Remark" text box or "remark" parameter. This is due to a
lack of user input validation in "Remark" text box or "remark"
parameter. It allows an authenticated WebGUI user with privileges
for the affected page to execute Stored Cross-site Scripting in
the Routing Table Entries (/cgi-bin/routing.cgi), which helps
attacker to redirect the victim to a attacker's phishing page.
The Stored XSS get prompted on the victims page whenever victim
tries to access the Routing Table Entries configuraiton page.
An attacker get access to the victim's session by performing
the CSRF and gather the cookie and session id's or possibly can
change the victims configuration using this Stored XSS.
This attack can possibly spoof the victim's informations.
Fixes: #12072
Reported-by: Dharmesh Baskaran <dharmesh201093@gmail.com>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
