zz:
1. Loading Kernel Modules
2. Modifying Swap on Disk
In a modern kernel, the swap (or page) area on disk is designated for excess virtual memory allocated by a process (or the kernel) which is not currently being stored in physical memory.
The contents of physical memory are written (or paged) to disk and the physical memory reassigned by the OS kernel.
The swap area on disk can either be a partition (as is commonly used on Linux), or a file (as is common on Windows and Mac OS). Regardless, if elements of the kernel can be swapped out to disk, and that area of the disk is writable by user-space applications, then there exists the potential to change kernel code or data arbitrarily. Applications such as the Bluepill installer can modify the kernel though forcing kernel pages to be swapped out, modifying those pages on disk, and then causing the pages to be pulled back into physical memory and the code on them run.
While Linux, in contrast to Windows Vista, does not appear to swap kernel code out to disk, it still allows kernel data to be swapped, and proposals exist for swapping kernel code.
3. Memory Access Interfaces
The kernel may export to applications an interface allowing arbitrary access to the physical address space of the machine.
This allows an application to:
（1） Talk to hardware mapped into memory: On many systems, reads and writes to certain ranges in the physical address space are used for communication with hardware (as opposed to the read/write being serviced by the RAM controller and underlying physical memory). Hardware devices such as the video card are controlled by accessing specific areas of the physical address space.
In Linux, the X server is one such application that relies on being able to access areas of physical memory assigned to the video card.
（2） Read from and write to memory allocated to another application already running on the system: While each process on a modern desktop is assigned its own virtual address space, physical memory is divided up across all processes on the system. By accessing the physical address space corresponding to RAM regions used by other processes, a process can modify or examine another process’ state on the system.
（3） Read from and write to memory allocated to the kernel: Similar to point 2, a process may be able to read and write to physical memory currently allocated to the kernel. While such functionality may be useful for kernel debugging, and entertaining for Russian roulette(A game where two or more players write random bytes to random areas of kernel memory and the one who crashes the computer looses - ), the feature is most commonly used by rootkits.
A user-space application will typically open the related device interface exported by the kernel, and then use seek, read, and write operations to modify the contents of the physical address space.
Typically, permission to open/use this interface is restricted by the kernel to only applications running with the highest privileges (super user). On Linux, applications gain access to physical memory through the /dev/mem device node, with the /dev/kmem device node allowing access to kernel memory specifically (other device nodes such as /dev/mergemem may also provide access to physical memory). On Windows, the device node for modifying physical memory is \Device\PhysicalMemory.
4. Hardware Interfaces to Kernel Memory
Certain hardware configurations may provide methods allowing a user-space application write access to kernel memory through functionality of the underlying hardware. For example, user-space applications may have access to a device on the FireWire bus. By sending specific commands to this device, it may be possible to have the device read and write to arbitrary areas of physical memory, with the result that the kernel can be modified.
FireWire, and ACPI may provide mechanisms for updating physical memory. Because the kernel mediates access to the underlying hardware, applications wishing to make use of hardware in modifying the kernel must request such access through the kernel.
5. Kernel Tuning Parameters
Many aspects of the running kernel can be tuned at run-time. While the ability to tune the kernel through modifying values made available to user-space applications does not necessarily result in a compromise, care must be taken in preventing vulnerabilities caused by incorrect parsing of untrusted values provided by user-space applications. Care must also be taken to avoid exporting functionality which can be used to modify the kernel in arbitrary ways.
On Linux, the operation of the kernel can be modified through reading and writing to files in /dev, as well as to files in the virtual file systems procfs, sysfs and configfs. Parameters passed to the kernel when loading a module or booting the kernel can also be modified. While some kernel parameters exported to user space do not directly depend on specific hardware, others do (e.g., CPU and display power management).
6. Boot Process Mechanisms
During the course of booting a system, typically firmware embedded on the commodity desktop will be responsible for loading and running the boot loader. The boot loader, in turn, is responsible for loading and running the OS kernel（2
In the case of Linux, the boot loader may also be responsible for loading an initial RAM disk, which contains kernel
modules required in order for the kernel to be able to access storage hardware and continue booting）.
If a user-space application has the ability to modify the firmware, boot loader, or kernel which will be run during the boot process, the application can modify the kernel which is run after the next reboot. Such an approach would typically resemble the following steps: 1) Modify the kernel or boot loader on disk; 2) Cause the system to reboot; 3) When the system comes back after the reboot, the modified kernel will be running. Since the kernel is loaded and executed by the boot loader, the opportunity exists for a modified boot loader to modify the kernel after it is loaded from disk, but before it is run (modified firmware can also alter the kernel). Depending on the firmware used during boot, the boot loader responsible for loading and executing the kernel may exist in EEPROM, in the boot sector, or in a partition.
For BIOS based machines, the BIOS will typically load and run the boot loader, which is stored in the first few sectors of the drive, prior to the sectors allocated to the file-system. The boot loader, in turn, is again responsible for loading and executing the kernel. For EFI based machines, a FATbased file-system is used to store code used during machine boot-up. The EFI approach allows both scripts and executables to be run by the firmware during the boot process, prior to the kernel being loaded and run.
Replacing the running kernel image without rebooting is possible in Linux through the kexec system call. This functionality allows the booting of an unauthorized new kernel on a system, effectively allowing arbitrary kernel execution. To protect the kernel, we must also therefore disable the booting of arbitrary kernels through kexec.
7. Kernel Security Vulnerabilities
Barring the ability to modify the kernel through any of the above methods, the only way left is apparently through discovering and exploiting a security vulnerability in the kernel. Typical application vulnerabilities (e.g., buffer and integer overflow exploits) can exist in the kernel as well, facilitating its compromise. The kernel can additionally be compromised through exploiting unchecked references to application memory (e.g., null pointers, and pointers to application data).
解决方法：
1. To prevent arbitrary code being inserted into the kernel, the loading of kernel modules must be
restricted.
2. Through Swap
The OS kernel is responsible for mediating all access to underlying system hardware, including storage devices. By restricting access to those areas of the disk being used by swap, the integrity of kernel memory can be protected. This includes restricting arbitrary writes to both the swap file, as well as to those sectors of the disk occupied by swap (e.g., even a root level process must not be allowed to perform arbitrary writes to either /dev/hda or /dev/hda1 if a swap file or partition exists on the drive).
While the Linux kernel does not currently attempt to restrict root’s ability to write to arbitrary blocks on disk, Windows Vista does. Vista prevents applications (even those with super-user privilege) from performing raw writes to volumes where the file-system is currently mounted. On Linux, a similar protection mechanism could be added. This protection rule would suffice for protecting both file and partition-based swap against arbitrary modification at the block (or raw) level.
To protect against file-based swap being modified, the kernel would need to additionally limit the ability to write to the swap file. In Linux, the ability to modify the swap file is not normally protected by any additional access controls beyond those protecting other (non-swap) files on the system. The Linux kernel would therefore need to be modified to treat the swap file as special and disallow write attempts (even those by root). Windows Vista already employs such an approach to prevent modifications to the page file.
3. Through Memory Access
If write access to physical pages containing kernel code (or data) is allowed, the potential exists for an application to modify the running kernel. If only read access is allowed to kernel memory, the threat of being able to modify kernel code is mitigated (although the threat of a user-space process gaining access to sensitive kernel or application information is not).
On Linux, the kernel can restrict write access to /dev/mem and /dev/kmem. These restrictions have been configurable
since version 2.6.26 of the main-line Linux kernel, and need only be enabled when building the kernel. Before being introduced in the mainline Linux kernel, the options had been used in Fedora and other Red Hat kernels for 4 years without any known problems. The potential exists to restrict some of the actions of user-space applications on physical memory without completely disabling the interface. The kernel can selectively allow access to memory mapped hardware without allowing access to those areas of physical memory associated with the kernel. This was the approach taken for restricting access to /dev/mem in Linux version 2.6.26. Only those areas of physical memory associated with I/O (e.g., the graphics card) can be accessed through /dev/mem. Of course, the abilities made available through memory mapped I/O still need to be limited such that hardware can not be used to modify the kernel (see Section 2.4). No areas of the physical address space associated with RAM can be written to through /dev/mem when the option is enabled. /dev/mem cannot be disabled entirely as X (the graphical display manager typically used in Linux) uses it to communicate with the video card.
In Windows, writes directly to physical memory are done using the \Device\PhysicalMemory device. Any attempt to access this device node by a user-space application, however, has been denied since Windows 2003 SP1.
4. Through Hardware Access
For user-space software to gain write access to kernel memory through the underlying hardware, the kernel would first have to allow the user-space applications sufficient access to the hardware device. The kernel is typically responsible for mediating all access to the underlying hardware, and we therefore see no fundamental reason why the kernel would not be able to sufficiently limit allowed hardware requests in such a way to prevent user-space applications from modifying the kernel. This may involve restricting both the hardware interface and allowed operations exposed to applications. The exact method for ensuring that applications cannot modify the kernel via hardware is highly dependent on the exact hardware in question, and therefore beyond the scope of this paper.
The hardware I/O memory management unit (IOMMU) presents the equivalent of virtualized memory to hardware devices, restricting the physical memory which can be accessed by a hardware device to only those areas which are assigned to it by the kernel through the mapping stored in the IOMMU page tables. The IOMMU can be used to prevent devices from writing to arbitrary memory (and hence modifying the kernel).
5. Through Kernel Tuning Parameters
The kernel can be tuned by modifying parameters made available through virtual file systems, as well as tuning parameters passed to the kernel during boot and module loading. While kernel authors limit the ability to modify many kernel parameters to those processes running as super-user, we are not aware of any specific focus on preventing the super-user from arbitrarily modifying the kernel through available tuning parameters. This is not surprising, since in the past much of the focus was on preventing unprivileged users from gaining kernel level privileges.
6. Through Changing the Boot Process
Though it requires a machine reboot, updating of the kernel image on disk remains an avenue through which the OS kernel can be modified. There are two methods for preventing a modified kernel from being run on a system reboot: (1) preventing arbitrary modification to disk blocks containing the boot loader, kernel, or kernel modules; or (2) detecting and refusing to execute a modified boot loader, kernel, or kernel module. Approach 1 was attempted for boot-sector virus protection, but was limited to those applications using the BIOS to overwrite the boot sector. Approach 1 has also been attempted with read-only media (e.g., booting off a CD). A more comprehensive implementation of approach 1 uses the currently running kernel to enforce that disk blocks containing the boot loader, kernel, and kernel modules cannot be written to arbitrarily. Approach 2 has been used on more specialized hardware such as video-game consoles, and kernel module signing has been used.
7. Through Exploiting a Vulnerability
There exist countless tools for detecting and mitigating software vulnerabilities (e.g., static analysis and address space layout randomization). Many of these tools may apply equally well to mitigating kernel vulnerabilities. Some approaches for mitigating kernel level vulnerabilities have been developed specifically for the kernel. Since Linux version 2.6.23, the feature has existed to prevent null pointer dereference vulnerabilities in the kernel from causing arbitrary code execution. The approach works by preventing an application from allocating memory at address 0. While super-user processes can disable this mechanism, most user-space processes are now prevented from exploiting a null pointer dereference vulnerability (except for denial of service).
1. Using Secure Boot
Secure boot approaches can be used to verify the boot loader and operating system as it is loaded. Secure boot involves having each component in the boot process compare a cryptographic hash of the next component to-be-run to a known-good value. If the computed hash is equal to a known-good value, the next component is executed, otherwise the currently running component avoids running the component for which verification failed (this is in contrast to authenticated boot, where each component is hashed, but execution of a component is not prevented).
2. Using Fine-Grained Mandatory Access Control
AppArmor and SELinux are two approaches which provide additional finegrained access control for the Linux kernel. Both use the Linux Security Module (LSM) hooks available within the kernel, but base their protection mechanisms on different sources of information. While SELinux uses security contexts (labels) in making security decisions, AppArmor confines applications based on their paths and the paths of the resources they want to access.
AppArmor confines applications only if there is a profile defined. Applications without associated profiles run unconfined, limited only by the discretionary access control (DAC) permissions on the system. For each application, a profile will specify the permissions on files that application is allowed to access. If a permission is not specified, then the access is denied. AppArmor can also meditate use of POSIX capabilities, and network access. While profiles may vary across installations, AppArmor has the ability to prevent modification of the kernel by blocking write access to devices exposed through the file-system. An application’s access to devices exposed under /dev can be denied, as can access to /boot and /lib/modules. AppArmor has the potential to limit, but does not provide blanket protection against any application modifying the running kernel.
SELinux provides a mechanism for administrators to label OS objects associated with kernel inputs and data structures. Access decisions are made based on the labels assigned to the object. Most deployments of SELinux use the reference policy [64], which provides (1) labels for some processes that may run on the system, including the kernel and multiple well known applications; (2) labels for file-systems and files, including kernel relevant files; and (3) the rules that specify access control (what subjects have access to what objects, and what kind of access). The reference policy does not attempt to restrict the permission of many services, including package managers and virtualization tools – these services are allowed to perform raw disk IO and write to kernel images. Other applications, such as the X server, are granted access to kernel memory as a sideeffect of being granted access to video card memory (SELinux does not require that the kernel be built with limited access to /dev/mem, as discussed in Section 3.3). While the loading of kernel modules is restricted to the two programs normally tasked with performing the loading operations – insmod and modprobe – other applications are allowed to call insmod and modprobe to perform the module loading on their behalf. In practice, SELinux ends up mainly being used to confine network-facing daemons, a policy goal first proposed by AppArmor.
3. Preventing Hard Drive Writes
Many proposals exist which attempt to either restrict the writing to hard drive sectors, or detect malicious writes. Butler et al. proposed a method where regions of disk were marked as requiring a specific USB key to be inserted before they could be updated. The approach works at the block level, underneath both the file-system and kernel. Blocks on disk become marked as associated with a USB key when they are updated while the key is installed, and can subsequently only be updated when the USB key is inserted. Pennington et al. proposed implementing an intrusion detection system in the storage device to detect suspicious modifications. Strunk et al. proposed logging all file modifications for a period of time to assist in the recovery after malware infection.
4. Using VMMs or Other Hardware
By far, the most common approach for dealing with OS kernel level malware is to have a detection mechanism installed outside the kernel that observes the kernel. Copilot, for example, operates as a distinct hardware device on the system. It monitors the OS kernel in an attempt to detect changes to static kernel elements such as privileged processor code. It also provides a mechanism for partial restoration of changes made by malicious kernel rootkits. Petroni et al. likewise use a system device to detect changes in the OS kernel, but concentrate on protecting dynamic data structures.
Carbone et al. take a snapshot of memory allocated to the running kernel and attempt to map all dynamic data contained within it. Using the memory snapshot and the corresponding kernel source code, they create a directed graph of memory usage within the snapshot. They then check function pointers and detect hidden objects as a method for detecting kernel rootkits. The approach operates offline, and works to detect rather than prevent rootkits. There is also extensive literature suggesting various approaches leveraging virtual machine monitor (VMM) technology to either detect or prevent kernel malware.
