This tool shows that it is trivial to re-construct the value memcmp() compares
against by just measuring the time the non-time-constant memcmp() requires to
fail.
It also shows that even when running without any network latencies it gets
very difficult to reconstruct MAC/ICV values, as the time variances due to the
crypto routines are large enough that it gets difficult to measure the time
that memcmp() actually requires after computing the MAC.
However, the faster/time constant an algorithm is, the more likely is a
successful attack. When using AES-NI, it is possible to reconstruct (parts of)
a valid MAC with this tool, for example with AES-GCM.
While this is all theoretical, and way more difficult to exploit with network
jitter, it nonetheless shows that we should replace any use of memcmp/memeq()
with a constant-time alternative in all sensitive places.
Centralize all uses of CPUID to a cpu_feature class, which in theory can support
optional features of non-x86/x64 as well using architecture specific code.
We previously checked for older library versions without locking support at
all. But newer libraries can be built in single-threading mode as well, where
we have to care about the locking.
If a vici client registered for (control-)log events, but a vici read/write
operation fails, this may result in a deadlock. The attempt to write to the
bus results in a vici log message, which in turn tries to acquire the lock
for the entry currently held.
While a recursive lock could help as well for a single thread, there is still
a risk of inter-thread races if there is more than one thread listening for
events and/or having read/write errors.
We instead log to a local buffer, and write to the bus not before the connection
entry has been released. Additionally, we mark the connection entry as unusable
to avoid writing to the failed socket again, potentially triggering an error
loop.
Real AEADs directly provide a suitable IV generator, but traditional crypters
do not. For some (stream) ciphers, we should use sequential IVs, for which
we pass an appropriate generator to the AEAD wrapper.
With OpenSSL commit 929b0d70c19f60227f89fac63f22a21f21950823 setting an empty
key fails if no previous key has been set on that HMAC.
In 9138f49e we explicitly added the check we remove now, as HMAC_Update()
might crash if HMAC_Init_ex() has not been called yet. To avoid that, we
set and check a flag locally to let any get_mac() call fail if set_key() has
not yet been called.
sem_init() is deprecated on OS X, and it actually fails with ENOSYS. Using our
wrapped semaphore object is not an option, as it relies on the thread cleanup
that we can't rely on at this stage.
It is unclear why startup synchronization is required, as we can allocate the
thread ID just before creating the pthread. There is a chance that we allocate
a thread ID for a thread that fails to create, but the risk and consequences
are negligible.
This commit reverts 84738b1a and 2ed5f569.
As we have no DH group available in the KE payload for IKEv1, the verification
can't work in that stage. Instead, we now verify DH groups in the DH backends,
which works for any IKE version or any other purpose.
While 0909bf6c explicitly includes the whole source tree (to cover README.md),
this has the unpleasant side effect of covering a workspace under "testing"
with all its sources, or any other potential subdirectory that exists.
As the plugin has its origins in the sql plugin, it still uses the naming
scheme for the attribute provider implementation. Rename the class to better
match the naming scheme we use in any other plugin
In addition that it may reduce memory usage and improve performance for large
responses, it returns immediate results. This is important for longer lasting
commands, such as initiate/terminate, where immediate log feedback is preferable
when interactively calling such commands.
To simplify handling of authentication rounds in dictionaries/hashtables on the
client side, we assign unique names to each authentication round when listing
connection.
An uninstall target is currently not supported, as there is no trivial way with
either plain setuptools or with easy_install. pip would probably be the best
choice, but we currently don't depend on it.
IKE is very strict in the length of KE payloads, and it should be safe to
strictly verify their length. Not doing so is no direct threat, but allows DDoS
amplification by sending short KE payloads for large groups using the target
as the source address.
If additional tasks get queued before/while rekeying an IKE_SA, these get
migrated to the new IKE_SA. We previously did not trigger initiation of these
tasks, though, leaving the task unexecuted until a new task gets queued.
As the startup timestamp needs 10 characters, we only have left 4 characters
for the IKE_SA unique identifier. This is insufficient when having 10000 IKE_SAs
or more established, resulting in non-unique session identifiers.
Fixes#889.
We are actually not in rekeying state, but just trigger a separate, new IKE_SA
as a replacement for the current IKE_SA. Switching to the REKEYING state
disables the invocation of both IKE and CHILD_SA updown hooks as initiator,
preventing the removal of any firewall rules.
Fixes#885.
While a passively installed IKE_SA does not queue a DPD timeout job, one that
switches from active to passive might execute it. Ignore such a queued job if
the IKE_SA is in passive state.
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
While the the meaning of the "inbound" flag on the kernel_interface->add_sa()
call is not very clear, we still need that update logic to allow installation of
inbound SAs without SPI allocation. This is used in the HA plugin as a passive
node.
This reverts commit 698ed656.
While this change results in the correct add/update flag during installation,
it exchanges all other values in the child_sa->install() call. We should pass
the correct flag, but determine the add/update flag by other means.
This reverts commit e722ee5d.
While the comment is rather clear that we should not adopt live CHILD_SAs
during reauthentication in IKEv2, the code does nonetheless. Add an additional
version check to fix reauthentication if the reauth responder has a replace
uniqueids policy.
Fixes#871.
Introduces basic support for EAP server module authentication constraints. With
EAP-(T)TLS, public key, signature and end entity or CA certificate constraints
can be enforced for connections.
Fixes#762.
Remove all previously loaded certificates during "ipsec reread", finally
allowing the removal of CA certificates from a running daemon.
Fixes#842, #700, #305.
This makes these CA certificates independent from the purge issued by reread
commands. Certificates loaded by CA sections can be removed through ipsec.conf
update/reread, while CA certificates loaded implicitly from ipsec.d/cacerts
can individually be reread using ipsec rereadcacerts.
Martin Willi