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 <dimaqq_at_gmail.com>
To: c-ares hacking <c-ares_at_cool.haxx.se>
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 <daniel_at_haxx.se> 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
>
Received on 2011-02-16