Quantcast
Username/Email:  Password: 

Apache and OpenSSH Vulnerabilities

Get your ounce of prevention now.

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

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Apache and OpenSSH Vulnerabilities

etbe's picture

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

Anonymous's picture

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

Anonymous's picture

For Red Hat Linux 7.2 Workstation Edition, none of these programs are started by default, unless specified.

RedHat?

Anonymous's picture

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

Anonymous's picture

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

Anonymous's picture

If you need additional functionality, that is.

Re: RedHat?

Anonymous's picture

I thought that was 2.0.29....

Re: RedHat?

Anonymous's picture

You wasted a thought...

http://httpd.apache.org/info/security_bulletin_20020620.txt

Re: RedHat? -- Backported

Anonymous's picture

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

whooper's picture

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

Anonymous's picture

I would give them a call -- 1-866-273-3428, X-45000.

Red Hat Security Advisory (please read carefully).

Anonymous's picture

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

Anonymous's picture

Adding to your 'Call to Action', should be constant/periodic checks to the CERT website.

www.cert.org

Post new comment

  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <pre> <ul> <ol> <li> <dl> <dt> <dd> <i> <b>
  • Lines and paragraphs break automatically.
  • Use to create page breaks.

More information about formatting options