Slashdot Mirror

← Back to Stories (view on slashdot.org)

Skype Can't Fix a Nasty Security Bug Without a Massive Code Rewrite (zdnet.com)

Posted by BeauHD on from the back-to-the-drawing-board dept.

ZDNet reports of a security flaw in Skype's updater process that "can allow an attacker to gain system-level privileges to a vulnerable computer." If the bug is exploited, it "can escalate a local unprivileged user to the full 'system' level rights -- granting them access to every corner of the operating system." What's worse is that Microsoft, which owns Skype, won't fix the flaw because it would require the updater to go through "a large code revision." Instead, Microsoft is putting all its resources on building an altogether new client. From the report: Security researcher Stefan Kanthak found that the Skype update installer could be exploited with a DLL hijacking technique, which allows an attacker to trick an application into drawing malicious code instead of the correct library. An attacker can download a malicious DLL into a user-accessible temporary folder and rename it to an existing DLL that can be modified by an unprivileged user, like UXTheme.dll. The bug works because the malicious DLL is found first when the app searches for the DLL it needs. Once installed, Skype uses its own built-in updater to keep the software up to date. When that updater runs, it uses another executable file to run the update, which is vulnerable to the hijacking. The attack reads on the clunky side, but Kanthak told ZDNet in an email that the attack could be easily weaponized. He explained, providing two command line examples, how a script or malware could remotely transfer a malicious DLL into that temporary folder.

5 of 151 comments (clear)

  1. Linux not vulnerable by gavron · · Score: 5, Informative

    The article indicates that the Updater is the problem, not Skype. The Updater runs in a privileged environment, and is susceptible to loading non-system DLLs. The article says the same can happen on Macs and on Linux except that neither platform uses DLLs nor allows sourcing libraries from local (no-system) directories.

    E

    1. Re:Linux not vulnerable by Xenx · · Score: 3, Informative

      The article links to a bulletin on hijacking of dynamic libraries on OSX. So......

    2. Re:Linux not vulnerable by Anonymous Coward · · Score: 2, Informative

      Linux [...] In fact, I've accidentally run into library versions probems because I had a copy in my home directory along with an executable.

      There are two things you need to deliberately do to make that happen:

      Set PATH to include your home directory.

      Set LD_PRELOAD appropriately or LD_LIBRARY_PATH to your home directory.

      So you've never accidentally run into that problem. You have to deliberately create that problem in two separate and independent steps.

  2. Re:Download the offline installer? by Rockoon · · Score: 4, Informative

    The issue as I understand it is that a bit of nefarious code running in user scope can take these steps:

    1) drop a properly named nefarious dll in a tmp directory
    2) alter the userspace path environment variable that will cause skypes updater to search this folder first for that properly named nefarious dll
    3) launch the skype installer which will then load the nefarious dll into a super user scope

    --
    "His name was James Damore."
  3. Re:Static Link? by Cassini2 · · Score: 5, Informative

    While officially Microsoft supports static linking, in practice, it is necessary to use DLLs in many situations. The Microsoft official answer is at: Extension DLLs

    The practical reasons that I have been forced to use DLLs are:

    • 1. If you want your application to upgrade smoothly over the years, you have to use either the DLL calls or the windows system calls and avoid the statically linked C libraries. For instance, when the times and dates for daylight savings time change, only the windows calls get updated automatically. The statically linked libraries don't get updated. DLL libraries get updated when the DLL gets updated (which can lead to DLL Hell, but that is another story.)
    • 2. If you have an application that allocates memory in one DLL and frees it in another, then it is vital that the library that does the memory management be a DLL. Otherwise, each DLL has it's own statically linked memory mapping library, and they don't know about each other's allocations.
    • 3. (2) applies to applications that use new and delete. It also applies to applications that are ActiveX controls and using IMalloc.
    • 4. Some of the cool Microsoft libraries link to DLLs, so it doesn't matter if you want to use static libraries. You are getting DLLs.
    • 5. Only the really old languages like C++ and QuickBasic supports static linking. I'm pretty sure Visual Basic, C# and .NET all require DLLs.