Re: Thoughts on protecting against PATH interception via user owned profiles

[Grant Taylor <gtaylor@tnetconsulting.net>]

[-- Attachment #1: Type: text/plain, Size: 3008 bytes --]

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 example
> 
> Consider 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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]