https://bugzilla.mindrot.org/show_bug.cgi?id=2636
--- Comment #4 from Tomas Kuthan <[email protected]> --- (In reply to Darren Tucker from comment #3) ... > getaddrinfo w/AI_PASSIVE should not return non-existent addresses. > Quoting RFC3493: > > If the AI_PASSIVE flag is specified, the returned address > information > shall be suitable for use in binding a socket for accepting > incoming > connections for the specified service (i.e., a call to bind()). > > In this case the returned address is not suitable to bind because > it'll never work (unless you race bring up the interface). Hi Darren, I don't think RFC 3493 says, that bind() on address returned by getaddrinfo() has to succeed. I think it specifies what address should be returned for NULL hostname based on AI_PASSIVE flag. If the AI_PASSIVE flag is specified, the returned address information shall be suitable for use in binding a socket for accepting incoming connections for the specified service (i.e., a call to bind()). In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to INADDR_ANY for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address. If the AI_PASSIVE flag is not specified, the returned address information shall be suitable for a call to connect() (for a connection-mode protocol) or for a call to connect(), sendto() or sendmsg() (for a connectionless protocol). In this case, if the nodename argument is null, then the IP address portion of the socket address structure shall be set to the loopback address. This flag is ignored if the nodename argument is not null. But I agree, the possibility of an IPv6 interface added after the IPv4 port was bound is troubling. In that case some user could hijack the traffic. I don't think it is directly exploitable; adding an IP interface can only be done by a privileged user, who already has all sorts of powers. But still, there is a a theoretical chance that an unprivileged attacker could exploit a condition that they did not cause. If we choose not to fix it this way, we should at least set hints.ai_family = options.address_family, so that users can make X11 forwarding work w/o IPv6 interface by setting AddressFamily=inet. Would you accept a patch for that? Thanks, Tomas -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
