5 ms·

It will also execute libc.so and libpcre.so from that folder. That's simply how libraries are loaded on both Linux and Windows, nothing specific to python. It'

It will also execute libc.so and libpcre.so from that folder. That's simply how libraries are loaded on both Linux and Windows, nothing specific to python. It's really far fetched to go for python or jupyter when there are easier options like system DLL. The downloads directory is fundamentally unsafe, that we can agree on. Thankfully browsers don't let website push files unlike what the author may imply.

kgwgk 6y ago
I don't think running something like /usr/local/bin/notpython ~/Downloads/legit.file will load libraries or execute code in ~/Downloads That seems something specific to python/jupyter
- quietbritishjim 6y ago
  But maybe it's more analogous to ask about running ~/Downloads/legit_program (or maybe ...\Downloads\legit_installer.exe). As I said in my sibling comment, this is safe on Linux (if legit_program really is safe) but they're right that on Windows it's dangerous because the program will pick up zlib.dll etc. in the downloads directory. Maybe this is part of the reason for .msi installers: they end up running the MSI installer executable, which is located in some system directory instead.
  - kgwgk 6y ago
    Sure, running executables in random places may be risky. But with python it’s not just the location of the binary program that matters and running scripts or notebooks stored in random places may also be risky.
- masklinn 6y ago
  Comments up thread note that lua will do the exact same thing, Perl used to do it as well (now changed). Ruby apparently does not though (the internet shows many asking how to do it). Good for them.
  - kgwgk 6y ago
    Well, I didn't literally expect it to be unique to python :-)
quietbritishjim 6y ago
> It will also execute libc.so and libpcre.so from that folder. That's simply how libraries are loaded on both Linux and Windows That's true on Windows but NOT on Linux (which I actually find a bit annoying for deploying applications to users). On Linux you could explicitly add "." to your LD_LIBRARY_PATH variable but even then I think it would look in the working directory rather than the executable directory.
- dfox 6y ago
  And since XP SP2 windows by default searches current directory as one of the last places that it looks into. It is not exactly perfect mitigation but probably works for most instances of this issue.
  - quietbritishjim 6y ago
    I think the main concern here is the directory containing the application (especially if it's in the downloads directory), which is always first in the search order on Windows [1]. There was an article in the Old New Thing blog about how this is because the application's directory is expected to be its own safe package, usually a subdirectory of Program Files. You're talking about the current working directory, which can be different, and you're right it was moved later in the search order in XP SP2 (also mentioned in [1]). I had no idea it was ever searched at all, so thanks for that! [1] https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-...
- account42 6y ago
  > which I actually find a bit annoying for deploying applications to users Linux ELF binaries can have a library search path embedded using the -rpath linker option. Inside that search path, '$ORIGIN' refers to the binary location so you can have the Windows behavior if you want to.
  - quietbritishjim 6y ago

kgwgk 6y ago

I don't think running something like /usr/local/bin/notpython ~/Downloads/legit.file will load libraries or execute code in ~/Downloads That seems something specific to python/jupyter

quietbritishjim 6y ago
But maybe it's more analogous to ask about running ~/Downloads/legit_program (or maybe ...\Downloads\legit_installer.exe). As I said in my sibling comment, this is safe on Linux (if legit_program really is safe) but they're right that on Windows it's dangerous because the program will pick up zlib.dll etc. in the downloads directory. Maybe this is part of the reason for .msi installers: they end up running the MSI installer executable, which is located in some system directory instead.
- kgwgk 6y ago
  Sure, running executables in random places may be risky. But with python it’s not just the location of the binary program that matters and running scripts or notebooks stored in random places may also be risky.
masklinn 6y ago
Comments up thread note that lua will do the exact same thing, Perl used to do it as well (now changed). Ruby apparently does not though (the internet shows many asking how to do it). Good for them.
- kgwgk 6y ago
  Well, I didn't literally expect it to be unique to python :-)

quietbritishjim 6y ago

> It will also execute libc.so and libpcre.so from that folder. That's simply how libraries are loaded on both Linux and Windows That's true on Windows but NOT on Linux (which I actually find a bit annoying for deploying applications to users). On Linux you could explicitly add "." to your LD_LIBRARY_PATH variable but even then I think it would look in the working directory rather than the executable directory.

dfox 6y ago
And since XP SP2 windows by default searches current directory as one of the last places that it looks into. It is not exactly perfect mitigation but probably works for most instances of this issue.
- quietbritishjim 6y ago
  I think the main concern here is the directory containing the application (especially if it's in the downloads directory), which is always first in the search order on Windows [1]. There was an article in the Old New Thing blog about how this is because the application's directory is expected to be its own safe package, usually a subdirectory of Program Files. You're talking about the current working directory, which can be different, and you're right it was moved later in the search order in XP SP2 (also mentioned in [1]). I had no idea it was ever searched at all, so thanks for that! [1] https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-...
account42 6y ago
> which I actually find a bit annoying for deploying applications to users Linux ELF binaries can have a library search path embedded using the -rpath linker option. Inside that search path, '$ORIGIN' refers to the binary location so you can have the Windows behavior if you want to.
- quietbritishjim 6y ago