Re: [tlug] Re: tlug] Security question with grep/e...

["Stephen J. Turnbull" <stephen@example.com>]

>>>>> "Jim" == Jim Breen <Jim.Breen@example.com> writes:

    Jim> Can you be more specific about the risks? As I understand it,
    Jim> doing a system("foobar par1 par2"); just stokes up /bin/sh
    Jim> under my account (it's usually cgiwrap or equivalent) and
    Jim> runs foobar.

ISTR that the main direct system risks come from the environment
(especially things like LD_PRELOAD).  The indirect risks come from the
fact that most command line apps are written assuming that the user is
right there and authorized.  They are large with many complex options
(especially the GNU versions), with lots of legacy code.  You really
can't depend on all buffer and array accesses being bounds-checked,
etc.

You also have to be sure that you get the protection against quote
characters right.  Note that if you're using "" for the regexp
argument in your system() call, you probably need to strip out $ and
`, since they're interpreted and the results interpolated.  Of course,
` can do anything that you can, and at least some shells accept $
extensions that call programs (although I don't know if they do if
called as /bin/sh, but see next para).

Also, /bin/sh is not terribly portable; ash, bash, and zsh all flunk
as POSIX shells in different ways.  (Maybe recent versions of ash are
OK.)  The problems with bash and zsh are not of interest to POSIX-
conforming scripts, they're impermissible extensions, but they are
extensions that conceivably could be used by hackers.  (No, I don't
know specifically; the point is that since I don't know, I have to
assume they are a risk.)

    Jim> I'm not doing it with anything suid, etc. I don't have su
    Jim> rights on the host.

Do you have a shell account?  Does the host have a working C compiler
on it?  If the answer to both questions is "yes", then the possibility
of a hostile agent using a web exploit to achieve shell access via
your account, and from there trampolining to root cannot be
discounted.  Again, I don't know the details, but AFAICT at the time
it's been done to me, so I know it's possible.  :-/

It's harder achieve a root exploit these days than when I was
root-kitted, but once it's been done and scripted even a Windows virus
can use it.

    >>> What's wrong with using the native regexp facility of whatever
    >>> you're using to write the CGI?  Even if it's in C or C++, the
    >>> POSIX regcomp/ regexec facility is not rocket science to use.
    >>> That's what you'd be using with grep, anyway, AFAIK.

    Jim> Two reasons:

    Jim> (a) laziness. It's easier to stoke up a system call than open
    Jim> the file and do it line-by-line. Actually it's *MUCH* easier
    Jim> than regexec()'s horrible call;

Oh, c'mon.  I don't see any real saving once you get to (a) trapping
the unsafe constructs on the way in and (b) implementing sane error-
handling on the way out.

    Jim> (b) portability. I have actually found some of those
    Jim> libraries not so smoothly implemented. Since I have mirrors
    Jim> on Solaris, AIX, FreeBSD and almost all Linices,
    Jim> system("egrep ..."); seemed more likely to work on them all.

If they can't implement the libraries to spec, that means that they've
hacked the utilities to work around, but aren't necessarily competent
to vouch for the security, either.  Who knows what evil lurks?  The
Hacker Knows....

I don't think the risks are all that high, but then I don't personally
have the visibility that some of the Monash mirrors do.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.