30 ms·

Skype can't fix a nasty security bug without a massive code rewrite

181 points by nautical 9y ago

enzanki_ars 9y ago
I 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. [1]: http://seclists.org/fulldisclosure/2018/Feb/33 http://seclists.org/fulldisclosure/2018/Feb/33
- stevekemp 9y ago
  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.
- brazzledazzle 9y ago
  It would be interesting to see Google Project Zero’s take on it. It’s a shame they didn’t discover it because I’m sure the back and forth between them and the Skype devs would have been really interesting.
  - _jal 9y ago
    PZ almost certainly is aware of at least the general issue - Windows DDL hijacking posts hit the Full Disclosure list pretty much weekly. It is a very well-known issue, at least among those who subscribe to security lists, approaching dead-horse status.
- cptskippy 9y ago
  > A couple of lines to fix the bug, in theory Yes that's all it takes. No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation. None of the work on the installer or updater. No release notes or other communication to the community. Just a couple lines of code. Easily done before morning coffee.
  - mosselman 9y ago
    Luckily 'they don't care about security at all'. They just looked into it for fun when the report came in.
  - dspillett 9y ago
    > code reviews, security review, integration testing, quality assurance testing, compatibility testing, Valid counter-criticism of the "just a couple of lines of code" line generally, but four months is a long time since disclosure and that is a lot of morning coffees.
    - cptskippy 9y ago
      I wasn't defending Microsoft, just responding to the trivialization the op made. According to the article, Microsoft is dedicating resources to a new client which won't exhibit the flaw. So I guess that means either they examined the flaw and determined it wasn't a high enough risk to warrant patching, or they don't care. Dealer's choice I guess. Maybe the number of people using Skype these days is insignificant? I tried to use it about a year ago and noped the hell away after 5 minutes.
  - enzanki_ars 9y ago
    As others have already noted, yes, it’s a pain ship fixes in a company setting, and I fully understand that. On the oth r hand, 4 months for no fix is inexcusable.
  - vorpalhex 9y ago
    > No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation. If this was a small startup, I can absolutely see those being hurdles. This is Microsoft on a product they've had for 20+ years that is a major part of their platform - those things should be mostly automated and well oiled machines. A mature enterprise level company has no excuses for "QA is hard!" or "We can't validate patches!" for a product they sell. I don't expect them to get this out in ten minutes, but they should be able to manage a patch in 24 - 72 hours for a fairly critical and relatively easily solved security bug.
- sametmax 9y ago
  More probably this is something they need for a reason we don't know about but won't disclose.
- Amezarak 9y ago
  > Why is Skype loading random DLLs from user accessible folders? %SYSTEMROOT%/Temp doesn't seem to be user-readable at all, so I'm having trouble understanding how you write anything there without already having escalated permissions.
  - enzanki_ars 9y ago
    I need to test this later as I only have access to an unprivileged account at the moment, but based on comments online (https://stackoverflow.com/a/11917816 https://stackoverflow.com/a/11917816), the folder is write only for unprivileged users (FILE_ADD_FILE).
    - Amezarak 9y ago
      You're correct, I was able to write a file without privilege escalation, and then I verified it was there by escalating. Thanks. If anyone is wondering, it's a little bit tricky to check because without the read permission, Windows Explorer can't see what the permissions are.
- mtgx 9y ago
  > Why is Skype loading random DLLs from user accessible folders? Good question. Almost every time I want to use some new security tool - like say AppLocker - Skype craps out on me, because it seems to be so badly programmed, and it's all over the place in Windows. It's why I stopped using the native app completely, and only use the web version whenever I still need to use Skype.
jwilk 9y ago
Technical information is here: http://seclists.org/fulldisclosure/2018/Feb/33 http://seclists.org/fulldisclosure/2018/Feb/33
INTPenis 9y ago
Time 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.
- StavrosK 9y ago
  I've had good experience with Jitsi Meet (https://meet.jit.si https://meet.jit.si). You can run it from a browser, it's very pleasant and works quite well. Plus, it's open source.
  - tmalsburg2 9y ago
    Thank you. Just tried it and it works great in Chromium.
user5454 9y ago
From the disclosure (http://seclists.org/fulldisclosure/2018/Feb/33 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".
- taspeotis 9y ago
  I believe the default permissions for a volume grant users the ability to create folders, so they should be able to create a folder in C: called Temp and put files into it. It’s also possible that when Skype’s updater creates the folder it has different ACLs.
  - Someone1234 9y ago
    > I believe the default permissions for a volume grant users the ability to create folders, so they should be able to create a folder in C: called Temp and put files into it. That's inaccurate. UAC makes it appear like you can, if you try to do this as an unprivileged user on a default install it will fail. Plus even if you could create C:\Temp, you'd need to add it to the system-scoped environmental variable PATH for it to be searched for libraries. If you could do that you've already effectively escalated without this. This Skype issue exists because they're running a SYSTEM level process from a directory a normal user owns.
  - Amezarak 9y ago
    %SYSTEMROOT% is C:\Windows, not C:\. I too cannot access C:\Windows\Temp at all without escalating permissions. Neither can I write to anything in C:\Windows as described in the original source without escalated permissions. I'm a little puzzled about what would stop someone with the same permissions from doing exactly the same thing with the fully qualified name.
    - enzanki_ars 9y ago
adamkruszewski 9y ago
Few years ago after not logging into Skype for few months when I have launched Skype I was logged in automatically to another person's account (similar in name to my own, but with additional prefix). It happen few times in period of 2-3 years. When I tried to report it, support staff supposedly handed the info to their supervisor and that's was it. Fortunately web client had resolved such issues.
codedokode 9y ago
It is interesting to note that there is no option to control or disable updates in new Skype RT for Windows. Opera browser also doesn't allow user to control updates.
airza 9y ago
Maybe it's pedantic, but I wish security reporters wouldn't list their pubkeys and signal # on a page that isn't served over TLS.
tankenmate 9y ago
The article mentioned that the bug reporter claimed that MacOS and Linux were also possibly affected. I run Skype on Xubuntu and it is installed via apt and a signed repo / package. Also Linux by default doesn't have '.' in the search path for dlopen() / ld.so.
pier25 9y ago
The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?
- pas 9y ago
  Hangouts, FB Messenger.
  - pier25 9y ago
    Hangouts has terrible performance and I won't force people into using anything FB related.
    - pas 9y ago
      We found that Hangouts was the most resilient, followed by FB Messenger. All better than Skype. (Of course all 3 are terrible from a lot of aspects, mainly they come with having a Google or FB account.) Slack is good for 1-1 calls though. And of course there are possibly hundreds of free and open source alternatives, but I don't know of any that can be easily used from a browser. I hope the Mattermost video-audio chat ( https://docs.mattermost.com/deployment/webrtc.html https://docs.mattermost.com/deployment/webrtc.html ) gains enough momentum to become a well established alternative.
      - pier25 9y ago
        Slack could be a good option, it has group calls and screen share, but my company won't pay for it.
- rantanplan 9y ago
  https://jitsi.org/ https://jitsi.org/ Surprisingly good. No account required, no limit on number of people, good screen sharing, works everywhere(because web-based).
- shlant 9y ago
  The new Skype is so bad, we joke that it must be malware. The design was bad already, but holy eyesore. At least the MacOS version works. On android, when I log in as my account, the only contacts I have are those from my sisters account (???) and none of my subscriptions are there so I can't even make calls that require Skype credit even though my account has credit. I had to add my wife as a contact and none of my chat history with her showed up. As close to unusable as it comes...
TorKlingberg 9y ago
A bug sure, but does anyone really care much about local privilege escalation on Windows? On a system where Skype is installed?
- jessaustin 9y ago
  Someone without 2FA might check their email on that system. Their bank might send them email...
redleggedfrog 9y ago
Oh yes please, whatever the reason. The current Skype is rubbish. Make us something nice!
vforvangelis 9y ago
An interim solution could be to install the UWP Skype app from the Store. I don't think it relies on Updater.exe for patches.
- ocdtrekkie 9y ago
  Yeah, the article seems to fail to mention that the current version of Windows, which almost everyone had two years to upgrade to for free, has a version of Skype that isn't vulnerable. Given that Windows 10 has been out since 2015, and everyone with a Windows license going back to 2009 had a free upgrade path, failing to mention that Skype on Windows 10 (they don't recommend classic Skype for Windows 10 users) isn't vulnerable borders on the FUD barrier.
  - Nexxxeh 9y ago
    I don't know if it's still the case, but is the UWP a crash-prone nightmare that doesn't have feature parity with the older client family?
    - ocdtrekkie 9y ago
      It's gotten significantly better over time. I can't remember the last time it crashed, sync between clients of the chat log is kinda wonky sometimes but that's just Skype in general. Not positive on feature parity, I've been on the UWP version for quite a while and couldn't tell you what's different anymore.
      - Nexxxeh 9y ago
        I've literally had to go out to unfuck a Skype UWP install onsite tonight, in what may be a freak co-incidence. Skype decided a perfectly working webcam was permanently in use by something else. It wasn't, but a uninstall and reinstall of the app cured it.
ulfw 9y ago
Absolutely nothing surprises me with Skype anymore. Sadly. Messages do not get delivered to iPhone, iPad and Mac. Only pick two. Pick random two. Not sure what Microsoft's plan for Skype was. But I don't see it working out either way.
devit 9y ago
It's not "nasty" at all, it's an irrelevant bug, since local account security is easily bypassable in a lot of ways. It's also trivial to fix: just create a directory in Temp and put the executable there instead of directly in the Temp directory.
jmull 9y ago
The title isn't quite right here. It's not that Microsoft can't fix this bug without a massive rewrite. It's that they'd rather do the massive rewrite than fix this security bug in the current client. They could put a small amount of resources on critical fixes for the current client. It would have a small effect on the release of the new client but put them in a much better position once the new client is ready in terms of how many users they retain and how happy those users are. Overall, there's a lot of bang for the buck for this in terms of the overall health of the product. Now, Microsoft may very well have a critical fix effort for the current client but this bug didn't make the grade as a critical bug. (I can't tell from just this article whether I would consider this a critical issue or not.)
korethr 9y ago
The article mentions that this vulnerability affects Mac and Linux too. I'm curious how that's the case. DLLs, as i understand, are the Windows equivalent of shared libraries on Unix-like systems. Even if that's the case, there'd have to be subtle but important differences in the implantation details, due to the differing heritage of both systems, wouldn't there? I've heard about DLL-injection many a time, for purposes ranging from benign (fun Counter-Strike mod) to evil (I am now NT AUTHORITY\SYSTEM, bitches). I've not heard about .so injection on Unix-like systems. Why is that? Is it because implementation details of Unix shared libraries preclude them being used in the same or a similar way, that I've just not been on the right mailing lists to hear about it, or more nobody cares to bother because everyone's on Windows? Those of you whom are familiar with either or both systems, what material would you recommend for study that would answer my questions, or help me understand enough to ask a smarter one?
- cesarb 9y ago
  On Windows, for legacy compatibility reasons, the default DLL search path includes the directory the executable is located on by default. On Unix, that's not the case. I'd recommend the following study material: - Windows: "Dynamic-Link Library Search Order" https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... - Linux: http://man7.org/linux/man-pages/man8/ld.so.8.html http://man7.org/linux/man-pages/man8/ld.so.8.html
- netvl 9y ago
  As far as my understanding goes, performing a .so injection at least on Linux systems is much easier: you just need to set up an LD_PRELOAD variable before running the program and that's it. See, for example, here [0]. And it is sometimes useful. One thing I can recall when this was necessary when I had an old webcam which did not work with Skype (a native application, at that moment) under Linux because of incompatibility with V4L2. To make the camera work, I had to do the LD_PRELOAD trick to preload a compatibility library (see here [1], search for "v4lcompat"). Another example, provided in [0], is overriding the default memory allocator. Another, more coarse-grained way to manipulate the way libraries are loaded is to use the LD_LIBRARY_PATH variable. I believe it is currently used by Steam to specify its own set of libraries. Granted, this is not really a DLL injection as it is usually understood (adding code to a running process), but it is the same thing as described in the article, as far as I can tell. [0]: https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick https://stackoverflow.com/questions/426230/what-is-the-ld-pr... [1]: https://wiki.ubuntu.com/SkypeWebCams https://wiki.ubuntu.com/SkypeWebCams edit: grammar
tamrix 9y ago
Sure they can't... P.S check out Microsoft teams!
heisenbit 9y ago
suid programs and the installer is de-facto such a beast should not be written if one can avoid it. Providing users with sufficient powerful APIs and installing software on a per user level is one way to avoid this mess. Another is to delegate installation to the operating system and not rolling your own. Anyone else messing up this way may be able to point to Microsoft. Now those folks at Skype are here in a bit a pickle.
Kipters 9y ago
As far as I've seen, no one noticed that this is about the old legacy version of Skype, the "rewritten client" they talk about in the article is the current Electron-based client. That one and the UWP version are not affected by this.
ppeetteerr 9y ago
Skype needs a rewrite. I don't like saying "rewrite" but I also hate Skype's messaging system.

181 points by nautical 9y ago

I 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. [1]: http://seclists.org/fulldisclosure/2018/Feb/33 http://seclists.org/fulldisclosure/2018/Feb/33

stevekemp 9y ago
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.
brazzledazzle 9y ago
It would be interesting to see Google Project Zero’s take on it. It’s a shame they didn’t discover it because I’m sure the back and forth between them and the Skype devs would have been really interesting.
- _jal 9y ago
  PZ almost certainly is aware of at least the general issue - Windows DDL hijacking posts hit the Full Disclosure list pretty much weekly. It is a very well-known issue, at least among those who subscribe to security lists, approaching dead-horse status.
cptskippy 9y ago
> A couple of lines to fix the bug, in theory Yes that's all it takes. No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation. None of the work on the installer or updater. No release notes or other communication to the community. Just a couple lines of code. Easily done before morning coffee.
- mosselman 9y ago
  Luckily 'they don't care about security at all'. They just looked into it for fun when the report came in.
- dspillett 9y ago
  > code reviews, security review, integration testing, quality assurance testing, compatibility testing, Valid counter-criticism of the "just a couple of lines of code" line generally, but four months is a long time since disclosure and that is a lot of morning coffees.
  - cptskippy 9y ago
    I wasn't defending Microsoft, just responding to the trivialization the op made. According to the article, Microsoft is dedicating resources to a new client which won't exhibit the flaw. So I guess that means either they examined the flaw and determined it wasn't a high enough risk to warrant patching, or they don't care. Dealer's choice I guess. Maybe the number of people using Skype these days is insignificant? I tried to use it about a year ago and noped the hell away after 5 minutes.
- enzanki_ars 9y ago
  As others have already noted, yes, it’s a pain ship fixes in a company setting, and I fully understand that. On the oth r hand, 4 months for no fix is inexcusable.
- vorpalhex 9y ago
  > No code reviews, security review, integration testing, quality assurance testing, compatibility testing, or validation. If this was a small startup, I can absolutely see those being hurdles. This is Microsoft on a product they've had for 20+ years that is a major part of their platform - those things should be mostly automated and well oiled machines. A mature enterprise level company has no excuses for "QA is hard!" or "We can't validate patches!" for a product they sell. I don't expect them to get this out in ten minutes, but they should be able to manage a patch in 24 - 72 hours for a fairly critical and relatively easily solved security bug.
sametmax 9y ago
More probably this is something they need for a reason we don't know about but won't disclose.
Amezarak 9y ago
> Why is Skype loading random DLLs from user accessible folders? %SYSTEMROOT%/Temp doesn't seem to be user-readable at all, so I'm having trouble understanding how you write anything there without already having escalated permissions.
- enzanki_ars 9y ago
  I need to test this later as I only have access to an unprivileged account at the moment, but based on comments online (https://stackoverflow.com/a/11917816 https://stackoverflow.com/a/11917816), the folder is write only for unprivileged users (FILE_ADD_FILE).
  - Amezarak 9y ago
    You're correct, I was able to write a file without privilege escalation, and then I verified it was there by escalating. Thanks. If anyone is wondering, it's a little bit tricky to check because without the read permission, Windows Explorer can't see what the permissions are.
mtgx 9y ago
> Why is Skype loading random DLLs from user accessible folders? Good question. Almost every time I want to use some new security tool - like say AppLocker - Skype craps out on me, because it seems to be so badly programmed, and it's all over the place in Windows. It's why I stopped using the native app completely, and only use the web version whenever I still need to use Skype.

jwilk 9y ago

Technical information is here: http://seclists.org/fulldisclosure/2018/Feb/33 http://seclists.org/fulldisclosure/2018/Feb/33

INTPenis 9y ago

Time 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.

StavrosK 9y ago
I've had good experience with Jitsi Meet (https://meet.jit.si https://meet.jit.si). You can run it from a browser, it's very pleasant and works quite well. Plus, it's open source.
- tmalsburg2 9y ago
  Thank you. Just tried it and it works great in Chromium.

user5454 9y ago

From the disclosure (http://seclists.org/fulldisclosure/2018/Feb/33 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".

taspeotis 9y ago
I believe the default permissions for a volume grant users the ability to create folders, so they should be able to create a folder in C: called Temp and put files into it. It’s also possible that when Skype’s updater creates the folder it has different ACLs.
- Someone1234 9y ago
  > I believe the default permissions for a volume grant users the ability to create folders, so they should be able to create a folder in C: called Temp and put files into it. That's inaccurate. UAC makes it appear like you can, if you try to do this as an unprivileged user on a default install it will fail. Plus even if you could create C:\Temp, you'd need to add it to the system-scoped environmental variable PATH for it to be searched for libraries. If you could do that you've already effectively escalated without this. This Skype issue exists because they're running a SYSTEM level process from a directory a normal user owns.
- Amezarak 9y ago
  %SYSTEMROOT% is C:\Windows, not C:\. I too cannot access C:\Windows\Temp at all without escalating permissions. Neither can I write to anything in C:\Windows as described in the original source without escalated permissions. I'm a little puzzled about what would stop someone with the same permissions from doing exactly the same thing with the fully qualified name.
  - enzanki_ars 9y ago

adamkruszewski 9y ago

Few years ago after not logging into Skype for few months when I have launched Skype I was logged in automatically to another person's account (similar in name to my own, but with additional prefix). It happen few times in period of 2-3 years. When I tried to report it, support staff supposedly handed the info to their supervisor and that's was it. Fortunately web client had resolved such issues.

codedokode 9y ago

It is interesting to note that there is no option to control or disable updates in new Skype RT for Windows. Opera browser also doesn't allow user to control updates.

airza 9y ago

Maybe it's pedantic, but I wish security reporters wouldn't list their pubkeys and signal # on a page that isn't served over TLS.

tankenmate 9y ago

The article mentioned that the bug reporter claimed that MacOS and Linux were also possibly affected. I run Skype on Xubuntu and it is installed via apt and a signed repo / package. Also Linux by default doesn't have '.' in the search path for dlopen() / ld.so.

pier25 9y ago

The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?

pas 9y ago
Hangouts, FB Messenger.
- pier25 9y ago
  Hangouts has terrible performance and I won't force people into using anything FB related.
  - pas 9y ago
    We found that Hangouts was the most resilient, followed by FB Messenger. All better than Skype. (Of course all 3 are terrible from a lot of aspects, mainly they come with having a Google or FB account.) Slack is good for 1-1 calls though. And of course there are possibly hundreds of free and open source alternatives, but I don't know of any that can be easily used from a browser. I hope the Mattermost video-audio chat ( https://docs.mattermost.com/deployment/webrtc.html https://docs.mattermost.com/deployment/webrtc.html ) gains enough momentum to become a well established alternative.
    - pier25 9y ago
      Slack could be a good option, it has group calls and screen share, but my company won't pay for it.
rantanplan 9y ago
https://jitsi.org/ https://jitsi.org/ Surprisingly good. No account required, no limit on number of people, good screen sharing, works everywhere(because web-based).
shlant 9y ago
The new Skype is so bad, we joke that it must be malware. The design was bad already, but holy eyesore. At least the MacOS version works. On android, when I log in as my account, the only contacts I have are those from my sisters account (???) and none of my subscriptions are there so I can't even make calls that require Skype credit even though my account has credit. I had to add my wife as a contact and none of my chat history with her showed up. As close to unusable as it comes...

TorKlingberg 9y ago

A bug sure, but does anyone really care much about local privilege escalation on Windows? On a system where Skype is installed?

jessaustin 9y ago
Someone without 2FA might check their email on that system. Their bank might send them email...

redleggedfrog 9y ago

Oh yes please, whatever the reason. The current Skype is rubbish. Make us something nice!

vforvangelis 9y ago

An interim solution could be to install the UWP Skype app from the Store. I don't think it relies on Updater.exe for patches.

ocdtrekkie 9y ago
Yeah, the article seems to fail to mention that the current version of Windows, which almost everyone had two years to upgrade to for free, has a version of Skype that isn't vulnerable. Given that Windows 10 has been out since 2015, and everyone with a Windows license going back to 2009 had a free upgrade path, failing to mention that Skype on Windows 10 (they don't recommend classic Skype for Windows 10 users) isn't vulnerable borders on the FUD barrier.
- Nexxxeh 9y ago
  I don't know if it's still the case, but is the UWP a crash-prone nightmare that doesn't have feature parity with the older client family?
  - ocdtrekkie 9y ago
    It's gotten significantly better over time. I can't remember the last time it crashed, sync between clients of the chat log is kinda wonky sometimes but that's just Skype in general. Not positive on feature parity, I've been on the UWP version for quite a while and couldn't tell you what's different anymore.
    - Nexxxeh 9y ago
      I've literally had to go out to unfuck a Skype UWP install onsite tonight, in what may be a freak co-incidence. Skype decided a perfectly working webcam was permanently in use by something else. It wasn't, but a uninstall and reinstall of the app cured it.

ulfw 9y ago

Absolutely nothing surprises me with Skype anymore. Sadly. Messages do not get delivered to iPhone, iPad and Mac. Only pick two. Pick random two. Not sure what Microsoft's plan for Skype was. But I don't see it working out either way.

devit 9y ago

It's not "nasty" at all, it's an irrelevant bug, since local account security is easily bypassable in a lot of ways. It's also trivial to fix: just create a directory in Temp and put the executable there instead of directly in the Temp directory.

jmull 9y ago

The title isn't quite right here. It's not that Microsoft can't fix this bug without a massive rewrite. It's that they'd rather do the massive rewrite than fix this security bug in the current client. They could put a small amount of resources on critical fixes for the current client. It would have a small effect on the release of the new client but put them in a much better position once the new client is ready in terms of how many users they retain and how happy those users are. Overall, there's a lot of bang for the buck for this in terms of the overall health of the product. Now, Microsoft may very well have a critical fix effort for the current client but this bug didn't make the grade as a critical bug. (I can't tell from just this article whether I would consider this a critical issue or not.)

korethr 9y ago

The article mentions that this vulnerability affects Mac and Linux too. I'm curious how that's the case. DLLs, as i understand, are the Windows equivalent of shared libraries on Unix-like systems. Even if that's the case, there'd have to be subtle but important differences in the implantation details, due to the differing heritage of both systems, wouldn't there? I've heard about DLL-injection many a time, for purposes ranging from benign (fun Counter-Strike mod) to evil (I am now NT AUTHORITY\SYSTEM, bitches). I've not heard about .so injection on Unix-like systems. Why is that? Is it because implementation details of Unix shared libraries preclude them being used in the same or a similar way, that I've just not been on the right mailing lists to hear about it, or more nobody cares to bother because everyone's on Windows? Those of you whom are familiar with either or both systems, what material would you recommend for study that would answer my questions, or help me understand enough to ask a smarter one?

cesarb 9y ago
On Windows, for legacy compatibility reasons, the default DLL search path includes the directory the executable is located on by default. On Unix, that's not the case. I'd recommend the following study material: - Windows: "Dynamic-Link Library Search Order" https://msdn.microsoft.com/en-us/library/windows/desktop/ms682586(v=vs.85).aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms6... - Linux: http://man7.org/linux/man-pages/man8/ld.so.8.html http://man7.org/linux/man-pages/man8/ld.so.8.html
netvl 9y ago
As far as my understanding goes, performing a .so injection at least on Linux systems is much easier: you just need to set up an LD_PRELOAD variable before running the program and that's it. See, for example, here [0]. And it is sometimes useful. One thing I can recall when this was necessary when I had an old webcam which did not work with Skype (a native application, at that moment) under Linux because of incompatibility with V4L2. To make the camera work, I had to do the LD_PRELOAD trick to preload a compatibility library (see here [1], search for "v4lcompat"). Another example, provided in [0], is overriding the default memory allocator. Another, more coarse-grained way to manipulate the way libraries are loaded is to use the LD_LIBRARY_PATH variable. I believe it is currently used by Steam to specify its own set of libraries. Granted, this is not really a DLL injection as it is usually understood (adding code to a running process), but it is the same thing as described in the article, as far as I can tell. [0]: https://stackoverflow.com/questions/426230/what-is-the-ld-preload-trick https://stackoverflow.com/questions/426230/what-is-the-ld-pr... [1]: https://wiki.ubuntu.com/SkypeWebCams https://wiki.ubuntu.com/SkypeWebCams edit: grammar

tamrix 9y ago

Sure they can't... P.S check out Microsoft teams!

heisenbit 9y ago

suid programs and the installer is de-facto such a beast should not be written if one can avoid it. Providing users with sufficient powerful APIs and installing software on a per user level is one way to avoid this mess. Another is to delegate installation to the operating system and not rolling your own. Anyone else messing up this way may be able to point to Microsoft. Now those folks at Skype are here in a bit a pickle.

Kipters 9y ago

As far as I've seen, no one noticed that this is about the old legacy version of Skype, the "rewritten client" they talk about in the article is the current Electron-based client. That one and the UWP version are not affected by this.

ppeetteerr 9y ago

Skype needs a rewrite. I don't like saying "rewrite" but I also hate Skype's messaging system.