Hacker News Reader

Comment by amluto | Hacker News Reader

It’s not just the X bit —- unixes also don’t implicitly put the current directory in the path.

In a GUI environment that's irrelevant. People can double click any file and the graphical shell will execute the file by its absolute path.

Nautilus (Gnome) recently removed that behavior

https://gitlab.gnome.org/GNOME/nautilus/commit/3a22ed5b8e3bb...

mount -o remount,noexec /home?

I'm curious what advantages that brings for security since executables can still be called via relative (./) and absolute paths.

The biggest advantage that immediately springs to mind is writable directories included in PATH but even there some Linux distributions do include ~/bin in their users PATH. Thankfully PATH is an order of precidence and ~/bin comes last negating the ability for a script in ~/bin from "overwriting" /usr/bin/ et al. (ie `~/bin/sed` wouldn't become the default sed). I believe in Windows - though I'm not in a position to check - also places the working directory as last precidence when checking for instances in PATH.

There maybe some other vulnerability I am completely unaware of though but that's what I've experienced when messing around with Windows

It's presumably easier for an attacker to get a malicious ls binary into some local directory and convince a privileged user to execute ls there than putting a malicious ls binary into /usr/bin.

Yeah, I already covered that point re writable directories in PATH (though maybe I wasn't all that clear?). But in your specific case you need the additional process of getting the privileged user to change to that directory as well and for there to be no executables with the same name in another directory in PATH with a higher precidence. By which point it's easier to just getting said administrator to just run an executable via its absolute path rather than social engineering it into PATH

To those that modded me down, I'll explain my point bit better: the order of precidence I was referring to is the individual directories that appear in the delimited PATH environmental variable. (Semicolon delimited in Windows, colon delimited in Linux / UNIX).

In both Windows and Linux the directories that appear earlier in the list in PATH get priority over those that appear later. So if you have the PATH that says

    /bin:/home/laumars/bin

Then any executables named 'sed' in my home directory's bin folder would NOT become my system default sed utility so long as an executable named 'sed' also existed in /bin. However if I swapped that order around:

    /home/laumars/bin:/bin

now my home directory's bin folder DOES become the first place the system looks for executables.

Windows also applies this order of precidence to its PATH variable.

This is why I believe having a writable localised directory in PATH is a relatively mitigated attack so long as the PATH variable is set correctly from the outset. Sure you could plonk a randomly named executable and get that called as there isn't any overriding executables higher up in the precidence, but then you need some way of launching that irregular file name - by which point your attack might just as easily use a relative or absolute path to the executable, sidestepping the need for a targeted attack against the machines specific PATH hierarchy in the first place.

One thing I didn't mention in my previous post but is worth noting is that on Linux, any zero length paths in PATH will be expanded to current working directory. This could be either two adjacent colons ( /bin::/usr/local/bin ) a prefixing colon ( :/bin ) or preceding one ( /bin: ). This can be really easy to miss if you build up PATH through other variables. Eg

    export PATH=$PATH:$GOBIN

Where you've forgotten to define GOBIN before appending it to PATH (ie GOBIN will return "")

So it is worth being extra careful how you're building up PATH when using variables

Reply on news.ycombinator.com