Bugtraq mailing list archives
Re: Vulnerability in 4.4BSD Secure Levels Implementation
From: newsham () LAVA NET (Tim Newsham)
Date: Fri, 26 Jun 1998 08:41:01 -1000
Not propagating the immutable filesystem flag on an executable to its address space, as you suggest is the correct and documented behaviour, implies the following: - The syslogd daemon can be covertly compromised, so no useful information ever gets logged to the protected system logs. But at least no-one can modify the useless information.
Be smart, niall, syslog can only be compromised after the system has been compromised.
McKusick et al have this to say: Files marked immutable include those that are frequently the subject of attack by intruders (e.g., login and su). The append-only flag is typically used for critical system logs. If an intruder breaks in, he will be unable to cover his tracks. Although simple in concept, these two features improve the security of a system dramatically.
Since the intruder cannot reverse time, he cannot cover his tracks in the system log. Just as McKusick said! (wow, he must have known about the time thing too!)
Why do they advocate protecting login and su if such protection can be trivially defeated using the same techniques we demonstrated in the attack on inetd? And why do they claim these features improve the security of a system "dramatically" if they can be bypassed so easily? Either they didn't read the chflags man page (hmm, I think they wrote it), they advocate partial security (hmm, don't think so), or there is a bug. I believe the latter is the case.
Because protecting login and su will protect the persistant system. Yes, the running system may still be compromised. Securelevels does not address that issue. (perhaps your stance could be summed up as: "securelevels should protect the running system"?)
Propogation of the immutable flag is the logical and correct thing to do. I agree that this behaviour is not explicitly documented, however it is a reasonable expectation that people hold. Secure levels become a farce without it.
I can see why one might think this is desirable, but it's hardly the only obvious alternative. I wouldn't call securelevels minus this feature a "farce" (that is, if securelevels plus this feature isn't considered a farce as well :)
Niall
Tim N.
Current thread:
- Re: Full Armor.... Fool Proof etc... bugs, (continued)
- Re: Full Armor.... Fool Proof etc... bugs Alan Ramsbottom (Jun 12)
- SECURITY: new mailx packages now available Alex K. (Jun 12)
- Re: Full Armor.... Fool Proof etc... bugs Joseph Gooch (Jun 13)
- Re: Full Armor.... Fool Proof etc... bugs Florian Weimer (Jun 12)
- Solaris 2.6 non-executable stacks Dax Kelson (Jun 12)
- Re: Solaris 2.6 non-executable stacks Edward S. Marshall (Jun 14)
- Re: Solaris 2.6 non-executable stacks Casper Dik (Jun 16)
- Re: Solaris 2.6 non-executable stacks Edward S. Marshall (Jun 14)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Darren Reed (Jun 13)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation tqbf () pobox com (Jun 11)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Niall Smart (Jun 13)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Tim Newsham (Jun 26)
- check-ps 1.2 alpha 4 released Duncan Simpson (Jun 26)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation tqbf () pobox com (Jun 14)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Niall Smart (Jun 28)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Tim Newsham (Jun 28)
- Re: Vulnerability in 4.4BSD Secure Levels Implementation Roger Harrison ? (Jun 29)
- Serious Linux 2.0.34 security problem David Luyer (Jun 30)
- Re: Serious Linux 2.0.34 security problem Jim Bourne (Jun 30)
- QPOPPER - FreBSD, BSDI/OS remote exploit MiG (Jun 30)