Hello all, one more (ever-returning) bug [1] reported recently caught my eye. The problem is that disabling IPv6 in kernel leads to OpenSSH failing to bind localhost IPv6 address and after the fix for CVE-2008-1483 [2] leads to the whole X11 forwarding fail. If I read the description of the CVE in question correctly, we should care only of the case when the address is already used (errno = EADDRINUSE). Other errors or at least EADDRNOTAVAIL (trying to bind IPv6 address when disabled or the other way round) should not lead to fatal errors and fallback to the other address (if any). This was already discussed in the bug #2143 [2] and #1356 [3] with basically the same patch I came up with. The comments from Darren nor Damien in any of them did not come with any convincing reasoning why not to include this change. Therefore I am bringing this issue up again here. Can you have a look into that and get that fixed almost 10 years later? Any comments welcome. Other discussed solution would be not to return IPv6 address from getaddrinfo() if disabled, but I don't think we will be able to justify this change of behavior. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1436097 [2] https://github.com/openssh/openssh-portable/commit/5f5cd746 [3] https://bugzilla.mindrot.org/show_bug.cgi?id=2143 Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat
Jakub Jelen wrote:> Hello all, > one more (ever-returning) bug [1] reported recently caught my eye. The > problem is that disabling IPv6 in kernel leads to OpenSSH failing to > bind localhost IPv6 address and after the fix for CVE-2008-1483 [2] > leads to the whole X11 forwarding fail.--- I can see the user-friendliness issue being possibly a good thing, but have some questions that might support current behavior (as you describe): 1) Why would openssh be configured to try IPV6 on a system where it doesn't exist? Or -- wouldn't it be an error to try to configure a transport that doesn't exist on that system? (why not just fix the global defaults?) 2) How would it be different than asking openssh to configure Netware sockets (or whatever) and use them? 3) I'm not sure that expecting an application (like openssh or others), upon failing some random proto's open, should fall back to IPv4. Should IPv4 always be expected to be "the" fallback if any other proto fails? Maybe I'm wondering how a non-existent protocol should be dealt with and whether or not any such non-existent proto should fall back to "something" and if that something should be ipv4? curious... -linda
On 03/31/2017 04:34 AM, L. A. Walsh wrote:> Jakub Jelen wrote: >> Hello all, >> one more (ever-returning) bug [1] reported recently caught my eye. The >> problem is that disabling IPv6 in kernel leads to OpenSSH failing to >> bind localhost IPv6 address and after the fix for CVE-2008-1483 [2] >> leads to the whole X11 forwarding fail. > --- > I can see the user-friendliness issue being possibly a > good thing, but have some questions that might > support current behavior (as you describe): > > 1) Why would openssh be configured to try IPV6 on a system > where it doesn't exist? Or -- wouldn't it be an error to > try to configure a transport that doesn't exist on that system? > (why not just fix the global defaults?)Probably because enabling both of stacks is a default configuration of all standard OSes these days.> 3) I'm not sure that expecting an application (like openssh > or others), upon failing some random proto's open, should > fall back to IPv4. Should IPv4 always be expected to be "the" > fallback if any other proto fails?It is not about random proto and fallback to IPv4. It is more about handling common use case in a fail-proof way. The proposed solution would work also the other way round in case IPv4 is not enabled/configured.> Maybe I'm wondering how a non-existent protocol should be > dealt with and whether or not any such non-existent proto should > fall back to "something" and if that something should be ipv4?This is pretty common practice in all the other cases (connecting from ssh client is handled correctly) and in all the other tools (browsers, ...) so I don't see a reason why it should not be handled in the X11 forwarding initialization code. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat