innd 2.2.2 remote buffer overflow
rra at stanford.edu
Tue Jun 6 21:11:00 UTC 2000
Michal Zalewski <lcamtuf at dione.ids.pl> writes:
> Uh, verified. RedHat (and probably other people) is shipping innd with
> following patch:
> --- inn-2.2/samples/inn.conf.in.rh Fri Nov 6 22:06:05 1998
> +++ inn-2.2/samples/inn.conf.in Wed Jun 2 12:04:09 1999
> -verifycancels: false
> -logcancelcomm: false
> +verifycancels: true
> +logcancelcomm: true
> wanttrash: false
Red Hat made a poor choice. Hopefully they'll fix this. The defaults in
INN exist for good reason, and it's rarely a good idea for a packager to
change the defaults without discussion with the developers and a really
good reason. I don't recall Red Hat ever discussing this on inn-workers.
> For attacker, it's quite easy to check if remote system has
> "verifycancels" set. In the meantime, I believe you should work a little
> on innd code. For example, most of article-parsing code operates on
> small temporary buffers (SMBUF = 256 bytes), while single header can be
> much longer (1 kB). Also, before calling shell-scripts used to parse
> control messages, strange characters are not always removed
> (eg. `$|;><() in Reply-To/Sender parameter). It doesn't mean there's a
> bug, but... only one mistake might mean a disaster, just like in
> 'verifycancels' case.
Yup. I'm aware.
INN is an extremely old and somewhat messy program. We're currently
working on cleaning up a lot of it and removing dangerous coding practices
in the process. My experience with the code base is that if one
understands the style in which it was originally written, the original
code *is* safe; the problems, like this one, arise from someone not
understanding the original style (in this case, the need to wrap this sort
of log message with MaxLength) while adding new features.
The solution is to make the coding style more obvious and more like other
packages that one runs into these days.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the inn-workers