5 ms·

Interestingly, I had an article featured om HN related to how easy this is to exploit: https://news.ycombinator.com/item?id=14518356 https://news.ycombinator.co

Interestingly, I had an article featured om HN related to how easy this is to exploit: https://news.ycombinator.com/item?id=14518356 https://news.ycombinator.com/item?id=14518356

IncRnd 9y ago
I just read through that. Nice debugging. Binary planting, incidentally, was one of those persistent bugs in all Windows versions, since the local directory in Windows generally is in the beginning of the path. That variant is called DLL planting or a DLL loading vulnerability. That single design decision to execute from the local folder has caused untold havoc, including half a dozen APIs for how to handle DLL loading.
- kuschku 9y ago
  And this is especially bad when your browser drops all downloaded .DLLs and .EXEs in the same Downloads folder
  - IncRnd 9y ago
    or when your email program downloads files you go to a network share and click java loads the configuration from the current directory or, or, or You're absolutely right :(
- AnIdiotOnTheNet 9y ago
  I don't see what the big deal is. That behavior allowed a ton of flexibility at the cost of DLL planting problems iff someone can already drop arbitrary files in the application's directory.
  - IncRnd 9y ago
    > I don't see what the big deal is. Let's say that a Windows user wants to use sandboxie to isolate web components when browsing, until Aug of this year. You're Pwned: https://nvd.nist.gov/vuln/detail/CVE-2017-12480 https://nvd.nist.gov/vuln/detail/CVE-2017-12480
    - AnIdiotOnTheNet 9y ago
      I think I'm missing something. It has been a while since I've used Sandboxie, but it seems like this is a behavioral oversight on it's part.
      - IncRnd 9y ago
        > It has been a while since I've used Sandboxie, but it seems like this is a behavioral oversight on it's part. What do you mean by a behavioral oversight? The installer loaded a non-existent dll from the temp folder. Any DLL of the same name would get executed upon installation of Sandboxie. That's why DLL hijacking is an issue.
        AnIdiotOnTheNet 9y ago
        The link you gave gives a single line description of the issue. It isn't very helpful in understanding what conditions were required to exploit. Is this a Sandboxie installer issue or all installers? If the latter, yeah that's a problem, but there are a lot of ways to fix it that don't involve crippling the flexibility. Edit: ok, read the medium link at the bottom. This is an issue with Sandboxie's installer behavior, for which I think it is unfair to blame the way Windows searches for and loads DLLs.
        IncRnd 9y ago
        > The link you gave gives a single line description of the issue. It isn't very helpful in understanding what conditions were required to exploit. Is this a Sandboxie installer issue or all installers? The single line description is literally an answer to both of those questions, "Sandboxie installer 5071703 has a DLL Hijacking or Unsafe DLL Loading Vulnerability via a Trojan horse dwmapi.dll or profapi.dll file in an AppData\Local\Temp directory." > Edit: ok, read the medium link at the bottom. This is an issue with Sandboxie's installer behavior, for which I think it is unfair to blame the way Windows searches for and loads DLLs. The vulnerability is literally caused by the dll load path containing the cwd. That is the subject of this entire thread.
jwilk 9y ago
Accidentally adding empty item to LD_LIBRARY_PATH (or PATH, or PYTHONPATH, or ...) is a pretty common bug. This should be fixed all at once, by stopping treating empty string as cwd. People who actually need to have cwd in *PATH can add it explicitly.

Interestingly, I had an article featured om HN related to how easy this is to exploit: https://news.ycombinator.com/item?id=14518356 https://news.ycombinator.com/item?id=14518356

IncRnd 9y ago

I just read through that. Nice debugging. Binary planting, incidentally, was one of those persistent bugs in all Windows versions, since the local directory in Windows generally is in the beginning of the path. That variant is called DLL planting or a DLL loading vulnerability. That single design decision to execute from the local folder has caused untold havoc, including half a dozen APIs for how to handle DLL loading.

kuschku 9y ago
And this is especially bad when your browser drops all downloaded .DLLs and .EXEs in the same Downloads folder
- IncRnd 9y ago
  or when your email program downloads files you go to a network share and click java loads the configuration from the current directory or, or, or You're absolutely right :(
AnIdiotOnTheNet 9y ago
I don't see what the big deal is. That behavior allowed a ton of flexibility at the cost of DLL planting problems iff someone can already drop arbitrary files in the application's directory.
- IncRnd 9y ago
  > I don't see what the big deal is. Let's say that a Windows user wants to use sandboxie to isolate web components when browsing, until Aug of this year. You're Pwned: https://nvd.nist.gov/vuln/detail/CVE-2017-12480 https://nvd.nist.gov/vuln/detail/CVE-2017-12480
  - AnIdiotOnTheNet 9y ago
    I think I'm missing something. It has been a while since I've used Sandboxie, but it seems like this is a behavioral oversight on it's part.
    - IncRnd 9y ago
      > It has been a while since I've used Sandboxie, but it seems like this is a behavioral oversight on it's part. What do you mean by a behavioral oversight? The installer loaded a non-existent dll from the temp folder. Any DLL of the same name would get executed upon installation of Sandboxie. That's why DLL hijacking is an issue.
      - AnIdiotOnTheNet 9y ago
        The link you gave gives a single line description of the issue. It isn't very helpful in understanding what conditions were required to exploit. Is this a Sandboxie installer issue or all installers? If the latter, yeah that's a problem, but there are a lot of ways to fix it that don't involve crippling the flexibility. Edit: ok, read the medium link at the bottom. This is an issue with Sandboxie's installer behavior, for which I think it is unfair to blame the way Windows searches for and loads DLLs.
        IncRnd 9y ago
        > The link you gave gives a single line description of the issue. It isn't very helpful in understanding what conditions were required to exploit. Is this a Sandboxie installer issue or all installers? The single line description is literally an answer to both of those questions, "Sandboxie installer 5071703 has a DLL Hijacking or Unsafe DLL Loading Vulnerability via a Trojan horse dwmapi.dll or profapi.dll file in an AppData\Local\Temp directory." > Edit: ok, read the medium link at the bottom. This is an issue with Sandboxie's installer behavior, for which I think it is unfair to blame the way Windows searches for and loads DLLs. The vulnerability is literally caused by the dll load path containing the cwd. That is the subject of this entire thread.

jwilk 9y ago

Accidentally adding empty item to LD_LIBRARY_PATH (or PATH, or PYTHONPATH, or ...) is a pretty common bug. This should be fixed all at once, by stopping treating empty string as cwd. People who actually need to have cwd in *PATH can add it explicitly.