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

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