[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260501194931.GX1827@brightrain.aerifal.cx>
Date: Fri, 1 May 2026 15:49:31 -0400
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fw@...eb.enyo.de>
Cc: musl@...ts.openwall.com
Subject: Re: Re: musl dn_expand issue (CVE-2026-40684 attributed to
Exim)
On Fri, May 01, 2026 at 03:27:13PM -0400, Rich Felker wrote:
> On Fri, May 01, 2026 at 03:42:39PM +0200, Florian Weimer wrote:
> > Rich,
> >
> > I saw a disclosure of an alleged Exim vulnerability flying by,
> > CVE-2026-40684. It's actually a musl bug, I think.
> >
> > Take this reproducer:
> >
> > #include <resolv.h>
> > #include <stdio.h>
> >
> > int
> > main (void)
> > {
> > static const unsigned char dn[] = "\3www\14example.net\0\7example\3org";
> > char buf[100] = { 0, };
> > dn_expand (dn, dn + sizeof (dn), dn, buf, sizeof (buf));
> > puts (buf);
> > }
> >
> > On a BIND-derived dn_expand implementation, it prints:
> >
> > www.example\.net\000.example.org
> >
> > (Note that \NNN escape sequences are decimal, as in SML, not octal.)
> >
> > On musl, it prints:
> >
> > www.example.net
> >
> > This is in a completely different part of DNS tree, so an unexpected
> > policy might be applied to the domain name. I haven't tried to find
> > an actual impacted application, but there's probably some adverse
> > consequences from this.
> >
> > Please let me know if you have questions.
>
> Thanks! I think someone raised before that this was different, but we
> never got a good plan on fixing it and it wasn't deemed important at
> the time because it didn't seem to allow doing anything more nefarious
> than you could already do if you control or can MITM the nameserver
> the stub resolver is using.
>
> Even if the above could be accepted by recursive/caching nameservers,
> I'm not clear how it's any worse than just putting
> "\3www\7example\3net\0" directly in the PTR. A PTR record can always
> point to a domain you're not authorized to use; it has to be
> round-trip checked by the application if you're going to trust it.
>
> I'll look at the Exim technical details and try to understand what
> went wrong there to better understand why we should fix this, but I
> think it's fine to discuss the matter in public so I've CC'd the list
> in case anyone else has something useful to add.
Ah, it looks like the problem was just that our unescaped, literal
output could be used to put things that looked like an escape in the
output, which the exim code then tried to decode, and crashed when the
following characters were non-digits.
I'm starting to recall the last time we looked at this, and I think
one big unanswered question was whether we should emit escaped forms
at all or just treat labels containing bytes not permitted in DNS as
malformed and produce an error.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
