• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 928
  • Last Modified:

OPENSSH Vulnerability

One of the security tool has generated reports for our production system which is RedHat Linux 2.1 installed on it.

The error in question is :

OpenSSH may be vulnerable      CVE-2003-0693

Vulnerability

http://www.cert.org/advisories/CA-2003-24.html 

Overview

A "buffer management error" in buffer_append_space of buffer.c for OpenSSH before 3.7 may allow remote attackers to execute

arbitrary code by causing an incorrect amount of memory to be freed and corrupting the heap, a different vulnerability than

CVE-2003-0695



Till now I was trying to upgrade the openssh package to openssh-3.7.Now the only solution to this vulnerability is to upgrade

or apply patch.Upgradation , is creating N no. of dependancies...which we are reluctant to go ahead with.
Also up2date requires valid subscription to redhat ?? Please comment on this.

Solution I have found on Internet somehow:

http://www.openssh.com/txt/buffer.adv 

Now the above patch needs to be applied (and my long awaited problem can be resolved ..atleast I hope so).
But now the problem is how to apply it in the system?? When I referred to this link , found that its a some kind of C- code.
How to apply the above path ?
Can you help me in this case ??
0
harmsingh
Asked:
harmsingh
  • 7
  • 7
1 Solution
 
ezatonCommented:
RH2.1 is still bound by RedHat's security advisory. It means that if your system is up to date, RH should have back-ported the fix to your current running version.

Security scanners check by a version-to-vulnerability tables contained in them. Only a monir number of such tools actually attempt to use the security hole to penetrate your system. If your system is up to date, these tools will not be able to use the hole, as it doesn't exist in the backported version you have.

All this - assuming you have an up2date account in RedHat for the machine and that you update it on a regular basis.

Mind you that RH2.1 is an old system, and you should consider an upgrade.
0
 
harmsinghAuthor Commented:

 All said and done. We have never used up2date. Its very unlikely that the system is up to date.
Now my first question is do we need to have official subscription from RedHat to use this tool?
 Becauze our subscription seems to be over recently.
Secondly the patch apply solution ..please comment on this.

0
 
ezatonCommented:
You need active RHN subscription to use up2date.

About compiling and patching - I do not recommend, under (almost) any circumstance, to install SSH from source on your system. If you want to do it anyhow, you will need to compile openssl and openssh downloaded directly from the relevant sites http://www.openssl.org/ and http://www.openssh.com/ , download the latest source packages, and start to compile following the INSTALL text. However, from what it seems to me, you are not familiar with the procedure of compiling software for Linux, so I would not recommend you do it, or at least, try it on a non-production server somewhere, running a similar version of RH.
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
harmsinghAuthor Commented:

 I could install the SRPM's for openssh-3.7 on other systems. But for these (RH ES 2.1) , it panics giving many dependancies.....mostly glibc...Now should I go for upgrdation of GLIBC-2.3 from 2.2 (current)??
 I fear of spoiling the whole system. Hence I was trying to go for patch option.
 Or is there any settings which will harden ssh and will remove the vulnerability itself???
0
 
ezatonCommented:
You cannot install RPM for a different version of system on your system. You do not want to upgrade GlibC, because you will probably break the system to bits.
You can do one of the following:
* Download srpm from RedHat for a newer version, and compile it using rpm --rebuild command which will attempt to compile it on your system and will, if successful, leave an RPM files inside /usr/src/redhat/RPMS/i386/ directory.
* Download RH's RPM using your RHN account from here: http://rhn.redhat.com/errata/RHSA-2003-280.html (you need to login and search for that RHSA. There you will be able to download the package).
* To avoid using RPM, and compile your own openssh package.

Notice that although Redhat's package version is old, it has been patched with the security fixes for the latest threats (it's called back porting)
0
 
harmsinghAuthor Commented:
When I did try to install using
rpm -rebuild  openssh-3.5  
it came out giving following error.

:
:
:
mv -f x11-ssh-askpass.man.tmp x11-ssh-askpass.man
rm -f x11-ssh-askpass._man
ln -s x11-ssh-askpass.man x11-ssh-askpass._man
+ popd
/usr/src/redhat/BUILD/openssh-3.5p1
+ gtk2=yes
+ pushd contrib
/usr/src/redhat/BUILD/openssh-3.5p1/contrib /usr/src/redhat/BUILD/openssh-3.5p1
+ '[' yes = yes ']'
+ make gnome-ssh-askpass2
cc `pkg-config --cflags gtk+-2.0` \
        gnome-ssh-askpass2.c -o gnome-ssh-askpass2 \
        `pkg-config --libs gtk+-2.0`
/bin/sh: pkg-config: command not found
/bin/sh: pkg-config: command not found
gnome-ssh-askpass2.c:52:21: gtk/gtk.h: No such file or directory
gnome-ssh-askpass2.c:53:22: gdk/gdkx.h: No such file or directory
make: *** [gnome-ssh-askpass2] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.6776 (%build)
RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.6776 (%build)



What now ??
0
 
harmsinghAuthor Commented:
One more update ...I followed the redhat link (http://rhn.redhat.com/errata/RHSA-2006-0698.html) you poset. And accordingly updated our system with  openssh-3.5p1-21 Source RPM.
I could managed to isntall the same. But unfortunately the tool still shows the same vulnerability.
I searched on google, it says that we need to upgrade it to openssh-3.7  for the vulneraibility to get vanished.
Does it mean I should install openssh-3.7 SRPM now ??
Please suggest?
0
 
ezatonCommented:
No. The security tool shows that your version number is known to be problematic. Redhat DO NOT CHANGE VERSION NUMBERS even when they patch a package to solve new security risks. Redhat's ssh version 3.5p1 will remain with this version untill the end of RH2.1 life. It includes, however, the patch which solves the security threat which the tool shows.

This is how Redhat works. The tool, however, has a table to compare version<->security holes. It sees version 3.5p1 and doesn't attempt to analyze it any further, and thus reports is to be dangerous. It is not. If you check the link you supplied at first, http://www.cert.org/advisories/CA-2003-24.html and browse in the page to appendix A, you will be able to find a direct link for Redhat's security advisory which deals with the hole you have reported. This advisory supplies a package which solves this security hole WITHOUT CHANGING VERSION. Do you see it now?
0
 
harmsinghAuthor Commented:

 Hi ,
 
ezaton : I was late to check your last message . Meanwhile I have gone further. Please see below.

 Now the update ...could be last one. I could manage to upgrade the openssh to 3.7p2 version using tar.gz package (downloaded from openssh.org) .
 I compiled the tar ball and installed it (configure , make , make install). It was all fine. When I checked using ssh -V , it shows the proper upgraded version as 3.7p2.
 Now my questions,

1. How can we be sure that now the system will use upgraded version of ssh and not the previously (RPM) installed ssh version (3.1p1).
      I mean if i do rpm -qa | grep ssh it still shows ,older  3.1p1 version of ssh. But ssh -V gives me upgraded version(3.7p2). Is there any way to tell
       that the system is not using RPM version but using compiled ssh version ??
2. Secondly , all these efforts were done to make the SSH non-vulnerable from the security tool point of view. But when i rerun the tool , its still giving the same vulerability alert(WHICH IT SHOULD NOT AS  SSH VERSION 3.7P1  DOES NOT CONTAIN THE SAID VULNERABILITY ). When I checked the logs and surprisingly found that the tool is still degtecting older (RPM) ssh version to be 3.1p1 (and not ssh-3.7p1)and hence its still giving the same vulnerability.
       So above both points lead to same question , is there any way to reflect the upgradation changes done(by compiling the 3.7 package) at the system level?
      Or shall I simply remove my older ssh 3.1p1 RPM package from the system?? Is this the proper way ? Will it help me ?? Or it will simply crash my working ssh in production system??

Please suggest.
0
 
ezatonCommented:
Your method is incorrect. The package management includes a record of installed-by-rpm packages. It is unaware of any manually installed packages.
Run on your ssh source package the command "make uninstall" and reconfigure it using the parameter --prefix=/usr
It will overwrite the existing ssh server (same PATH and locations) and will leave you with the startup scripts used by the RPM.
Removing the RPM will remove the startup scripts as well, and your SSH will not start automatically.

As I have tries to stress before, you are replacing a non-vulnerable package just because the major version is old, you don't understand RedHat's  package baseline, and your security tool reports incorrectly.
If I may add - you have an almost 7 years old system, with hardly any update. You have much larger security holes to worry about.
0
 
harmsinghAuthor Commented:
In case I want to use the new path of ssh then  the sshd daemon path in /etc/rc.d/init.d is stil using the older path i.e.
 Contents of /etc/rc.d/init.d
    KEYGEN=/usr/bin/ssh-keygen
    SSHD=/usr/sbin/sshd

Whereas the new path where ssh is residing is actualyl /usr/local/bin/ssh-keygen and /usr/local/sbin/sshd

So if I simply change these locations manually ...and then restart sshd ..will it help?

0
 
ezatonCommented:
Do not change locations.
Move (mv) the old version of ssh files to file.old in the same directory, and use ln (symbolic link) to link the files in /usr/local/sbin and /usr/local/bin to /usr/sbin and /usr/bin accordingly.

Or, as I have said before, recompile with --prefix=/usr for your configure script.

Or, as I have also said before - understand that your sshd is already patched against the security hole describes, and stop trying to replace sshd.
0
 
harmsinghAuthor Commented:
I did install using --prefix=/usr  option. Then when I tried to restart sshd using service sshd restart,
sshd failed , giving following error :
Privilege separation user sshd does not exist

Please note that now sshd is not running on this system.

Are you aware of this error? Whats missing here ........ :(
0
 
ezatonCommented:
Check if you have a user called sshd ( grep sshd /etc/passwd ). If not, add the user using this command:
useradd -u 74 -d /var/empty/sshd -s /sbin/nologin sshd
And then try to restart the sshd service.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 7
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now