[TAG] freeshell.org service outage

[Rick Moen]

I wrote:

> Ben mentioned on a private mailing list that Stephen's a good guy and
> performs a generous service to the public but for reasons of personal
> experience loathes Linux.  I vaguely remembered when that came about,
> and have re-found the rant he posted at the time, which still makes
> interesting reading:
> 
> http://web.archive.org/web/20010712145226/http://www.lonestar.org/sdf/

Stephen goes into a _little_ more detail about his circa-2001
disenchantment with Linux, here:

http://mail-index.netbsd.org/port-alpha/2001/12/28/0008.html

But the guy I shave did some pretty thorough analysis at the time:
http://www.crackmonkey.org/pipermail/crackmonkey/2001q3/021695.html

Oh, what the heck, I might as well just quote it, because it's still
relevant:


 From rick at linuxmafia.com Sun, 15 Jul 2001 13:59:04 -0700
 Date: Sun, 15 Jul 2001 13:59:04 -0700
 From: Rick Moen rick at linuxmafia.com
 Subject: [CrackMonkey] How come I am just hearing about this?

begin Bob Bernstein quotation:

> Found on the netbsd-advocacy list:
> http://www.lonestar.org/sdf/

It's got to really suck, being sysadmin of a public-access Unix system:
You'll have an ungodly number of careless users, plus you have to worry
about attacks both from arbitrary remote locations and attacks both _by_
your users and by outsiders masquerading as legitimate users.  When the
day comes of you suddenly realising that your site has for some time
been massively compromised, more often than not, you have only surmises
about how entry and compromise occurred.

Numerous of Stephen Jones's statements suggest that such was the case
with freeshell.org (aka "SDF"):

> I'm even thinking of just removing telnet/ftp/pop3 all together...

Plaintext-authentication network access to shell accounts:  check.

> ...we might as well had our passwords in plain text as LINUX's use of
> encryption is about twice as good as Microsoft's.

Unless I misremember very badly how the login process works, passwords
are not processed in kernelspace.  Some Unixes introduce a PAM layer,
while others do not.  Some support MD5; others do not.  But the irony is
that Stephen's users _did_ have their passwords in plaintext -- every
time they did telnet/ftp/pop3!

In fact, it's obvious that Steven's brand new to security-mindedness:

> I've never felt security was important because I sincerely thought
> that a public system would be sacred ground to anyone be they a
> cracker or just normal user.

Poor bastard.  I'd say he's had a rude awakening, except that I think
it's not even begun, yet.  

His July 11 note suggests that he was _still_ running Linux kernel
2.2.18, which has been security-obsolete for a dog's age.  (Note
exception:  Some distribution provide kernels with nominally earlier
version numbers that have been patched to have the fixes introduced in
nominally later kernels.)  

Stephen writes: 

> I blame LINUX due to the recent unveiling of the "oh, if root wasn't
                           ^^^^^^
> already easy to get, here is an easy way" bug in the execve() system
> call... 

But that ptrace/execve() race condition (note:  a _local-user_ exploit)
was _not_ recent at all:  It was a _long_ while back.  Wojciech
Purczynski reported it to BugTraq on 2001-03-27:

http://www.securityfocus.com/templates/archive.pike?list=1&mid=171708&_ref=539250975

> ...where malicious code an be executed via almost any binary. 
                                             ^^^^^^^^^^^^^^^^^
As Purczynski says, any _SUID_ binary.  But the point is that all this
is _very_ old news, 3+ months old.  And _extremely_ well known (as the
"ptrace exploit").

Now, it seems likely that Stephen was still running an
non-ptrace-patched 2.2.18 (or earlier) Linux kernel when the shit hit
the fan, proving if nothing else did that he was asleep at the wheel --
but it's also clear that his system was security-exposed in a multitude
of other ways, AND that he still is.  (Example:  He hasn't yet firmly
deep-sixed telnet, POP3, and ftp inbound access mechanisms exposing
shell passwords to the Net.  He will.)

Let's do a taxonomy of root-compromise attacks (as opposed to DoS
attacks and other categories):  Rarely, these might be compromises of
daemon processes or kernel network stacks from remote -- e.g., against
vulnerable releases of BIND v. 8.x, lpr, or wu-ftpd.  If the attack is
not one of those, it must involve acquiring user-level access first, and
then attacking the host from inside, impersonating a legitimate user.
(In other words, the compromise of root authority is either from outside
the host, or inside.  Inside is much easier.)

The latter category breaks down further, according to how the attacker
arranges to impersonate a legitimate user, into sniffing versus other.
Sniffed passwords are, of course, what you get with standard deployments
of telnet, non-anonymous ftp, and POP3 daemons -- and are a particularly 
ignominious way to get compromised.  Stephen is only _now_ thinking of
shutting off this possibility -- so I fear he has other hard lessons yet
to come.

The other ways of compromising shell-account passwords all trace back to
the fact that users are pretty much always the weak element.  If you let
them, they'll use the same weak password everywhere.  If you assign
passwords yourself, change them at intervals, and remove the SUID bit 
from /usr/bin/passwd -- _and_ sternly admonish the users not to expose
their passwords through re-use on other systems -- they'll still do the 
latter, because they can, and because you can't stop them.  Switch to 
one-time pad authentication, and they'll store the pads or seeds on 
vulnerable systems.  And of course they'll ssh in, thinking that's 
unconditionally secure -- from compromised systems where attackers are
logging all keyboard activity.  And, remember, it takes only _one_ 
user's shell access getting compromised.  (Or, of course, the attacker
might just _sign up_ for a user account.)

You _might_ be able to prevent system security from being shot in the
foot by your users by requiring them all to use physical security
dongles (e.g., SecureID) plus one-time pads.  Maybe.  But not on a
public-access Unix system.  In that sense, Stephen is screwed.

How so?  Because he's doomed to having attackers occasionally get
user-level access -- and protecting root against local users is much
more difficult.  While the remote attacker can fruitfully attack only 
running your network daemons and network stacks, as a local user he 
can attack any security-sensitive binary on your system -- a much 
wider field of targets.  Stephen can try to keep installed software
current, remove some, remove SUID/SGID from others, recompile using
StackGuard, implement a capabilities model / ACLs, keep selected
subtrees on write-protected media, and so on.

And he'll still get clobbered, from time to time.  Odds are, he won't 
even be aware of compromise for quite a long time (as he probably
wasn't, this time).  Does he have IDSes set up?  Of course not!  He's 
"still against security".  But that will change.  Papa Darwin is a good,
if ungentle, teacher.

NetBSD 1.5.1 on Alpha is going to be an eminently suitable system for
him (even though the Alpha is doomed over the longer term).  And Nick
used to deliberately keep an Alpha on-line with a very vulnerable,
antique OS load, just for the amusement value of watching x86-oriented
kiddies' canned attacks crash and burn on it.

But Stephen has a longer-term problem, and it has nothing to do with
kernel vulnerabilities -- let alone old ones that he should have long
ago patched.

-- 
Cheers,           "I don't like country music, but I don't mean to denigrate
Rick Moen         those who do.  And, for the people who like country music,
rick at linuxmafia.com         denigrate means 'put down'."      -- Bob Newhart