i have a question about something i read in my linux book.. ill type out a quote from it:
i cant seem to comprehend it; why is it a threat? The example used in the book i think was (as i closed it just now and am really lazy ) "PATH=$PATH:."

could someone explain briefly how this could be a threat/exploited? also include your ip address, any opened ports and username + passwd please. thanks
..haha.. ok, jk about that.. but really, just wondering how this could be a threat?
thanks.

also, right when the above example command is executed, the . (dot) is read by the shell and immediately replaced with the current directory/pwd THEN saved in the path environment variable, right? like, if i use the above command then cd to someplace else, my now pwd isnt in the path variable right? ya.. ok i assume thast right, nevermind heh.

i wont ever be trying this command, i dont see myself ever finding any use for it, but i just read it last night and was wondering, thats all

I can see a threat if the hacked program/service wasn't chroot'd, because they would then know the present working directory, but being jailed would "jail" them into the chroot and shouldn't allow them out of it.

Other than that, I don't really understand the paragraph you quoted to be any more of a threat than normal.

In theory, an attacker may trick you into running a different binary than you think you were running, but if . is the last entry in your PATH then the risk is negligible. But if . is the first entry, it can be very dangerous (the following is a true story I read somewhere):

A sysadmin at a site had . as the first entry in root's PATH. One day a user asked him to delete a file beginning with a dash in /tmp (feigning cluelessness). The sysadmin su'ed to root and proceeded to do so. After that the "clueless user" had root. How? He had put a shell script namred "rm" in /tmp. The admin had done cd /tmp and then rm <whatever>. But since . was the first PATH entry, the command executed was not /bin/rm, but /tmp/rm. And /tmp/rm was a shell script that created and copied a SETUID shell into the user's home directory and then called the "real" rm to delete itself and the file in question, so the admin never suspected a thing.

A remote attacker could do the same thing, but really in your case the risk is quite negligible and ports and network services have nothing really to do with it at all other than to give a malicious person who would not normally have access to the system access.

yes that is what i would have said

I agree that the risk is negligible (but when it's exploited, it *really* hurts).

The other argument against is standards-compliance; the norm (afaik) is to not have . in $PATH--at the very least it won't hurt being used to not having . in $PATH, but if you grow too attached to it and it gets taken away from you (umm... company politics), you'll get pissed.

(hmm... I argue for following standards for the sake of not being used to something not available; yet I use the dvorak keyboard layout... standards -> good; double standards -> double good)

--Jonas

hmm.. alright, ok i guess it makes sense.. the book doesnt do a good job at explaining or going into any details about anything *nix related for roughly 95% of the content.. oh well i had to buy it for a class anyway, just wish it was actually worth reading even after i finished the course.
sure are some really tricky/very smart people out there to think of stuff like that though, good trick.. but evil, lol.
still, kudos to someone who thinks of something like that.