This fixes a DoS and potential remote code execution vulnerability that was
caused because the original payload type that was returned previously was
used to cast such payload objects to payloads of the indicated type (e.g.
when logging notify payloads with a payload type for the wrong IKE version).
Fixes CVE-2015-3991.
Only one of `--user-install` and `--install-dir` may be set and if
`--user-install` is the default on a system installation will fail
unless we disable it explicitly.
Fixes#914.
Installing them might not work well when building distro packages (e.g.
with DESTDIR installs). It might be easier to install them later with a
script in the distro package.
When building from source on the local system it could still be useful to
install the packages directly, which can be enabled with separate configure
options.
The main problem with DESTDIR installations of the Python Egg is that
easy_install creates or modifies a file called easy-install.pth in the
installation directory. So it's not actually possible to simply copy
the results in DESTDIR over to the actual system as that file would have
to be merged with any existing one.
Fixes#914.
We also don't require setup.py to exist during cleanup, as e.g. with
make distcheck the source directory is not writable when the build directory
is cleaned, so setup.py can't be created (to just get removed again anyway
if VICI and the Python Eggs haven't been enabled previously).
Instead of just implicitly destroying the old SA we properly delete it to
notify the other peer (if the other peer keeps the SA up after the
reauthentication and sends DPDs it might consider us dead even though the
new SA is up, that seems to be the case with racoon). We delay the DELETE
a bit to give the other peer time to get the new SA fully established.
Since DELETE messages are not retransmitted it is still possible that
the other peer misses that we deleted the SA.
The interface is currently not very nice, but if we ever were able to
safely checkout multiple SAs concurrently we could add something similar
to ike_rekey() and call that when we detect a reauthentication.
There are several situations that the previous code didn't handle that
well, for example, interim updates during rekeying (until the rekeyed SA
was deleted the numbers were too high, then suddenly dropped afterwards),
or rekeying for IKEv1 in general because rekeyed IPsec SAs stay installed
until they expire (so if they were still around when the IKE_SA was
terminated, the reported numbers in the Stop message were too high).
If intermediate updates are not used the cache entries for rekeyed
CHILD_SA will accumulate, we can't clean them up as we don't get
child_updown() events for them.
If we sent retransmits for a message and didn't receive a response it might
still arrive later. Such a message will be queued on the socket. The next
read will then return not the expected response but the one for the earlier
request. For this message the verification will fail and the message gets
discarded. But with the earlier code the actual response was never received.
Instead, a subsequent request resulted in the same failure and so on.
Fixes#838.
The only purpose of starter is to control the IKE daemon, so we
terminate it if the daemon executable is not found (e.g. because
DAEMON_NAME is incorrect).
This removes the charonstart setting (it was not actually configurable
anymore).
Since the removal of pluto this is quite superfluous. The flag itself
might be useful to avoid starting charon if the executable does not
exist for some reason (e.g. if DAEMON_NAME is incorrect).
Returning FAILED in the constructor is wrong, but returning NULL doesn't work
either as it's currently assumed tasks always can be created.
Therefore, delay this check until we actually try to allocate a nonce.
This prevented `stroke memusage` from reporting the leaks on the
console. Instead, they were sent to the callbacks set up by libstrongswan.
Fixes a426851f63 ("leak-detective: Use callback functions to report
leaks and usage information").
While DES-ECB is not registered by the plugin in this case (so the
function will never actually be called), the compiler still warns
about the implicitly declared function.
This is needed to fix usage stats sent via RADIUS Accounting if clients
use MOBIKE or e.g. the kernel notifies us about a changed NAT mapping.
The upper layers won't expect the stats to get reset if only the IPs have
changed (and some kernel interface might actually allow such updates
without reset).
It also fixes traffic based lifetimes in such situations.
Fixes#799.
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
OpenBSD's isakmpd uses the latest ISAKMP SA to delete other expired SAs.
This caused strongSwan to delete e.g. a rekeyed SA even though isakmpd
meant to delete the old one.
What isakmpd does might not be standard compliant. As RFC 2408 puts
it:
Deletion which is concerned with an ISAKMP SA will contain a
Protocol-Id of ISAKMP and the SPIs are the initiator and responder
cookies from the ISAKMP Header.
This could either be interpreted as "copy the SPIs from the ISAKMP
header of the current message to the DELETE payload" (which is what
strongSwan assumed, and the direction IKEv2 took it, by not sending SPIs
for IKE), or as clarification that ISAKMP "cookies" are actually the
SPIs meant to be put in the payload (but that any ISAKMP SA may be
deleted).
Since the BLISS private key supports this we don't do any special
handling anymore (if the user choses a digest that is not supported,
signing will simply fail later because no signature scheme will be found).
The specific traffic selectors from the acquire events, which are derived
from the triggering packet, are usually prepended to those from the
config. Some implementations might not be able to handle these properly.
References #860.
The verification introduced with 84738b1aed ("encoding: Verify the length
of KE payload data for known groups") can't be done for IKEv1 as the KE
payload does not contain the DH group.
Some clients like iOS/Mac OS X don't do a mode config exchange on the
new SA during re-authentication. If we don't adopt the previous virtual
IP Quick Mode rekeying will later fail.
If a client does do Mode Config we directly reassign the VIPs we migrated
from the old SA, without querying the attributes framework.
Fixes#807, #810.
TKM can't verify such signatures so we'd fail in the authorize hook.
Skipping the algorithm identifier doesn't help if the peer uses
anything other than SHA-1, so config changes would be required.
Previously, we failed without recovery if a private key did not support
a selected signature scheme (based on key strength and the other peer's
supported hash algorithms).
Especially callback jobs might refer to memory that gets invalid after
the plugins got unlaoded, so make sure we destroy these jobs before.
References #840.
Since we can't get rid of all unmet dependencies (at least not in every
possible plugin configuration) the message is more confusing than
helpful. In particular because a detailed warning about plugin features
that failed to load due to unmet dependencies is only logged on level 2.
In case a CA certificate uses the same subject DN as the server the
previous code could end up trying to verify the server's signature with
the CA certificate's public key. By comparing the certificate with the
one sent by the peer we make sure to use the right one.
Fixes#849.
Some tokens might not fail when creating EC public keys in the incorrect
format, but they will later not be able to use them to verify signatures.
References #872.
The payload we sent before is not compliant with RFC 2407 and thus some
peers might abort negotiation (e.g. with an INVALID-PROTOCOL-ID error).
Fixes#819.
Some CAs don't use SHA-1 hashes of the public key as subjectKeyIdentifier and
authorityKeyIdentifier. If that's the case we can't force the
calculation of the hash to compare that to authorityKeyIdentifier in the CRL,
instead we use the subjectKeyIdentifier stored in the issuer certificate, if
available. Otherwise, we fall back to the SHA-1 hash (or comparing the
DNs) as before.
If many requests are sent to the kernel the events generated by these
requests may fill the receive buffer before the daemon is able to read
these messages.
Fixes#783.
This adds support for RFC 7427 signature authentication in IKEv2,
enabling the use of stronger signature schemes (e.g. RSA with SHA-2)
for IKE authentication.
Public key constraints defined in `rightauth` are now also checked
against IKEv2 signature schemes (may be disabled via strongswan.conf).
Fixes#863.
Tobias Brunner