9

Today I heard at Uni something that broke my mental model about separation of users' rights. Namely, I heard that:

I can freely debug all programs I have the permission to run, even those that have setuid set to root.

That means I can, for example, run su under debugger. I tried it and it worked:

gdb su

This is mind-blowing for me. May I present you my former mental model about users' rights management so that you can correct me where I'm wrong and explain to me how things really are?

Until today, I used to believe that:

  • Anything that runs under my user account is, by definition, "mine". That is, I can freely do anything what I want with such a program, in particular I can debug it, which entails I can read and modify all data such a program stores in its memory, or even patch it while it is running.
  • Programs with setuid set to other user - let's assume it's root, for the sake of simplicity - run with rights exceeding rights of my user account, but in return they're supposed to do only what they were designed to do: anything more and it's a security breach. Thus, these programs, while they can be run by my account, nevertheless run under the account that owns them - so from the POV of rights management, they run as if they were run by their owner - so I cannot read their memory or interrupt their execution, so that I cannot bend them to my will, so in particular I cannot debug them.

The second point is manifestly false. But, according to my (clearly wrong) mental model, this entails that, if I - for example - run su under gdb, I can trap the moment where su decides if the password is correct, modify this fragment of su's memory to force it to believe that the answer to this fundamental question is positive, then resume its execution and voila, I now have root rights. Well, binary authors might try to obfuscate their code to make this difficult, but a skilled and persistent person can always overcome this and this doesn't apply to su anyway since it's open source.

Where is my mental model wrong? Where is it at odds with reality?

gaazkam
  • 5,657
  • 11
  • 24
  • 38
  • I don't have time right now to offer a detailed answer but I'll briefly say...long story short if you can execute code on a box it is usually straightforward to get root (in much easier ways than messing with memory). – DarkMatter Oct 29 '18 at 21:46
  • @DarkMatter This defeats the purpose of multi-user systems, doesn't it? – gaazkam Oct 29 '18 at 21:48
  • 1
    @DarkMatter I mean its not necessarily practical or desireable to ensure that on a multi-user system (like the one at Uni, accessible by all students) no regular user can ever create a file with the `x` permission set! (how could Professors ask students to do an exercise in C or C++ otherwise?) By what You've written once they've created a file with the `x` permission set they're basically root. – gaazkam Oct 29 '18 at 21:53
  • 1
    https://webcache.googleusercontent.com/search?q=cache:efKwhGEiWiIJ:https://payatu.com/guide-linux-privilege-escalation/+&cd=1&hl=en&ct=clnk&gl=us <-- read this as an entry point into linux priv esc... – DarkMatter Oct 29 '18 at 22:01
  • @DarkMatter https://security.stackexchange.com/questions/196664/are-most-linux-systems-that-allow-non-root-users-to-execute-code-straightforward – gaazkam Oct 29 '18 at 22:52
  • 2
    @DarkMatter I'm sorry, but you are incorrect. You would need to exploit a novel vulnerability which, for most people, is not straightforward. This is evident simply by virtue of the fact that most people have _not_ designed their own LPE for the Linux kernel (such vulnerabilities, while not obscenely rare, are quite valuable and can even be sold for tens of thousands of dollars). – forest Oct 29 '18 at 23:08
  • @gaazkam You may want to read the `ptrace(2)` man page. – forest Oct 29 '18 at 23:09
  • @gaazkam See also https://unix.stackexchange.com/a/15912/277264 (cross-site dupe) – forest Oct 29 '18 at 23:15
  • @forest As per your link I can only gdb su when I'm already root. I tried running `gdb su` as a non-root user...and it worked. Im perplexed – gaazkam Oct 30 '18 at 01:03
  • 1
    @gaazkam _Worked_ meaning what, it simply ran? – forest Oct 30 '18 at 01:04
  • @forest Yes. And I could enter an incorrect password and read that the password was incorrect.... Guess now its my turn to try entering a correct password and see what happens – gaazkam Oct 30 '18 at 01:06
  • There doesn't need to be a novel kernel vulnerability just one of countless of vulnerabilities present... A cron job that is running with elevated permissions (either root, or any user with sudo priviledges) that isn't properly setup so that I can get it to run a piece of my code...any vulnerable service running with privilege... heck there are even attacks I can do against the hardware if I have code execution. I'm not saying you are guaranteed each of these things on every box but there is almost always at least one available. – DarkMatter Oct 30 '18 at 14:21
  • @DarkMatter Again, the implication of what you're saying is that if you're operating a multi-user system, you could just as well give all students root. – gaazkam Oct 30 '18 at 22:52
  • 1
    @DarkMatter You are describing the average live of the pentester. Yes, there are ways to attack many systems, either by exploiting improperly configured setups or by discovering a novel 0day. However, to say that it is _straightforward_ is patently false. – forest Oct 31 '18 at 02:35
  • @forest, in my world this is the reality (there is a way to root if you have code execution) much more often than it is not. By having this mindset, I can be sure to always include compensating controls for when the low level user gets root (without permission). If you live in a world where your systems are not vulnerable to privilege escalation then I am genuinely happy for you. However, I think for most of us it is a dangerous mindset to adopt. – DarkMatter Oct 31 '18 at 15:59
  • @DarkMatter What you are describing is a vulnerability in deployment and configuration, not a vulnerability in the Linux kernel (which is what manages the protections relevant to the question). – forest Nov 01 '18 at 06:51
  • @forest a valid distinction. Maybe I misunderstood the thrust of the question. Sorry for taking us down a rabbit hole. – DarkMatter Nov 01 '18 at 13:58

1 Answers1

15

Normally, when su runs, it runs setuid (as root). When you start it with gdb, the setuid bit doesn't take effect (because it's being ptraced), so even if you convince it that you entered the right password, it won't have permission to actually give you a new UID. The reason for this is to mitigate the exact attack you describe.

Joseph Sible-Reinstate Monica
  • 7,224
  • 3
  • 22
  • 35