local root ~= remote root
local root ~= remote root
Posted Nov 30, 2003 19:22 UTC (Sun) by ncm (guest, #165)Parent article: Debian.org compromise update
This is a good demonstration that the distinction always made between local privilege-elevation bugs and remote exploits is academic hair-splitting. It's rarely difficult to get unprivileged access through a buggy non-privileged service. (Web-server plug-ins are a reliable source of entry points.) Once you're in, privilege elevation takes you the rest of the way.
Certainly the distinction is useful to security students and analysts, but it's misleading for everybody else. "Oh, that one's just a local exploit; not so bad." The OpenBSD advocates promote the fallacy: "only one remote exploit in this millennium!" (or something like that), encouraging us to ignore almost equally damaging exploits in non-core services that provide access to local accounts and more damaging attacks.
There's a similar fallacy in distinguishing security holes from other bugs. Without a depth of analysis that hardly anybody can ever afford, almost any bug might actually be a security hole, too. The OpenBSD people get this one right -- to them, any bug is a security hole until proven otherwise, and they encourage running latest versions -- but almost everybody else gets it wrong. When I fixed a double-free segfault in lib[mumble], nobody posted security warnings about every program that relies on it. despite that double-free bugs can often be exploited.
Debian gets this wrong, and very selectively backports only proven security holes, ignoring the myriad bugfixes that might just as easily be security holes as well. To find holes in stable-branch services, just look for bug fixes in later versions, particularly in libraries used by those services. Failing that, look at new features added shortly before the library-version used. Chances are the last new feature added has bugs that haven't been noted yet, and that might be exploitable.
This might be a good place to mention that the CVS codebase is almost irreparably insecure. The practical implications are: (1) A remotely-accessible CVS server should never be run on a host that does anything else that matters, or that has access to anything else; (2) An anonymous CVS server should never be the same CVS server that is used for checkins, or even run on the same machine. The pserver should be a slave that only gets read access to a copy of the archive. (3) Checkins on remotely-accessible servers should result in patches logged to another archive kept on another, not-remotely-accessible machine. Patches from that server should be posted to the mailing list.
Posted Nov 30, 2003 20:29 UTC (Sun)
by mikesalib (guest, #17162)
[Link] (1 responses)
For most machines, the distinction between local and remote root exploits is far from academic. That is because most machines do not offer meaningful unprivelaged access to the wide area net. That includes most small group servers and almost all desktops. For that class of machines, a remote root vulnerability is a very real hazard while a local root hole is much less serious because only authorized users can get into the system anyway. My desktop is a classic example; the only people who have access to this machine are myself and one or two trusted friends. A remote root hole can take my machine down or turn it into a worm or spam spreading zombie so I pay attention to those. But I rarely worry about local exploits because I don't plan on exploiting my own box anytime soon. The truth is that most computers in the world are not used for classic Unix work where they have 200 relatively untrusted people logged in remotely doing all sorts of work. For such machines, there are lots of unprivelaged access paths and the distinction between local and remote root exploits is pretty silly. The debian servers definitely fall into that category. But it is important to understand that most computers on the net don't fall into that category. Bugfixing verification and testing takes a lot of time and effort, especially when you have to support 12+ architectures. Because Debian only pushes security critical updates, administrators can feel a lot more confident updating production machines without having to worry about an unecessary change breaking a system that does real work. Yes, if your machine is compromised you can't work, but if you're constantly breaking a working production system applying unneeded bug fixes that change functionality, you're not much better off. Either way you have unplanned outages. Debian made a judegement call on where they want to direct their limited (read: volunteer) resources and it looks like the right call to me.
Posted Dec 1, 2003 7:39 UTC (Mon)
by ken (subscriber, #625)
[Link]
You are very much mistaken here every bug is a potetial problem even for you. Take a bug in some media codec for xmms. Now someone could infect your computer by making you play some mp3,ogg(whatever) file. You must realise that any program that takes external data could be used to gain access to you computer it dose not have to be suid or a program litening to the network and once they got your account they hardly even need a local ecploit to gain root. A simple redirect on sudo or su would do it for most home computers. Still a remote hole is a big problem as the rate of infection is so great something that a local exploit is not.
Posted Nov 30, 2003 21:36 UTC (Sun)
by iabervon (subscriber, #722)
[Link]
Posted Nov 30, 2003 22:49 UTC (Sun)
by Ross (guest, #4065)
[Link]
Personally I run all services as non-root users chroot()ed to a directory (That's not to say I don't sometimes take additional precautions. For Except for kernel bugs I find it unlikely that a remote user could
Posted Dec 1, 2003 19:06 UTC (Mon)
by job (guest, #670)
[Link]
While I agree with a lot of what you say, I think you may be oversimplifying the situation.local root ~= remote root
As for Debian's refusal to port non-security bug fixes into their stable distribution, I think they've made the right choice. Every change carries with it the possibility of introducing new bugs, bugs that can themselves present new vulnrabilities. While some projects maintain bug fix only branches for stable releases, for other projects, the only way to get at some bugfixes is to update to the development version.
---local root ~= remote root
My desktop is a classic example; the only people who have access to this machine are myself and one or two trusted friends. A remote root hole can take my machine down or turn it into a worm or spam spreading zombie so I pay attention to those. But I rarely worry about local exploits because I don't plan on exploiting my own box anytime soon.
---
In some cases, the security issue is more remote user-level exploits; local root ~= remote root
it's reasonably likely that on a desktop, most of the significant
information could be read without priviledge escalation, and the box is
secured to avoid remote access to the machine at all. In fact, remote
access in general may be a narrower window to secure.
Of course, local root exploits are still significant, because more damage
may be caused by an attacker if they are available. Furthermore, it's
very hard to ensure the security of a remotely accessible user account,
so local root exploits only don't matter if there is no possibility of a
non-local user of any sort.
I agree with what you are saying in that people generally discountlocal root ~= remote root (it doesn't have to be)
local exploits as unimportant when they really are. However I disagree
that they all but guarantee remote root access.
with no executables or libraries and which is mounted with nosuid and
nodev and no proc mounted. (I wish that the kernel provided a way to
remove process capabilities, but it only allows to you give portions of
root access to non-root users. I know I could use LSM but that's getting
overly complicated.)
example my firewall has no suid or sgid executables.)
exploit a buggy service running as a non-root user in order to obtain
root access -- even with buggy userspace binaries installed.
I disagree. If you properly ACL your system with SELinux or its likes, the local root ~= remote root
privilege escalation part becomes extremely difficult.