Re: [SECURITY] Out-of-Bounds Read in MPLS Extension Parsing — traceroute 2.1.2

[Dmitry Butskoy <buc () buc spb ru>]

MOHAMED,

From the appearing of this fragment of code in 2.0.12 (2008 year), the 
statement "n -= hlen;" is present here. Including the current version of 
2.1.6, see line 1423 of traceroute/traceroute.c :

>         if (!err &&
>             af == AF_INET &&
>             /*  XXX: Assume that the presence of an extra header means
>                 that it is not a raw socket...
>             */
>             ops->header_len == 0
>         ) {
>             struct iphdr *ip = (struct iphdr *) bufp;
>             int hlen;
>
>             if (n < sizeof (struct iphdr))  return;
>
>             hlen = ip->ihl << 2;
>             if (n < hlen)  return;
>
>             bufp += hlen;
>             n -= hlen;
>         }

What source did you use? Why is your report for version 2.1.2 when the 
latest version is 2.1.6?

Note again, that the version of 2.1.2 has this statement as well.

Could you please find out where you got this inherently corrupted code 
based on an old version?


Best regards,
Dmitry Butskoy
http://traceroute.sf.net


MOHAMED AZIZ RAHMOUNI wrote:
> Hello,
>
> I am reporting a security vulnerability I discovered in traceroute 
> 2.1.2 during manual code review and dynamic fuzzing.
>
> Summary:
> An out-of-bounds read exists in traceroute/traceroute.c. After 
> recvmsg() returns, bufp is advanced past the IPv4 header (bufp += 
> hlen) but n is not decremented accordingly. The subsequent call:
>
>     handle_extensions(pb, bufp + offs, n - offs, step);
>
> passes a len value that is hlen bytes (20 for IPv4, 40 for IPv6) 
> larger than the actual data available from bufp + offs. This causes 
> the MPLS extension parser to read past the received packet boundary 
> into uninitialized stack memory within buf[1280].
>
> The vulnerability is remotely triggerable by any on-path network 
> device that can send a crafted ICMP Time Exceeded response with MPLS 
> extensions to a traceroute -e invocation. I have confirmed the issue 
> with a working proof of concept.
>
> Proposed fix (single line addition after line 1427):
>
>     bufp += hlen;
>     n -= hlen;   // add this line
>
> I have attached a full technical report including root cause analysis, 
> proof of concept code, memory layout analysis, and impact assessment.
>
> I am following a 90-day responsible disclosure policy. I intend to 
> publish details publicly on 2026-07-27 unless a patch is available 
> sooner, at which point I will coordinate the disclosure timeline with you.
>
> Please confirm receipt of this report.
>
> Regards,
> Security researcher Zyyz
>
> Mohamed Aziz Rahmouni