Checking for whitelisted functions in every backtrace is not very
efficient. And because OpenSSL 1.1 does no proper cleanup anymore until
the process is terminated there are now a lot more "leaks" to ignore.
For instance, in the openssl-ikev2/rw-cert scenario, just starting and
stopping the daemon (test vectors are checked) now causes 3594 whitelisted
leaks compared to the 849 before. This prolonged the shutdown of the
daemon on each guest in every scenario, amounting to multiple seconds of
additional runtime for every affected scenario. But even with this
patch there is still some overhead, compared to running the scenarios on
jessie.
RC4, which was previously used for performance reasons, is not supported
anymore with newer versions of SSH (stretch still supports it, but it
requires explicit configuration on the guests when they act as clients
too - the version in Ubuntu 18.04 apparently doesn't support it anymore
at all).
AES-GCM should actually be faster (at least for larger amounts of data and
in particular with hardware acceleration).
ClientAuthentication is known in OpenSSL 1.1 and the redefinition, therefore,
causes an error. These two OIDs are not used anyway in these config
files.
This adds the ability to return supported signature schemes (and
parameters) from a private key.
This is useful for keys on a TPM 2.0 as these can be used only with a
particular scheme (the hash algorithm and for RSA even the padding scheme
is fixed). For RSA with PSS padding there is an additional complication
because different TPMs use different salt lengths, which we have to know
beforehand to correctly produce e.g. a certificate request (the signature
covers the algorithm identifier that describes the signature scheme).
It turned out that the new method is also useful for the agent plugin.
Newer ssh/gpg-agents support SHA-256 and SHA-512 for RSA signatures, but
not SHA-384, which we can now convey to the pubkey authenticator.
Unfortunately, older agents ignore the flags that request a SHA2 signature
and just return one with SHA-1, in such scenarios IKEv2 signature
authentication has to be disabled.
SHA-384 is not supported but is selected by signature_schemes_for_key()
for keys between 3072 and 7680 bits.
Since this is only called for IKEv2 signature authentication we don't
even provide SHA-1 anymore. We always provide both schemes, though,
which is what pubkey-authenticator does too for RSA.
Older agents apparently just ignore the flags and always return a SHA-1
signature. If that's the case, charon.signature_authentication has to
be disabled.
On newer Android versions (8+) this does not seem to be necessary (adding
the onClick handler also sets "clickable" and that in turn seems to make
it focusable), however, for older releases it is (tested with 7.1.1
keyboard navigation just skips over the button). This was seen on a
Fire TV stick.
It looks like Android 9 incorrectly continues to use the regular DNS
servers after the blocking TUN device is replaced with the actual
interface. Setting DNS servers prevents that (since all traffic is
blocked, which ones doesn't really matter but local/loopback addresses
are rejected).
Interestingly, if the VPN server later does not assign any DNS servers, there
is no fallback to the non-VPN DNS servers for some reason (that's definitely
not as documented). This could potentially be a problem as we don't
offer an option to configure DNS servers in the VPN profile.
Neither issue is seen on older Android versions (only tested on 7.1.1).
Not sure when this happens exactly, in particular because the reported
stack traces look like this
java.lang.NullPointerException:
at org.strongswan.android.ui.VpnTileService.updateTile (VpnTileService.java:220)
at org.strongswan.android.ui.VpnTileService.onStartListening (VpnTileService.java:97)
at android.service.quicksettings.TileService$H.handleMessage (TileService.java:407)
which violates the API documentation for getQsTile(), which states:
This tile is only valid for updates between onStartListening() and
onStopListening().
But apparently that's not always the case. There have been two reports
of such a crash, both on Android 8.0 and on Xiaomi Mi 5/6 devices, so
maybe it's a bug in that particular image.
The previous code lost track of the selected profile IDs, but the
widgets maintained their state (i.e. the list item was still selected and the
edit button still enabled). Clicking the edit button then caused a crash when
trying to get the first item in the set.
Because `keylen` is unsigned the subtraction results in an integer
underflow if the key length is < 11 bytes.
This is only a problem when verifying signatures with a public key (for
private keys the plugin enforces a minimum modulus length) and to do so
we usually only use trusted keys. However, the x509 plugin actually
calls issued_by() on a parsed certificate to check if it is self-signed,
which is the reason this issue was found by OSS-Fuzz in the first place.
So, unfortunately, this can be triggered by sending an invalid client
cert to a peer.
Fixes: 5955db5b12 ("gmp: Don't parse PKCS1 v1.5 RSA signatures to verify them")
Fixes: CVE-2018-17540
Instead we generate the expected signature encoding and compare it to the
decrypted value.
Due to the lenient nature of the previous parsing code (minimum padding
length was not enforced, the algorithmIdentifier/OID parser accepts arbitrary
data after OIDs and in the parameters field etc.) it was susceptible to
Daniel Bleichenbacher's low-exponent attack (from 2006!), which allowed
forging signatures for keys that use low public exponents (i.e. e=3).
Since the public exponent is usually set to 0x10001 (65537) since quite a
while, the flaws in the previous code should not have had that much of a
practical impact in recent years.
Fixes: CVE-2018-16151, CVE-2018-16152
This merges all source files into botan_all.cpp, which reduces the build
time by almost 50%. Building outside the strongSwan tree avoids analyzing
Botan with sonarqube.
ldconfig is required, otherwise the library won't be found by
strongSwan in the same session.
Should later be changed to 2.8.0 or a newer stable release.
This also changes how unknown/corrupted memory is handled in the free()
and realloc() hooks in general.
Incorporates changes provided by Thomas Egerer who ran into a similar
issue.
Due to the mangled C++ function names it's tricky to be more specific. The
"leaked" allocations are from a static hashtable containing EC groups.
There is another leak caused by the locking allocator singleton
(triggered by the first function that uses it, usually initialization of
a cipher, but could be a hasher in other test runners), but we can avoid
that with a Botan config option.
Tobias Brunner