Live data from Hacker News

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

zdnet.com

71–80 of 99 posts

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

#71
post #69

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 purpos…

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

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

#72
post #69

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 purpos…

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.

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

#73
post #26

The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?

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.

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

#74
post #71
post #69

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 purpos…

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 incompati…

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.

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

#75
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.

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

#76

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.

They currently can't get my messages to reliably send, stop my UI from turning to Korean, keep my pinned chat groups at the top, or make the answer call button work reliably.

I wouldn't get your hopes up

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

#77
post #69

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 purpos…

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.

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?

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

#78
post #26

The new Skype version has been terrible, at least on macOS. What are some good alternatives that offer group calls and screen sharing?

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.

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.

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

#79

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

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

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

#80

Earlier quoted context omitted.

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.

Not sure, but based on the image in the stackoverflow link, it states that it has FILE_ADD_FILE, which translates in the GUI to “Create files / write data,” which I would assume means that overwrites are possible. Don’t trust my word on that though as I am no expert. Will try that a bit later and see what happens.

Given the name, you should assume that it specifically prevent from overwriting files.

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.

Post reply on HN