3 ms·

It doesn't need to be the default/transparent behavior, isn't it? Mechanisms like LD_PRELOAD can be used for the same purpose in more controlled way. Not havi

by shiro 11y ago

It doesn't need to be the default/transparent behavior, isn't it? Mechanisms like LD_PRELOAD can be used for the same purpose in more controlled way. Not having the current directory in PATH / LD_LIBRARY_PATH is a well-known wisdom now to avoid inadvertent interference. I suspect Windows behavior is more like an overlook, designed when environment was less hostile, but now they can't change because of the backward compatibility. It's not a vulnerability per se, but a bad choice in retrospect, imho.

whoopdedo 11y ago
It was a design decision from a time when software management was non-existent. "Installing" meant creating a directory in the root of the hard drive and copying all your files there. Shared libraries didn't exist. But this type of exploit still existed even under MS-DOS in the form of BBS door hacks. Remote access systems would let you run external programs connected to the serial line. But some would leave the CWD in the download directory after an upload thus allowing you to send a file with the name of an external program then when you activate that program you have a shell. The solution then still applies today: Don't run external programs without sanitizing your environment. Quarantine all uploads. Don't allow the remote client to control the filename of uploads. And it's not like Windows doesn't have an executable bit on files. The shell already prompts you for permission to run downloaded programs. Why is it not clearing execute permission by default then adding it when the file is confirmed safe? (I know from experience that a non-executable ACL will prevent a DLL from loading.)
- yuhong 11y ago
  That was added as part of XP SP2 as an ADS I think.
alkonaut 11y ago
> I suspect Windows behavior is more like an overlook I prefer to have dynamically loaded libraries (dll's) but never shared locations, other than for OS level libraries and runtimes (which are rarely installed by applications). Everything I manage myself I prefer to keep in the application directories. This is also the normal behaviour of application installers on windows. \app1\app1.exe \app1\somelib-1.0.dll \app2\app2.exe \app2\somelib-1.1.dll Now it is pretty reasonable that the application searches for dependencies somewhere relative to the directory of the application. This has several benefits but a few security drawbacks 1) hijacking is possible since the current directory is used, 2) if there is a security vulnerability in somelib, you have to patch all applications that use it. I much prefer this to the idea of applications installing files to a shared location on my disk however.

by shiro 11y ago

whoopdedo 11y ago

It was a design decision from a time when software management was non-existent. "Installing" meant creating a directory in the root of the hard drive and copying all your files there. Shared libraries didn't exist. But this type of exploit still existed even under MS-DOS in the form of BBS door hacks. Remote access systems would let you run external programs connected to the serial line. But some would leave the CWD in the download directory after an upload thus allowing you to send a file with the name of an external program then when you activate that program you have a shell. The solution then still applies today: Don't run external programs without sanitizing your environment. Quarantine all uploads. Don't allow the remote client to control the filename of uploads. And it's not like Windows doesn't have an executable bit on files. The shell already prompts you for permission to run downloaded programs. Why is it not clearing execute permission by default then adding it when the file is confirmed safe? (I know from experience that a non-executable ACL will prevent a DLL from loading.)

yuhong 11y ago
That was added as part of XP SP2 as an ADS I think.

alkonaut 11y ago

> I suspect Windows behavior is more like an overlook I prefer to have dynamically loaded libraries (dll's) but never shared locations, other than for OS level libraries and runtimes (which are rarely installed by applications). Everything I manage myself I prefer to keep in the application directories. This is also the normal behaviour of application installers on windows. \app1\app1.exe \app1\somelib-1.0.dll \app2\app2.exe \app2\somelib-1.1.dll Now it is pretty reasonable that the application searches for dependencies somewhere relative to the directory of the application. This has several benefits but a few security drawbacks 1) hijacking is possible since the current directory is used, 2) if there is a security vulnerability in somelib, you have to patch all applications that use it. I much prefer this to the idea of applications installing files to a shared location on my disk however.