fpCGI failure

[Fairlight]

The honourable and venerable Matt Cordes spoke thus:
> BROKEN submission:
> ----------------
> 2008-03-06 14:22:26 INFO   PID(00008186) SUCCESSFUL return from command designated in Field_cmd
> 2008-03-06 14:22:26 INFO   PID(00008186) Command string is /appl/fp/rreport ajax -fp cWebInvoice -sr 34 -n -u -y automaticCGI -rw /usr/local/apache/htdocs/rweb2a2
> 2008-03-06 14:22:26 INFO   PID(00008186) Return code from command is 0. Errno is 0

And that's a broken one?  That's not only interesting, it's not possible.
See below.

> Next came redirecting stdout (1) and stderr (2) as requested.  I changed the form's Field_cmd to reflect this.  Here's a snip from another log to show what fpcgi was seeing:
> 
> 2008-03-11 15:59:57 DEBUG  PID(00002595) fpcgi.c 000773 Name: Field_cmd  Value: rreport ajax -fp cWebInvoice -sr 307 -n -u -y automaticCGI 1> /tmp/fpcgi/fpcgi.113108_15330.4.log 2> /tmp/fpcgi/fpcgi.113108_15330.4.err.log
> 
> The result is no files are created.  A response htm is not generated, and
> /tmp/fpcgi remains empty; not even 0 byte files are created (i've made
> sure the permissions are correct).

If you redirect, the file should be created as long as the shell
interpreter got the command--whether the command fails or not.  If the
files being redirected to are not being created, /bin/sh is never even
getting called from system() inside fpcgi, period, the end.  I can think of
-no- circumstance in which a redirect will fail to generate a file as long
as the shell got a hold of it.

Now whether system() is failing or the shell is...I can't tell.  That's
internal.  But fP thinks the command is returning 0?  What does it think it
executed, is my question.  Because there's no way in hell it's getting as
far as /bin/sh, much less rreport that should come under it.

> In addition, I'd kind of hope redirection like this didn't work, and that
> there's really a different way to redirect output through fpcgi.  If I
> had a choice between letting anyone submit a form that could utilize I/O
> redirection on my server, versus not letting anyone do that, i'll take
> the latter (I don't even want to THINK about pipes working like this!).

You bring up an interesting point.  When I found the remote arbitrary code
execution hole in v1 and got them to fix it (after 45 days!!!), I was told
it took so long because they didn't just ban metacharacters, they allowed
them because they said people would be using them already in current
implementations on the product, so it took a while to sanitise things while
remaining backwards compatible.  Wonder if redirects got smacked...

But uhm...yeah, if you use a pipe in a command on Windows or unix, it
-will- let you do remote arbitrary command execution in all but a few final
versions of v1.  Semicolon worked on unix, pipe worked on both unix and
Windows.  In v2, it would tell you if it had to sanitise it.

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan