
Skype can't fix a nasty security bug without a massive code rewrite - nautical
http://www.zdnet.com/article/skype-cannot-fix-security-bug-without-a-massive-code-rewrite/
======
user5454
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
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.

~~~
Amezarak
%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
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)),
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](https://news.ycombinator.com/item?id=16367722)

------
jmull
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
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?

~~~
netvl
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...](https://stackoverflow.com/questions/426230/what-is-the-ld-preload-
trick) [1]:
[https://wiki.ubuntu.com/SkypeWebCams](https://wiki.ubuntu.com/SkypeWebCams)

edit: grammar

~~~
cesarb
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.

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

------
jwilk
Technical information is here:
[http://seclists.org/fulldisclosure/2018/Feb/33](http://seclists.org/fulldisclosure/2018/Feb/33)

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

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

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

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

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

~~~
saagarjha
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
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.

~~~
pier25
That may be true, but the Cocoa version was still better in terms of
performance and usability.

------
INTPenis
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
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
Thank you. Just tried it and it works great in Chromium.

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

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

------
enzanki_ars
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)

~~~
cptskippy
> 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.

~~~
vorpalhex
> 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.

~~~
latencyloser
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.

~~~
patcheudor
Microsoft is still actively patching Skype. Here's an example of them patching
what sounds like a similar DLL flaw just last year:

[https://www.cvedetails.com/cve/CVE-2017-6517/](https://www.cvedetails.com/cve/CVE-2017-6517/)

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

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

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

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

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

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

------
tamrix
Sure they can't...

P.S check out Microsoft teams!

