Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Two denial of service vulnerabilities were found in ntpd-rs related to the handling of NTS cookies in our client functionality. Whenever an NTS source is configured and the server behind that source is sending zero-sized cookies or cookies larger than what would fit in our buffer size, ntpd-rs would crash. Only configured NTS sources can abuse these vulnerabilities. NTP sources or third parties that are not configured cannot make use of these vulnerabilities. For zero-sized cookies: a division by zero would force an exit when the number of new cookies that would need to be requested is calculated. In ntpd-rs 1.5.0 a check was added to prevent the division by zero. For large cookies: while trying to send a NTP request with the cookie included, the buffer is too small to handle the cookie and an exit of ntpd-rs is forced once a write to the buffer is attempted. The memory outside the buffer would not be written to in this case. In ntpd-rs 1.5.0 a check was added that prevents accepting…
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Missing limit for accepted NTS-KE connections allows an unauthenticated remote attacker to crash ntpd-rs when an NTS-KE server is configured. Non NTS-KE server configurations, such as the default ntpd-rs configuration, are unaffected. Details Operating systems have a limit for the number of open file descriptors (which includes sockets) in a single process, e.g. 1024 on Linux by default. When ntpd-rs is configured as an NTS server, it accepts TCP connections for the NTS-KE service. If the process has reached the descriptor limit and tries to accept a new TCP connection, the accept() system call will return with the EMFILE error and cause ntpd-rs to abort. A remote attacker can open a large number of parallel TCP connections to the server to trigger this crash. The connections need to be opened quickly enough to avoid the key-exchange-timeout-ms timeout (by default 1000 milliseconds). Impact Only NTS-KE server configuration are affected. Those without an NTS-KE server…
Recommended action: Upgrade to 1.1.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
During startup, an attacker that can man-in-the-middle traffic to and from NTS key exchange servers can trigger a very expensive key validation process due to a vulnerability in webpki. Impact This vulnerability can lead to excessive cpu usage on startup on clients configured to use NTS Patches Affected users are recommended to upgrade to version 0.3.7 References See also https://github.com/rustsec/advisory-db/blob/main/crates/rustls-webpki/RUSTSEC-2023-0053.md
Recommended action: Upgrade to 0.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact ntpd-rs does not validate the length of NTS cookies in received NTP packets to the server. An attacker can crash the server by sending a specially crafted NTP packet containing a cookie shorter than what the server expects. The server also crashes when it is not configured to handle NTS packets. ntpd-rs running purely as an ntp client is not affected. Patches The issue was caused by improper slice indexing. The indexing operations were replaced by safer alternatives that do not crash the ntpd-rs server process but instead properly handle the error condition. A patch was released in version 0.3.3 Workarounds ntpd-rs running purely as an ntp client is not affected. By default, ntpd-rs packages are not configured to run as a server. For machines where serving the time is required, there is no known workaround. Users are recommended to upgrade ntpd-rs as soon as possible. References https://github.com/pendulum-project/ntpd-rs/pull/752 We would like to thank @mlichvar for…
Recommended action: Upgrade to 0.3.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.