Currently, the build option to enable/disable engine support isn't
reflected in the final '/etc/ssl/openssl.cnf' config. It assumes `engines`
is always enabled, producing an error whenever running any
commands in openssl util or programs that explicitly use settings
from '/etc/ssl/openssl.cnf'.
```
➤ openssl version
FATAL: Startup failure (dev note: apps_startup()) for openssl
307D1EA97F000000:error:12800067:lib(37):dlfcn_load:reason(103):crypto/dso/dso_dlfcn.c:118:filename(libengines.so):
Error loading shared library libengines.so: No such file or directory
307D1EA97F000000:error:12800067:lib(37):DSO_load:reason(103):crypto/dso/dso_lib.c:152:
307D1EA97F000000:error:0700006E:lib(14):module_load_dso:reason(110):crypto/conf/conf_mod.c:321:module=engines, path=engines
307D1EA97F000000:error:07000071:lib(14):module_run:reason(113):crypto/conf/conf_mod.c:266:module=engines
```
Build should check for the `CONFIG_OPENSSL_ENGINE` option, and comment out `engines`
if not explicitly enabled.
Example:
```
[openssl_init]
providers = provider_sect
```
After this change, openssl util works correctly.
```
➤ openssl version
OpenSSL 3.0.14 4 Jun 2024 (Library: OpenSSL 3.0.14 4 Jun 2024)
```
Signed-off-by: Sean Khan <datapronix@protonmail.com>
Link: https://github.com/openwrt/openwrt/pull/15661
Signed-off-by: Robert Marko <robimarko@gmail.com>
(cherry picked from commit 31ec4515c3)
Link: https://github.com/openwrt/openwrt/pull/15873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Major changes between OpenSSL 3.0.13 and OpenSSL 3.0.14 [04-Jun-2024]
* Fixed potential use after free after SSL_free_buffers() is called.
[CVE-2024-4741]
* Fixed checking excessively long DSA keys or parameters may be very slow.
[CVE-2024-4603]
* Fixed an issue where some non-default TLS server configurations can cause
unbounded memory growth when processing TLSv1.3 sessions. An attacker may
exploit certain server configurations to trigger unbounded memory growth that
would lead to a Denial of Service. [CVE-2024-2511]
* New atexit configuration switch, which controls whether the OPENSSL_cleanup
is registered when libcrypto is unloaded. This can be used on platforms
where using atexit() from shared libraries causes crashes on exit
Signed-off-by: John Audia <therealgraysky@proton.me>
Build system: x86/64
Build-tested: x86/64/AMD Cezanne
(cherry picked from commit bac2f1bed6)
Link: https://github.com/openwrt/openwrt/pull/15873
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Major changes between OpenSSL 3.0.12 and OpenSSL 3.0.13 [30 Jan 2024]
* Fixed PKCS12 Decoding crashes
([CVE-2024-0727])
* Fixed Excessive time spent checking invalid RSA public keys
([CVE-2023-6237])
* Fixed POLY1305 MAC implementation corrupting vector registers on PowerPC
CPUs which support PowerISA 2.07
([CVE-2023-6129])
* Fix excessive time spent in DH check / generation with large Q parameter
value ([CVE-2023-5678])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit 44cd90c49a)
Major changes between OpenSSL 3.0.11 and OpenSSL 3.0.12 [24 Oct 2023]
* Mitigate incorrect resize handling for symmetric cipher keys and IVs. (CVE-2023-5363)
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
(cherry picked from commit e4ebc7b566)
Changes between 3.0.10 and 3.0.11 [19 Sep 2023]
* Fix POLY1305 MAC implementation corrupting XMM registers on Windows. ([CVE-2023-4807])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit bfd54529fa)
Changes between 3.0.9 and 3.0.10 [1 Aug 2023]
* Fix excessive time spent checking DH q parameter value ([CVE-2023-3817])
* Fix DH_check() excessive time with over sized modulus ([CVE-2023-3446])
* Do not ignore empty associated data entries with AES-SIV ([CVE-2023-2975])
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit 92602f823a)
openssl sets additional cflags in its configuration script. We need to
make it aware of our custom cflags to avoid adding conflicting cflags.
Fixes: #12866
Signed-off-by: Jitao Lu <dianlujitao@gmail.com>
(cherry picked from commit 51f57e7c2d)
Add "linux-riscv64-openwrt" into openssl configurations to enable building
on riscv64.
Signed-off-by: Zoltan HERPAI <wigyori@uid0.hu>
(cherry picked from commit a0840ecd53)
CVE-2023-2650 fix
Remove upstreamed patches
Major changes between OpenSSL 3.0.8 and OpenSSL 3.0.9 [30 May 2023]
* Mitigate for very slow OBJ_obj2txt() performance with gigantic OBJECT IDENTIFIER sub-identities. (CVE-2023-2650)
* Fixed buffer overread in AES-XTS decryption on ARM 64 bit platforms (CVE-2023-1255)
* Fixed documentation of X509_VERIFY_PARAM_add0_policy() (CVE-2023-0466)
* Fixed handling of invalid certificate policies in leaf certificates (CVE-2023-0465)
* Limited the number of nodes created in a policy tree (CVE-2023-0464)
Signed-off-by: Ivan Pavlov <AuthorReflex@gmail.com>
(cherry picked from commit 6348850f10)
Built-in engine configs are added in libopenssl-conf/install stage
already, postinst/add_engine_config is just duplicating them, and
due to the lack of `config` header it results a broken uci config:
> uci: Parse error (invalid command) at line 3, byte 0
```
config engine 'devcrypto'
option enabled '1'
engine 'devcrypto'
option enabled '1'
option builtin '1'
```
Add `builtin` option in libopenssl-conf/install stage and remove
duplicate engine configuration in postinst/add_engine_config to
fix this issue.
Fixes: 0b70d55a64 ("openssl: make UCI config aware of built-in engines")
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
(cherry picked from commit a0d7193425)
This applies commit 02ac9c94 to fix this OpenSSL Security Advisory
issued on 20th April 2023[1]:
Input buffer over-read in AES-XTS implementation on 64 bit ARM
(CVE-2023-1255)
==============================================================
Severity: Low
Issue summary: The AES-XTS cipher decryption implementation for 64 bit
ARM platform contains a bug that could cause it to read past the input
buffer, leading to a crash.
Impact summary: Applications that use the AES-XTS algorithm on the 64
bit ARM platform can crash in rare circumstances. The AES-XTS algorithm
is usually used for disk encryption.
The AES-XTS cipher decryption implementation for 64 bit ARM platform
will read past the end of the ciphertext buffer if the ciphertext size
is 4 mod 5 in 16 byte blocks, e.g. 144 bytes or 1024 bytes. If the
memory after the ciphertext buffer is unmapped, this will trigger a
crash which results in a denial of service.
If an attacker can control the size and location of the ciphertext
buffer being decrypted by an application using AES-XTS on 64 bit ARM,
the application is affected. This is fairly unlikely making this issue a
Low severity one.
1. https://www.openssl.org/news/secadv/20230420.txt
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Apply two patches fixing low-severity vulnerabilities related to
certificate policies validation:
- Excessive Resource Usage Verifying X.509 Policy Constraints
(CVE-2023-0464)
Severity: Low
A security vulnerability has been identified in all supported versions
of OpenSSL related to the verification of X.509 certificate chains
that include policy constraints. Attackers may be able to exploit
this vulnerability by creating a malicious certificate chain that
triggers exponential use of computational resources, leading to a
denial-of-service (DoS) attack on affected systems.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
- Invalid certificate policies in leaf certificates are silently ignored
(CVE-2023-0465)
Severity: Low
Applications that use a non-default option when verifying certificates
may be vulnerable to an attack from a malicious CA to circumvent
certain checks.
Invalid certificate policies in leaf certificates are silently ignored
by OpenSSL and other certificate policy checks are skipped for that
certificate. A malicious CA could use this to deliberately assert
invalid certificate policies in order to circumvent policy checking on
the certificate altogether.
Policy processing is disabled by default but can be enabled by passing
the `-policy' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
Note: OpenSSL also released a fix for low-severity security advisory
CVE-2023-466. It is not included here because the fix only changes the
documentation, which is not built nor included in any OpenWrt package.
Due to the low-severity of these issues, there will be not be an
immediate new release of OpenSSL.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This adapts the engine build infrastructure to allow building providers,
and packages the legacy provider. Providers are the successors of
engines, which have been deprecated.
The legacy provider supplies OpenSSL implementations of algorithms that
have been deemed legacy, including DES, IDEA, MDC2, SEED, and Whirlpool.
Even though these algorithms are implemented in a separate package,
their removal makes the regular library smaller by 3%, so the build
options will remain to allow lean custom builds. Their defaults will
change to 'y' if not bulding for a small flash, so that the regular
legacy package will contain a complete set of algorithms.
The engine build and configuration structure was changed to accomodate
providers, and adapt to the new style of openssl.cnf in version 3.0.
There is not a clean upgrade path for the /etc/ssl/openssl.cnf file,
installed by the openssl-conf package. It is recommended to rename or
remove the old config file when flashing an image with the updated
openssl-conf package, then apply the changes manually.
An old openssl.cnf file will silently work, but new engine or provider
packages will not be enabled. Any remaining engine config files under
/etc/ssl/engines.cnf.d can be removed.
On the build side, the include file used by engine packages was renamed
to openssl-module.mk, so the engine packages in other feeds need to
adapt.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Engines that are built into the main libcrypto OpenSSL library can't be
disabled through UCI. Add a 'builtin' setting to signal that the engine
can't be disabled through UCI, and show a message explaining this in
case buitin=1 and enabled=0.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Building openssl with OPENSSL_SMALL_FOOTPRINT yelds only from 1% to 3%
decrease in size, dropping performance from 2% to 91%, depending on the
target and algorithm.
For example, using AES256-GCM with 1456-bytes operations, X86_64 appears
to be the least affected with 2% performance penalty and 1% reduction in
size; mips drops performance by 13%, size by 3%; Arm drops 29% in
performance, 2% in size.
On aarch64, it slows down ghash so much that I consider it broken
(-91%). SMALL_FOOTPRINT will reduce AES256-GCM performance by 88%, and
size by only 1%. It makes an AES-capable CPU run AES128-GCM at 35% of
the speed of Chacha20-Poly1305:
Block-size=1456 bytes AES256-GCM AES128-GCM ChaCha20-Poly1305
SMALL_FOOTPRINT 62014.44 65063.23 177090.50
regular 504220.08 565630.28 182706.16
OpenSSL 1.1.1 numbers are about the same, so this should have been
noticed a long time ago.
This creates an option to use OPENSSL_SMALL_FOOTPRINT, but it is turned
off by default unless SMALL_FLASH or LOW_MEMORY_FOOTPRINT is used.
Compiling with -O3 instead of -Os, for comparison, will increase size by
about 14-15%, with no measureable effect on AES256-GCM performance, and
about 2% increase in Chacha20-Poly1305 performance on Aarch64.
There are no Arm devices with the small flash feature, so drop the
conditional default. The package is built on phase2, so even if we
include an Arm device with small flash later, a no-asm library would
have to be built from source anyway.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This reduces open coding and allows to easily add a knob to
enable it treewide, where chosen packages can still opt-out via
"no-gc-sections".
Note: libnl, mbedtls and opkg only used the CFLAGS part without the
LDFLAGS counterpart. That doesn't help at all if the goal is to produce
smaller binaries. I consider that an accident, and this fixes it.
Note: there are also packages using only the LDFLAGS part. I didn't
touch those, as gc might have been disabled via CFLAGS intentionally.
Signed-off-by: Andre Heider <a.heider@gmail.com>
Fix the trivial abscence of $() when assigning engine config files to
the main libopenssl-config package even if the corresponding engines
were not built into the main library.
This is mostly cosmetic, since scripts/ipkg-build tests the file's
presence before it is actually included in the package's conffiles.
Fixes: 30b0351039 "openssl: configure engine packages during install"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
The bump to 3.0.8 inadvertently removed patches that are needed here,
but were not adopted upstream. The most important one changes the
default value of the DIGESTS setting from ALL to NONE. The absence of
this patch causes a sysupgrade failure while the engine is in use with
digests enabled. When this happens, the system fails to boot with a
kernel panic.
Also, explicitly set DIGESTS to NONE in the provided config file, and
change the default ciphers setting to disable ECB, which has been
recommended for a long time and may cause trouble with some apps.
The config file change by itself is not enough because the config file
may be preserved during sysupgrade.
For people affected by this bug:
You can either:
1. remove, the libopenssl-devcrypto package
2. disable the engine in /etc/config/openssl;
3. change /etc/ssl/engines.cnf.d/devcrypto.cnf to set DIGESTS=NONE;
4. update libopenssl-devcrypto to >=3.0.8-3
However, after doing any of the above, **you must reboot the device
before running sysupgrade** to ensure no running application is using
the engine. Running `/etc/init.d/openssl restart` is not enough.
Fixes: 7e7e76afca "openssl: bump to 3.0.8"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
PowerPC CONFIG_ARCH is defined as powerpc, not ppc. Fix that in the
DEPENDS condition.
Arc needs to be built with libatomic. Change the OpenSSL configuration
file, and add it to the libatomic DEPENDS condition.
Fixes: 7e7e76afca "openssl: bump to 3.0.8"
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Removed upstreamed patch: 010-padlock.patch
Changes between 1.1.1s and 1.1.1t [7 Feb 2023]
*) Fixed X.400 address type confusion in X.509 GeneralName.
There is a type confusion vulnerability relating to X.400 address processing
inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING
but subsequently interpreted by GENERAL_NAME_cmp as an ASN1_TYPE. This
vulnerability may allow an attacker who can provide a certificate chain and
CRL (neither of which need have a valid signature) to pass arbitrary
pointers to a memcmp call, creating a possible read primitive, subject to
some constraints. Refer to the advisory for more information. Thanks to
David Benjamin for discovering this issue. (CVE-2023-0286)
This issue has been fixed by changing the public header file definition of
GENERAL_NAME so that x400Address reflects the implementation. It was not
possible for any existing application to successfully use the existing
definition; however, if any application references the x400Address field
(e.g. in dead code), note that the type of this field has changed. There is
no ABI change.
[Hugo Landau]
*) Fixed Use-after-free following BIO_new_NDEF.
The public API function BIO_new_NDEF is a helper function used for
streaming ASN.1 data via a BIO. It is primarily used internally to OpenSSL
to support the SMIME, CMS and PKCS7 streaming capabilities, but may also
be called directly by end user applications.
The function receives a BIO from the caller, prepends a new BIO_f_asn1
filter BIO onto the front of it to form a BIO chain, and then returns
the new head of the BIO chain to the caller. Under certain conditions,
for example if a CMS recipient public key is invalid, the new filter BIO
is freed and the function returns a NULL result indicating a failure.
However, in this case, the BIO chain is not properly cleaned up and the
BIO passed by the caller still retains internal pointers to the previously
freed filter BIO. If the caller then goes on to call BIO_pop() on the BIO
then a use-after-free will occur. This will most likely result in a crash.
(CVE-2023-0215)
[Viktor Dukhovni, Matt Caswell]
*) Fixed Double free after calling PEM_read_bio_ex.
The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the "name" (e.g. "CERTIFICATE"), any header data and the payload
data. If the function succeeds then the "name_out", "header" and "data"
arguments are populated with pointers to buffers containing the relevant
decoded data. The caller is responsible for freeing those buffers. It is
possible to construct a PEM file that results in 0 bytes of payload data.
In this case PEM_read_bio_ex() will return a failure code but will populate
the header argument with a pointer to a buffer that has already been freed.
If the caller also frees this buffer then a double free will occur. This
will most likely lead to a crash.
The functions PEM_read_bio() and PEM_read() are simple wrappers around
PEM_read_bio_ex() and therefore these functions are also directly affected.
These functions are also called indirectly by a number of other OpenSSL
functions including PEM_X509_INFO_read_bio_ex() and
SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL
internal uses of these functions are not vulnerable because the caller does
not free the header argument if PEM_read_bio_ex() returns a failure code.
(CVE-2022-4450)
[Kurt Roeckx, Matt Caswell]
*) Fixed Timing Oracle in RSA Decryption.
A timing based side channel exists in the OpenSSL RSA Decryption
implementation which could be sufficient to recover a plaintext across
a network in a Bleichenbacher style attack. To achieve a successful
decryption an attacker would have to be able to send a very large number
of trial messages for decryption. The vulnerability affects all RSA padding
modes: PKCS#1 v1.5, RSA-OEAP and RSASVE.
(CVE-2022-4304)
[Dmitry Belyavsky, Hubert Kario]
Signed-off-by: John Audia <therealgraysky@proton.me>
Byte swapping code incorrectly uses the number of AES rounds to swap expanded
AES key, while swapping only a single dword in a loop, resulting in swapped
key and partially swapped expanded keys, breaking AES encryption and
decryption on VIA Padlock hardware.
This commit correctly sets the number of swapping loops to be done.
Upstream: 2bcf8e69bd
Acked-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: ValdikSS ValdikSS <iam@valdikss.org.ru>
Changes between 1.1.1r and 1.1.1s [1 Nov 2022]
*) Fixed a regression introduced in 1.1.1r version not refreshing the
certificate data to be signed before signing the certificate.
[Gibeom Gwon]
Changes between 1.1.1q and 1.1.1r [11 Oct 2022]
*) Fixed the linux-mips64 Configure target which was missing the
SIXTY_FOUR_BIT bn_ops flag. This was causing heap corruption on that
platform.
[Adam Joseph]
*) Fixed a strict aliasing problem in bn_nist. Clang-14 optimisation was
causing incorrect results in some cases as a result.
[Paul Dale]
*) Fixed SSL_pending() and SSL_has_pending() with DTLS which were failing to
report correct results in some cases
[Matt Caswell]
*) Fixed a regression introduced in 1.1.1o for re-signing certificates with
different key sizes
[Todd Short]
*) Added the loongarch64 target
[Shi Pujin]
*) Fixed a DRBG seed propagation thread safety issue
[Bernd Edlinger]
*) Fixed a memory leak in tls13_generate_secret
[Bernd Edlinger]
*) Fixed reported performance degradation on aarch64. Restored the
implementation prior to commit 2621751 ("aes/asm/aesv8-armx.pl: avoid
32-bit lane assignment in CTR mode") for 64bit targets only, since it is
reportedly 2-17% slower and the silicon errata only affects 32bit targets.
The new algorithm is still used for 32 bit targets.
[Bernd Edlinger]
*) Added a missing header for memcmp that caused compilation failure on some
platforms
[Gregor Jasny]
Build system: x86_64
Build-tested: bcm2711/RPi4B
Run-tested: bcm2711/RPi4B
Signed-off-by: John Audia <therealgraysky@proton.me>
Changes between 1.1.1p and 1.1.1q [5 Jul 2022]
*) AES OCB mode for 32-bit x86 platforms using the AES-NI assembly optimised
implementation would not encrypt the entirety of the data under some
circumstances. This could reveal sixteen bytes of data that was
preexisting in the memory that wasn't written. In the special case of
"in place" encryption, sixteen bytes of the plaintext would be revealed.
Since OpenSSL does not support OCB based cipher suites for TLS and DTLS,
they are both unaffected.
(CVE-2022-2097)
[Alex Chernyakhovsky, David Benjamin, Alejandro Sedeño]
Signed-off-by: Dustin Lundquist <dustin@null-ptr.net>
Changes between 1.1.1o and 1.1.1p [21 Jun 2022]
*) In addition to the c_rehash shell command injection identified in
CVE-2022-1292, further bugs where the c_rehash script does not
properly sanitise shell metacharacters to prevent command injection have been
fixed.
When the CVE-2022-1292 was fixed it was not discovered that there
are other places in the script where the file names of certificates
being hashed were possibly passed to a command executed through the shell.
This script is distributed by some operating systems in a manner where
it is automatically executed. On such operating systems, an attacker
could execute arbitrary commands with the privileges of the script.
Use of the c_rehash script is considered obsolete and should be replaced
by the OpenSSL rehash command line tool.
(CVE-2022-2068)
[Daniel Fiala, Tomáš Mráz]
*) When OpenSSL TLS client is connecting without any supported elliptic
curves and TLS-1.3 protocol is disabled the connection will no longer fail
if a ciphersuite that does not use a key exchange based on elliptic
curves can be negotiated.
[Tomáš Mráz]
Signed-off-by: Andre Heider <a.heider@gmail.com>
This release comes with a security fix related to c_rehash. OpenWrt
does not ship or use it, so it was not affected by the bug.
There is a fix for a possible crash in ERR_load_strings() when
configured with no-err, which OpenWrt does by default.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
engine.mk is supposed to be included by engine packages, but it will not
be present in the SDK in the same place as in the main repository.
Move it to include/openssl-engine.mk to avoid this.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This is a bugfix release. Changelog:
*) Fixed a bug in the BN_mod_sqrt() function that can cause it to loop
forever for non-prime moduli. (CVE-2022-0778)
*) Add ciphersuites based on DHE_PSK (RFC 4279) and ECDHE_PSK
(RFC 5489) to the list of ciphersuites providing Perfect Forward
Secrecy as required by SECLEVEL >= 3.
Signed-off-by: Martin Schiller <ms@dev.tdt.de>
This uses uci to configure engines, by generating a list of enabled
engines in /var/etc/ssl/engines.cnf from engines configured in
/etc/config/openssl:
config engine 'devcrypto'
option enabled '1'
Currently the only options implemented are 'enabled', which defaults to
true and enables the named engine, and the 'force' option, that enables
the engine even if the init script thinks the engine does not exist.
The existence test is to check for either a configuration file
/etc/ssl/engines.cnf.d/%ENGINE%.cnf, or a shared object file
/usr/lib/engines-1.1/%ENGINE%.so.
The engine list is generated by an init script which is set to run after
'log' because it informs the engines being enabled or skipped. It
should run before any service using OpenSSL as the crypto library,
otherwise the service will not use any engine.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This enables an engine during its package's installation, by adding it
to the engines list in /etc/ssl/engines.cnf.d/engines.cnf.
The engine build system was reworked, with the addition of an engine.mk
file that groups some of the engine packages' definitions, and could be
used by out of tree engines as well.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This changes the configuration of engines from the global openssl.cnf to
files in the /etc/ssl/engines.cnf.d directory. The engines.cnf file has
the list of enabled engines, while each engine has its own configuration
file installed under /etc/ssl/engines.cnf.d.
Patches were refreshed with --zero-commit.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This is a bugfix release. Changelog:
*) Avoid loading of a dynamic engine twice.
*) Fixed building on Debian with kfreebsd kernels
*) Prioritise DANE TLSA issuer certs over peer certs
*) Fixed random API for MacOS prior to 10.12
Patches were refreshed.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Backport an upstream patch that adds support for ELFv2 ABI on big endian
ppc64. As musl only supports ELFv2 ABI on ppc64 regardless of
endianness, this is required to be able to build OpenSSL for ppc64be.
Modify our targets patch to add linux-powerpc64-openwrt, which will use
the linux64v2 perlasm scheme. This will probably break the combination
ppc64 with glibc, but as we really only want to support musl, this
shouldn't be a problem.
Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>
Acked-by: Rui Salvaterra <rsalvaterra@gmail.com>
This version fixes two vulnerabilities:
- SM2 Decryption Buffer Overflow (CVE-2021-3711)
Severity: High
- Read buffer overruns processing ASN.1 strings (CVE-2021-3712)
Severity: Medium
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Before this commit, it was assumed that mkhash is in the PATH. While
this was fine for the normal build workflow, this led to some issues if
make TOPDIR="$(pwd)" -C "$pkgdir" compile
was called manually. In most of the cases, I just saw warnings like this:
make: Entering directory '/home/.../package/gluon-status-page'
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
bash: line 1: mkhash: command not found
[...]
While these were only warnings and the package still compiled sucessfully,
I also observed that some package even fail to build because of this.
After applying this commit, the variable $(MKHASH) is introduced. This
variable points to $(STAGING_DIR_HOST)/bin/mkhash, which is always the
correct path.
Signed-off-by: Leonardo Mörlein <me@irrelefant.net>
This version fixes 2 security vulnerabilities, among other changes:
- CVE-2021-3450: problem with verifying a certificate chain when using
the X509_V_FLAG_X509_STRICT flag.
- CVE-2021-3449: OpenSSL TLS server may crash if sent a maliciously
crafted renegotiation ClientHello message from a client.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
The packages feed has a proposed package for a GOST engine, which needs
support from the main openssl library. It is a default option in
OpenSSL. All that needs to be done here is to not disable it.
Package increases by a net 1-byte, so it is not really really worth
keeping this optional.
This commit also includes a commented-out example engine configuration
in openssl.cnf, as it is done for other available engines.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
OpenSSL downloads itself are distributed using Akamai CDN, so use these
sources as the highest priority.
Remove a stale mirror which seems to be offline for a longer time
already.
Add fallbacks to the old release path also for the mirrors.
Signed-off-by: David Bauer <mail@david-bauer.net>
This fixes 4 security vulnerabilities/bugs:
- CVE-2021-2839 - SSLv2 vulnerability. Openssl 1.1.1 does not support
SSLv2, but the affected functions still exist. Considered just a bug.
- CVE-2021-2840 - calls EVP_CipherUpdate, EVP_EncryptUpdate and
EVP_DecryptUpdate may overflow the output length argument in some
cases where the input length is close to the maximum permissable
length for an integer on the platform. In such cases the return value
from the function call will be 1 (indicating success), but the output
length value will be negative.
- CVE-2021-2841 - The X509_issuer_and_serial_hash() function attempts to
create a unique hash value based on the issuer and serial number data
contained within an X509 certificate. However it was failing to
correctly handle any errors that may occur while parsing the issuer
field (which might occur if the issuer field is maliciously
constructed). This may subsequently result in a NULL pointer deref and
a crash leading to a potential denial of service attack.
- Fixed SRP_Calc_client_key so that it runs in constant time. This could
be exploited in a side channel attack to recover the password.
The 3 CVEs above are currently awaiting analysis.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Fixes: CVE-2020-1971, defined as high severity, summarized as:
NULL pointer deref in GENERAL_NAME_cmp function can lead to a DOS
attack.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This sets the --cross-compile-prefix option when running Configure, so
that that it will not use the host gcc to figure out, among other
things, compiler defines. It avoids errors, if the host 'gcc' is
handled by clang:
mips-openwrt-linux-musl-gcc: error: unrecognized command-line option
'-Qunused-arguments'
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Tested-by: Rosen Penev <rosenp@gmail.com>
Fixes NULL dereference in SSL_check_chain() for TLS 1.3, marked with
high severity, assigned CVE-2020-1967.
Ref: https://www.openssl.org/news/secadv/20200421.txt
Signed-off-by: Petr Štetiar <ynezz@true.cz>
There were two changes between 1.1.1e and 1.1.1f:
- a change in BN prime generation to avoid possible fingerprinting of
newly generated RSA modules
- the patch reversing EOF detection we had already applied.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This adds patches to avoid possible application breakage caused by a
change in behavior introduced in 1.1.1e. It affects at least nginx,
which logs error messages such as:
nginx[16652]: [crit] 16675#0: *358 SSL_read() failed (SSL: error:
4095126:SSL routines:ssl3_read_n:unexpected eof while reading) while
keepalive, client: xxxx, server: [::]:443
Openssl commits db943f4 (Detect EOF while reading in libssl), and
22623e0 (Teach more BIOs how to handle BIO_CTRL_EOF) changed the
behavior when encountering an EOF in SSL_read(). Previous behavior was
to return SSL_ERROR_SYSCALL, but errno would still be 0. The commits
being reverted changed it to SSL_ERRO_SSL, and add an error to the
stack, which is correct. Unfortunately this affects a number of
applications that counted on the old behavior, including nginx.
The reversion was discussed in openssl/openssl#11378, and implemented as
PR openssl/openssl#11400.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
This version includes bug and security fixes, including medium-severity
CVE-2019-1551, affecting RSA1024, RSA1536, DSA1024 & DH512 on x86_64.
Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
