Linux Security: Reflections on 2002, Eye on 2003

Mirko Zorz writes "Here are the reflections on Linux security in 2002 and predictions for 2003 by Bob Toxen, one of the 162 recognized developers of Berkeley UNIX and author of the acclaimed book "Real World Linux Security" already in its 2nd edition. Read more at Help Net Security."

Comments

Re:Disappointing article

[robbyjo]

Actually two...

As the worldwide recession continues in 2003, budget pressures will help move the world from expensive SysAdmin-intensive proprietary solutions to Linux. Even the last two holdouts, Sun and Microsoft, have grudgingly started to embrace Linux.

Talking about Linux security...

[fungus]

You guys should know that a trivial remote root hole for SSH was released today on bugtraq.

Someone who wants karma bad enough should reply to this with the advisory :)

Re:Talking about Linux security...

[fungus]

ERRATA:

--- begin cut & paste ---

To: BugTraq
Subject: Re: OPENSSH REMOTE ROOT COMPROMISE ALL VERSIONS
Date: Jan 6 2003 8:05PM
Author: Global InterSec Research
Message-ID:
In-Reply-To:

As some may have gathered, the advisory recently posted by mmhs@hushmail.com
was indeed a fake, intended to highlight several unclear statements made in GIS2002062801.

The advisory in question is currently being updated with more detailed information and will
be
re-posted at: http://www.globalintersec.com/adv/openssh-20020628 01.txt as soon as it becomes

available.

Note that the kbd-init flaw described in GIS2002062801 was proven to be exploitable in our lab
although not all evidence to demonstrate this was provided in the original advisory. A mistake
was made in the original advisory draft, where chunk content data was shown, rather than the
entire corrupted malloc chunk. This will be amended in the revision.

Also note that to our knowledge there are currently no known, exploitable flaws in OpenSSH 3.5p1,

due to its use of PAM as suggested by mmhs@hushmail.com. It is almost certain that the posted
bogus advisory was also intended to cause alarm amongst communities using OpenSSH, through
miss-information.

Global InterSec LLC.

--- end cut & paste ---

The original advisory I was talking about can be found here.

Sorry for misguiding you, humble slashdot readers.

Re:Talking about Linux security...

[Florian Weimer]

You guys should know that a trivial remote root hole for SSH was released today on bugtraq.

The posting appears to be a fake. (I wonder why your snake oil alerts didn't go off...)

Re:Real World Computer Security

[SuperDuG]

Who cares who has "dirtier" dirty water. Hell parts of Ol Miss can't even keep fish alive in it. There is a twang of high radition in some areas. And lets not even get into the amount of chemicals that are used to kill things (bacteria, insects, weeds, etc.) and then there's the industry and sewage run off in it.

It's hard to believe that something in the wonderful utopia of wonderfulness which is America can have something so dirty running right down the middle of it.

You think it's so clean?? I'll getcha a glass, and we'll see if you want to drink it, considering how "Clean" it is.

Too many services?

[pben]

I really think that this Toxen guy should quit spouting on about SuSE installing too many services by default. None of the services he complains about is installed by default. He needs to really download and install a Linux distribution that has been released in the last couple of years. You have to turn on the services now at least for SuSE 8.1. He may have written some good stuff in his day but he should do some research before he makes a fool of himself in print.

Honeypots are awesome.

[tkoney]

I had a very hard time convincing my manager to allow us to set up a honeypot on our DMZ. He said since no one could get there, what was the point. Three weeks later, when a hacker managed to break in via some badly written ASP programs (not my fault) it was the honeypot that send us the alerts that let us get him off our network.

Of course honeypots can also be used to learn what hackers do. The Honeynet Project is a great place to go to learn how to set one up securely so it can't be used to attack other people.

In fact, today a new version of honeyd was released:

As many of you already know, Honeyd is an OpenSource honeypot designed for the Unix platform. It has many featues, including the ability to monitor millions of IP addresses, detect activity on any UDP or TCP port, OS emulation at the user and kernel level, create virtual networks, and so on.

Marcus Ranum and I are big fans of Honeyd. To make it easier for people to work with and understand this technology, we took all the necessary ingrediants together and 'cooked' them up for you, creating the Linux Honeyd Toolkit. This toolkit is a ready to go distribution of Honeyd, with statically precompiled binaries, configuration files, and startup scripts. The idea being you just update the honeyd.conf file to what you want your honeypot to look like and let her rip.

Toxen's fear of Honeynets and Honeypots shows the "if I don't understand it, it's not good" theory I find in too many managers. He should take some time to run a honeypot or two and see how useful they can be.

OpenSSH server not run by OpenSSH crew

[Anonymous Coward]

The OpenSSH server is not run by the OpenSSH team, it's a university machine. Yes, it was broken into. It's running Solaris, not OpenBSD either, in case you're curious. They use it because it has bandwidth.

Naturally, you should check the pgp signature and/or cryptographic checksums before trusting any code you download.

There are still bugs in SSH.com's version - mostly stability, but I bet there are several security bugs too. OpenSSH will be updated several hours after new bugs are found - can you say the same for SSH.com's versions? I don't think so, not if history is a guide.

Re:Linux securty? Be more specific. Kernel | Userl

[octogen]

The userland software in question is: all of it.

No, only suid binaries. You don't hack into something which runs in the context of your own account (your own level of access).

Software that uses suid bit set will still be susceptible to leaving control to the "root" user after it crashes

That's the difference between a secure configuration of common OSs like Linux, Free/Net/OpenBSD,... and really secure OSs like VMS or Trusted Solaris (yes, Unix can be a really secure OS).

Secure OSs don't run things as root, they assign privileges to certain users and/or binaries instead. For example, you don't want to allow Apache to override the Discretionary Access Control when it actually only needs 'root' to open port 80.

On Trusted Solaris you just do 'setfpriv -m -a -f net_privaddr /usr/local/apache/bin/httpd' and noone would ever get something like root by hacking into your apache webserver.
That's how the 'principle of least privilege' works.

There is mainly one thing wich keeps your system secure: Access restrictions (users must not load kernel modules, mount disks, access files which they're not allowed to access, ...). But access restrictions can't protect your system from users/processes who are privileged to override these restrictions, and that's why you need fine grained privilege controls to build really secure OSs.

Wow. Another uneducated whitehat.

[mcroot]

Perhaps he should start by reading bugtraq. If he had, perhaps he would have seen this hole in ssh.com's lovely software in 2002.
http://online.securityfocus.com/bid/6247

Or, who can forget this unbeliavably idiotic mistake in their client from 2001
http://online.securityfocus.com/bid/3078

Yet he call's it more reliable that OpenSSH. Maybe he should look into the nice new privsep code in OpenSSH and comment on that. So called security experts make me wish public floggings were still a common event.