Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


OPENSSH Vulnerability

Posted on 2007-07-23
Medium Priority
Last Modified: 2013-12-06
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




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


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:


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 ??
Question by:harmsingh
  • 7
  • 7

Accepted Solution

ezaton earned 500 total points
ID: 19546261
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.

Author Comment

ID: 19546594

 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.


Expert Comment

ID: 19547719
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.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Author Comment

ID: 19547858

 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???

Expert Comment

ID: 19548963
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)

Author Comment

ID: 19549120
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
+ 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 ??

Author Comment

ID: 19549394
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?

Expert Comment

ID: 19549815
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?

Author Comment

ID: 19553826

 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.

Expert Comment

ID: 19553975
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.

Author Comment

ID: 19554965
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

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?


Expert Comment

ID: 19558951
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.

Author Comment

ID: 19567249
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 ........ :(

Expert Comment

ID: 19567380
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.

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Linux users are sometimes dumbfounded by the severe lack of documentation on a topic. Sometimes, the documentation is copious, but other times, you end up with some obscure "it varies depending on your distribution" over and over when searching for …
It’s 2016. Password authentication should be dead — or at least close to dying. But, unfortunately, it has not traversed Quagga stage yet. Using password authentication is like laundering hotel guest linens with a washboard — it’s Passé.
Learn how to navigate the file tree with the shell. Use pwd to print the current working directory: Use ls to list a directory's contents: Use cd to change to a new directory: Use wildcards instead of typing out long directory names: Use ../ to move…
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
Suggested Courses
Course of the Month10 days, 16 hours left to enroll

571 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question