[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#129104: bug 129104 (buffer overflow + template reading in cgiemail)

On Wed, Jan 16, 2002 at 04:17:25PM -0500, Thomas Smith wrote:
> I had released a new version with an almost-correct fix for the buffer
> overflow problem last night, and just looked at your mail to the bug
> this afternoon.  My fix was almost the same as yours; it used
> CGI_ERRMSG_MAX-1 instead of CGI_ERRMSG_MAX.  My next upload will use
> your correct version.

Right, that change isn't too big a deal.

> That leaves the other stuff...  the main problem is the template files,
> and I like the solution you suggested (restricting them to a specific
> directory).  The relevant code, I think, is in the
> cgi_standard_{email,echo,file} functions at the end of cgilib.c
> (beginning on line 1010).
> Hmm, one problem that just occurred to me is that we can't easily make
> the location of the template files a compile-time option because people
> reconfigure their webservers to have different document roots, and the
> current design of cgiemail requires the template files to have
> PATH_TRANSLATEDs.  That means, I guess, that configuration file parsing
> might have to be added.

Yes, with the current design there really isn't any way to do it well
(including backwards compatibility), only patch it up. I suggest a
simple 'templatedir="/foo/bar/baz"' in a trusted place like
/etc/cgiemail.conf. That has the advantage that it can be parsed by the
shell, so you can easily set it with debconf and not clobber the old
setting on upgrades.

> Maybe could restrict to files with extension .CGIEMAIL_TEMPLATE.
> Do you have any other ideas, or a preference between these two?

I think I prefer the directory idea: I usually prefer moving files
between directories to renaming files, somehow.

> The other issue is that it uses mkstemp() which is not very secure.  I
> don't guess that this is exploitable, but should be fixed at some point.

tmpnam(), rather - mkstemp() is fine. It's not very hard to convert from
one to the other with a bit of care, so I'll do that later.

Colin Watson                                  [cjwatson@flatline.org.uk]

Reply to: