Hi guys and thanks for the lively discussion. Daniel: You hit the nail on the head with:
> I can see how a windows app that is used to the Windows way of doing things > may believe that libcurl would work the same way as they're used to have > getaddrinfo() work on their platform, even if I personally see that as an > obvious hack: Exactly. You have a windows application that was working fine, and all of a sudden when you run on a newer system, it either malfunctions in some cases or in worst case, has new attack surface. That's unfortunately what it comes down to. Usually Microsoft does pretty well with backwards compatibility. I guess they saw an opportunity to diverge a bit more with Vista/Win 7. If they wanted to continue with having localhost defined in the hosts file, I am not sure how they would have resolved the problem about having two localhosts in the hosts file when IPV4 and IPV6 were both installed on a system, but they probably could have fixed that. It's true also that text based configuration is really easy to attack. I actually saw a vendor showing off a simple batch script to add a host line to the hosts file, which redirected browsers to a different IP address for windows software updates. Of course from an access standpoint, it's not any more defended when the information is stored elsewhere but only accessible via an API. They still support the hosts file anyway, so that's not the issue. Internally, we are going to need to do some hacks to work around this. If a new version of C-ARES is available that takes care of this that would indeed be great. But we at least need to patch our version at this point. Or change all references in the code to localhost, and then branch accordingly based on whether or not IPV6 is there. Greg ----- Original Message ---- From: Dima Tisnek <[email protected]> To: c-ares hacking <[email protected]> Sent: Wed, February 16, 2011 11:01:00 AM Subject: Re: DNS issue with c-aress. I think Greg's point was that we should use system resolver if it is good. IIUC "localhost" is handled correctly-ish on win* platforms either through file or system code depending on version, c-ares uses only a file (old win* version) which produces unexpected results (new win* version). It is, in a way, a bug. If I use a big stack (c-ares/libcurl/pycurl/python) and a program on top of that and distribute the stack as binary, I'd like it to work on all versions of win* same way as native win* programs do, well mostly. If it doesn't it's a big kick in c-ares', libcurl's, pycurl's etc. nuts and package/release has to use another resolver. 2c from someone who doesn't actually use localhost. On 16 February 2011 10:47, Daniel Stenberg <[email protected]> wrote: > On Wed, 16 Feb 2011, Greg Christopher wrote: > >> Security issue: >> >> This creates a potentially bad situation. It's possible for systems to >> create listeners that only work on loopback. In those cases, you may have >> assurances that the connection can be trusted, so you don't do the normal >> authentication steps. Listening on a regular socket of course requires >> authentication and such. > > /etc/hosts has been the place for localhost resolving for 40 something > years, I don't see why that all of a sudden introduces a security problem. > > I can see how a windows app that is used to the Windows way of doing things > may believe that libcurl would work the same way as they're used to have > getaddrinfo() work on their platform, even if I personally see that as an > obvious hack: > > getaddrinfo on Windows is documented > (http://msdn.microsoft.com/en-us/library/ms738520(v=vs.85).aspx) to return > "all loopback addresses on the local computer" when "localhost" is passed > in. > > Another funny quirk is: On Windows Server 2003 and later if the pNodeName > parameter points to a string equal to "..localmachine", all registered > addresses on the local computer are returned. > > Anyone up for providing a patch that brings this "feature" to c-ares for > Windows? > > -- > > / daniel.haxx.se >
