SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   Application (Security)  >   OpenSSH Vendors:   OpenSSH.org
(Additional Information is Provided) Re: OpenSSH Allows Authorized Users to Delete Other User Files Named Cookies
SecurityTracker Alert ID:  1001684
SecurityTracker URL:  http://securitytracker.com/id/1001684
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Jun 5 2001
Impact:   Denial of service via local system, Modification of system information
Fix Available:  Yes  Vendor Confirmed:  Yes  
Version(s): openssh-server-2.5.2p2-1.7.2
Description:   A vulnerability has been reported in OpenSSH that allows an authorized user to delete any file on the file system if the file is named "cookies".

The author of the original report has provided the following information about the exact versions tested:

"Tested on:-

Red Hat Linux release 7.0 (Guinness)

[zen-parse@clarity zen-parse]$ rpm -qf /usr/sbin/sshd
openssh-server-2.5.2p2-1.7.2
[zen-parse@clarity zen-parse]$ ssh -V
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f

The configuration file has not been modified from the default settings.

Although sshd does drop root privileges, the processes groups are not
cleared. (From /proc/$$/status of the sshd handling the session, and the
output of strace and ltrace. (no use of initgroups in the ltrace output of
the process that creates the directory, although it does do change euid
before hand. there no setgroups in the strace output.))

There may be a race condition for writing the cookie file to any directory
that the groups root has if you can delete the directory and replace it
with a symlink before the file is created, but I haven't tested this.

The file itself is created with O_EXCL so a symlink in place of the file
cannot be used to create/overwrite arbitrary files.

On Redhat 7.0 it appears creation of a file called cookie could be
acheived in only a few places

/var/lock/subsys
/var/run/netreport
/mnt/cdrom
/mnt/floppy

and any of the world writable directorys."

Impact:   A local user can delete files named "cookies" in certain directories on the file system.
Solution:   The OpenSSH vendor (www.openssh.org) has reportedly created a patch for OpenSSH to address this issue.
Vendor URL:  www.openssh.org/ (Links to External Site)
Cause:   Access control error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry is a follow-up to the message listed below.
Jun 5 2001 OpenSSH Allows Authorized Users to Delete Other User Files Named Cookies



 Source Message Contents

Subject:  OpenSSH_2.5.2p2 RH7.0 <- version info


Sorry, I forgot some relevant information.

With regards to previous post:
Tested on:-

Red Hat Linux release 7.0 (Guinness)

[zen-parse@clarity zen-parse]$ rpm -qf /usr/sbin/sshd
openssh-server-2.5.2p2-1.7.2
[zen-parse@clarity zen-parse]$ ssh -V
OpenSSH_2.5.2p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f

The configuration file has not been modified from the default settings.

Although sshd does drop root privileges, the processes groups are not
cleared. (From /proc/$$/status of the sshd handling the session, and the
output of strace and ltrace. (no use of initgroups in the ltrace output of
the process that creates the directory, although it does do change euid
before hand. there no setgroups in the strace output.))

There may be a race condition for writing the cookie file to any directory
that the groups root has if you can delete the directory and replace it
with a symlink before the file is created, but I haven't tested this.

The file itself is created with O_EXCL so a symlink in place of the file
cannot be used to create/overwrite arbitrary files.

On Redhat 7.0 it appears creation of a file called cookie could be
acheived in only a few places

 /var/lock/subsys
 /var/run/netreport
 /mnt/cdrom
 /mnt/floppy

and any of the world writable directorys.


 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2022, SecurityGlobal.net LLC