Beginners' mistakes in Mac OS X
For well over twenty years, setuid programs have been a standard mechanism on Unix systems to execute specific activities with other rights than those of the user who is logged in. The security risk this poses and the minimal security precautions that need to be taken have also been known for just as long. However, word on this does not yet seem to have reached the developers of MacOS X. Thus the system settings use the writeconfig utility program, which as a Setuid root program always runs with the rights of the administrator. Among other things, it calls the shell script /sbin/service, which in turn starts launchctl. This procedure ignores and bypasses a number of basic and well-known security rules:
- You should not call up shell scripts in a Setuid context. This can almost always be exploited in some way to take over their rights.
- You should always sanitize the environment in a setuid context to prevent hackers slipping in their own programs via the path variable for example.
- Shell scripts used in an administrative context should always launch external programs with an absolute path name to ensure that an incorrect program is not launched accidentally.
- Setuid programs should be subjected to a special check since they are especially vulnerable.
In this case, a local program can achieve root privileges under Mac OS X by opening the system settings with a special path variable. Up until to now, it has not been clear whether this requires the cooperation of the user -- there are no demonstrations that work without, yet.
But that is secondary. What is a great deal more unsettling than the basic problem is the fact that such elementary security concepts were evidently not taken into consideration during the development of Mac OS X. What is truly alarming is that this problem escaped the notice of the internal quality control system. Because Setuid programs are the starting point for anyone looking for security loopholes to exploit in a system, they should be checked rigorously. And errors of this type are easy to track down. It is therefore highly likely that Mac OS X has more errors of the same type. A brief test by heise Security revealed that in any case writeconfig calls up three further shell scripts.
To protect yourself against this concrete problem, all you have to do is to insert at the top in /sbin/service a line such as:
to define a clean path variable.
- System Preferences writeconfig Local Privilege Escalation Vulnerability by LMH and Kevin Finisterre