Re: A question of Security

Michael H. Warfield (mhw@wittsend.com)
Thu, 16 Dec 1999 14:58:27 -0500


On Thu, Dec 16, 1999 at 04:39:41PM +0100, jt@npdaxp.fuw.edu.pl wrote:
> >From: "David W. Robinson" <dwrobinson@socalled.com>
> >To: linux-net@vger.rutgers.edu
> >Date: Wed, 15 Dec 1999 17:14:19 -0800

> >I am currently trying to convince our network people of the safety of
> >using a Linux machine as an internet server, running Apache and
> >Realmedia Streaming Media. What I am looking for is evidence,
> >articles, papers etc that compares the security of a linux server against
> >the security of a box running Solaris and other common Unix
> >Operating systems. Can anyone help by pointing me in the right
> >direction, or sending me material to use in the defense of Linux?

> Intuitively seems a system with full source available is more
> sensitive because a hacker can look sources, find a bug there

Intuition, in this case is wrong. The intruders (hackers, crackers,
script kiddies, bozos, if you want) have got better debugging tools and
reverse engineering tools than most developers I know and they know how
to use them and what to look for. You think the recent buffer overflows
found in Solaris snoop was from looking at the sources? I think not. You
think all of these lovely holes in Windows are from looking at the sources?
I think not. They're going to find the holes, with our without the sources.
You're the one who is short changed.

> and use it to break system security. However, after one of our
> Linux machines was compromised I looked into sources trying to
> find the security hole the hacker used (knowing well _HOW_ he
> did it), and failed to find it - it was too much work for me.

Maybe so, maybe no. But someone with the sources will find it and
fix it. If neither of you have the sources, you're screwed until the vendor
gets around to fixing it. That can (documented examples) take a year or more.
Sometimes (Sun and M$ plus others) they will fix it and not even tell you
(oh just install this Jumbo Patch / Service Pack and try it again - maybe
we fixed it, maybe we didn't).

> Anyway, I suppose a hacker who has a lot of time can try to
> find bugs this way and use them to break security.

Had one break a crypto algorithm by using a debugger to disassemble
it and cut and past it into his own C code with an escape to assembler.
That's just the way some of these guys think. Then it's loose with the
script kiddies who wouldn't know what to do with sources if it bit them
anyways.

> Because our department has a lot of computers (I cannot even
> approximately say how much: 200? 300? more?) I have some info
> from practice. We have few SUN Solaris systems, and there were
> 1-2 security breaks a month, so we put a firewall. And I know
> about two Linux machines which were compromised - they were
> running old versions of Linux, like kernel version 2.0.30 or
> similar, and later there were lots of breaks there (seems
> hackers noticed there are hosts not protected by a firewall,
> and attacked them frequently). I asked many people about the
> security hole the first hacker used, and someone wrote it was
> fixed in RedHat 5.2 (w/ kernel 2.0.36; the hole was in RPC).
> SUN-s were compromised earlier, in spite they were controlled
> by people well knowing security problems.

As you hopefully have learned... Lack of sources is not
a barrier to being compromised. It's not even a speed bump. It
can be quite a barrier to getting a hole fixed though.

Be it Solaris, Linux, OpenBSD (which is audited for security
problems and is proactively secure), AIX or Windows, if you don't keep
up on every fix, you're going to get surprised. Even RedHat 5.2 and 6.0
have security updates. Do you have all of them installed? Are you on the
security mailing lists for these operating systems?

> If security is important, maybe better choice is VAX or Alpha
> with VMS - if this system is acceptable. We know no case of
> compromising our VMS machines in spite they are excluded from
> firewall protection. And I know about exactly one case of

No one knew of security holes in Windows and M$ went around
prancing for ages about how secure Windows NT 3.51 was. They proclaimed
how it was C2 secure and had never been broken into. We warned them
that they just hadn't gotten the attention they were asking for. They
finally got it and we now know better. Don't depend on a system being
secure just because you don't know of anyone who has ever broken into it.
Many breakins are due to configuration and administrative errors. Most
web breakins fall into that category. The OS might help protect you,
then again, it might not.

> compromising of a VMS host in place I was working in - there
> was a script which could be copied to VMS host via DECNET and
> allowed shell commands there; a way to protect from it was
> disabling write to default directory of DECNET, and making
> all writable directory names at least 15 char long (it used
> some directory to write logs, normally the default directory,
> and it was possible to send a script there, and invoke it;
> but system limits name of script to invoke to 16 chars, and
> it is not possible to use it in case the dirname is too long);
> anyway, the harm was not serious since DECNET has almost no
> privileges - like "guest" or "nobody" on most systems. In VMS
> there is no "buffer overflow" security hole due to different
> method of passing buffer, always with correct length (to pass
> incorrect, a programmer must do it purposely, unlike Unix-es
> which have gets() function which has no length parameter).
> But I do not know if the VMS has what you need, and surely
> it is _much_ different from all Unix systems.

Security is not a product or an end state. It is a process,
and a mindset, and a way of living. What is secure now, may not be
secure tomorrow (and your definition of secure may vary from mine).

> Jerzy

Mike

-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 331-2437   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.rutgers.edu