You don't have to give up the convenience of it if you don't want to.
If you're using zsh, it has the "command_not_found" option, which will be triggered for shell commands that aren't found, but won't be triggered for subcommands or non-interactive shells.
If you add the following as your command not found handler, you'll be able to keep on typing "a.out" instead of "./a.out" without the security issue.
The point is that you don't want this convenience, implemented in any way. You want to be sure that all the invocations of stuff like `ssh` or `sudo` or even plain `cat` would actually come from your OS userland, and not some executable that happens to be in the current directory.
With this, it's only run from cwd if there is no "ssh" in PATH. It's basically the same as putting "." at the end of the PATH though.
Putting "." at the start of PATH is probably not a good idea (and probably also not very convenient), but putting it at the end should be mostly harmless for most desktop users.
It's better than putting '.' at the end of your path though, because your PATH is inherited by non-interactive processes (like the compiler run by 'go get'), while command_not_found is only for your interactive shell session.
The vulnerability this post is about is one where command_not_found is safe, but a '.' at the end might not be (if you don't have 'gcc' installed, but the malicious repository you 'go get' included a 'gcc' executable)
What's the point of this? The original vulnerability was "I execute an untrusted binary because my shell searched an untrusted directory". Isn't this just reimplementing PATH and still subject to the same vulnerability?
The vulnerability was that 'go get github.com/malicious/go-repo' would execute arbitrary code if that repo had a specifically named executable file in it.
A user's interactive terminal having certain conveniences is different, and the command not found handler is only used in an interactive context.
Yes, if a user types "pwnme" in their terminal in a directory that has a malicious executable from the internet named "pwnme", they're owned. Same as if they type "./pwnme" without the command not found handler.
It doesn't really change anything; you have to be aware of what you're typing and what it'll do at an interactive terminal.
The go one is a vulnerability because 'go get' is supposed to have a contract that it can't execute arbitrary code, while an interactive terminal that a user types text into doesn't necessarily have that contract.
Also, it will try the path _first_ before command-not-found, so most forms of this vulnerability (a file named 'ls' or whatever) won't cause a vulnerability with this helper variant.
If you're using zsh, it has the "command_not_found" option, which will be triggered for shell commands that aren't found, but won't be triggered for subcommands or non-interactive shells.
If you add the following as your command not found handler, you'll be able to keep on typing "a.out" instead of "./a.out" without the security issue.
Bash has a similar mechanism (command_not_found_handle) as well.