6 ms·

cd /var/tmp; When I see things like this it makes me think that if standard paths weren't used, then it would it at least make things a little more interesting

by devmonk 16y ago

cd /var/tmp; When I see things like this it makes me think that if standard paths weren't used, then it would it at least make things a little more interesting for the hacker. (They'd have to find a location first.)

jeebusroxors 16y ago
It would be trivial to find a directory. You would be left with a bunch of boxes with things in random places, and programs possibly looking for non existent dirs.
- devmonk 16y ago
  But for simple devices or server setups with few changes over time, it might be worth it as it would at least cause a little more work to hack in. I remember that it used to be encouraged to use non-standard paths for security's sake, but then it seemed like too much work for the reason you stated. But these days, with more automated attacks relying on standard paths, I don't think it is out of the question.
daten 16y ago
cd `find / -type d -perm -o+wx | head -n1`
- devmonk 16y ago
  I'm beginning to think I could cause hackers a lot of headache via long-running find commands caused by directory trees full of tmp-like dirs. But then they'd just use one of them.
Nitramp 16y ago
like, "cd $TEMP;"?
- devmonk 16y ago
  Change the environment variable name, go through through your apps (and kernel probably) change the code to use a new one. Anything is doable, it just takes time. I'm not saying it is trivial by any means; I'm just saying it is an option. If you build everything from source, it is more doable. In fact, it would be nice to have a secure -nix distro that did it for you. (I know there isn't one that does this, but it could generate a random env var names and paths during install, and maybe change them on demand (by external boot).) I'm perfectly aware that this could be "extremely difficult" or "not feasible" in many situations, but it wouldn't be so hard to control if you made the device and designed the OS for it (linux-based routers, etc.). I'm just tired of people giving up and laying things out like a holiday dinner because it's "too difficult". Good security requires sacrifice of work and time.
  - enneff 16y ago
    What you're describing is security through obscurity, not good security. Anything that can be obfuscated programatically (while still remaining usable) can be rediscovered programatically. This accomplishes nothing.
dionysiac 16y ago
find / -maxdepth 3 -perm -7 -type d -print and tweak as needed.
- devmonk 16y ago
  But a find on root takes a lot of time in some cases, during which the attacker could be compromised. And the scripts might not use it for that reason. The script could use it as a backup only if the standard one doesn't exist, but still, it is a bump in the road, and might be worth it to cause the script to use find and delay it.
  - dionysiac 16y ago
    Hence the -maxdepth 3 param: # time find / -maxdepth 3 -perm -7 -type d -print /tmp /var/tmp real 0m0.034s user 0m0.005s sys 0m0.028s This was run on a pretty anemic VPS. Might have to up the depth to 4 if it doesn't return anything, but IMO that's pretty unlikely.

by devmonk 16y ago

jeebusroxors 16y ago

It would be trivial to find a directory. You would be left with a bunch of boxes with things in random places, and programs possibly looking for non existent dirs.

devmonk 16y ago
But for simple devices or server setups with few changes over time, it might be worth it as it would at least cause a little more work to hack in. I remember that it used to be encouraged to use non-standard paths for security's sake, but then it seemed like too much work for the reason you stated. But these days, with more automated attacks relying on standard paths, I don't think it is out of the question.

daten 16y ago

cd `find / -type d -perm -o+wx | head -n1`

devmonk 16y ago
I'm beginning to think I could cause hackers a lot of headache via long-running find commands caused by directory trees full of tmp-like dirs. But then they'd just use one of them.

Nitramp 16y ago

like, "cd $TEMP;"?

devmonk 16y ago
Change the environment variable name, go through through your apps (and kernel probably) change the code to use a new one. Anything is doable, it just takes time. I'm not saying it is trivial by any means; I'm just saying it is an option. If you build everything from source, it is more doable. In fact, it would be nice to have a secure -nix distro that did it for you. (I know there isn't one that does this, but it could generate a random env var names and paths during install, and maybe change them on demand (by external boot).) I'm perfectly aware that this could be "extremely difficult" or "not feasible" in many situations, but it wouldn't be so hard to control if you made the device and designed the OS for it (linux-based routers, etc.). I'm just tired of people giving up and laying things out like a holiday dinner because it's "too difficult". Good security requires sacrifice of work and time.
- enneff 16y ago
  What you're describing is security through obscurity, not good security. Anything that can be obfuscated programatically (while still remaining usable) can be rediscovered programatically. This accomplishes nothing.

dionysiac 16y ago

find / -maxdepth 3 -perm -7 -type d -print and tweak as needed.

devmonk 16y ago
But a find on root takes a lot of time in some cases, during which the attacker could be compromised. And the scripts might not use it for that reason. The script could use it as a backup only if the standard one doesn't exist, but still, it is a bump in the road, and might be worth it to cause the script to use find and delay it.
- dionysiac 16y ago
  Hence the -maxdepth 3 param: # time find / -maxdepth 3 -perm -7 -type d -print /tmp /var/tmp real 0m0.034s user 0m0.005s sys 0m0.028s This was run on a pretty anemic VPS. Might have to up the depth to 4 if it doesn't return anything, but IMO that's pretty unlikely.