Hacker News Reader

Ironically NTFS DACLs have an execute bit (on directories this allows traversal of the directory to reach a subdirectory you have permission to access, on files it controls execute). The kernel only enforces this on executables directly. Scripts are handled via user-space file extension associations.

Unfortunately the default inherited DACL on NTFS grants execute to all files, either via CREATOR OWNER, EVERYONE, POWER USERS, or ADMINISTRATOR.

Nearly all interpreters don't bother checking for execute, even though nothing stops Python, Wscript, et al from checking for execute before parsing a file. This probably comes down to a lack of #!-type mechanism on Windows, so there's no way to disambiguate between a script invocation and the user manually invoking the interpreter; you'd want to enforce +x for the former case but not the latter.

Like UAC vs sudo, culturally Windows simply didn't grow up enforcing these things so attempting to retrofit them causes tremendous pain and massive incompatibilities, despite the fact that the underlying system has robust support.

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

There are certainly some mitigating controls that make this a better story than what Windows implemented.

The malicious actor may have indirect access, or access via a web service that might give them limited ability to call a command or file. So in those cases, this framework can potentially make the complexity level of a vulnerability lower and the overall risk higher.

For now, I just limit binfmt and debugfs mounts so that regular users (especially service accounts) can't even access them. I think this only partially reduces the risk, since systemd acts as a proxy to binfmt. SELinux also reduce some risks, but so many people disable it that I can't factor that in.

/etc/fstab:

    binfmt	/proc/sys/fs/binfmt_misc	binfmt_misc	defaults,rw,noatime,mode=00500 0 0

    nodev	/sys/kernel/debug	debugfs defaults,noatime,mode=00500 0 0

There is probably a better way to disable this behavior, but I am working around many new features of systemd that are blurring the line between desktops and servers. The above also fixed several race conditions in systemd on hyper-v VM's that are considered low priority bugs.