Skype can't fix a nasty security bug without a massive code rewrite
zdnet.com
zdnet.com
> 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".
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.
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.
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
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
The windows filesystem has more than a dozen specific permissions, similar to advanced acl on Linux, that allows very fine grained permissions.
This allows to have shared folders where users can do anything, except delete the directory itself or modify files created by other users.
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.)
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?
I'd recommend the following study material:
- Windows: "Dynamic-Link Library Search Order" https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...
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-pr... [1]: https://wiki.ubuntu.com/SkypeWebCams
edit: grammar
> "Windows provides multiple ways to do it," he said. But DLL hijacking isn't limited to Windows, he said -- noting that it can apply to Macs and Linux, too.
is an artifact of the reporting, and not worth head scratching about.
The exploit would look completely different on Mac or Linux. As far as I know.
My Debian machine updates software through apt + dpkg, and I installed Skype via the Skype repository. Why would Skype for Linux then choose to bundle its own updater, thereby breaking the integrity a package manager provides?
If skype is in the base set of packages, I'd expect debian to require proper packaging. But if this is in some third party package, there are no such guarantees.
That said, maybe some third party package that just installs the normal (auto-updating) version into /opt or /usr/local might be an option. It is better than having no installer, and shouldn't break too much of your package manager. Proper clean-up on uninstall is the only real issue I can think of.
Chrome and vscode have their own apt repositories. I don't know about intellij, but at least for the other two you just have to install them using their repos, and not using the dpkg package directly.
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.
What are some good alternatives that offer group calls and screen sharing?
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 ) gains enough momentum to become a well established alternative.
Surprisingly good. No account required, no limit on number of people, good screen sharing, works everywhere(because web-based).
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...
Skype was decent a decade ago, and it has declined since then.
Or not at all, I haven't had a need for skype but the last client I used was the web client on Linux.
It's also trivial to fix: just create a directory in Temp and put the executable there instead of directly in the Temp directory.
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.
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.
There have been a lot of write-ups on this topic on Raymond Chen's blog, here is a good example:
I doubt this was intentional at first, but the fact that they don't want to fix it is very fishy.
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.'
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.
To anyone going "but what if they replace the binary!" well then they've already gotten past the air-tight hatchway.
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.
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.
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.
“If this was a small startup I couldn’t see those being hurdles but at a behemoth like MS with an almost 2 decade old product I can.”
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.
The bike shed won't get painted to a new color just because a the new middle manager asked for it.
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.
In a large enterprise the process isn't too hard, it's just complicated.
I was neither justifying or admonishing MS for this issue, I was just responding to a gross trivialization of the process that I found offensive.
%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.
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.
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.
P.S check out Microsoft teams!