The protocol has long been replaced by IKEv2 and is officially deprecated
since several years (RFC 9395). As a first step to removing support for
it completely, this makes the configure option disabled by default and
warns users about its use.
There is no reason to keep this around anymore (has been superseded by
TNCCS-2.0 a long time ago). Removed the corresponding test scenarios.
Since this is the last user of libxml, also removed those references.
This was primarily used in our labs to visualize some TNC aspects but
the third-party daemon and frontend we used have not seen any development
in a decade. There never was any industry interest in this protocol
anyway, so just remove it.
Besides the relatively recent update to libsoup-3, this has not seen
much development and lacks several features. There does not seem to be
any advantage over using the curl plugin. So just remove it to reduce
the maintenance burden.
This has not seen any significant changes for years. So it lacks support
for modern algorithms and would require quite some work for an overhaul.
Given that we support several other crypto backends, let's just remove
this to reduce the maintenance burden.
The test scenarios and other references are also removed.
The 7.2 kernel has officially deprecated the interface and it will soon
be removed (support for hardware crypto offload has already been removed).
Also removed the corresponding test scenarios.
This plugin was developed for a customer who had very specific
requirements. It never did anything useful for regular users and
usually caused confusing errors if they enabled it by mistake. So
just remove it.
There is no reason to use Blowfish nowadays. Given that there are some
other plugins that still provide it, there is especially no reason to
maintain this custom implementation. Also removed the two test scenarios
that used the plugin to avoid promoting the use of this algorithm.
This was from a student project that has never been developed further.
And similar to the manager web application it lacks all sorts of modern
standards. So just remove it and the two plugins it relied on.
The test scenario is renamed to avoid confusion (neither of the two
p2pnat scenarios uses medsrv/medcli).
This fixes a potential TOCTOU issue with opening log files. The use of
`chown()` instead of `fchown()` could theoretically allow modifying the
ownership of an unintended file.
The log file now also is not world-readable anymore.
Also, the patch fixes the log groups for the two `(f)chown()` errors.
Fixes: d35d669180 ("Make syslog and file loggers configurable at runtime")
It might not be a good idea to blindly accept such extensions. A scoped
CRL could be accepted for the wrong scope. So just reject them again.
This reverts commit 126778679f.
The enumerator strictly handles pointers to pointers, so passing a
`u_int` is incorrect on 64-bit platforms.
Fixes: 918e92c4c9 ("Support multiple different public key strength types in constraints")
While for most uses the length is fixed and public (e.g. PRF/MAC outputs),
there are a few (e.g. in xauth-generic) that compare variable length
data.
The previous code directly leaked a differing length by short-circuiting
before comparing anything. While we could limit the comparison by the
minimum length (and call `memeq_const()`), that could still leak the
length because the time will plateau once the secret's length is reached.
Similarly, if the comparison was bound by the longer chunk (would prevent
the use of `memeq_const()`), the length could also be revealed once the
input gets longer than the secret and the time increases.
This changes the semantics of the function by declaring the first
argument the expected/reference secret and the second the variable input.
This strictly makes the function constant-time, bound by the secret's
length. So the length can't be guessed by providing different input (but
if an attacker can trigger the comparison against different secrets, of
potentially known lengths, it might still be possible). If the chunks
are known to have the same length, the order doesn't matter.
Callers of this function have been updated accordingly.
The check only references the original chunk, so for each parsed payload
it checks the same thing. The length of each individual payload is
checked by the parser anyway. So I think this was primarily added for
the IKEv1 "wrong PSK" use case. Let's keep it for now.
Fixes: dd5c3787dc ("Give a hint that decryption failed if payload length invalid")
If the padding was larger than the whole blob, all available bytes were
checked for a match and the blob's length was eventually adjusted and
SUCCESS returned. Due to the underflow this could result in a huge size
that would then get copied. Zero-length padding was also incorrectly
accepted as was padding larger than the block size.
Fixes: 160f4c225d ("moved PEM parsing functionality to its own plugin")
Should be rare that the eap-identity plugin is not loaded when
authenticating clients with EAP. And the second error path will
currently never get used as `process()` always succeeds.
Fixes: 79f2102cb4 ("implemented server side support for EAP-TTLS")
Because `builtin_vsnprintf()` returns the length of the (theoretically)
produced string even if the buffer is too small, the `fwrite()` calls
would read past the buffer. While it rarely happens that log messages
are even close to the current buffer size, it might get triggered by an
overlong IKE/EAP identity or similar.
For `vasprintf()`, the allocation for the complete required length is
now correctly handled (capped at `INT_MAX` as that's what
`builtin_vsnprintf()` can technically return).
Also fixed is an incorrect mapping of the return value of `fwrite()` in
case of an error. While the latter returns the elements written so far,
the expected return value from `vfprintf()` is negative.
Fixes: cabe5c0ff4 ("printf-hook-builtin: Add a new "builtin" backend using its own printf() routines")
I've overlooked the "m = q if d = 12" note in the pseudo-code for
Algorithm 6. The text further up in the section actually clarifies
this:
For d = 12, ByteDecode produces integers modulo q as output...(it)
converts each 12-bit segment of its input into an integer modulo 4096
and then reduces the result modulo q. This is no longer a one-to-one
operation.
This did not have any practical impact (other than accepting public keys
that are technically non-compliant) because the values would get properly
reduced anyway by the Barrett reduction used in `mul_modq()`.
Fixes: 89f4b345e3 ("ml: Add software implementation of ML-KEM")
If multiple clients call list commands concurrently, each would replace
the global certificate printer instance the previous client created
and then operate on shared state. The destruction then causes a
double-free or NULL-pointer dereference.
Fixes: 02d431022c ("Refactored certificate management for the vici and stroke interfaces")
Because the flag was set before running the TLS cleanup, a thread
waiting in `join()` could exit the loop and destroy the thread object
before `docleanup()` is called in `end_thread()`.
This change removes the `terminated` flag and instead properly waits for
the thread to exit in `join()`. By always removing the threads from the
hashtable in `end_thread()`, we also avoid requiring to check any flags
in `cleanup_tls()`, as it now only finds an object for external threads.
We now also make sure to call `docleanup()` before removing the thread
from the hashtable. Otherwise, if a TLS cleanup callback calls
`thread_current[_id]()`, a new thread object would get created that is
never cleaned up.
Fixes: 0fa9c95811 ("windows: Provide a complete native Windows threading backend")
This would cause a use-after-free because `lookup_iv()` inserts, removes
and destroys the still returned entry.
Fixes: aeaab528e8 ("ikev1: Factor out IV and QM management")
In the (very) unlikely case that a unique ID is reused (e.g. due to
counter wraparound) while the original SA is still in this manager,
the entries should properly get removed from the other lookup tables
before the entry is destroyed to prevent stale pointers from getting
used in later lookups.
Fixes: e732fb11a9 ("child-sa-manager: Add a global manager storing CHILD_SA relations")
Unlike chunk_compare() this first compares the prefix of two nonces,
then falls back to comparing the length. This is basically intended to
compare nonces as specified in RFC 7296:
"Lowest" means an octet-by-octet comparison (instead of, for instance,
comparing the nonces as large integers). In other words, start by
comparing the first octet; if they're equal, move to the next octet,
and so on. If you reach the end of one nonce, that nonce is the
lower one.
When left-padding a value shorter than the RSA key, the code previously
calculated the length incorrectly so that some bytes might have been
cleared if the value was shorter than half the required length.
Fixes: a2f1bb238e ("enforce correct RSA signature lenght in gcrypt")
This could prevent the VIP from getting installed later and actually
causes those threads to block indefinitely as they wait for the entry to
either get removed or the VIP marked as installed, which will never
happen.
Fixes: c6b401581a ("Changed how kernel-netlink handles virtual IP addresses")
This applies some of the same fixes found in the previous commit but also
ensures that the offsets are valid before accessing the bitmask. Because
of an off-by-one error in the latter, the last address could get released
incorrectly (the pool constructor explicitly excludes it).
Fixes: 98d0343870 ("Implemented a HA enabled in-memory address pool")
Due to the overflow when mapping addresses to offsets, no addresses could
get released when the pool was defined in a way that the last address
assignable is 255.255.255.255 (probably never the case in practice).
While not really useful in practice, the range 0.0.0.0-255.255.255.255
resulted in an empty pool (`size = 0xffffffff + 1`), which triggers the
%config like behavior. Since the implementation currently uses signed
integers throughout, we make sure the largest assignable offset is
INT_MAX.
The two off-by-one fixes (`>= pool->size`) were never an issue in practice
because `get_new()` has a guard that caps the offset at the size and
released addresses originally came from the pool so are always in range.
Fixes: 0897cda33b ("Add a constructor to create in-memory pools from an address range")
If the installation fails while a shunt is concurrently uninstalled,
the entry could already be destroyed when trying to remove and destroy
it after acquiring the lock again in `install()`.
This change handles the conflict the same way trap-manager does since
69cbe2ca3f ("trap-manager: Wait for install to finish before
uninstalling").
Fixes: 616ff9a236 ("shunt-manager: Remove stored entries if installation fails")
Tobias Brunner