RE: virtual server - security

["Dave Paris" <dparis () w3works com>]

a few notes..

> -----Original Message-----
> From: jnf [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 31, 2004 11:23 AM
> To: Dave Paris
> Cc: Serban Gh. Ghita; [EMAIL PROTECTED]
> Subject: RE: [SC-L] virtual server - security
[...]
> > What's the point of the exercise if you're passing plaintext passwords
> > across on port 21?  At the very least, mandate SCP/SFTP on port 22.
>
> yes because having a remote exploit every month or two for
> root^H^H^HSecure shell is much better than limiting it to sniffing on the
> lan, or even better than using one of the ssl type wrappers for telnet.

Sniffing on the LAN isn't my main concern, it's the concentration points
inbetween A and B.  Good idea on the SSL wrapper on Telnet, although the
original poster said they doesn't want to offer shell access.  I'm not quite
sure the security community's concensus would agree that FTP is better than
SCP/SFTP.  I certainly don't, but I've already made that point.  So that
leaves us with flaws in implementation *and* plaintext usernames/passwords.
That doesn't give me warm fuzzies.

> > use 'chroot' jails
>
> and look into kernel patches like grsec that take some of the damn
> stupidity out of the standard chroot system call. You perhaps may want to
> look into where you might be able to use read only filesystems in your
> setup, while breaking out of a (good) chroot jail on a read only
> partition
> is not impossible- it could make life hell for quite a few.

Good call.  Perhaps better would be using SELinux as a base, although the
learning curve is one heckuvalot steeper.

> > "PHP" and "run safely" in the same sentence?  Have you perused Bugtraq
> > lately?
>
> have you ever noticied that a good 80-90% of those posts are cross site
> scripting holes or sql injections that are the result of shoddy
> programming (web developers bad programmers as a whole? nooo never.)
> And less often language specific. As to answer the poster's question, I'm
> not sure if suexec works with php, i dont think it does, but you might
> want to look into that or see if you can find something similar.
>
>
> > That's primarily because PHP will let you shoot yourself in the head, as
> > opposed to most languages which will only let you shoot yourself in the
> > foot, or at least no higher than the knee.  (snide
> commentary... unless it's
> > a microsoft product, which seem to aim squarely for "the jewels")
>
> yea I'd describe a stack or heap based overflow to be shooting
> yourself in
> the foot.

Assuming your foot is squarely between your thighs or in front of your
nose.. ;-)  My comments were based on the nature of the poster's message,
which seemed to allow scripted/interpreted languages rather than compiled
executables, given the lack of shell access.  (that's not to say that a user
can't upload a binary, but if a non-x86 arch is chosen as a base for the
deployment, things get tougher for a user to screw up by default... save for
misconfigurations of the host, of course)

> > Yes.  Near daily bugtraq reports about why PHP is a darned good
> idea that
> > made a left turn into a really bad neighborhood.  The manpage for
> > SCP/SFTP/SSH.  The manpage for 'chroot'.
>
> I will agree that php could be more secure, although i must admit
> its come
> a hell of a long ways since its first introduction, there are plenty of
> articles over php security on google- I'm sure your local bookstore will
> have books that will at least cover the subject to some degree. Just like
> any language php will let you screw yourself- most of what you find on
> bugtraq as I said are not language problems, but programmer problems. A
> quick google search will show nearly as many exploits (if not more) for
> [open]ssh as for wuftp, yet wu is considered horribly insecure and ssh
> secure, go figure. I'd also look into chroot as suggested, I am unsure of
> whether it is avail. to php programs, it might be- and you might consider
> figuring a way to wrap all php scripts executed in chroot, although if it
> is anything like perl, chroot'ing it will be a major pain in the ass.
> In short, screw bugtraq- goto google or your book store, or even
> php.net -
> they are all bound to have tons of information about what you are looking
> for.

It's not the poster who's writing the PHP, it's the users.  Unless the users
are sufficiently clued into the existing issues, the view doesn't change.
My comments regarding PHP are centered around most of the default
configuration issues that too many "web programmers" (for very loose values
of the word "programmer") won't mitigate or fail to mitigate at any rate.
While all of the flaws stated can be reproduced in any language, PHP makes
it _relatively_ easy for the flaws to remain, or to be coded in.

Rather than going to specific distributions, I ran a slightly different
google queries...

Google results:
search terms:  exploit SCP  results:   9,810
search terms:  exploit SFTP results:   3,300
search terms:  exploit SSH  results:  71,900
search terms:  exploit FTP  results: 285,000

What does this mean?  Not much, frankly.  Without deeper analysis of the
result set, any determination could be made in favor of either argument.
The fact remains that both have had (and perhaps remain) in both protocols,
but one takes plaintext username/passwords out of the network flow and the
other doesn't.  Note that I did SCP and SFTP since no shells are available
and therefore only SCP and SFTP are appropriate (but may have
vunlerabilities based on SSH).

Kind Regards,
-dsp