Loadable Kernel Module Programming and System Call Interception
After a machine is compromised, malicious users tend to replace commonly used programs with trojan horses (programs that execute malicious instructions in addition to their normal functions). Packages of such trojan horses are widely distributed over the Internet and are easily accessible by anyone. Therefore, it becomes important to protect programs from being replaced by malicious users.
In order to protect against such problems, our next example involves the interception of various system calls, most importantly sys_execve, to check the hash of the program to be executed against a known hash present in a database file. The program is denied execution if the hashes do not match, and such an attempt is logged. One way to implement this is seen in the following steps:
Intercept sys_execve and compute the inode of the file being executed, than compare it with the inodes of the files present in the hash database. Inodes are data structures that contain information about files in the file system. Since there is a unique inode for each file, we can be certain of our comparison results. If no match is found, call the original sys_execve and return. However, if a match is found, compute the hash of the program and then compare it with the hash present in the hash database. If they match, call the original sys_execve and return. If they do not match, log the attempt and return an error.
Intercept sys_delete_module. If called with our module name as the parameter, return an error. Our module cannot be deleted.
Intercept sys_create_module, and return an error. No more modules can be inserted because we do not want any malicious module to be able to intercept the sys_execve described in step 1.
Intercept sys_open to prevent our hash database and log file to be opened for writing.
Intercept sys_unlink to prevent deletion of the hash database and log file.
Note that the above does not offer complete protection, but it is a simple first-step implementation. For example, a malicious user may modify kernel symbols in /dev/kmem or use raw device access to the hard disk, and bypass open to write to the hash database file. Also, since our implementation is only a loadable module, a malicious user can alter our /etc/rc.d files and stop our module from being loaded the next time the machine is rebooted. In addition, various other system calls exist that could cause our hash database and log files to be altered or deleted.
At this time, it becomes important to acknowledge the possibility of loadable module support being misused by a malicious user. For example, the sys_execve function call can be intercepted to invoke a trojan program instead of the one intended, and system calls such as read and write can be intercepted to perform keystroke logging. Therefore, the flexibility and power of loadable kernel modules can be misused by malicious users who may have gained access to the system. See Resources for a web site that has details of this example along with complete source code.
Gustavo Rodriguez-Rivera is a Visiting Assistant Professor at Purdue University and is also software architect for Geodesic Systems. His interests are operating systems, networking and memory management. He can be reached at email@example.com.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
34 min 59 sec ago
- Please correct the URL for Salt Stack's web site
3 hours 46 min ago
- Android is Linux -- why no better inter-operation
6 hours 1 min ago
- Connecting Android device to desktop Linux via USB
6 hours 30 min ago
- Find new cell phone and tablet pc
7 hours 28 min ago
8 hours 57 min ago
- Automatically updating Guest Additions
10 hours 5 min ago
- I like your topic on android
10 hours 52 min ago
- This is the easiest tutorial
17 hours 27 min ago
- Ahh, the Koolaid.
23 hours 6 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?