4 ms·
Interesting point - one I hadn't considered. While I'm not trying to discount your valid concerns, Linux does have one other thing in it's favour and that is th
by laumars 8y ago
Interesting point - one I hadn't considered. While I'm not trying to discount your valid concerns, Linux does have one other thing in it's favour and that is that files still need an executable bit to be set in order for binfmt_misc to even get called. Whereas on Windows the only requirement for something to be executable is the file extension to have an association with an interpreter. So on Linux you wouldn't have the same default behaviour because that executable bit isn't set by default.
Moreover, if you can get around that executable bit problem then you're no worse of with binfmt_misc than you would be without since you could legitimately create a text file called "cat.jpg" with a Bash shebang and that would launch Bash in the same was a somescript.sh might.
Of course, you could take things one step further and say if a malicious actor has access to your system then they might get around the execution bit problem by just calling the interpreter directly (eg "bash somescript.sh" or the /lib64/ld-linux-x86-64.so.2 /bin/sleep 30 example in the article). But that requires the actor has remote code execution rights rather than just permissions to write to the file system. And honestly by that point you've already lost the game anyway.
- amluto 8y agoIt’s not just the X bit —- unixes also don’t implicitly put the current directory in the path.
- pilif 8y agoIn a GUI environment that's irrelevant. People can double click any file and the graphical shell will execute the file by its absolute path.
- laumars 8y agoI'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
- jupp0r 8y agoIt'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.
- laumars 8y agoYeah, 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
- deleted 8y ago[deleted]
- laumars 8y agoTo 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
- xenadu02 8y agoIronically 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.
- LinuxBender 8y agoThere 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.