fpCGI

[Fairlight]

At Tue, Sep 20, 2005 at 01:05:31PM -0500 or thereabouts, 
suspect Chris Rendall was observed uttering:
> Command from Field_cmd could not be run. Error 256 Errno 0.
> 
> ------------------------------------------------------------------------
> --------
> 
> Command string is /appl/fp/rreport itemastr -sr 1 -fp brwitemastr -n -rw
> /usr/local/apache2/htdocs/brwitm053 > /dev/null
> 
> When I try to use fpCGI 1.0 on SCO OpenUNIX 8 to access filePro 5.0.14
> data I get the error above.  I can type the command from the shell
> prompt and the .htm file gets created like it should and I can view the
> .htm file in the web browser if I manually type the URL in.  
> 
> As anyone else run into this problem and/or know how to fix it?

I'll address trying to fix this issue under fpcgi 1.0 first, then make a
few comments.

Since fpcgi automagically tacks on the "> /dev/null" on its own, you can't
capture fP's screen output to debug from it or see what's going on
directly.  Put your command inside a script that parses out the -rw value
and subtitutes it into the -real- command above, but redirect that
command's STDOUT and STDERR to a real file, rather than the bit bucket.

That may give you an idea of why it blows up in the CGI environment.

You -did- set TERM in the environment, right?  Most common cause of
non-tty-based crashes I've ever seen.

As for fpcgi 1.0, it's got serious security issues.  Namely, it has
a hole that allows arbitrary command execution.  One intentionally
malformed request, and all your filepro-owned files system-wide could be
wiped out, altered, whatever.  Anything filepro can get at, including
filepro itself, is at risk.

They have a 2.0 release, but while they made some changes, the -default-
configuration is still not secure.  You need to take advantage of some
things they added.  If you don't, a malicious user could bleed your fP
license dry in seconds, and it would require -manual- intervention to fix
the problem--each time it happened.  Literally, I've written a 13-line
proof-of-concept in perl that showed that one can drain even a fictional
2000 user license of filePro down to 0 available sessions in the amount
of time it takes to make the requests--and not really tax the attacking
system at all.  The results were not pretty, and you have to use fpcgi 2.0
very carefully to avoid this DoS attack potential.  The 1.0 release is just
plain insecure--I can illustrate how to do arbitrary command execution not
only on *nix, but on Windows as well.  It could best be summed up as, "How
to trash an fpcgi-running server's filePro in under five minutes."  It's
ridiculously easy to exploit.

I would unabashedly suggest investigating my OneGate solution.  I at least
know it's secure all around--it was designed that way.  It also allows for
far easier debugging than what you'll have to go through to get around
fpcgi's auto-adding of the redirect.  It's also far more feature-rich.
http://onegate.fairlite.com/

That said, good luck with the bug hunt if you stay with fpcgi.  The TERM
and redirect wrappers are the best suggestions I can give you off the top
of my head.  TERM is easy to fix.  The wrapper is a bit more work.

mark->
-- 
There is no "I" in TEAM.
This would be the primary reason I've chosen not to join one.