Bugtraq mailing list archives
Re: OSF & SCO potential security problems
From: watt () sware com (Charlie Watt)
Date: Wed, 21 Dec 1994 10:47:41 -0500 (EST)
-----BEGIN PRIVACY-ENHANCED MESSAGE----- Proc-Type: 4,MIC-CLEAR Content-Domain: RFC822 Originator-Certificate: MIIBwDCCAWoCEQC43J7oZ50NWTRSVBShvvaXMA0GCSqGSIb3DQEBAgUAMFkxCzAJ BgNVBAYTAlVTMRgwFgYDVQQKEw9TZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNl Y3VyZVdhcmUgUENBMRcwFQYDVQQLEw5FbmdpbmVlcmluZyBDQTAeFw05NDA0MDUx NzA2NDJaFw05NTA0MDUxNzA2NDJaMHAxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9T ZWN1cmVXYXJlIEluYy4xFzAVBgNVBAsTDlNlY3VyZVdhcmUgUENBMRcwFQYDVQQL Ew5FbmdpbmVlcmluZyBDQTEVMBMGA1UEAxMMQ2hhcmxlcyBXYXR0MFkwCgYEVQgB AQICAgQDSwAwSAJBDNmUqe2+nqg6iuUWzxaXegxki426RzmVNO6VHHYCV4nbo/WL X9a7Jn/2nWqZUK/l+RXqCHU/21Ur9jFIt4GNHhcCAwEAATANBgkqhkiG9w0BAQIF AANBAEY6kP5jHqK9B9PhZCCJ9mckYuKMufWr7l61LulXGwUTqFzjFC0MOYwXo5s+ 8lqrLQ7YpTzyE74pKR1cl5TAUU4= MIC-Info: RSA-MD5,RSA, AM4CaXJzg1GybpwYhGOTjv8a9e6MGgSliPpS9AMFl3CrA5gh0BRSVDpdHNCfo0IM KJxOyLH+eikjWxsIEUQpvo0= X-Sensitivity-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED X-Information-Label: 1,CMW+3.0/SCO_2.1/sware.com,UNCLASSIFIED I've been too busy lately to keep up with bugtraq on a real-time basis, so this is pretty delayed. Darren Bock wrote on 12/12/94:
While this is old news to anyone that has been around the traps for a while it was interesting to see that DEC OSF V3.0 has repeated the mistakes of people like SCO by creating files that contain security information that are not owned by root.... Under OSF V3.0 there can be a small trap with the C2 security if you also use NFS 'Lionel Provost' (on the alpha-osf-managers () ornl gov list) said :But , if you have the C2 Security installed you could always modify /etc/passwd, it doesn't work because /etc/passwd is in yhis case a mirror of a database which is in /tcb/files/auth...This supposed security setup is a bit like what SCO did when they started using (in)secureware. The one minor problem with the method used to implement this idea is that root no longer owns these files. If you are silly enough (or by mistake) to allow your "/" filesystem to be NFS exported it is fairly trivial for anyone to give themselves root privs on your system (in this C2 setup). I have seen people with SCO systems allow unrestricted NFS export on all their filesystems (including / and /usr). One particular person went on holidays and forgot his root password, I used this particular trick as an easy way to reset the root password, it took 3 minutes all up (quicker than a reboot off floppy)
Being from SecureWare, I feel the need to respond. The specific attack Darren mentions is quite accurate, and is unique to operating systems based upon SecureWare technology. The hole, however, i.e. being stupid enough to export your root filesystem, is common across all variants of Unix. If you are running Unix and you allow export of "/", it is trivial to gain root access to your system through any number of attacks -- even if you remap uid 0 to "anonymous". NOTE that on many older systems it is not sufficient to restrict export of "/" to read-only. Sun's NFS 3.X code had a bug in the rename operation that failed to check for read-only on the target path's export information. Most vendors missed this and incorporated it into their ports. Charles Watt SecureWare, Inc. -----END PRIVACY-ENHANCED MESSAGE-----
Current thread:
- OSF & SCO potential security problems Darren Bock (Dec 12)
- Re: OSF & SCO potential security problems Charlie Watt (Dec 21)