Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: SNI-12: BIND Vulnerabilities and Solutions
From: paul () VIX COM (Paul A Vixie)
Date: Wed, 23 Apr 1997 00:45:49 -0700


DO NOT destroy the resolver by applying this patch. There are some systems,
e.g. AIX 3.2.5, which still have MAXHOSTNAMELEN at 32, so even if it works it
will do more harm than good.

what they're worried about is something that a lot of apps actually do:

        char name[MAXHOSTNAMELEN];
        struct hostent *hp = gethostbyname("foo");

        strcpy(name, hp->h_name);

i myself don't program this way.  properly written, this is AT LEAST:

        char name[MAXDNAME];
        struct hostent *hp = gethostbyname("foo");

        strncpy(name, sizeof name, hp->h_name);
        name[sizeof name - 1] = '\0';

noting that MAXDNAME is the max uncompressed size, which means it can have
\000 or other decimal encodings in it, and is presently "1025" in the *.h's.
truncation is suboptimal, though, since it can truncate a name from one
valid meaningful token to another, valid meaningful token.  so, correctly:

        char name[MAXDNAME];
        struct hostent *hp = gethostbyname("foo");

        if (strlen(hp->h_name) + 1 > sizeof name)
                exit(1);
        strcpy(name, hp->h_name);

this is the least efficient but it does the completely right thing.  now, i
don't want to get into arguments as to whether it is reasonable for apps to
assume that hp->h_name will in fact fit in sethostname()'s buffer size, but
the fact is that they do.

on vendorware systems where fixing the apps isn't an option, fixing it in
the resolver library seems like the best short term compromise, so that's
what we'll do in BIND 4.9.5-P2 and BIND 8.1-REL, both due this week if all
goes well.



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault