Linux Kernel instant intrusion detection security enhancement-kernel patch to prevent Buffer Overflow

Linux Kernel instant intrusion detection security enhancement-kernel patch to prevent Buffer Overflow-Linux general technology-Linux programming and kernel information. For details, see the following. 3. kernel patch to prevent Buffer Overflow
Ice cubes
In this section, we will describe a Linux kernel patch with a buffer overflow that is very harmful to system security.

3.1 buffer overflow vulnerability attacks

The restrictions on queue resources in C language can easily cause a memory overflow. There are many well-known methods to use the buffer overflow vulnerability to attack the system. They can exploit the buffer overflow vulnerability to insert malicious system commands into the system to obtain a privileged shell to control the system. The main attack is to use programs run by the root or administrator to insert some commands, and these commands have the root operation permission.

A root process can be divided into the following types:

Interactive: This is a standard superuser process. The User ID (UID) and valid user ID (SUID) are both 0. This user has no permissions because the user has obtained all the control permissions on the system.
Background: This mainly refers to the background processes of programs that run at the root user level when the system is started. Although the technology in this area is complicated, it can also be used to attack the buffer overflow vulnerability in most cases.
Setuid process: this process has a user tag (UID, EUID), and the value must be greater. Therefore, a process from setuid to root indicates a macro definition.
# Define IS_SETUID_TO_ROOT (proc )! (Proc)-> euid) & (proc)-> uid

Different systems of this macro may have different definitions.

In the following content, we will discuss what kind of root process in the kernel can be identified immediately.

3.2 background root program

Only one Unix system can run the root program in the background. In most cases, system administrators do not enable them directly or control their execution. Therefore, as we mentioned earlier, such privileged programs are considered as the primary targets of buffer overflow vulnerability attacks. It can be divided into the following types:

Background programs run directly by the initialization script in the system. Like the inetd super server program in the network server, there is a web server in it, and the mail server (mainly sendmail) is started in this way. Another example is the syslogd background program.
The network server is started by the inetd super server to perform services such as remote access (telnet) and file transfer (ftp.
Program Execution starts a specific background program, most of which are run at system startup. (Belongs to type Level 1 .)
The program will be started with the at command at a specific time in the future. In fact, these programs can be considered as level classifications of specific types.
The program runs in the background during interactive sessions. These are applied only for some specific reasons.
These programs generally do not have a control terminal. To tell them that they are not running in the program interaction mode, we can use the macro definition below.

# Define IS_A_ROOT_RAEMON (proc )! (Proc)-> euid) & (proc)-> tty = NULL)

Here, we first check whether the program runs at the root level, and then we check whether the program has a control terminal.

3.3 System Call tools

To prevent dangerous buffer overflow attacks, some simple code is added to the following system calls.

Execve (executable-file ,...) : This system call allows an embedded setuid process to call an interactive shell. To prevent such calls and other simple attacks, we define an original check to determine whether the called process has root permissions. If no, the system will not continue the check. This system call can continue to run, and other actions of the system call will be ignored. If the called system call has the root permission, and the setuid is root, the access control database determines whether the executable-file parameter can be called by the setuid process. If yes, the call will continue. Unless the call is not abandoned by the system of intrusion processing. In other cases, these calls are recorded in a log file.
Setuid: Any process with the root permission or root permission in the background can be considered as a potential attack target. For such processes, we use specific check programs to filter these system calls. A setuid process can run setuid (0) calls in interactive mode before calling other systems that do not run the setuid process. In this way, we can skip all the checks we have introduced. For this reason, we must load a piece of code to supplement the setuid system call to prevent a setuid process from obtaining the root UID permission.
Chmod: When we call a setuid process. You can apply Chmod to obtain the write permission for sensitive files. (For example, password files ). To prevent such and other related attacks, a check code is added to the chmod System Call code to prevent a setuid process from modifying the access permissions of general files or directories.
Chown: When a setuid process is called, chown can be used to change the owner of an executable file to root. Chown is a very call, especially when it is applied together with chmod. For this reason, we also added a piece of check code to the chown system call to prevent a setuid process from modifying the ownership of regular files or directories.
Chgrp: Like chown, chgrp is used to change group users to gain certain access permissions to attack the system.