Bug#1063484: libuv1: CVE-2024-24806
Hi Dominique, On Thu, Mar 07, 2024 at 08:58:11AM +0100, Dominique Dumont wrote: > On Wednesday, 6 March 2024 21:07:56 CET Salvatore Bonaccorso wrote: > > Thank you very much. Looks good to me, feel free to upload as well to > > security-master (and build as well with -sa). > > Done. DSA 5638-1 has been released today. Thanks a lot for your contribution! Regards, Salvatore
Bug#1063484: libuv1: CVE-2024-24806
On Wednesday, 6 March 2024 21:07:56 CET Salvatore Bonaccorso wrote: > Thank you very much. Looks good to me, feel free to upload as well to > security-master (and build as well with -sa). Done. All the best
Bug#1063484: libuv1: CVE-2024-24806
Hi On Wed, Mar 06, 2024 at 07:06:55PM +0100, Dominique Dumont wrote: > On Tuesday, 5 March 2024 22:15:50 CET Salvatore Bonaccorso wrote: > > The debdiff for bookworm-security looks good to me. Please do upload > > to security-master (and make sure to build with -sa as the orig > > tarball is not yet on security-master for 1.44.2). > > Done. Thank you, builds arrived. > > So we just need as well the bullseye-security one, as per above, can > > you prepare this one as well. > > Done. Here's the debdiff in attachment Thank you very much. Looks good to me, feel free to upload as well to security-master (and build as well with -sa). Regards, Salvatore
Bug#1063484: libuv1: CVE-2024-24806
Hi Dominique, On Sun, Mar 03, 2024 at 03:51:28PM +0100, Dominique Dumont wrote: > On Thu, 29 Feb 2024 21:53:07 +0100 Salvatore Bonaccorso > wrote: > > libuv1 is as well affected in bullseye and it's still supported. Can > > you have a look as well at this version? > > The same patch (with a refresh) applies to bullseye. I can also prepare an > upload. The debdiff for bookworm-security looks good to me. Please do upload to security-master (and make sure to build with -sa as the orig tarball is not yet on security-master for 1.44.2). So we just need as well the bullseye-security one, as per above, can you prepare this one as well. Regards, Salvatore
Bug#1063484: libuv1: CVE-2024-24806
On Thu, 29 Feb 2024 21:53:07 +0100 Salvatore Bonaccorso wrote: > libuv1 is as well affected in bullseye and it's still supported. Can > you have a look as well at this version? The same patch (with a refresh) applies to bullseye. I can also prepare an upload. All the best
Bug#1063484: libuv1: CVE-2024-24806
Hi Dominique, [Adding CC to team@s.d.o] On Tue, Feb 20, 2024 at 07:08:48PM +0100, Dominique Dumont wrote: > Hi > > On Wed, 14 Feb 2024 12:57:52 +0100 Dominique Dumont wrote: > > I'm still pondering what should be done for stable which ships a libuv > 1.44.2 > > I've prepared a fix for bookworm. You'll find the debdiff in attachment. > > Please tell me if I can upload this package to bookworm-security. Thanks for preparing the update, I will try to have a look at the debdiff in the next days. libuv1 is as well affected in bullseye and it's still supported. Can you have a look as well at this version? Regards, Salvatore
Bug#1063484: libuv1: CVE-2024-24806
On Thu, 08 Feb 2024 20:51:30 +0100 Salvatore Bonaccorso
wrote:
> Note, that the advisory at [1] mentions that affected versions are
> only > 1.45.x. Looking at the git changes, is it not introduced after
> 6dd44caa35b4 ("unix,win: support IDNA 2008 in uv_getaddrinfo()") in
> v1.24.0?
The advisory has been changed and list v1.24.0 as affected version.
I'm going to pacakge v1.48 to fix this issue in unstable.
I'm still pondering what should be done for stable which ships a libuv 1.44.2
All the best
Bug#1063484: libuv1: CVE-2024-24806
Source: libuv1
Version: 1.46.0-3
Severity: grave
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team
Hi,
The following vulnerability was published for libuv1.
CVE-2024-24806[0]:
| libuv is a multi-platform support library with a focus on
| asynchronous I/O. The `uv_getaddrinfo` function in
| `src/unix/getaddrinfo.c` (and its windows counterpart
| `src/win/getaddrinfo.c`), truncates hostnames to 256 characters
| before calling `getaddrinfo`. This behavior can be exploited to
| create addresses like `0x7f01`, which are considered valid
| by `getaddrinfo` and could allow an attacker to craft payloads that
| resolve to unintended IP addresses, bypassing developer checks. The
| vulnerability arises due to how the `hostname_ascii` variable (with
| a length of 256 bytes) is handled in `uv_getaddrinfo` and
| subsequently in `uv__idna_toascii`. When the hostname exceeds 256
| characters, it gets truncated without a terminating null byte. As a
| result attackers may be able to access internal APIs or for websites
| (similar to MySpace) that allows users to have
| `username.example.com` pages. Internal services that crawl or cache
| these user pages can be exposed to SSRF attacks if a malicious user
| chooses a long vulnerable username. This issue has been addressed in
| release version 1.48.0. Users are advised to upgrade. There are no
| known workarounds for this vulnerability.
Note, that the advisory at [1] mentions that affected versions are
only > 1.45.x. Looking at the git changes, is it not introduced after
6dd44caa35b4 ("unix,win: support IDNA 2008 in uv_getaddrinfo()") in
v1.24.0?
If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
For further information see:
[0] https://security-tracker.debian.org/tracker/CVE-2024-24806
https://www.cve.org/CVERecord?id=CVE-2024-24806
[1] https://github.com/libuv/libuv/security/advisories/GHSA-f74f-cvh7-c6q6
Please adjust the affected versions in the BTS as needed.
Regards,
Salvatore
