"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> Well, you missed the point of what I was trying to say. The issues that
> came up, were not really issues. But in actually going thru the code:
No, I got your point. "Don't worry about it."
I think you missed my point. All I wanted was to have other people look
over the code flagged by the program; all you did was look at the
flawfinder output without even looking at the actual code.
> 1. Getopt - No big deal. spamc is spawned by the mailer (If configured to
> do so) and because of that, there really is no oppertunity to "hijack"
> environment variables.
True enough in our case.
> 2. This is not SUID, so there is no issues with any of the non-'n' commands
> ('strcpy vs strncpy' for example) other than error detection. If there
> were a way to buffer over-run and get a shell, all you would receive is a
> shell in your own account.
Well, spamd is sometimes run as a single virtual mail user (especially
when running via SQL configuration and databases) and spamc can
similarly be run as root or such a virtual user out of the MTA or MDA,
so this is not exactly true.
As another issue, I think better error detection is probably called for
in several places.
> 3. The file descriptor problems are also moot, since it is not set UID, and
> there is only a pipe opened up.
See above.
> 4. The strcpys are copying static characters, so there is no chance for
> buffer overruns. In this case it is better to use strcpy anyway.
Except for one or two cases that appear to be okay.
Daniel
--
Daniel Quinlan
http://www.pathname.com/~quinlan/