Re: OSF & SCO potential security problems

[watt () sware com (Charlie Watt)]

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