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

SecurityTracker
Archives


 


Category:   Application (Security)  >   OpenSSH Vendors:   OpenSSH.org
(Vulnerability Cause is Provided) Re: OpenSSH Allows Authorized Users to Delete Other User Files Named Cookies
SecurityTracker Alert ID:  1001688
SecurityTracker URL:  http://securitytracker.com/id/1001688
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): 2.9p1, 2.5.2p2, 2.3.0p1
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".

A user reports that the vulnerability is due to code invoked in the X forwarding of ssh. The user reports:

"If you try again, this time passing -X as a command line argument to the ssh client, you may find different results. Depending upon the user's combination of ssh_config and the server's sshd_config, this may or may not be (quickly) exploitable on your system. [1] Running ssh -X will create the /tmp/ssh-XXXXXXXX directory that is needed for the exploit."

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:  Re: SSH allows deletion of other users files...


On Mon, Jun 04, 2001 at 11:19:37AM -0400, David F. Skoll wrote:
> I could not duplicate this with OpenSSH 2.9p1-1 on Red Hat 6.2

David (and other bugtraq readers), we think we have found some
additional information that is important in tracking the source of the
problem.

The problem code is invoked in the X forwarding of ssh. If you try
again, this time passing -X as a command line argument to the ssh
client, you may find different results. Depending upon the user's
combination of ssh_config and the server's sshd_config, this may or
may not be (quickly) exploitable on your system. [1] Running ssh -X
will create the /tmp/ssh-XXXXXXXX directory that is needed for the
exploit.

Another thing to note: Solar Designer's Openwall patch for the 2.2.x
series of Linux kernels effectively prevents this exploit with a
kernel syslog entry similar to:

Security: not followed symlink of 5049.5050 by UID 0, EUID 0, process sshd:20264

The versions of OpenSSH we have found to be vulnerable are:
2.9p1, 2.5.2p2, 2.3.0p1

Cheers!


[1]: I seem to recall some changes in the X forwarding code in OpenSSH
recently (last year or so) that affects how the client and server
negotiate X forwarding, specifically that the sshd_config file may not
be able to prevent X forwarding, possibly depending upon the version
of sshd. It may have been the X client was not able to prevent X
forwarding, depending upon the version of ssh. Disabling X forwarding
in the configuration files may or may not disable this exploit.


 
 


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