Introduction

Shared Object files (.so files) are a compiled library file type following the ELF (Executable and Linkable Format) structure. They’re used by Linux and Unix-based operating system like Ubuntu, Debian, and CentOS, and they allow applications to share functionality by dynamically loading various features at runtime.

In this article, you’ll learn about .so files in more detail, how they interact with the dynamic linker, and why they’re extremely dangerous file types when threat actors exploit them. We’ll look at some real-world threat examples involving malicious .so payloads, and we’ll take a broader look at the techniques attackers generally use to bypass upload protections when delivering .so payloads.

At the end, we’ll discuss how Cloudmersive’s Advanced Virus Scan API protects against .so-based attacks with deep content verification and malware signature detection.

How Shared Object Files Operate in Linux and Unix Systems

Shared Object files serve as dynamically linked libraries in Linux systems. If you’re more familiar with Windows systems, their comparable file type is .dll. These file types are designed to load at runtime, rather than compiling directly into the program binary – and this benefits applications tremendously. It makes them smaller, easier to maintain, and more efficient because they’re sharing common functionality.

Examples of .so files in action are easy to come by. When a media player on Ubuntu plays an MP3 file, for instance, it needs a library to handle file decoding – and it isn’t the only application that needs to do that. So, instead of carrying that functionality independently, it loads a shared library. That library is only stored and loaded once into memory.

The key concepts to bear in mind here are Dynamic Linking, Dynamic Linkers themselves, and ELF structure. These are shared ideas across most operating systems.

1. Dynamic Linking addresses the idea that applications should link to external code while running rather than during the compilation process.
2. Dynamic Linkers are the system components (e.g., ld-linux.so) specifically responsible for finding and loading dynamic link files into memory.
3. ELF Format defines the specific way in which executables and shared objects are structured on the OS.

Linux and Unix-based systems provide welcome functionality in managing libraries. Toos like LD_LIBRARY_PATH, ld.so.conf, and rpath, for example, make it possible for users and/or applications to define where libraries should be loaded from. This is a powerful capability – but attackers are aware of it, too. It creates opportunities for path hijacking and injection attacks which are very difficult to mitigate.

Why Shared Object Files Pose a Serious Security Risk

When shared library files are used malicious (or improperly), they become a serious liability. Sophisticated attackers with deep knowledge of OS behaviors and .SO file structure can exploit these dynamic linking files in ways that don’t require any actual changes to a program’s main executable.

If, for instance, an attacker uploads a malicious .so file to a web server that uses a plugin architecture, they might gain the opportunity to trigger malicious code during normal operations without leaving an immediately noticeable trace.

On the extreme end, attackers might replace or modify system-wide .so files like libpam.so (used during login) to include backdoors that give them persistent and potentially privileged access into a system. That’s an ideal situation for an attacker to be in.

In environments running CentOS, Debian, or Ubuntu, these risks are particularly amplified. In these examples, many services dynamically link to core .so files, providing numerous targets for exploitation.

Below are brief summaries of some of the most common techniques employed in .SO-based attacks.

1. LD_PRELOAD Injection: Attackers can manipulate the LD_PRELOAD environment variable to load malicious .so files before system libraries. This variable was originally created as a debugging and development tool allowing developers to override wrap functions in shared libraries without additional modification. It tells dynamic linkers to load specified shared objects before any other libraries when launching a program.

2. Library Hijacking via Path Manipulation: Any application that uses a relative path can be tricked into loading attacker-controlled files. Attackers can place malicious .so files in a directory they know the application searches first – like the working directory, for example. If the application looks for the .so file without specifying a full path, and the attacker’s version of that file comes up first in the search order, that version will be loaded at runtime. This results in arbitrary code execution in the context of the application.

3. Shared Object Payloads in Compressed Archives: Archives are a common obfuscation tool used in myriad upload- and file-transfer-based attacks. That’s certainly the case in .so-based attacks too. Since most antivirus (AV) and content protection systems are configured to treat executable and dynamic linking file types as inherent threats, attackers like to bury their .so payloads in compressed archives (like ZIP, TAR, 7Z, etc.) to evade detection. This assumes security policies aren’t configured to unpack and scan the archive contents recursively.

4. System Persistence: Attackers can gain persistence (i.e., long term access to a system) by replacing or modifying legitimate .so files with malicious versions of those same files. If these files break into a system and run without immediate detection, they’ll load automatically during system boot or user login until they’re cleansed from the system. That means malicious code can literally become an inherent routine in the operating system. This gives attackers long-term access to a system, allowing them to monitor activity and re-establish control after system reboots. It’s one of the worst-case-scenarios for any cyberattack.

.SO Vulnerabilities in the Wild: CVE-2021-4034

Back in 2021, a critical Linux vulnerability was identified. This showed that environment manipulation could cause a legitimate application – in this case, pkexec – to load a malicious .so file.

By injecting a crafted shared object, an attacker could exploit this vulnerability to gain root access to a system without any authentication. This vulnerability highlights how shared objects can quickly become weapons under the right set of conditions.

Bypassing Security Policies with Basic Shared Object Manipulations

There’s a common misconception that extension blocking solves the problem of mitigating insecure files in file upload- and file transfer-based attacks. It’s important to dispel this logic.

Attackers can easily disguise .so files (and many other insecure file types) with manually changed extensions like .jpg or .txt and re-name the file correctly after it enters the target system. Shared Object file headers can also be spoofed to show non-executable internal file signatures.

Additionally, as we alluded to in the prior section, .so files can be nested deeply within archives – often more than one archive at a time. There’s nothing stopping an attacker from hiding .so payloads in a .tar file compressed in a .zip file compressed in a .rar file.

In classic trojan-type attacks, malicious .so files can be snuck into otherwise legitimate .deb packages as “installer bait”. Downloading apparently legitimate software from illegitimate websites can initiate this type of attack.

Detecting Shared Object Threats with Cloudmersive

Cloudmersive’s Advanced Virus Scan API is designed to identify sophisticated threats by looking deep under the hood of each file and its nested objects.

Files with spoofed extensions are identified through rigorous content verification, confirming that the file contents don’t rigorously conform with the formatting requirements associated with the given file extension. Archives are unpacked and scanned recursively, ensuring each subfile, folder, and nested sub-archive is opened and scoured thoroughly. Traditional malware signature detection policies take care of known virus and malware libraries, and heuristic & behavioral analysis identify unusual or obfuscated patterns typical of malicious shared libraries.

Whether a malicious .so file is named “helper.jpg” or embedded 5 layers deep in a .tar.gz, Cloudmersive’s Advanced Virus Scan engine will uncover and identify the true nature of the underlying content.

Conclusion

Shared Object files are essential to the operation of Linux and Unix systems, but they also represent a significant attack surface. Exploiting the dynamic linker, hijacking path resolution, or injection malicious .so code into legitimate workflows can give attackers powerful control over a system. As ever, prevention is better than cure, so it’s important to carefully defend against .SO-based attacks with rigorous content inspection.

*To learn more about defending against .SO threats with Cloudmersive’s Advanced Virus Scan API, please contact a member of our team.