Google
Web BSDatwork.com
OpenBSD, OpenSSH, And Network Operating Systems
OpenBSD has finally been "forced" to change their famous catch phrase "Five years without a remote hole in the default install" to the phrase "One remote hole in the default install, in nearly 6 years!"
The statement is rather meaningless in either form. What does a UNIX type operating system DO as a default install? Yes, a firewall or some other minor function can be performed with the default system, and that default system is secure. That is great. However, the whole point of servers is SERVICES. If FreeBSD had deployed with zero services enabled by default for the past 5 years, they too would be able to say, "Five years without a remote hole in the default install!" It means nothing. The fact is people run Apache, Samba, OpenSSH, BIND, MySQL, etc, to actually make servers useful. While OpenBSD can quite fairly disavow any responsibility for exploits in any third party programs, the fact is if you honestly consider OpenBSD’s overall market share (not to knock OBSD’s market share), the number of default OpenBSD installations in "production" could probably be counted with an 8-bit number. A network operating system is responsible not only for its own behavior, but for maintaining a sane and secure environment for its services. Since we expect that a network operating system would not allow one service to modify another service’s memory (regardless that it is a function of the CPU/architecture), we also expect that an operating system would be designed such that a single service given some invalid input, should not compromise the entire system. Despite the claim that the problem lies with the services rather than the operating system, I submit that the design of the operating system is what allows the bad code in the services to be exploited in a useful fashion.
This fault is not limited to OpenBSD. It is a clear flaw in a majority of the network operating systems available today. Services are not sufficiently encapsulated from the host operating system, or from each other. Services should not be executed as the super user on a network operating system. This entire design has spawned a huge security industry that simply would not exist were it not for these obvious flaws in our systems.
When obvious design flaws are exposed and abused time after time, there is little interest in fixing the actual issues. How long have we suffered with architectures such as x86 that store the return instruction pointer on the local stack? How many millions of dollars have been wasted on stack overflow exploits and patches due to this design? How many people are making far too much money trying to find flaws in software that allow this design flaw to be executed? How much would it cost Intel and/or AMD to redesign the CALL/RET instructions to hide the return instruction pointer elsewhere (like branch registers or some hidden/reserved backing store)? Why aren’t certain string.h and stdio.h functions depreciated or removed? With automatic detection of GCC’s trampolines why can’t we all enjoy non-executable stack patches? How long must we endure programs that must be run, at least initially, as the super-user merely for the privilege of accessing ports 1-1023 or for the sole purpose of logging in common users?
OpenSSH attempts to answer part of the issue through privilege separation. Privilege separation is an excellent idea, but it doesn’t cover the entire super-user problem. Privilege separation involves the daemon forking, the child process using setuid to surrender its inherited root privileges, the child process encapsulating all network I/O and thus all of the risks, while the parent process handles the authentication and PTY activity. This is reasonable and secure. However, a superior design would allow user-to-user authentication (not involving root), and pre-configured non-superuser access to privileged ports. Under this design, OpenSSH could run initially as user "nobody." Due to the pre-configuration of the system, it would be granted access to the port 22. It would accept user logins, and use the login information in order to setuid to the specific user via a setuid API that required login/password information in order for the setuid to succeed. This would allow OpenSSH, and other such programs, to be free of root exploits permanently, because the services would never have root privileges in the first place. There needs to be a compelling reason to run any process as root. The complete package of security privileges that comes with super-user access makes it foolish to design the system such that super-user access is required in order to provide basic remote access functionality.
Kudos to the OpenSSH project for implementing a partial solution. However, the primary problem remains. Many services run as root. They may later surrender root privileges or spawn unprivileged children, but if the processes never had root from start to finish, remote root exploits would be nonexistent. The binary all-or-nothing privilege system of UNIX’s super-user must end.
Content Copyright © Original Author