4 ms·

This is due to the way that Windows loads DLLs, there is a defined search order and the current working-directory is one of the locations. There have been a lo

This is due to the way that Windows loads DLLs, there is a defined search order and the current working-directory is one of the locations. There have been a lot of write-ups on this topic on Raymond Chen's blog, here is a good example: https://blogs.msdn.microsoft.com/oldnewthing/20101110-00/ https://blogs.msdn.microsoft.com/oldnewthing/20101110-00/

photonios 9y ago
That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
- enzanki_ars 9y ago
  I was just about to come back here and mention that. The article and comments that @stevekemp linked to provided a lot of insight, but as you mentioned, there are ways to prevent exploits of that nature, which the comments in the article point to also. Something still seems to be missing from my understanding of what Skype is doing...
  - chaz6 9y ago
    The cynic in me thinks this is already known and is in use by a "strategic partner" as a vector. The next version will only make it harder to find and exploit.
    - Tiki 9y ago
      Your comment reminded me of this: https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hacking-issue.html https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac... I doubt this was intentional at first, but the fact that they don't want to fix it is very fishy.
      - saurik 9y ago
        That is a very different issue, as there the concept is that the original file in the original location is being replaced. As is stated in that post, at that point the person could just as easily replace the program itself with a modified version of the entire program. That is not a security issue in the software.
mannykannot 9y ago
If that were all there is to it, would this not be an issue for all Windows applications, not just Skype? Is it just Skype that puts the current working directory in the list, or at least in a position where it can be used to preempt the loading of the correct DLL? The link you provide as an example suggests that this sort of thing might be done to facilitate testing, but again, that doesn't seem to be a compelling reason for not fixing it now - 'ship what you test' is a good principle, but it does not preempt 'fix known security holes.'
- Svip 9y ago
  Well, I guess not all Windows applications are run as the SYSTEM account, but the Skype SKY-tmp is? I'd assume, at least, that programs intended to run as the SYSTEM account does a better job of loading DLLs from secure locations.
  - notriddle 9y ago
    In other words, the Linux equivalent would be a setuid executable that doesn't properly ignore LD_PRELOAD_PATH.
    - user5994461 9y ago
      Well, the system executable should not be run as root from /tmp obviously.
- rhodysurf 9y ago
  Its an issue with all windows applications but not all windows applications have the same elevated permissions that skype seems to
- mherdeg 9y ago
  It is an issue for all Windows applications. There was a month when 50%+ of the traffic on full-disclosure@ was just one person repeatedly announcing newly discovered problems with various Windows software that all involved search-path problems ("DLL hijacking" or related issues). There's at least one author who is super keen on using the phrase "binary planting" to refer to a similar class of attacks.
leeter 9y ago
You can actually control most of this using an application manifest. The advantage being you can prevent any non-"known" dll from loading from any folder it's not supposed to. Moreover you can ensure that it's embedded in the binary so if someone tries to modify the manifest it breaks the cryptographic signature on the binary. To anyone going "but what if they replace the binary!" well then they've already gotten past the air-tight hatchway.

photonios 9y ago

That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms684175(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

enzanki_ars 9y ago
I was just about to come back here and mention that. The article and comments that @stevekemp linked to provided a lot of insight, but as you mentioned, there are ways to prevent exploits of that nature, which the comments in the article point to also. Something still seems to be missing from my understanding of what Skype is doing...
- chaz6 9y ago
  The cynic in me thinks this is already known and is in use by a "strategic partner" as a vector. The next version will only make it harder to find and exploit.
  - Tiki 9y ago
    Your comment reminded me of this: https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hacking-issue.html https://notepad-plus-plus.org/news/notepad-7.3.3-fix-cia-hac... I doubt this was intentional at first, but the fact that they don't want to fix it is very fishy.
    - saurik 9y ago
      That is a very different issue, as there the concept is that the original file in the original location is being replaced. As is stated in that post, at that point the person could just as easily replace the program itself with a modified version of the entire program. That is not a security issue in the software.

mannykannot 9y ago

If that were all there is to it, would this not be an issue for all Windows applications, not just Skype? Is it just Skype that puts the current working directory in the list, or at least in a position where it can be used to preempt the loading of the correct DLL? The link you provide as an example suggests that this sort of thing might be done to facilitate testing, but again, that doesn't seem to be a compelling reason for not fixing it now - 'ship what you test' is a good principle, but it does not preempt 'fix known security holes.'

Svip 9y ago
Well, I guess not all Windows applications are run as the SYSTEM account, but the Skype SKY-tmp is? I'd assume, at least, that programs intended to run as the SYSTEM account does a better job of loading DLLs from secure locations.
- notriddle 9y ago
  In other words, the Linux equivalent would be a setuid executable that doesn't properly ignore LD_PRELOAD_PATH.
  - user5994461 9y ago
    Well, the system executable should not be run as root from /tmp obviously.
rhodysurf 9y ago
Its an issue with all windows applications but not all windows applications have the same elevated permissions that skype seems to
mherdeg 9y ago
It is an issue for all Windows applications. There was a month when 50%+ of the traffic on full-disclosure@ was just one person repeatedly announcing newly discovered problems with various Windows software that all involved search-path problems ("DLL hijacking" or related issues). There's at least one author who is super keen on using the phrase "binary planting" to refer to a similar class of attacks.

leeter 9y ago

You can actually control most of this using an application manifest. The advantage being you can prevent any non-"known" dll from loading from any folder it's not supposed to. Moreover you can ensure that it's embedded in the binary so if someone tries to modify the manifest it breaks the cryptographic signature on the binary. To anyone going "but what if they replace the binary!" well then they've already gotten past the air-tight hatchway.