I was reading this wikipedia article explaining why Linux is generally less susceptible to malware than Windows when I encountered this statement:
If an infected binary containing one of the viruses were run, the system would be infected. The infection level would depend on which user with what privileges ran the binary. A binary run under the root account would be able to infect the entire system.
What happens when an infected binary is run? It takes advantage of the user’s access level on the system, AND/OR configured attacks against known system security holes to:
- Attempt to prevent detection possibly by intercepting or disabling antivirus software
- Propagate itself to one or more locations in the system
- Perform any additional configured tasks such as joining a botnet, copying files, &c
How does Linux prevent most infections?
- User accounts do not under normal circumstances have the ability to change system files
- Cryptographic checksums are used to verify that installation packages have not been unofficially modified
- System services that accept outside connection such as SMTP, WWW, Network file access, &c run under low privileged accounts
Windows has similar mechanisms (e.g. User Access Control, file and service permissions, &c) but there are a lot more users on that OS so it is a more attractive target to malware authors.
There are two problems that facilitate malware propagation despite these protections:
- Once the user escalates to an administrative permission account/permission level to install a program that program can do just about anything to the system
- The system cannot tell that a previously installed program has been modified/infected.
Because the malware has near total access to the system while installing it can achieve its goals of self preservation and accomplishing its mission.
But wait… Why does an installer need total access to the system?
- It may have to remove old copies of its own files (i.e. self updating software like browsers, antivirus, editors, etc)
- It may have to change/add system configuration files (e.g. the registry in Windows, device drivers, etc)
- It may have to change/add common libraries (e.g. C++, VB, .Net runtime libraries)
- It may need to add/change/remove a service (daemon)
What does the malware target in order to ensure its propagation? Files/programs (and related configuration) that the system automatically trusts and runs whenever it starts like device drivers, system services, and common libraries.
The problem is some programs (input devices like keyboards, external storage devices like USB drives, etc) need to change/add device drivers while others do not. Some programs may need to run as system services (like screen savers, internet proxies, antivirus) in order to perform their functions. For convenience many programs automatically update themselves. And many, many programs use the same common libraries.
What to do? Let’s take a look at what modern browsers are doing to block malware infection. They run programs in a “sandbox”, a safe area, wherein the program can do whatever it wants. If the program wants to interact with system services (e.g. files, registry) it has to get permission. What if all programs ran in a sandbox including the installer?
The sandbox manager would manage all interaction between the program and the OS:
- Programs can do whatever they want within their own home directory (e.g. c:\program files\Microsoft Word). This covers the ability to auto update.
- Programs cannot access files in other program home directories.
- Programs cannot access system files.
- Programs would have to ask user permission to register device drivers or services. All files would live in the program home directory, the system would merely make a note of the device driver or service home directory.
- Registry/system configuration values could be read from the system but changes would be written to a local copy. The sandbox would manage providing whichever value was most recently updated.
- There would be no common libraries shared between programs. The program has to bring everything it needs and can only use what it has. Disk space is cheap compared to a malware infection.
- Services would run sandboxed as well.
- Likewise the OS and users have home directories and can do what they want in them but their access to other home directories would be sandboxed.
This makes the sandbox a single point of failure. If something escapes it can do anything right? Who’s watching the watcher?
We might be able to block executable files from being modified except by an installer. The installer would store the binary in the requested location and keep a cryptographic hash of the file in an encrypted archive. Then when a binary is loaded for execution by the sandbox the loader compares its cryptographic hash with the one in the archive. If they match it continues to run, if not it halts and reports a problem. The installer and loader might be independently self updating or update as a set.
These changes appear to solve the problems of an escalated program being able to do anything to the system and the system being able to detect an unauthorized change. They also substantially reduce malware’s ability to propagate by sandboxing all activities and eliminating shared libraries and configurations as propagation vectors.