OPENSSH Vulnerability

Posted on 2007-07-23
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
    LVL 7

    Accepted Solution

    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


     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.

    LVL 7

    Expert Comment

    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 and , 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.

    Author Comment


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

    Expert Comment

    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: (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

    When I did try to install using
    rpm -rebuild  openssh-3.5  
    it came out giving following error.

    mv -f
    rm -f x11-ssh-askpass._man
    ln -s 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

    One more update ...I followed the redhat link ( 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?
    LVL 7

    Expert Comment

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


     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 .
     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.
    LVL 7

    Expert Comment

    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

    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?

    LVL 7

    Expert Comment

    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

    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 ........ :(
    LVL 7

    Expert Comment

    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

    Courses: Start Training Online With Pros, Today

    Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.

    Join & Write a Comment

    After running Ubuntu some time, you will be asked to download updates for fixing bugs and security updates. All the packages you download replace the previous ones, except for the kernel, also called "linux-image". This is due to the fact that w…
    SSH (Secure Shell) - Tips and Tricks As you all know SSH(Secure Shell) is a network protocol, which we use to access/transfer files securely between two networked devices. SSH was actually designed as a replacement for insecure protocols that sen…
    Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
    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…

    745 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

    Need Help in Real-Time?

    Connect with top rated Experts

    14 Experts available now in Live!

    Get 1:1 Help Now