[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Avoiding command hijacking in shells (was Re: setting path for root after "sudo su" and "sudo" for Debian Bullseye (11))



On 2022-05-20 at 21:20, Greg Wooledge wrote:

> On Fri, May 20, 2022 at 08:41:43PM -0400, The Wanderer wrote:
>
>> On 2022-05-20 at 20:28, David Wright wrote:
>>
>> > $ function /usr/bin/sudo { echo teehee; }
>> > $ /usr/bin/sudo whatever
>> > teehee
>> > $ 
>> 
>> A quick test demonstrates that this can be worked around via the 'unset'
>> command:
> 
> Until you define a function named unset.

Well, yes - that was the point of the paragraphs after the demonstration.

> But the real point here is that you should only use sudo or su (or
> doas or any other program that reads your password) from a trusted
> environment. What you definitely should NOT do is get called by a
> coworker, go over to their workstation, hear the description of a
> problem, and try to fix it from their computer, where they may have
> overridden su/sudo/etc.
> 
> Go back to your own desk first, and fix it from there.

I wasn't even thinking of it in those terms, although now that you point
it out that's a good thing to be aware of. I was thinking of it in terms
of A: trying to write scripts that are safe against such problematic
elements being in the environment, and B: being able to detect and
recover from some piece of malware having inserted such elements into
the environment on your *own* computer.

Which is also about only doing it from a trusted environment, I suppose
- just with even more stringent and depressing considerations about what
the limitations of trustability are.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: