* Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] @ 2015-04-17 13:10 Matt Johnston 2015-04-17 17:23 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Matt Johnston @ 2015-04-17 13:10 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-17 13:10 Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] Matt Johnston @ 2015-04-17 17:23 ` Rich Felker 2015-04-17 18:03 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-17 17:23 UTC (permalink / raw) To: Matt Johnston; +Cc: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-17 17:23 ` Rich Felker @ 2015-04-17 18:03 ` Rich Felker 2015-04-17 18:09 ` Solar Designer 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-17 18:03 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-17 18:03 ` Rich Felker @ 2015-04-17 18:09 ` Solar Designer 2015-04-18 13:32 ` Matt Johnston 0 siblings, 1 reply; 24+ messages in thread From: Solar Designer @ 2015-04-17 18:09 UTC (permalink / raw) To: musl; +Cc: Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-17 18:09 ` Solar Designer @ 2015-04-18 13:32 ` Matt Johnston 2015-04-18 15:25 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Matt Johnston @ 2015-04-18 13:32 UTC (permalink / raw) To: musl; +Cc: Rich Felker > 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 13:32 ` Matt Johnston @ 2015-04-18 15:25 ` Rich Felker 2015-04-18 15:49 ` Harald Becker 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-18 15:25 UTC (permalink / raw) To: musl; +Cc: Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 15:25 ` Rich Felker @ 2015-04-18 15:49 ` Harald Becker 2015-04-18 15:58 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Harald Becker @ 2015-04-18 15:49 UTC (permalink / raw) To: musl; +Cc: Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 15:49 ` Harald Becker @ 2015-04-18 15:58 ` Rich Felker 2015-04-18 16:27 ` Harald Becker 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-18 15:58 UTC (permalink / raw) To: Harald Becker; +Cc: musl, Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 15:58 ` Rich Felker @ 2015-04-18 16:27 ` Harald Becker 2015-04-18 16:37 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Harald Becker @ 2015-04-18 16:27 UTC (permalink / raw) To: musl; +Cc: Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 16:27 ` Harald Becker @ 2015-04-18 16:37 ` Rich Felker 2015-04-18 17:07 ` Harald Becker ` (2 more replies) 0 siblings, 3 replies; 24+ messages in thread From: Rich Felker @ 2015-04-18 16:37 UTC (permalink / raw) To: Harald Becker; +Cc: musl, Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 16:37 ` Rich Felker @ 2015-04-18 17:07 ` Harald Becker 2015-04-18 18:27 ` Laurent Bercot 2015-04-18 18:13 ` Harald Becker 2015-04-18 18:25 ` Harald Becker 2 siblings, 1 reply; 24+ messages in thread From: Harald Becker @ 2015-04-18 17:07 UTC (permalink / raw) To: musl; +Cc: Matt Johnston 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 17:07 ` Harald Becker @ 2015-04-18 18:27 ` Laurent Bercot 2015-04-18 18:47 ` Harald Becker 0 siblings, 1 reply; 24+ messages in thread From: Laurent Bercot @ 2015-04-18 18:27 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 18:27 ` Laurent Bercot @ 2015-04-18 18:47 ` Harald Becker 0 siblings, 0 replies; 24+ messages in thread From: Harald Becker @ 2015-04-18 18:47 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 16:37 ` Rich Felker 2015-04-18 17:07 ` Harald Becker @ 2015-04-18 18:13 ` Harald Becker 2015-04-18 19:56 ` Rich Felker 2015-04-18 18:25 ` Harald Becker 2 siblings, 1 reply; 24+ messages in thread From: Harald Becker @ 2015-04-18 18:13 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 18:13 ` Harald Becker @ 2015-04-18 19:56 ` Rich Felker 2015-04-18 21:02 ` Laurent Bercot 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-18 19:56 UTC (permalink / raw) To: musl; +Cc: Harald Becker 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 19:56 ` Rich Felker @ 2015-04-18 21:02 ` Laurent Bercot 2015-04-19 3:44 ` Rich Felker 0 siblings, 1 reply; 24+ messages in thread From: Laurent Bercot @ 2015-04-18 21:02 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 21:02 ` Laurent Bercot @ 2015-04-19 3:44 ` Rich Felker 2015-04-20 10:17 ` Harald Becker 0 siblings, 1 reply; 24+ messages in thread From: Rich Felker @ 2015-04-19 3:44 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-19 3:44 ` Rich Felker @ 2015-04-20 10:17 ` Harald Becker 2015-04-20 11:20 ` Kurt H Maier 0 siblings, 1 reply; 24+ messages in thread From: Harald Becker @ 2015-04-20 10:17 UTC (permalink / raw) To: musl [-- 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 --] ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-20 10:17 ` Harald Becker @ 2015-04-20 11:20 ` Kurt H Maier 2015-04-20 11:35 ` Harald Becker 0 siblings, 1 reply; 24+ messages in thread From: Kurt H Maier @ 2015-04-20 11:20 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-20 11:20 ` Kurt H Maier @ 2015-04-20 11:35 ` Harald Becker 2015-04-20 11:50 ` Harald Becker 2015-04-20 14:14 ` Kurt H Maier 0 siblings, 2 replies; 24+ messages in thread From: Harald Becker @ 2015-04-20 11:35 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-20 11:35 ` Harald Becker @ 2015-04-20 11:50 ` Harald Becker 2015-04-20 14:14 ` Kurt H Maier 1 sibling, 0 replies; 24+ messages in thread From: Harald Becker @ 2015-04-20 11:50 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-20 11:35 ` Harald Becker 2015-04-20 11:50 ` Harald Becker @ 2015-04-20 14:14 ` Kurt H Maier 2015-04-20 14:21 ` Harald Becker 1 sibling, 1 reply; 24+ messages in thread From: Kurt H Maier @ 2015-04-20 14:14 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-20 14:14 ` Kurt H Maier @ 2015-04-20 14:21 ` Harald Becker 0 siblings, 0 replies; 24+ messages in thread From: Harald Becker @ 2015-04-20 14:21 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: Re: Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] 2015-04-18 16:37 ` Rich Felker 2015-04-18 17:07 ` Harald Becker 2015-04-18 18:13 ` Harald Becker @ 2015-04-18 18:25 ` Harald Becker 2 siblings, 0 replies; 24+ messages in thread From: Harald Becker @ 2015-04-18 18:25 UTC (permalink / raw) To: musl 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 ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2015-04-20 14:21 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-04-17 13:10 Security advisory for musl libc - stack-based buffer overflow in ipv6 literal parsing [CVE-2015-1817] Matt Johnston 2015-04-17 17:23 ` Rich Felker 2015-04-17 18:03 ` Rich Felker 2015-04-17 18:09 ` Solar Designer 2015-04-18 13:32 ` Matt Johnston 2015-04-18 15:25 ` Rich Felker 2015-04-18 15:49 ` Harald Becker 2015-04-18 15:58 ` Rich Felker 2015-04-18 16:27 ` Harald Becker 2015-04-18 16:37 ` Rich Felker 2015-04-18 17:07 ` Harald Becker 2015-04-18 18:27 ` Laurent Bercot 2015-04-18 18:47 ` Harald Becker 2015-04-18 18:13 ` Harald Becker 2015-04-18 19:56 ` Rich Felker 2015-04-18 21:02 ` Laurent Bercot 2015-04-19 3:44 ` Rich Felker 2015-04-20 10:17 ` Harald Becker 2015-04-20 11:20 ` Kurt H Maier 2015-04-20 11:35 ` Harald Becker 2015-04-20 11:50 ` Harald Becker 2015-04-20 14:14 ` Kurt H Maier 2015-04-20 14:21 ` Harald Becker 2015-04-18 18:25 ` Harald Becker
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).