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?

Improve this question
17
  • 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
    Commented Oct 29, 2018 at 21:53
  • 1
    webcache.googleusercontent.com/… <-- read this as an entry point into linux priv esc...
    – DarkMatter
    Commented Oct 29, 2018 at 22:01
  • 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
    Commented Oct 29, 2018 at 23:08
  • 1
    @gaazkam Worked meaning what, it simply ran?
    – forest
    Commented Oct 30, 2018 at 1:04
  • 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
    Commented Oct 31, 2018 at 2:35

1 Answer 1

Reset to default
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.

Improve this answer
2
  • What if you started su without gdb, attached to it's pid, and manipulated it like this?
    – fzgregor
    Commented Oct 31, 2018 at 0:58
  • 2
    @fzgregor If it starts normally (setuid root), gdb itself will need to be running as root to be able to attach to it.
    – Joseph Sible-Reinstate Monica
    Commented Oct 31, 2018 at 1:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .