“This paper discusses the security implications of Mach being integrated with the Mac OS X kernel. A few examples are used to illustrate how Mach support can be used to bypass some of the BSD security features, such as securelevel. Furthermore, examples are given that show how Mach functions can be used to supplement the limited ptrace functionality included in Mac OS X.”
I copy/paste the code of slevel and compile it.
Here what I got when I launch it as a simple user:
“./slevel -1
[!] error: requires root.”
And after reading again this document, I discovered that all “exploits” must be launched as root.
Well, I don’t need to develop anything nor to use any proof of concept if I want to hack a Mac where I am logged as root …
Edited 2006-06-10 16:56
Securelevels are supposed to be able to protect certain things from tampering even from the root user.
Moreover, the more general idea of the article is to show that exploiting the layering of Mach and BSD provide a vector for security attacks against the OS. This is an extremely important point. Mach was designed with a security model that wasa reasonably sound. So was BSD. However, that does not necessarily mean that the combined systems’ model is sound.
You need to understand the purpose of securelevels to understand this article, and you obviously dont. The BSD Securelevel implementation really only serve one useful purpose, it makes it possible to keep the root account from performing certain activities. The scope of these activities is very narrow (primarily writing to a mounted filesystem) and is honestly of limited usefulness, but regardless that is what it is for.
So saying that the requirement to be root in order to reduce securelevel settings makes this exploit silly is missing the point. If you are a sysadmin and you are intending on implementing BSD securelevels, the one and only one account you care AT ALL about securing against is root, otherwise you wouldnt even bother. There is no point at all in raising the kernels securelevel if it is possible for ANY account to then lower it. Lowering the kernels securelevel is intended to simply be IMPOSSIBLE.
As such the article is in fact giving out some quite useful information, namely that OSX users should consider their kernels implementation of securelevels to be completely broken and not trustworthy AT ALL. I.e. dont use it. Does this affect alot of people? No, not at all. But it is still noteworthy I think.
Well, I don’t need to develop anything nor to use any proof of concept if I want to hack a Mac where I am logged as root …
The first bypass which we will look at is the “kern.securelevel” sysctl. This sysctl is used to restrict various functionality from the root user. When this sysctl is set to -1, the restrictions are non-existent. Under normal circumstances the root user should be able to raise the securelevel however lowering the securelevel should be restricted.
The chroot() call is a UNIX mechanism which is often (mis)used for security purposes. This can also be bypassed using the Mach API/functionality. A process running on Mac OSX within a chroot() is able to attach to any process outside using the task_for_pid() Mach trap.
By using the task_for_pid() mach trap and passing in pid=0 the kernel mach_port_t port is available. Obviously, root privileges are required in order to do so.
How does this relate to:
However! Due to the fact that we can task_for_pid() pid=0 and write to kernel memory, we can bypass this.?
If one is root you don’t have to bypass anything.
From OpenBSD’s description of the securelevel feature:
This issue also directly subverts the system securelevel. 4.4BSD has a
facility called “securelevels” which adds restrictions to the kernel that
take effect only when a flag in the kernel (the “securelevel”) is set.
These restrictions include “immutable” files, which cannot be altered
(even by root), and “append-only” files, which can only have data appended
to. The former is useful for system binaries (to prevent attackers from
backdooring libraries and executables), and the latter is useful for logs
(to prevent attackers from covering their tracks by deleting log data).
The 4.4BSD securelevel features are active when the securelevel is
nonzero. The securelevel is set using the “sysctl” facility. The system
does not allow the securelevel to be lowered once it is nonzero; if
an attacker can lower the securelevel, she can evade securelevels
protections by turning them off.
The 4.4BSD kernel does not allow processes to write directly to kernel
memory when the securelevel is nonzero; this prevents “root” from
bypassing the securelevel simply by writing to “/dev/kmem”. This is
controlled by an access check in “sys/miscfs/specfs/spec_vnops.c”, which
provides vnode operations (open, read, write, etc) for special files (like
character devices).
Securelevels provide some protection to the system even in the case the attacker is able to compromise the root account. In order to provide this protection, BSD prevents even the root user from writing to kernel memory if the securelevel is greater than zero. What the article shows is that OS X’s underlying Mach kernel can be used to bypass this BSD protection feature.
Edited 2006-06-10 18:10
Securelevels provide some protection to the system even in the case the attacker is able to compromise the root account.
However, if I have root what is the point? You are hosed if I can get root. I own your system at that point.
No you do not. That in fact IS the point of running a system at a higher securelevel. If setup an implemented correctly, gaining root access to such a system wont let you do much of anything _permanent_ to it. There are lots of nasty non-permanent things you could do, but it would be impossible for you to actually comprimise the data on disk or in memory (well technically you could append false log entries for example, but you could not delete anything or alter existing data)
The catch is such a system is VERY limited in its usefulness, it cant do much of anything outside of acting as a webserver (or similar read-only function) that performs absolutely no disk-writes outside of basic logging.
One big thing securelevels let you do is keep a hacker who got the root account from erasing system log entries to hide their tracks. It also allows you to write-protect files so that even the root user can’t modify them. That’d provide some level of protection against, for example, defacement of a website.