Skype can't fix a nasty security bug without a massive code rewrite
1–10 of 99 posts
Re: Skype can't fix a nasty security bug without a massive code rewrite
#2I must be missing something obvious here. Why can’t skype just hard code the locations and hashes of the dll files it needs to load? Why is Skype loading random DLLs from user accessible folders? I must be misunderstanding how Windows programs use DLLs and why it needs to just search for them.
Edit: @jwilk in the comments here pointed to a better article about the security vulnerability [1]. Based on the technical details, there seems to be no reason why Microsoft could not issue a very quick fix loading the DLL from the secure location.
Important quote in my eyes:
“The engineers provided me with an update on this case. They've reviewed the code and were able to reproduce the issue, but have determined that the fix will be implemented in a newer version of the product rather than a security update. The team is planning on shipping a newer version of the client, and this current version will slowly be deprecated. The installer would need a large code revision to prevent DLL injection, but all resources have been put toward development of the new client.”
In other words, it seems Microsoft/Skype doesn’t care about security at all. A couple of lines to fix the bug, in theory, but Microsoft is too busy to do it. Doesn’t make sense, unless a new version would have been released shortly, but it has been 4 months between that email and disclosure.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#3I must be missing something obvious here. Why can’t skype just hard code the locations and hashes of the dll files it needs to load? Why is Skype loading random DLLs from user accessible folders? I must be misunderstanding how Windows programs use DLLs and why it needs to just search for them. Edit: @jwilk in the comments here pointed to a better article about the security vulnerability [1]. Based on the technical de…
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:
Re: Skype can't fix a nasty security bug without a massive code rewrite
#4I must be missing something obvious here. Why can’t skype just hard code the locations and hashes of the dll files it needs to load? Why is Skype loading random DLLs from user accessible folders? I must be misunderstanding how Windows programs use DLLs and why it needs to just search for them. Edit: @jwilk in the comments here pointed to a better article about the security vulnerability [1]. Based on the technical de…
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/
That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
Re: Skype can't fix a nasty security bug without a massive code rewrite
#5Technical information is here: http://seclists.org/fulldisclosure/2018/Feb/33
Re: Skype can't fix a nasty security bug without a massive code rewrite
#6Earlier quoted context omitted.
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/
That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
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...
Re: Skype can't fix a nasty security bug without a massive code rewrite
#7Time to use the web client.
Or not at all, I haven't had a need for skype but the last client I used was the web client on Linux.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#8Earlier quoted context omitted.
That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
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...
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.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#9From the disclosure (http://seclists.org/fulldisclosure/2018/Feb/33):
> An unprivileged (local) user who is able to place UXTheme.dll or any of the other DLLs loaded by the vulnerable executable in %SystemRoot%\Temp\ gains escalation of privilege to the SYSTEM account.
On my machine at least an unprivileged user does not have access to %SystemRoot%\Temp\ so it seems to be a case of what Raymond Chen refers to as "on the other side of the airtight hatchway".
Re: Skype can't fix a nasty security bug without a massive code rewrite
#10I must be missing something obvious here. Why can’t skype just hard code the locations and hashes of the dll files it needs to load? Why is Skype loading random DLLs from user accessible folders? I must be misunderstanding how Windows programs use DLLs and why it needs to just search for them. Edit: @jwilk in the comments here pointed to a better article about the security vulnerability [1]. Based on the technical de…
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/
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.'