Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Matt Johnston]

Hi,

I think Dropbear probably is vulnerable to CVE-2015-1817
post-authentication. TCP forwarding requests will call
getaddrinfo() 
https://secure.ucc.asn.au/hg/dropbear/file/cbd674d63cd4/dbutil.c#l415
(moved to netio.c in head, and PF_UNSPEC has been fixed to
AF_UNSPEC). Pre-authentication should be OK, only
getnameinfo() is called (if that's enabled).

musl's network-facing DNS code seems a bit precarious with
pointer arithmetic?

Please CC replies, I'm not subscribed.

Cheers,
Matt

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Fri, Apr 17, 2015 at 09:10:08PM +0800, Matt Johnston wrote:
> Hi,
> 
> I think Dropbear probably is vulnerable to CVE-2015-1817
> post-authentication. TCP forwarding requests will call
> getaddrinfo() 
> https://secure.ucc.asn.au/hg/dropbear/file/cbd674d63cd4/dbutil.c#l415
> (moved to netio.c in head, and PF_UNSPEC has been fixed to
> AF_UNSPEC). Pre-authentication should be OK, only
> getnameinfo() is called (if that's enabled).

Yes, I agree dropbear is affected.

And wow, this is an utter mess. Not only does dropbear fail to drop
root before processing forwards; it NEVER drops root at all. The
user's session remains running as root for its full lifetime. Aside
from being a huge risk, it also allows users to bypass uid-based
firewall rules via port forwarding; for example, a rule that forbids
normal users from making outgoing connections on port 25 would not be
honored.

Is there any reason for not performing the setgroups/setgid/setuid
immediately after authentication succeeds? Have you looked at whether
it would be easy to patch that in?

None of this excuses CVE-2015-1817 which was a huge failure on our
part, but it seems pretty crazy that dropbear is doing EVERYTHING as
root.

> musl's network-facing DNS code seems a bit precarious with
> pointer arithmetic?

Which code are you talking about? There was a previous problem with
dn_expand, which is the main function that comes to mind for me, and
the code was fixed and heavily reviewed at the time.

Are there other areas you're concerned about?

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Fri, Apr 17, 2015 at 01:23:27PM -0400, Rich Felker wrote:
> On Fri, Apr 17, 2015 at 09:10:08PM +0800, Matt Johnston wrote:
> > Hi,
> > 
> > I think Dropbear probably is vulnerable to CVE-2015-1817
> > post-authentication. TCP forwarding requests will call
> > getaddrinfo() 
> > https://secure.ucc.asn.au/hg/dropbear/file/cbd674d63cd4/dbutil.c#l415
> > (moved to netio.c in head, and PF_UNSPEC has been fixed to
> > AF_UNSPEC). Pre-authentication should be OK, only
> > getnameinfo() is called (if that's enabled).
> 
> Yes, I agree dropbear is affected.
> 
> And wow, this is an utter mess. Not only does dropbear fail to drop
> root before processing forwards; it NEVER drops root at all. The
> user's session remains running as root for its full lifetime. Aside
> from being a huge risk, it also allows users to bypass uid-based
> firewall rules via port forwarding; for example, a rule that forbids
> normal users from making outgoing connections on port 25 would not be
> honored.
> 
> Is there any reason for not performing the setgroups/setgid/setuid
> immediately after authentication succeeds? Have you looked at whether
> it would be easy to patch that in?

Simply copying/moving the code from svr-chansession.c's execchild to
svr-auth.c's send_msg_userauth_success seems to fix the entire issue.
I had to disable the (useless on systems with proper pty support)
chown/chmod for the pty, but otherwise it seems to be working fine.

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Solar Designer]

Rich,

You dropped the copy to Matt on the previous reply.  I've re-added it.

On Fri, Apr 17, 2015 at 02:03:25PM -0400, Rich Felker wrote:
> On Fri, Apr 17, 2015 at 01:23:27PM -0400, Rich Felker wrote:
> > And wow, this is an utter mess. Not only does dropbear fail to drop
> > root before processing forwards; it NEVER drops root at all. The
> > user's session remains running as root for its full lifetime. Aside
> > from being a huge risk, it also allows users to bypass uid-based
> > firewall rules via port forwarding; for example, a rule that forbids
> > normal users from making outgoing connections on port 25 would not be
> > honored.
> > 
> > Is there any reason for not performing the setgroups/setgid/setuid
> > immediately after authentication succeeds? Have you looked at whether
> > it would be easy to patch that in?
> 
> Simply copying/moving the code from svr-chansession.c's execchild to
> svr-auth.c's send_msg_userauth_success seems to fix the entire issue.
> I had to disable the (useless on systems with proper pty support)
> chown/chmod for the pty, but otherwise it seems to be working fine.

I guess changes like these should be upstream'ed.  Matt?

Thanks,

Alexander

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Matt Johnston]

> On Fri, Apr 17, 2015 at 02:03:25PM -0400, Rich Felker wrote:
> > On Fri, Apr 17, 2015 at 01:23:27PM -0400, Rich Felker wrote:
> > > And wow, this is an utter mess. Not only does dropbear fail to drop
> > > root before processing forwards; it NEVER drops root at all. The
[snip]
> > > Is there any reason for not performing the setgroups/setgid/setuid
> > > immediately after authentication succeeds? Have you looked at whether
> > > it would be easy to patch that in?
> > 
> > Simply copying/moving the code from svr-chansession.c's execchild to
> > svr-auth.c's send_msg_userauth_success seems to fix the entire issue.
> > I had to disable the (useless on systems with proper pty support)
> > chown/chmod for the pty, but otherwise it seems to be working fine.
> 
> I guess changes like these should be upstream'ed.  Matt?

Hi Rich,

Thanks for the suggestion. When the code was originally
written quite a few systems had to use older pty methods
though that has improved now, it is worth revisiting.
Some systems still require --disable-openpty (old uClibc or
built with strange configurations, I think).

utmp/wtmp logs require privileges to write, Dropbear could
add utmp group on systems using that (not sure how
widespread it is). The server hostkey will remain in process
memory since it's required for rekeying - not as bad as root
code execution though.

Proper separation with a privileged supervisor is
on my todo list, I'll have a look how feasible a simpler
approach is.

> > musl's network-facing DNS code seems a bit precarious with
> > pointer arithmetic?
> 
> Which code are you talking about? There was a previous
> problem with
> dn_expand, which is the main function that comes to mind for
> me, and
> the code was fixed and heavily reviewed at the time.

Yes, dn_expand was what I was thinking of - at the time I
looked at the fix and it seemed like difficult code to
reason about. Overall the code style of musl seems quite
nice, I guess the parsing type code is just fairly terse.
The masking with ip[i&7]=0 in the recent fix was a bit
non-obvious without looking at the commit message - makes
sense as a safety mechanism.

Cheers,
Matt

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Sat, Apr 18, 2015 at 09:32:02PM +0800, Matt Johnston wrote:
> > On Fri, Apr 17, 2015 at 02:03:25PM -0400, Rich Felker wrote:
> > > On Fri, Apr 17, 2015 at 01:23:27PM -0400, Rich Felker wrote:
> > > > And wow, this is an utter mess. Not only does dropbear fail to drop
> > > > root before processing forwards; it NEVER drops root at all. The
> [snip]
> > > > Is there any reason for not performing the setgroups/setgid/setuid
> > > > immediately after authentication succeeds? Have you looked at whether
> > > > it would be easy to patch that in?
> > > 
> > > Simply copying/moving the code from svr-chansession.c's execchild to
> > > svr-auth.c's send_msg_userauth_success seems to fix the entire issue.
> > > I had to disable the (useless on systems with proper pty support)
> > > chown/chmod for the pty, but otherwise it seems to be working fine.
> > 
> > I guess changes like these should be upstream'ed.  Matt?
> 
> Hi Rich,
> 
> Thanks for the suggestion. When the code was originally
> written quite a few systems had to use older pty methods
> though that has improved now, it is worth revisiting.
> Some systems still require --disable-openpty (old uClibc or
> built with strange configurations, I think).

The "clean" (albeit ugly if you don't like suids) solution to this
problem on legacy systems was to have a setuid pt_chown binary to
implement the grantpt function. No idea if the systems you care about
have such a utility. Short of that you could fork a second time prior
to dropping privs and have the new forked child do nothing but listen
on a pipe for pty-control commands. Of course this is problematic for
NOMMU, and it's also wasteful if the process has to wait around to
cleanup the pty at exit rather than just doing its thing and exiting
at startup.

> utmp/wtmp logs require privileges to write, Dropbear could
> add utmp group on systems using that (not sure how
> widespread it is).

Yes, I neglected to mention that (and didn't even notice it at first)
because I don't use utmp and musl nops it out. There are various
solutions to the problem with external utmp utilities/daemons but I'm
not really familiar with them.

In any case the current code does not error out when utmp update
fails; it just silently fails to produce an entry. So a "drop privs
early" build or runtime option would be practical without any change
to that code as long as users can live with no utmp.

> The server hostkey will remain in process
> memory since it's required for rekeying - not as bad as root
> code execution though.

Ugly. I don't see how this can be solved without a more advanced
privsep model. I agree it's lower-severity though.

Based on this:

http://www.snailbook.com/faq/no-rekeying.auto.html

rekeying is unreliable since the client or server may fail to support
it. I have no idea if that information is still at all relevant, but
if rekeying is not widely in use it might be worthwhile to provide an
option for paranoid users to disable it and clear the key in the
child. (Of course there are lots of obstacles to effectively
eliminating all traces of it.)

> Proper separation with a privileged supervisor is
> on my todo list, I'll have a look how feasible a simpler
> approach is.

Part of the approach I would recommend is having a separate executable
for the session process and invoking it via posix_spawn if possible.
This makes it possible to run on NOMMU without having to rely on vfork
hacks which almost certainly introduce vulnerabilities via program
state corruption. If you're interested in discussing design ideas for
it I'd be happy to.

> > > musl's network-facing DNS code seems a bit precarious with
> > > pointer arithmetic?
> > 
> > Which code are you talking about? There was a previous
> > problem with
> > dn_expand, which is the main function that comes to mind for
> > me, and
> > the code was fixed and heavily reviewed at the time.
> 
> Yes, dn_expand was what I was thinking of - at the time I
> looked at the fix and it seemed like difficult code to
> reason about. Overall the code style of musl seems quite
> nice, I guess the parsing type code is just fairly terse.
> The masking with ip[i&7]=0 in the recent fix was a bit
> non-obvious without looking at the commit message - makes
> sense as a safety mechanism.

Yes, a lot of the justifications for various things are in the git log
rather than comments. I've found this produces a more useful narrative
of the motivations for changes, but there are places where we could
use more comments, and gradually I'm trying to add them where I find
people are getting confused. The ip[i&7] trick is a place that could
use one, I think.

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

On 18.04.2015 17:25, Rich Felker wrote:
>> The server hostkey will remain in process
>> memory since it's required for rekeying - not as bad as root
>> code execution though.
>
> Ugly. I don't see how this can be solved without a more advanced
> privsep model. I agree it's lower-severity though.

IMO you may put the host keys in a file readable (not writable) with a 
dropbear group, and only using that group for dropbear (no other users 
or programs using that group). So you may read the keys even if not 
root, if you add this dropbear group to setgroups (not setgid) before 
dropping root privileges.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Sat, Apr 18, 2015 at 05:49:51PM +0200, Harald Becker wrote:
> On 18.04.2015 17:25, Rich Felker wrote:
> >>The server hostkey will remain in process
> >>memory since it's required for rekeying - not as bad as root
> >>code execution though.
> >
> >Ugly. I don't see how this can be solved without a more advanced
> >privsep model. I agree it's lower-severity though.
> 
> IMO you may put the host keys in a file readable (not writable) with
> a dropbear group, and only using that group for dropbear (no other
> users or programs using that group). So you may read the keys even
> if not root, if you add this dropbear group to setgroups (not
> setgid) before dropping root privileges.

The key is already in memory. A design like the above would not
significantly improve security (except for heartbleed type issues); it
would be just like the situation now where the key is already in
memory. To make it more secure, the session process would not have any
access to the key and would have to communicate with an existing
privileged process to rekey.

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi !

@Rich: I still get DNS error (Mozilla Thunderbird) for dalias@libc.org, 
when tying to send mail :(

On 18.04.2015 17:58, Rich Felker wrote:
> On Sat, Apr 18, 2015 at 05:49:51PM +0200, Harald Becker wrote:
>> On 18.04.2015 17:25, Rich Felker wrote:
>>>> The server hostkey will remain in process memory since it's
>>>> required for rekeying - not as bad as root code execution
>>>> though.
>>>
>>> Ugly. I don't see how this can be solved without a more advanced
>>> privsep model. I agree it's lower-severity though.
>>
>> IMO you may put the host keys in a file readable (not writable)
>> with a dropbear group, and only using that group for dropbear (no
>> other users or programs using that group). So you may read the keys
>> even if not root, if you add this dropbear group to setgroups (not
>> setgid) before dropping root privileges.
>
> The key is already in memory.

As far as I understand it, the question was, *not to have* the key
hanging around in memory, but still have access without requirement to
keep root privileges. My suggestion is to solve this, with a very simple
and easy to implement solution. I consider it a slight increased
security, as the dropbear process can drop root privileges (and has to
do so), but still has access to the host keys.


> A design like the above would not significantly improve security
> (except for heartbleed type issues); it would be just like the
> situation now where the key is already in memory.

ACK, as told it's intention is a simple solution to give dropbear access
to the host keys without letting them hang in memory all the time.


> To make it more secure, the session process would not have any access
> to the key and would have to communicate with an existing privileged
> process to rekey.

ACK, much better, but this would need major restructuring, wouldn't it?

So consider my suggestion a simpler to implement solution, in between 
having full root privileges or hanging keys in memory, and an external 
process to do the rekey steps (in addition: with the possibility to let 
that process use the dropbear group and not root to access keys - even 
better than let that process hang around as root)

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Sat, Apr 18, 2015 at 06:27:48PM +0200, Harald Becker wrote:
> Hi !
> 
> @Rich: I still get DNS error (Mozilla Thunderbird) for
> dalias@libc.org, when tying to send mail :(

Odd. I just verified that Google's 8.8.8.8 resolves it right, so I
don't know what's wrong, but it seems to be on your end. Let me know
if you find anything that looks like a problem on my side.

> On 18.04.2015 17:58, Rich Felker wrote:
> >On Sat, Apr 18, 2015 at 05:49:51PM +0200, Harald Becker wrote:
> >>On 18.04.2015 17:25, Rich Felker wrote:
> >>>>The server hostkey will remain in process memory since it's
> >>>>required for rekeying - not as bad as root code execution
> >>>>though.
> >>>
> >>>Ugly. I don't see how this can be solved without a more advanced
> >>>privsep model. I agree it's lower-severity though.
> >>
> >>IMO you may put the host keys in a file readable (not writable)
> >>with a dropbear group, and only using that group for dropbear (no
> >>other users or programs using that group). So you may read the keys
> >>even if not root, if you add this dropbear group to setgroups (not
> >>setgid) before dropping root privileges.
> >
> >The key is already in memory.
> 
> As far as I understand it, the question was, *not to have* the key
> hanging around in memory, but still have access without requirement to
> keep root privileges. My suggestion is to solve this, with a very simple
> and easy to implement solution. I consider it a slight increased
> security, as the dropbear process can drop root privileges (and has to
> do so), but still has access to the host keys.

Well anything that gets code execution in the dropbear session process
would be able to steal the key still. The only added protection you'd
get is is against heartbleed-type attacks (arbitrary memory read but
no code exeution).

> >To make it more secure, the session process would not have any access
> >to the key and would have to communicate with an existing privileged
> >process to rekey.
> 
> ACK, much better, but this would need major restructuring, wouldn't it?

Yes.

> So consider my suggestion a simpler to implement solution, in
> between having full root privileges or hanging keys in memory, and
> an external process to do the rekey steps (in addition: with the
> possibility to let that process use the dropbear group and not root
> to access keys - even better than let that process hang around as
> root)

If this external process is setuid/setgid, I consider that a much
bigger vuln. It would have to somehow verify that it's being invoked
by a valid dropbear session process and not some other caller that
just wants to use it to steal keys/forge key negotiations, and you
have all the usual issues with setuid programs having to be defensive
about the state they inherit when invoked.

If on the other hand the session process just kept gid=dropbear to
open and reload the key, it wouldn't be so bad.

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

On 18.04.2015 18:37, Rich Felker wrote:
>> @Rich: I still get DNS error (Mozilla Thunderbird) for
>> dalias@libc.org, when tying to send mail :(
>
> Odd. I just verified that Google's 8.8.8.8 resolves it right, so I
> don't know what's wrong, but it seems to be on your end. Let me know
> if you find anything that looks like a problem on my side.

AFAIK, you use a CNAME as MX, which is resolved on some, but not all 
systems / programs. You need to add an absolute IP address for your MX, 
not a CNAME, to be accessible for all.

A-record lookup is ok (resolved recursive), but MX lookup fails (doesn't 
do recursive lookup everywhere).


>> On 18.04.2015 17:58, Rich Felker wrote:
> Well anything that gets code execution in the dropbear session process
> would be able to steal the key still. The only added protection you'd
> get is is against heartbleed-type attacks (arbitrary memory read but
> no code exeution).

ACK, ... isn't that bad, to protect against that kind of key steeling, 
with a very simple solution, and no need to further code restructuring?

IMO it is a quick intermediate solution, until someone may be able to 
restructure key creation code, still giving the possibility to let 
dropbear drop root privileges completely (except pty/utmp question).


>> So consider my suggestion a simpler to implement solution, in
>> between having full root privileges or hanging keys in memory, and
>> an external process to do the rekey steps (in addition: with the
>> possibility to let that process use the dropbear group and not root
>> to access keys - even better than let that process hang around as
>> root)
>
> If this external process is setuid/setgid, I consider that a much
> bigger vuln.

Just to mention: My statement 'separate process' doesn't included or 
intended a separate suid/sgid program.


> It would have to somehow verify that it's being invoked
> by a valid dropbear session process and not some other caller that
> just wants to use it to steal keys/forge key negotiations, and you
> have all the usual issues with setuid programs having to be defensive
> about the state they inherit when invoked.

I didn't think of an exec to a separate program, but just fork and let a 
process for key management run in the back. So a bit simpler to verify 
authentication of caller, but still somehow required ... or what else 
did you suggest?


> If on the other hand the session process just kept gid=dropbear to
> open and reload the key, it wouldn't be so bad.

That's it, the key creator part doesn't need root privileges for it's 
operation either. That is just a combination of the two approaches.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Laurent Bercot]

On 18/04/2015 19:07, Harald Becker wrote:
> AFAIK, you use a CNAME as MX, which is resolved on some, but not all
> systems / programs. You need to add an absolute IP address for your
> MX, not a CNAME, to be accessible for all.

  Indeed. The normative text is RFC 2181, section 10.3 : it explicitly
forbids MX targets to be a CNAME. Most modern MTAs don't care, but some
old ones *cough* sendmail *cough* do.


> I didn't think of an exec to a separate program, but just fork and
> let a process for key management run in the back. So a bit simpler to
> verify authentication of caller, but still somehow required ... or
> what else did you suggest?

  I second the fact that forking several communicating processes at start,
each process dropping privileges to the minimal amount required to do its
job, is the most secure design.
  (That's how qmail was designed, way back in 1996, and it's definitely the
right approach for secure Unix programming.)
  If there's interest in converting dropbear to that model, I'd be happy
to help.

-- 
  Laurent

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Laurent !

On 18.04.2015 20:27, Laurent Bercot wrote:
>  Indeed. The normative text is RFC 2181, section 10.3 : it explicitly
> forbids MX targets to be a CNAME. Most modern MTAs don't care, but some
> old ones *cough* sendmail *cough* do.

The problem is, even mail relays of big Internet providers fail on this. 
AFAIK, United Internet uses a qmail based system.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Rich !

On 18.04.2015 18:37, Rich Felker wrote:
> Odd. I just verified that  Google's 8.8.8.8 resolves it right, so I
 > don't know what's wrong, but it seems to be on your end. Let me know
 > if you find anything that looks like a problem on my side.

I verified this again:

A-record lookup gets correct address, but MX lookup get's:

libc.org    mail exchanger = 10 mail.aerifal.cx.

... and that neither works when using Mozilla Thunderbird, nor claws 
mail on any current Linux distribution, when sending through the mail 
relay of GMX (United Internet = one of the major Internet provider in 
Germany). The SMTP to the mail relay rejects any mail to domain libc.org 
(SMTP error response).

Sorry it's neither my software, nor is there any way for me to change 
the kind of lookup done on the mail relay of the provider. Postmaster 
answer of mail relay was simple: Not a failure of mail relay, your MX 
lookup erroneously return a CNAME and not an IP address.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Sat, Apr 18, 2015 at 08:13:50PM +0200, Harald Becker wrote:
> Hi Rich !
> 
> On 18.04.2015 18:37, Rich Felker wrote:
> >Odd. I just verified that  Google's 8.8.8.8 resolves it right, so I
> > don't know what's wrong, but it seems to be on your end. Let me know
> > if you find anything that looks like a problem on my side.
> 
> I verified this again:
> 
> A-record lookup gets correct address, but MX lookup get's:
> 
> libc.org    mail exchanger = 10 mail.aerifal.cx.

And then:

mail.aerifal.cx 74177   IN A    216.12.86.13

I don't see any CNAMEs involved. Can you show me where the CNAME is
coming from?

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Laurent Bercot]

On 18/04/2015 21:56, Rich Felker wrote:
> mail.aerifal.cx 74177   IN A    216.12.86.13
>
> I don't see any CNAMEs involved. Can you show me where the CNAME is
> coming from?

  There must be something poisoning caches somewhere, or you changed
something recently.
  Initially, here's what I had in my cache:

$ s6-dnsqr a mail.aerifal.cx
74 bytes, 1+2+0+0 records, response, rd, ra, noerror
query: 1 mail.aerifal.cx.
answer: mail.aerifal.cx. 76356 CNAME brightrain.aerifal.cx.
answer: brightrain.aerifal.cx. 76356 A 216.12.86.13

  Then I flushed my cache, and I got the correct result:

$ s6-dnsqr a mail.aerifal.cx
49 bytes, 1+1+0+0 records, response, rd, ra, noerror
query: 1 mail.aerifal.cx.
answer: mail.aerifal.cx. 86400 A 216.12.86.13

  I have no idea how the CNAME made it into my cache in the first
place. The .cx nameservers all correctly delegate without answering.
But since Harald saw the same thing as I did, I think it warrants
further investigation.

  (It's DNS, so it sucks. That's to be expected.)

-- 
  Laurent

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Rich Felker]

On Sat, Apr 18, 2015 at 11:02:24PM +0200, Laurent Bercot wrote:
> On 18/04/2015 21:56, Rich Felker wrote:
> >mail.aerifal.cx 74177   IN A    216.12.86.13
> >
> >I don't see any CNAMEs involved. Can you show me where the CNAME is
> >coming from?
> 
>  There must be something poisoning caches somewhere, or you changed
> something recently.

It was nearly a year ago that I last changed anything (and I think
this was what I changed), but it seems I forgot to update the sequence
number in the SOA at the time, so perhaps some broken nameserver kept
the old data cached ever since then as a result? I've updated the SOA
now.

Rich

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

[-- Attachment #1: Type: text/plain, Size: 1557 bytes --]

Hi Rich !

Sending mail still fails, see appended screen shot of Thunderbird message!

On 19.04.2015 05:44, Rich Felker wrote:
> On Sat, Apr 18, 2015 at 11:02:24PM +0200, Laurent Bercot wrote:
>> On 18/04/2015 21:56, Rich Felker wrote:
>>> mail.aerifal.cx 74177   IN A    216.12.86.13
>>>
>>> I don't see any CNAMEs involved. Can you show me where the CNAME
>>> is coming from?

As far as I know, the MX lookup has to result in an address, not a name. 
Not every software does recursive lookup (I know, this is bad, bad not 
my failure). And the qmail system of the provider is not an obsolete 
part of software.


>> There must be something poisoning caches somewhere, or you changed
>>  something recently.
>
> It was nearly a year ago that I last changed anything (and I think
> this was what I changed),

May be it was due to my complain on this, but as you told you fixed
that, I did not check this again.


> but it seems I forgot to update the sequence number in the SOA at
> the time,

Thats a horrible failure in the DNS system :(


> so perhaps some broken nameserver kept the old data cached ever since
> then as a result? I've updated the SOA now.

So let me try sending mail again ... (this message)

My problem is, all the lookup stuff, and used software is out of my 
control. I just send mail out over the official mail relay of my 
Internet provider. So I can't do much, when I send an SMTP MAIL TO and 
receive an error, complaining about unresolvable mail address. And 
United Internet is one of the biggest providers in Germany.

Harald

[-- Attachment #2: Mail_Error.png --]
[-- Type: image/png, Size: 29138 bytes --]

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Kurt H Maier]

Quoting Harald Becker <ralda@gmx.de>:

> Hi Rich !
>
> Sending mail still fails, see appended screen shot of Thunderbird message!

Testing this, I get random failures and/or delays when looking up
libc.org MX records, usually from DNS3.REGISTRAR-SERVERS.COM. This
is probably what's happening to you as well, except your software is
giving up instead of retrying.

khm

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Kurt !

On 20.04.2015 13:20, Kurt H Maier wrote:
> Quoting Harald Becker <ralda@gmx.de>:
>> Sending mail still fails, see appended screen shot of Thunderbird
>> message!
>
> Testing this, I get random failures and/or delays when looking up
> libc.org MX records, usually from DNS3.REGISTRAR-SERVERS.COM.

Thanks, for helping to test this.

> This is probably what's happening to you as well, except your
> software is giving up instead of retrying.

The problem is, it's not my software, it is the mail relay of my 
provider, which rejects accepting mail for "libc.org". I don't see any 
possibility to let them change the address lookup in their qmail system.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Rich !

 > On 20.04.2015 13:20, Kurt H Maier wrote:
>> Quoting Harald Becker <ralda@gmx.de>:
>>> Sending mail still fails, see appended screen shot of Thunderbird
>>> message!
>>
>> Testing this, I get random failures and/or delays when looking up
>> libc.org MX records, usually from DNS3.REGISTRAR-SERVERS.COM.

Random delays? One suggestion: Rich are you able to add several MX 
records for your domain, with the same address? e.g.

10 mail.aerifal.cx.
20 mail.aerifal.cx.
30 mail.aerifal.cx.
40 mail.aerifal.cx.
50 mail.aerifal.cx.

This may help to solve random lookup problems, as the lookup proceed 
with the other entries, when the first fails. This should add some 
retrial to the providers address lookup.

AFAIR, anywhere exists an official suggestion to have at least 5 MX 
records for each domain, may be all pointing to same address. I think 
those random failures are exactly the reason for this suggestion.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Kurt H Maier]

Quoting Harald Becker <ralda@gmx.de>:

> The problem is, it's not my software, it is the mail relay of my  
> provider, which rejects accepting mail for "libc.org". I don't see  
> any possibility to let them change the address lookup in their qmail  
> system.

I'm not ascribing blame; I said "your software" as a shorthand for
"the software involved in transporting your email."  Sorry for any
confusion there.

khm

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Kurt !

On 20.04.2015 16:14, Kurt H Maier wrote:
> Quoting Harald Becker <ralda@gmx.de>:
>> The problem is, it's not my software, it is the mail relay of my
>> provider, which rejects accepting mail for "libc.org". I don't see any
>> possibility to let them change the address lookup in their qmail system.
>
> I'm not ascribing blame; I said "your software" as a shorthand for
> "the software involved in transporting your email."  Sorry for any
> confusion there.

Yes. Excuse my bad English.

I just wanted to state clear, this is not on my opportunity to change 
anything (as Rich stated), as it's the providers mail relay, failing. I 
know you didn't meant my "personal" software.

Thanks for your help.

Harald

Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817]

[Harald Becker]

Hi Rich !

On 18.04.2015 18:37, Rich Felker wrote:
> Odd. I just verified that  Google's 8.8.8.8 resolves it right,


MX and NS records must never point to a CNAME alias (RFC 2181 
<https://tools.ietf.org/html/rfc2181> section 10.3)

From: https://en.wikipedia.org/wiki/CNAME_record

I think this is the failure!

Harald