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

http://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/

by nautical • 8 years ago

181 96 8 years 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

stevekemp• 8 years 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/

photonios• 8 years ago

That doesn't mean you cannot load a DLL manually from a static location: https://msdn.microsoft.com/en-us/library/windows/desktop/ms6...

mannykannot• 8 years 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.'

leeter• 8 years 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• 8 years 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• 8 years 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.

cptskippy4• 8 years 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• 8 years ago

Luckily 'they don't care about security at all'. They just looked into it for fun when the report came in.

dspillett• 8 years 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.

enzanki_ars7• 8 years 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• 8 years 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.

orblivion• 8 years ago

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.

sp332• 8 years ago

I think this is a response to the headline, which specifically mentions a "massive code rewrite".

sodapopcan• 8 years ago

"Can't you just..."

corporatocracy• 8 years ago

Bureaucracy is hard, but so is losing clients or getting sued by an enterprise customer for negligence in handling a known security hole in a timely fashion. Corporations can become extremely agile when there's money on the line.

sametmax• 8 years ago

More probably this is something they need for a reason we don't know about but won't disclose.

Amezarak3• 8 years 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_ars7• 8 years 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), the folder is write only for unprivileged users (FILE_ADD_FILE).

mtgx• 8 years 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• 8 years ago

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

INTPenis• 8 years 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• 8 years ago

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.

tmalsburg2• 8 years ago

Thank you. Just tried it and it works great in Chromium.

user54542• 8 years ago

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 "on the other side of the airtight hatchway".

taspeotis2• 8 years 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• 8 years 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.

Amezarak3• 8 years 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_ars7• 8 years 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), 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

user54542• 8 years ago

You're right. It is possible to write a file but not to list or access any other files. So it is a security bug. You could "fix" it yourself though, by using a privileged account and copy any DLLs loaded by the Skype updater into the directory.. An unprivileged user would not be able to overwrite the files.

adamkruszewski• 8 years 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• 8 years 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• 8 years 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• 8 years 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.

pier254• 8 years ago

The new Skype version has been terrible, at least on macOS.

What are some good alternatives that offer group calls and screen sharing?

pas2• 8 years ago

Hangouts, FB Messenger.

pier254• 8 years ago

Hangouts has terrible performance and I won't force people into using anything FB related.

rantanplan• 8 years ago

https://jitsi.org/

Surprisingly good. No account required, no limit on number of people, good screen sharing, works everywhere(because web-based).

shlant• 8 years 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...

bernardino• 8 years ago

I wonder what the engineering team is doing over at Skype HQ. I can't even see my message history with the latest overhaul/update. I would migrate to a new platform but most of my friends are already on Skype, thus migrating to another would be a hassle.

xrisk• 8 years ago

Discord

AlphaSite• 8 years ago

Discord has both!

saagarjha2• 8 years ago

That's because they rewrote their native Cocoa application in Electron and threw away years of work that they had put into it making it decent along with it.

rspeer• 8 years ago

I don't know what those years of work were accomplishing, but they didn't make Skype decent.

Skype was decent a decade ago, and it has declined since then.

TorKlingberg• 8 years ago

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

jessaustin• 8 years ago

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

redleggedfrog• 8 years ago

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

vforvangelis• 8 years 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.

ocdtrekkie2• 8 years 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.

Nexxxeh2• 8 years 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?

ulfw• 8 years 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• 8 years 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• 8 years 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• 8 years 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?

cesarb2• 8 years 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/ms6...

- Linux: http://man7.org/linux/man-pages/man8/ld.so.8.html

netvl• 8 years 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-pr... [1]: https://wiki.ubuntu.com/SkypeWebCams

edit: grammar

cesarb2• 8 years ago

Both the LD_PRELOAD and LD_LIBRARY_PATH variables are ignored for setuid programs, and if the program was started by something else you won't be able to change these variables. The issue here is not injecting code into a process you control, it's injecting code into a process running under a different account.

EnFinlay• 8 years ago

I'm far from an expert, but my guess is that the quote

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

joshumax• 8 years ago

I was about to say this.

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?

heisenbit• 8 years 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• 8 years 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• 8 years ago

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

tamrix• 8 years ago

Sure they can't...

P.S check out Microsoft teams!

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

Related Stories