[ntp:questions] ntpd IPv6 support on Windows?
Danny Mayer
mayer at ntp.isc.org
Tue Jan 13 02:52:57 UTC 2009
Terje Mathisen wrote:
> Dave Hart wrote:
>> On Jan 11, 6:04 pm, ma... at ntp.isc.org (Danny Mayer) wrote:
>>> Dave Hart wrote:
>>>> I am not suggesting you to go referencing Wsp* functions willy-nilly
>>>> to avoid some perceived (and insignificant) overhead of using
>>>> published APIs. I'm suggesting you use the published API names like
>>>> getaddrinfo and let Microsoft's runtime binding implementation do what
>>>> it is designed to do. That it involves macros to inline functions
>>>> with names like WspiapiGetAddrInfo is an implementation detail
>>>> invisible to everyone not using a symbolic debugger against ntp
>>>> binaries on Windows.
>>> That is not correct. These are not macros. The SPI layer is a layer
>>> between Winsock2 and the base layer and there can be multiple SPI layers
>>> and in fact you can specify the order. All of this gets very tricky and
>>> it's one of the reasons why I don't want to go there. Just because
>>> Microsoft provides something doesn't mean that we should use it.
>> You are mistaken. I'm getting sick of you speaking without checking
>> on the accuracy of your claims. Wspiapi.h and the Wspiapi-prefixed
>> inline functions and macros have nothing to do with Winsock's Service
>> Provider Interface (SPI). Rather, they are part of the pedestrian
>> client application socket API. Please take a few minutes and read the
>> header file, since you are so stubbornly unwilling to believe the
>> documentation I've referred you to repeatedly.
>>
>> http://pf.itd.nrl.navy.mil/mdp/dox/html/wspiapi_8h-source.html
>>
>> You don't even need to have a set of Windows header files handy, the
>> US Navy has kindly published the entire header file at the URL above.
>> You said "these are not macros." The source code disagrees:
>>
>> 00027 #define getaddrinfo WspiapiGetAddrInfo
>>
>
> Dave, I was inclined to agree with you that these headers do look like
> what we need, functionality-wise they look spot on, but when I started
> to read the code I found some ugly stuff, i.e.:
>
> 00272 __inline
> 00273 int
> 00274 WINAPI
> 00275 WspiapiLookupNode(
> 00276 IN const char *pszNodeName,
> 00277 IN int iSocketType,
> 00278 IN int iProtocol,
> 00279 IN WORD wPort,
> 00280 IN BOOL bAI_CANONNAME,
> 00281 OUT struct addrinfo **pptResult)
> 00282 /*++
> [snip]
>
> 00308 char szFQDN1[NI_MAXHOST] = "";
> 00309 char szFQDN2[NI_MAXHOST] = "";
> 00310 char *pszName = szFQDN1;
> 00311 char *pszAlias = szFQDN2;
> 00312 char *pszScratch = NULL;
> 00313 strcpy(pszName, pszNodeName);
>
> I.e. the _very_ first operation of this function is to enable a stack
> overflow bug/security hole!
>
> If you send in a too-long szNodeName, then the strcpy() will overwrite
> lots of stack values. :-(
>
> Terje
And line 340-341 makes it clear that it's doing it's own lookups:
// there was a new CNAME, look again.
WspiapiSwap(pszName, pszAlias, pszScratch);
That also means that it is not using the resolvers since CNAME restart
is the job of a resolver and that means that this code cannot make use
of DNSSEC and other security changes being added to DNS.
In addition as Martin mentioned this is compile-time code. We need it to
do the right thing at runtime. We won't be supporting IPv6 on Windows
2000, it's just too difficult to deal with from a support point of view.
Danny
More information about the questions
mailing list