Comment by korethr | Hacker News Reader

Comment by korethr | Hacker News Reader

Parent Full thread

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?

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

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.

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?

Would you really be certain a commercial company buisness is going to care about correctly packaging for a flavor of linux? Some companies wil do this, even more so if they work with FOSS and linux. But in general, especially for companies on the proprietary train, I wouldn't be so sure.

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.

Lots of programs I have try to update outside dpkg: Chrome, Intellij, VS Code.

> Lots of programs I have try to update outside dpkg: Chrome, Intellij, VS Code.

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.

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

Reply on news.ycombinator.com