Oh yes please, whatever the reason. The current Skype is rubbish. Make us something nice!
Skype can't fix a nasty security bug without a massive code rewrite
41–50 of 99 posts
Re: Skype can't fix a nasty security bug without a massive code rewrite
#42Earlier quoted context omitted.
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.
%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.
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), C:\Windows\Temp (%systemroot%\Temp redirects here, and is the folder Skype accesses from, is write only for unprivileged users (FILE_ADD_FILE).
Preliminary testing shows that I was able to write there with out any problem. No way for me to read it at the moment though...
Edit: As noted by another user here, yes, it is writeable. https://news.ycombinator.com/item?id=16367722
Re: Skype can't fix a nasty security bug without a massive code rewrite
#43Earlier quoted context omitted.
> 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…
As a former Microsoft employee, my experience was that the longer a product was around, the harder it was to figure out who understood any part of it well enough to change something. I would guess I averaged about 10 lines a month on my project that had been around for decades. Making even slight tweaks required dozens of meetings, design discussions, functional and performance testing, etc. etc. It took an eternity.
Microsoft is still actively patching Skype. Here's an example of them patching what sounds like a similar DLL flaw just last year:
Re: Skype can't fix a nasty security bug without a massive code rewrite
#44The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?
Discord
Re: Skype can't fix a nasty security bug without a massive code rewrite
#45An interim solution could be to install the UWP Skype app from the Store. I don't think it relies on Updater.exe for patches.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#46I 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…
> 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.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#47Earlier quoted context omitted.
> 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.
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 ), the folder is write only for unprivileged users (FILE_ADD_FILE).
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.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#48Earlier 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…
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.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#49Earlier quoted context omitted.
> 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.
> 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…
> 24 - 72 hours for a fairly critical and relatively easily solved security bug
Let's see. How many microsoft employees would it take to change a lightbulb? ;-)
https://blogs.msdn.microsoft.com/ericlippert/2003/10/28/how-...
Highlight:
> That initial five minutes of dev time translates into many person-weeks of work and enormous costs
This is just to add an interesting article on top of the sibling comment from the MS employee; nothing's easy in the engineering of a large product.
Re: Skype can't fix a nasty security bug without a massive code rewrite
#50I 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 enjoyed your retort, but I'll note that it being "just a couple lines of code" at least should imply that this is no harder than other security fixes, which somehow do make their way out faster than main releases.