Re: Signature for this?

[scott campbell <axonpotential () yahoo com>]

The preprocessor and plugin are done (and available),
but the situation is far more complex than a simple
'big dns' packet.

I spent a little time digging into the patch code for
FreeBSD and came up with the following overflow
scenerio.  I am hoping to put together a sig for it
this weekend, but time has been a little short as of
late.

The following is based on the code found in
gethostbydns.c .  It is freely available off the web
cvs server.

There is a buffer, hostbuf[8*1024], which will be
attacked.  There is a
variable buflen which is incorrectly decremented when
processing
non-CNAME T_A and T_AAAA records.  The part of the
code that does all
the work for us is around line 443:

                if (!host.h_name) {
                        n = strlen(qname) + 1;  /* for
the \0 */
                        if (n > buflen || n >=
MAXHOSTNAMELEN)
                                goto no_recovery;
                        strcpy(bp, qname);
                        host.h_name = bp;
                        bp += n;
                        buflen -= n;
                }

Since the quantity buflen does not correctly reflect
the size of the buffer, the test should be straight
forward to fool and strcpy will over-run the end of bp
(buffer pointer).

There are two bufsize decrements which were fixed. 
The first is a nice meaty failure to adjust bufsize by
the length of the full resolved name.  Unfortunatly
this same routing also resets host.h_name to a
non-null value so we can't use it (rather, I could not
see a way to use it).  The other is an adjustment to
the bit alignment.  This was also left out of the
unpatched code and is the way into the routine.

In order to over-run the ~10k buffer with a single udp
resolve, we can just exploit the domain name
compression for multile responses (ie response + cname
records).  

The real problem is to keep host.h_name from being set
in the struture
(so we must not provide a 'good' response back).

What the packet should look like would be:

[T_A || T_AAAA resp w/ no host.h_name]
[padding w/ T_PTR && T_CNAME]
[many more T_PTR && T_CNAME till overflow possible]

There may be problems with the exact structure of
this, but I am thinking that the key is the number of
T_PTR && T_CNAME records.  The CNAME response id a
legitimate way to fill the buffer, and the PTR CNAME
is the only one which will not reset host.h_name to a
non-NULL value.

This should give a basic idea as to the nature of the
resolver problem.  It ought to be possible to detect
this situation due to the unusual nature of T_PTR
record type.

Hope this helps - feel free to contact me at this
address if there are questions as I am not regularly
looking at the snort-user list.

cheers,

scott


On Sat, 2002-09-07 at 23:37, Michael Scheidell wrote:
> > is anyone aware of a snort sig for this one?=20
> > http://www.theregister.co.uk/content/55/26967.html

> sounds more complicated than a snort sig.


Yeah, I was afraid you guys would say that...

Wasn't there someone working on a DNS pre-processor?
Maybe that would
catch it (overly long DNS responses, etc.)

Frank






__________________________________________________
Do you Yahoo!?
Yahoo! News - Today's headlines
http://news.yahoo.com


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users