On 12/15/19 12:57 AM, Andrew Parker wrote:
The privilege escalation comes after the PATH is changed.
Please clearly explain what you think the privilege escalation is.Changing the PATH does not change privileges. It likely changes which program gets executed.
The problem effectively is me, the developer. I run another program which escalates and inherits the PATH variable. That program then executes commands without specifying the full path to the binary.
This is why that it is best practice to put the full path to commands when when possible. Particularly in scripts.
Here's an exampleConsider Homebrew. The installation script calls sudo. The root shell inherits my user's env. Brew them executes numerous commands that can be intercepted. My system is now forever compromised.
I don't know about homebrew. But I do know that this is exactly why sudo scrubs (rebuilds) (almost all of) the environment as the target user and specifically does NOT copy it from the source user.
If homebrew, or more specifically the sudoers template allowing this, is going contrary to all sudo best practices that I've ever read. Sudo should be configured to thwart such an attack.
It's easy to argue that this is a homebrew issue. However what about the 100s if not 1000s of "reasonable quality" tools that do similar things. As a modern developer how am I supposed to handle this? Do I have to audit every tool I use before allowing escalation? That's maybe a reasonable argument as well, but that's a hell of an overhead. Then what about upstream dependencies? Just because I audited homebrew today doesn't mean it'll be good tomorrow. Do we expect every developer to do this? Not really. Even if I do this, do I expect that I'll remember or get it right every time? Not really.
This is one of the reasons that sudo templates specify which command(s), including the full path, is (are) allowed to be executed, likely including parameters.
Yes, it is the system administrator's job to do the auditing that you specify /if/ they care about avoiding the class of things you are asking about. Many ~> most do not. Or if they do aren't able to audit things for one reason or another.
So my view is that a defence in depth strategy is the best approach. A relatively cheap and simple change would, at least as far as I can see, potentially add a lot of benefit to a lot of people.
Remember that the PATH environment variable is a convenience. I can still specify the full path to a program and run it. So simply setting PATH and then making it read-only won't prevent a determined actor. It may be another picket fence to close and latch.
Aside: I believe in and advocate closing and latching as many picket fences as possible. But I do question the security value of what I understand to be discussed in this thread.
-- Grant. . . . unix || die
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature