21–30 of 99 posts
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.
I've had good experience with Jitsi Meet ( https://meet.jit.si ). You can run it from a browser, it's very pleasant and works quite well. Plus, it's open source.
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 de…
> 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.
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.
From 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 "o…
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.
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.
Earlier 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/
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 r…
What are some good alternatives that offer group calls and screen sharing?
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 de…
> 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.
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 de…
> 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.
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.
The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?
From 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 "o…
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.
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.