[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAJ33NAVY_jKsLqGZpuWTXUFTAkkg60qH2hd3uhVmyaDGX7P2cg@mail.gmail.com>
Date: Wed, 25 Sep 2024 14:31:19 +0530
From: Sandipan Roy <saroy@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Joel GUITTET <jguittet@...ekio.com>
Subject: Re: CVE-2024-42154: Linux kernel: tcp_metrics:
validate source addr length
Hello Alexander and Joel,
Thank you for your quick review.
Regarding the CVE, Red Hat is still in the analysis phase. Our assessment
is based on our own kernel build, which may differ from the default
configuration upstream.
According to our latest analysis, the CVSS score is 4.4:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
The impact level is considered moderate for Red Hat due to the following
reasons:
1. Missed check existed before and worked correctly (because by default it
worked for int32 value, even if it was not specified exactly).
2. Even if for some specific case a fail could happen, still it can lead
only to incorrect memory read.
3. Even if memory corruption happens, it should not lead to anything apart
from incorrect tcp-ip statistics output to the local user.
Additionally, It can lead to incorrect statistics output for commands like
"ip tcp_metrics show", but actually no security impact (or very low
security impact).
Thanks
Sandipan Roy
On Tue, Sep 24, 2024 at 9:10 PM Solar Designer <solar@...nwall.com> wrote:
> Hi Joel,
>
> When you bring issues to this list, please include in the Subject and
> start your messages with information on the issue itself - at least the
> affected project and vulnerability type when applicable. As a
> moderator, I've edited the Subject line to contain such information.
>
> On Tue, Sep 24, 2024 at 09:12:46AM +0000, Joel GUITTET wrote:
> > I'm working on a medical product actually and have trouble about the
> CVE-2024-42154. It is regarding NETLINK socket which can be used only
> locally, but it is classified with "NETWORK" flag. NETWORK flag is annoying
> because it means more difficult to justify the CVE.
> >
> > I already ask the NIST why the NETWOKR flag was set for this CVE, they
> answer me that it's linked to socket and without more public reference they
> are just setting the NETWORK flag, in case of.
> >
> > Can I ask you your opinion about this CVE and the pertinence of the
> NETWORK flag here?
>
> I didn't fully analyze this issue, but at a glance:
>
> 1. NIST NVD commonly inflates CVSS scores. You could reasonably dispute
> their CVSS vector and they may correct it and the score:
>
> https://nvd.nist.gov/vuln/detail/CVE-2024-42154
>
> Base Score: 9.8 CRITICAL
> Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
>
> 2. There are other sources for CVSS vectors/scores, notably Red Hat:
>
> https://access.redhat.com/security/cve/CVE-2024-42154
>
> CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
>
> leading to a score of 2.5. Indeed, they treat this issue as local, not
> network, which is probably correct, although some other components of
> this CVSS vector look weird to me.
>
> You could use Red Hat as your source of severity scores.
>
> 3. The CVE description originates from Linux kernel CNA, which in turn
> reuses the commit message:
>
> https://lists.openwall.net/linux-cve-announce/2024/07/30/76
>
> > tcp_metrics: validate source addr length
> >
> > I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
> > is at least 4 bytes long, and the policy doesn't have an entry
> > for this attribute at all (neither does it for IPv6 but v6 is
> > manually validated).
>
> The code change is:
>
> +++ b/net/ipv4/tcp_metrics.c
> @@ -624,6 +624,7 @@ static const struct nla_policy
> tcp_metrics_nl_policy[TCP_METRICS_ATTR_MAX + 1] =
> [TCP_METRICS_ATTR_ADDR_IPV4] = { .type = NLA_U32, },
> [TCP_METRICS_ATTR_ADDR_IPV6] = { .type = NLA_BINARY,
> .len = sizeof(struct
> in6_addr), },
> + [TCP_METRICS_ATTR_SADDR_IPV4] = { .type = NLA_U32, },
> /* Following attributes are not received for GET/DEL,
> * we keep them for reference
> */
>
> It would require more context to review and to assess the bug's impact,
> but my _guess_ is it may have been merely over-read potential, so local
> infoleak maybe? Besides code review, it could make sense to locate the
> corresponding syzbot report, if one exists, and see what type of crash
> it was - if it was.
>
> Somehow Red Hat's description lists possibilities worse than over-read,
> so either my guess is wrong or they didn't analyze the issue to identify
> specific impact:
>
> > A vulnerability was found in the Linux kernel's tcp_metrics subsystem,
> > where insufficient validation of the length of the source address for
> > TCP metrics could lead to buffer overflows, memory corruption, or
> > crashes.
>
> I hope this helps.
>
> Alexander
>
>
--
*Sandipan Roy*
Product Security Engineer, Product Security
Secure Engineering - Incident Response
Email: sandipan@...hat.com
PGP:0x4B5C7470051BB332 <https://bytehackr.fedorapeople.org/saroy.asc>
*secalert@...hat.com <secalert@...hat.com>* For Urgent Response.
<https://www.redhat.com/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
