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

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 20:28, David Wright wrote:

> On Thu 19 May 2022 at 15:42:33 (-0500), Nicholas Geovanis wrote:
>
>> On Thu, May 19, 2022, 3:14 AM 황병희 <soyeomul@doraji.xyz> wrote:
>> > Tom Browder <tom.browder@gmail.com> writes:
>> >
>> > > I need a special path setting for root after both "sudo" and "sudo
>> > > su." (...)
>> >
>> > Just you try like as "sudo su -". Sometimes i use it that way.
>> >
>> 
>> When I need to use sudo or su to invoke executables, I fully qualify the
>> path to sudo and the path to that specific executable by using their full
>> path from /. And I often assign values to the important environment
>> variables at the beginning of that same command line. Like...
>> 
>> joe="schmoe" slap="moe" /usr/bin/sudo ....
>> 
>> The idea is to draw a line around that invocation by limiting what it
>> "knows".
> 
> If you're running bash, then giving the full path for sudo will
> circumvent any aliases you've defined, and any other versions
> of sudo available from earlier in your $PATH, but there's not
> necessarily any security bonus. After Greg (2018):
> 
> $ 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:


$ type malicious
bash: type: malicious: not found
$ function malicious { echo "Not really, but..."; }
$ type malicious
malicious is a function
malicious ()
{
    echo "Not really, but..."
}
$ unset malicious
$ type malicious
bash: type: malicious: not found


It might look as if this could mean you could work around many possible
cases of malice by just issuing 'unset [command-name]' before any
command you're concerned about, but unfortunately, this same process can
be used to override 'unset' itself; I'm not going to reproduce the exact
commands and output here (mostly because I already closed that window
and I don't want to run through it all again), but a malicious actor
could just override 'unset' to something malicious and then you might
have no way of getting out of it within the running session.

(Such an actor could also override 'type' and 'set' and so forth to
something that would report the expected values, so even detecting that
this had been done could be difficult. Writing a shell function that
would behave "correctly" in that role could be difficult, and I
certainly don't intend to try to do it, but I don't think it would be at
all impossible.)

-- 
   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: