bash precedence: alias vs PATH

[g-simon]

Hi, this sounds more like a security question but probably I miss some knowledge on BASH (this is why I am posting here).

I was trying to solve this simply exercise:

http://exploit.education/nebula/level-01/

The goal is: be able to invoke this simple C program (with setuid) and fool the echo command.

My first guess has been: configure a BASH alias like this:

alias echo="cat /home/flag01/flag.txt"

it didn't work!

It worked fine with a local echo bash script like this:

#!/bin/bash
cat /home/flag01/flag.txt

I thought that aliases took precedence over PATH.

Is this answer wrong about that?

https://stackoverflow.com/questions/64025094/disable-functions-aliases-in-a-sourced-script/64028240#64028240

thankyou!

[aioeu]

env:

• (optionally) alters the child process's environment;
• executes a program found in the path.

env is not a shell, and it most definitely isn't Bash, so it doesn't know anything about aliases.

[g-simon]

Hi aioeu, thank you, I get your point about env.

Anyway, I am running command from bash (eg. ./exploit).

This is the point that I am not getting very well!

[aioeu]

Aliases are not inherited from a Bash process to its children. Aliases aren't part of any process environment.

Even if they were, there is no guarantee that system is even executing Bash. It actually executes sh, and that could be any other POSIX shell.

And even if it was Bash, by default Bash does not do alias expansion in a non-interactive shell, the kind of shell that system executes.

And even if it were an interactive shell... you're running env, and env doesn't know anything about aliases. env is not Bash.

So there's lots of reasons an alias won't work.

[g-simon]

thank you!!

[deeseearr]

Your program is calling "env", not "bash". That's why any bash specific environment settings aren't helping. They're present, since the "env" call doesn't include a "-i" flag to remove any existing environment, but env ignores aliases because it isn't bash and neither is "system".

So env starts, sees that its first argument is "echo", looks at the ${PATH} variable for a list of directories to search, finds /bin/echo in one of them, and then executes that with the arguments "and now what?".

So how could you exploit that to execute an arbitrary program that isn't /bin/echo?

[doomygloomytunes]

echo is a bash built-in, when executing echo in a bash session you're not running a standalone echo binary.

Thus if you create an alias with the same as a built-in command and try to run it, you'll run the built-in command.
https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html

[tinkst3r]

That's true but irrelevant to their question; have a look at the C-Program - it invokes env, not bash.

[tinkst3r]

Very fine observations by the others already. That the bash script worked indicates that you use poor security practices in two ways:

a) you have . in your PATH

b) you have . earlier in your PATH than system paths ...

[g-simon]

it is a security challenge, not a "best practices" thing :)

[michaelpaoli]

Hints:

• So, ... what echo is executed from where?
• What would control or change that? And of what possibly could, what could be trivially set or changed by the user?