Vulnerability Development mailing list archives

Windows XP SP1 gethostbyaddr() flow (Re[3]: mirc32 6.0x crash when resolving dns.)


From: 3APA3A <3APA3A () SECURITY NNOV RU>
Date: Sat, 31 May 2003 14:18:40 +0400

Dear vulndev,

It's  definitely  bug  in  Windows  XP SP1, as it was supposed by Roland
Postle <mail () blazde co uk> To reproduce it:

1. Created zone 1.168.192.in-addr.arpa and add record:

254 IN CNAME non.existant.name

2. Use test program attached

3.  I  did  tests  on  Windows  NT 4.0, Windows 2000 and Windows XP SP1.
Results:

Windows NT 4.0:

c:\>test.exe 192.168.1.254
gethostbyaddr failed

Windows 2000:

C:\>test.exe  192.168.1.254
gethostbyaddr failed

Windows XP SP1:

C:\>test.exe 192.168.1.254
h_name: (null)

So,  this problem is not specific to mIRC and it's possible to crash any
application    on    Windows    XP    Sp1   where   gethostbyaddr()   or
WSAAsyncGetHostByAddr()   is  used  for  reverse  name  resolution  (IRC
clients, Peer-to-Peer clients, personal firewalls, etc).

Can somebody test Windows 2003?


--Thursday, May 29, 2003, 11:52:59 AM, you wrote to roam () ringlet net:

3> Dear Peter Pentchev,

3> A  way  to  delegate  reverse  resolution  for  network less than /24 is
3> defined in RFC 2317. And it's different from one used.

3> But  you're  right: the problem is probably not in unresolvable PTR. The
3> problem  is  in unresolvable CNAME instead of PTR, so PTR is never found
3> at   all.   And   yes:   it  may  affect  different  applications  where
3> gethostbyname()  is  used. I will test gethostbyname() behavior for this
3> case in Windows and Unix and report back.

3> --Thursday, May 29, 2003, 11:26:04 AM, you wrote to 3APA3A () SECURITY NNOV RU:

PP>> On Wed, May 28, 2003 at 02:45:25PM +0400, 3APA3A wrote:
Dear Davide Del Vecchio,

Currently 210.193.16.25 doesn't resolve. But during original test it had
flowed PTR record:

bash-2.03$ host 210.193.16.25
25.16.193.210.IN-ADDR.ARPA is a nickname for 25.16.16.193.210.IN-ADDR.ARPA

(.16 is twice)

PP>> This is not necessarily a flawed record; I believe it might be as simple
PP>> as the ultimate in classless reverse DNS delegation.  Note that the
PP>> 16.193.210.in-addr.arpa zone is delegated to ns[12].qala.com.sg, while
PP>> this specific "alias" subdelegates the reverse DNS records for
PP>> 210.193.16.25 to dns[12].lga.net.sg.

PP>> G'luck,
PP>> Peter





-- 
~/ZARAZA
Машина оказалась способной к единственному действию,
а именно умножению 2x2, да и то при этом ошибаясь. (Лем)

Attachment: gethostbyaddr.c
Description:


Current thread: