Buffer overflow in inndstart
rra at stanford.edu
Tue Sep 7 10:01:01 UTC 1999
Forrest J Cavalier <mibsoft at mibsoftware.com> writes:
> Well, there are two schools of thought....There are times when you
> should just do exactly what the user asks, allocate all the needed space
> for a string, and move on. The problem is that this can lead to DoS
> attacks pretty easily, and nothing gets logged.
In this particular case, I don't see how you can cause a denial of service
attack against INN by starting it with a really large environment
variable. inndstart is only supposed to be run by the news user anyway,
and the news user can delete the entire news spool, which is a far more
effective DoS attack. :)
> For fast, efficient, "limitless" strings which "drop into" existing code
> without much modification, I use my open source astring library.
Yes, this is a very frequently reinvented wheel. Yours is a nice one,
although they all start looking about the same after a while. :)
I'm inclined to take a somewhat less aggressive approach. I'm going to
check in an implementation of concat() into the current development
sources and convert inndstart for INN 2.3 to use it. Most of our problems
so far have stemmed from using sprintf() to copy strings. We need a
better string copying method.
For those who haven't seen concat(), it's a variadic strdup(). You call
env[i++] = concat("BIND_INADDR=", p, (char *)0);
and it walks the argument list, determines how much memory it will need,
allocates that much space, and then walks the list again doing strcat()
into the allocated space. It returns a pointer to malloc()'d memory.
If anyone objects to me doing this, yell now. The potential drawback is
that I can't just copy concat() from libiberty because libiberty is GPL'd,
so I'll need to write it myself, which means it will be a straight stdarg
implementation and won't work with varargs. (I know nothing about varargs
and don't have a system that uses them to test on.) If people care
strongly about INN continuing to work on a system without stdarg.h, yell
now, and I'll come up with something else; the general consensus seems to
be towards assuming ANSI C, though.
Alternately, if you know varargs, I'd be happy to have you port it after I
check it in. configure already does the right tests, I believe; I just
don't know how to take advantage of them.
> BTW, if funding could be secured, I'd be able to rewrite ALL of the
> string handling code in INN to use astrings instead of the clumsy
> methods now. This is something I've wanted to do since the 1997 buffer
> overflow reports, but it is not a spare time project.
I think innd and nnrpd are probably reasonably okay; it's the various
front ends and support programs that I'm worried about.
Russ Allbery (rra at stanford.edu) <URL:http://www.eyrie.org/~eagle/>
More information about the inn-workers