Apache and OpenSSH Vulnerabilities
While our web site is not a security
warning site (we strongly recommend subscribing to your
distribution's security mailing list), we feel there are two
serious Linux security problems of which you should be aware, even
if you don't think your Linux box is a "server".Both Apache and OpenSSH have had remotely exploitable
vulnerabilities reported in the past week.If you don't know for sure if your Linux box runs Apache or
OpenSSH, you are at the greatest risk. We do not have space here to
teach you about your package management tool. All we can say is
take your system off the Net, learn how to check what you have
installed and either remove these packages or upgrade them. Many
Linux distributions come with services running "out of the box" and
don't tell users about everything that is present. Do not assume
that you're not running Apache or OpenSSH
unless you know for sure how to check.Please check your distribution's security page for an
upgrade, and either install it now
or, if for any reason you cannot upgrade, disconnect your systems
running Apache or OpenSSH from the network until you deal with it
or hire someone who can.Do not take our word for it. Never type anything as root
because you read it in some e-mail, even an e-mail with a
respectable From address. Go to the source you trust for Linux
packages.You probably haven't read about these Apache and OpenSSH
security problems on the mainstream news sites or seen them on TV.
Nobody's web site is being defaced, and no viruses are spreading
because of them. That's because in the world of free software, we
fix problems early instead of waiting for them to bite us.But these security holes will get some of us and show up in
the mainstream media, probably starting early next week. Exploits
are in the hands of a few people now and will be widespread within
days. If these exploits are built into a worm, there will be a
massive compromise of Linux systems everywhere very quickly. (An
already-built worm that's only waiting for a plugin exploit to arm
it could be out soon.)On Monday morning, a big dumb story will appear in the
Mainstream Media about how Open Source Security is Really Lame And
Nobody Should Run Linux Ever, along with comments from all the
proprietary OS vendors. There will be a screenshot of a defaced web
site, or worse. Do you want to smirk at the inaccuracies in the
story over your morning coffee, or do you want to spend Monday
morning replacing your Linux boxes with something else because it
was your web site?Linux isn't the most secure of the popular OS choices because
it's naturally secure; it's secure because we fix things before
it's too late. Fix your systems now.Call to Action
- If you don't know how to make security fixes on
your Linux systems or do not have permission to do them, remove the
systems from the Net until you or someone else can fix them. - Check your distribution's security updates page for
new Apache and OpenSSH packages. Install them. - If you're not on your distribution's security
mailing list, subscribe now. - If you built Apache and OpenSSH from source, get
the new versions and install them. Don't forget to replace the
"spare" or "emergency" static sshd you might have running on a high
port.
Don Marti is technical
editor of Linux Journal.
email: dmarti@ssc.com










This week 5 lucky Members will receive a copy of The Official Ubuntu Server Book by Benjamin Mako Hill and Linux Journal's very own Kyle Rankin. No entry necessary. Check back here early next week to find out who the lucky Online Members are.




Comments
Re: Apache and OpenSSH Vulnerabilities
After the recent SSH vulnerability a change was made to the default security policy for NSA Security Enhanced Linux.
The change is to deny the sshd daemon access to run programs in the "sysadm_r" role (the role for system administration) or the "sysadm_t" domain (the domain that gives full administrative access).
This means that on a default SE Linux install you have to change roles (which requires entering your password) before doing any administrative work after logging in via ssh. So an attacker who exploits a SSH hole can not get administrative access unless they trojan the sshd and wait for a password to be entered. This doesn't completely stop ssh holes from being exploited (that is impossible given the nature of the program). However it does mean that if a server is left idle an attacker can't gain full admin rights from a ssh hole.
Russell Coker
Re: Apache and OpenSSH Vulnerabilities
All we can say is take your system off the Net, learn how to check what you have installed and either remove these packages or upgrade them.
Of course, it's awfully hard to download the latest versions of Apache and OpenSSH while your computer is off the net ;) Likewise, if a user doesn't have a printed manual, they might look to the net for information on how to remove packages.
For new Linux users: here's a way to stop Apache and OpenSSH from running while you either get new packages, or read about removing them.
Step 1: Open up a terminal window by running kterm, gnome-terminal, xterm, or some other terminal program. There should be an icon for one of these programs in your program menu.
Step 2: At the terminal prompt, type "su". At the "Password:" prompt, type in your system's root password, and press "Enter".
Step 3: In the terminal window, type "killall httpd" and press "Enter". This will shut down the Apache program.
Step 4: Type "killall sshd" in the terminal window and press "Enter". This will shut down the OpenSSH server.
If you get a message like "httpd: no processes killed" or "sshd: no processes killed", that just means that you weren't running Apache or OpenSSH, respectively. If you get both messages, then you weren't running either Apache or OpenSSH. You should still upgrade or remove both programs, though.
If Apache or OpenSSH were running, then they will start running again the next time you boot up your computer, unless you get rid of them or disable them. Make sure you deal with them before turning off your computer!
Re: Apache and OpenSSH Vulnerabilities
For Red Hat Linux 7.2 Workstation Edition, none of these programs are started by default, unless specified.
RedHat?
I can only find a RedHat update to 1.3.22 while the Apache site recommends 1.3.26. Am I missing something?
Re: RedHat? from 1.3.22 to 1.3.26
yes, it seems that you have to compile the new version 1.3.26
Stiv
Re: RedHat? from 1.3.22 to 1.3.26
If you need additional functionality, that is.
Re: RedHat?
I thought that was 2.0.29....
Re: RedHat?
You wasted a thought...
http://httpd.apache.org/info/security_bulletin_20020620.txt
Re: RedHat? -- Backported
Redhat says they have "backported" the patch.
I wonder what is the point of this. Why not just release the latest version from Apache? They did the same thing with OpenSSH I think. Anyone have an idea why RedHat is doing this?
Re: RedHat? -- Backported
They do this so that you can have the security fixes without a big disruption of services. For example, I use Apache 1.3.22 with mod_perl and php. Since Redhat backported the fix, I didn't have any trouble having to re-install or rebuild anything to make it work. It is just a drop-in replacement and I'm secure from this bug.
It helps for the people that have a "go with what you know" mentality. No need for the added features so why change versions?
Re: RedHat? -- Backported
I would give them a call -- 1-866-273-3428, X-45000.
Red Hat Security Advisory (please read carefully).
From Red Hat:
Updated Apache packages fix chunked encoding issue
Advisory: RHSA-2002:103-13
Last updated on: 2002-06-19
Security Advisory
Details:
The Apache Web server contains a security vulnerability which can be used
to launch a denial of service attack, or in some cases, allow remote code
execution.
Versions of the Apache Web server up to and including 1.3.24 contain a bug
in the routines which deal with requests encoded using "chunked" encoding.
A carefully crafted invalid request can cause an Apache child process to
call the memcpy() function in a way that will write past the end of its
buffer, corrupting the stack.
The Common Vulnerabilities and Exposures project (cve.mitre.org) has
assigned the name CAN-2002-0392 to this issue.
Our investigations show that this bug cannot be used to gain remote access
to a server running Apache on Red Hat Linux on 32-bit platforms, but it
does cause the child process to die. The Apache parent process will
notice this and start a new child process when necessary -- using more
resources than normal.
Investigations by the Apache Software Foundation show that in some cases
64-bit platforms may have a greater exposure and could be remotely
exploited to allow arbitrary code to be run on the server.
We have backported the security fix from the official Apache 1.3.26
release. This should help minimize the impact of upgrading to our errata
packages.
All users of Apache should update to these errata packages to correct this
security issue.
-----
FIX: http://rhn.redhat.com/errata/RHSA-2002-103.html
Re: Apache and OpenSSH Vulnerabilities
Adding to your 'Call to Action', should be constant/periodic checks to the CERT website.
www.cert.org
Post new comment