CN109858252B - Vulnerability analysis and repair method for homemade system - Google Patents
Vulnerability analysis and repair method for homemade system Download PDFInfo
- Publication number
- CN109858252B CN109858252B CN201711239471.8A CN201711239471A CN109858252B CN 109858252 B CN109858252 B CN 109858252B CN 201711239471 A CN201711239471 A CN 201711239471A CN 109858252 B CN109858252 B CN 109858252B
- Authority
- CN
- China
- Prior art keywords
- vulnerability
- homemade
- bug
- kernel
- repair
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Landscapes
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to a vulnerability analysis and repair method of a homemade system, which comprises the following steps: step S1: checking whether the kernel version of the homemade system is in the vulnerability influence range; if yes, executing step S3, and if not, executing step S2; step S2: confirming whether the modification log influences the loophole, if not, the homemade system does not need to repair the loophole, and if so, executing step S3; step S3: verifying the explloit, checking whether the loophole exists on the homemade system, if so, repairing the loophole through the patch, and if not, repairing the loophole by the homemade system. According to the vulnerability analysis and repair method for the homemade system, whether the vulnerability exists or not is judged by analyzing the difference between the source code modification part related to the kernel vulnerability patch and the source code corresponding to the current homemade system, and the source code modification part in the patch is transplanted, so that the homemade system is free from the influence of the vulnerability.
Description
Technical Field
The invention relates to the technical field of computer software security analysis, in particular to a vulnerability analysis and repair method of a homemade system.
Background
When programmers develop secondarily under an open source operating system, a large amount of modification is often carried out on the bottom kernel code, some projects even have the condition that a plurality of programmers modify the same set of code, so that the safety of the self-made operating system is greatly reduced for a long time, and patches aiming at source loopholes cannot be directly used on the system.
The biggest features of open source operating systems, such as Windows and Mac, are open source code and free customization, but many unpredictable situations and maintenance problems occur due to the technical level of users, and most of hardware and software manufacturers do not support open source software.
One of the most well known international open source operating systems is the "Linux operating system", which is a generic term for computer operating systems, and chinese reading is approximately "rink". The name of the kernel of the Linux operating system is also "Linux". Linux operating systems are also the best known example in the development of free software and open source code.
Currently, a newly released kernel vulnerability generally requires a user to download an official explloit by self-defunct network to perform vulnerability verification, and replace a previous version by using the latest kernel; or the user can conduct secondary development in the kernel version of the bug repaired.
Because of the difference in kernel application, the expllois issued by the official network is likely to not directly run in the homemade operating system, and the homemade operating system directly replaces the new version of the authority to cause all the previous changes to be invalid because a great number of custom modifications are made on the kernel, but the security of the system cannot be ensured without repairing the loopholes, so that the later expansibility of the system is limited.
Therefore, a new vulnerability analysis and repair method for homemade systems is needed.
Disclosure of Invention
In order to solve the defects existing in the prior art, the invention provides a vulnerability analysis and repair method of a homemade system, which comprises the following steps:
step S1: checking whether the kernel version of the homemade system is in the vulnerability influence range; if yes, executing step S3, and if not, executing step S2;
step S2: confirming whether the modification log influences the loophole, if not, the homemade system does not need to repair the loophole, and if so, executing step S3;
step S3: verifying the explloit, checking whether the loophole exists on the homemade system, if so, repairing the loophole through the patch, and if not, repairing the loophole by the homemade system.
In the step S3, the file contents to be modified for repairing the bug are given by comparing the file differences before and after bug repair, so as to complete bug repair.
Wherein, still include step S4: if the bug is repaired, executing the exact file of the bug again, and verifying whether the bug is repaired successfully.
In step S3, before performing bug repair, the modification record before the patch file to be repaired is inspected to see whether the previous code is affected.
In the step S3, whether the vulnerability exists is determined by analyzing the difference between the source code modification part related to the kernel vulnerability patch and the source code corresponding to the current homemade system.
According to the vulnerability analysis and repair method for the homemade system, whether the vulnerability exists or not is judged by analyzing the difference between the source code modification part related to the kernel vulnerability patch and the source code corresponding to the current homemade system, and the source code modification part in the patch is transplanted, so that the homemade system is free from the influence of the vulnerability.
Drawings
Fig. 1: the implementation flow chart of the vulnerability analysis and repair method of the homemade system is provided;
fig. 2: the exp structure schematic diagram of the vulnerability CVE-2016-8655 of the embodiment 1 of the present invention;
fig. 3: the exp structure of the vulnerability CVE-2016-5195 of example 2 of the present invention is schematically illustrated.
Detailed Description
In order to further understand the technical scheme and beneficial effects of the present invention, the technical scheme and beneficial effects thereof will be described in detail with reference to the accompanying drawings.
Aiming at the problem that the expllois released by the official network and cannot directly run in the homemade operating system in the prior art, the invention provides the invention concept that the source code modification part related in the kernel vulnerability patch is compared and analyzed with the source code corresponding to the current homemade system to carry out secondary modification on the expllois released by the official system so as to enable the expllois to run normally.
Meanwhile, aiming at the problem that the direct replacement of the official core in the prior art can cause the complete invalidation of the previous core modification, the invention concept of transplanting the source code modification part in the patch is provided, so that the self-made system can be free from the influence of the vulnerability, all code modifications in the history version of the core are reserved, and the effect of repairing the vulnerability is achieved.
Specifically, as shown in fig. 1, the method for implementing the method for repairing the vulnerability analysis of the homemade system of the present invention includes the following steps:
1. and checking the kernel version influenced by the vulnerability to determine whether the source kernel version of the homemade system is in the influence range. If the vulnerability is within the influence range, the vulnerability can be repaired directly by a patching method. If the file is not in the influence range, the relevant modification log of the file influenced by the vulnerability needs to be confirmed, and whether the modification affecting the vulnerability exists or not is checked.
2. Looking up the expllois of the loophole, the loophole will have a basic utilization method to influence the system, the kernel loophole usually takes the acquisition of the root user authority as the final purpose, and the code of some part in the kernel of the system is usually not strict or is easy to be abnormal when being attacked, at this time, the third party user can acquire the management authority of the root user through certain conditions, thereby grasping the whole system. The utilization method is the explloid of the vulnerability, and the related files of the current system are patched and repaired by analyzing the attack source code of the vulnerability, so that the homemade system can be effectively prevented from being attacked by the similar method. And through the vulnerability expllois given by the authorities, the root cause of the vulnerability formation can be searched by comparing and analyzing the difference between the source code modification part related in the kernel vulnerability patch and the source code corresponding to the current homemade system, so that a special test program for the homemade system is written to verify whether the vulnerability exists on the current system or not and verify the repairing condition of the vulnerability after verification.
3. Analyzing vulnerability restoration patches given by the authorities, wherein the patches given by the authorities are aiming at the latest kernel version, and providing file contents required to be modified for restoring the vulnerability by comparing file differences before and after vulnerability restoration; for a homemade system, the situation that the content of the same-name file in the kernel is not corresponding to the official version can occur in a large probability, the codes need to be checked one by one, the key code parts of the vulnerability cause are found out without considering irrelevant modification, and the content in the vulnerability patch is transplanted to the homemade system.
By the method, whether the kernel on which the homemade system depends is in the influence range of a certain vulnerability can be effectively judged, vulnerability restoration can be performed on the homemade system, the security level of the system is improved, and malicious attacks of external hackers are avoided.
In order to make the flow of the technical scheme of the invention more clear, the method for determining whether the kernel on which the homemade system depends is within the influence range of a certain vulnerability is further described in detail below in combination with the specific embodiment.
In the following examples, the native kernel version used by the homemade system is linux-3.10.0, which is relatively stable and mature and suitable for secondary development of the kernel. The specific implementation mode is as follows:
example 1
1. The detailed information of the vulnerability CVE-2016-8655 is obtained, and the vulnerability can be found to mainly influence all linux systems with kernel versions smaller than 4.8.12; the kernel version of the current homemade operating system is linux-3.10.0, so the vulnerability can affect the current homemade system.
2. Looking at the expllo_root.c of CVE-2016-8655, the reason for the vulnerability formation is found out by triggering a race state, so that the kernel does not log off the timer in the socket, then the kernel space before the timer is not released is covered by using a memory injection method, the function in the timer is replaced by the function to be executed, once the timer time expires, the kernel executes the expiration processing function of the timer, and the function is actually the replaced function, thereby achieving the purpose of vulnerability exploitation. FIG. 2 is an exp structure diagram of the vulnerability CVE-2016-8655 of example 1 of the present invention;
3. and verifying whether the vulnerability CVE-2016-8655 exists on the homemade system through a test program choloo_root.c.
The pre-condition is as follows: placing an expllo-root.c file applicable to a homemade operating system under the root directory of a user
The method comprises the following specific steps: (1) The root user logs in the system and enters the root directory of the user.
(2) Compiling test source code chocobo_root.c to generate an executable file, and executing a command by a terminal:
gcc chocobo_root.c–o chocobo_root–lpthread
(3) Executing a command under a root user:
./chocobo_root
(4) Switching a user to log in the system, executing a command id, and displaying a user number of the current user by the terminal, wherein user=1000 (user)
(5) Executing the command under the user:
./chocobo_root
the expected results are shown below:
[root@localhost user]#gcc chocobo_root.c-o chocobo_root-lpthread
[root@localhost user]#./chocobo_root
[root@localhost user]#su user
[user@localhost～]S id
user=1001 (user) gid=100 (users) group=100 (users) environment=user_u:user_r:user_t:s0
[user@localhost～]S./chocobo_root
[user@localhost～]#id
uid=0 (root) gid=0 (root) group=0 (root), 100 (user) environment=user_u:user_r:user_t:s0
As shown in the above results: the terminal is changed into a root user from a common user, and the self-made system is proved to have loopholes and have the risk of being controlled by a third party user.
4. And performing vulnerability restoration by referring to the restoration patch of CVE-2016-5195, and restoring the homemade system by analyzing the modification scheme in the patch.
The patch is mainly used for modifying an af_packet.c file under the/net/packet/directory, and the calling mode of the packet_set_ring function is adjusted. When the modification is performed, the modification record before the af_packet.c file needs to be checked first to see whether the previous code is affected. After the kernel is modified, the test script is executed again, and if the terminal is still a common user, the bug of the homemade system is proved to be repaired.
Example two
1. The detailed information of the vulnerability CVE-2016-5195 is obtained, and the vulnerability can be found to mainly influence the mm/gup.c files in the versions 2.X to 4.X of the kernel, and the version of the kernel of the current homemade operating system is linux-3.10.0, so that the vulnerability can influence the current homemade system.
2. Looking at the explet file dirty0w.c of CVE-2016-5195, it can be found that the reason for the vulnerability is that the get_user_page kernel function may generate race conditions during Copy-on-Write processing, resulting in a failure of the COW process and an opportunity to Write data to a read-only memory area in the process address space. The hacker can use the vulnerability and obtain root authority by modifying the/etc/passswd file, so the key for repairing the vulnerability is the exploitation condition for closing the vulnerability. Fig. 3 is an exp structure diagram of the vulnerability CVE-2016-5195 of example 2 of the present invention.
3. The existence of the vulnerability CVE-2016-5195 on the homemade system was verified by the test program dirty0w.c.
The pre-condition is as follows: and placing the exploid file dirty0w.c applicable to the homemade operating system under the root directory of the user.
The method comprises the following specific steps: (1) A user logs in the system, enters a root directory and creates a foo file; the terminal executes the command:
echo this is not a test>fo1
(2) The file is given readable rights, but no write rights, and the terminal executes the command:
chmod 0404fo1
(3) Looking at the content of the fo1 file, the terminal executes the command:
cat fo1
at this point the viewing terminal will display this is not a test.
(4) Compiling a test accessory dirty0w.c, and executing a command by the terminal:
gcc dirtyc0w.c-o dirtyc0w-lpthread
(5) Executing the test program, and executing the command by the terminal:
./dirtyc0w
if the program is not completed after 1 minute, the program needs to be manually exited according to Ctrl+C.
(6) Checking whether the content of the fo1 file is changed, and executing a command by the terminal: cat fo1
The expected results are shown in the following figures:
[user@localhost～]S echo this is not a test>fol
[user@localhost～]S chmod 0404fol
[user@localhost～]S cat foo
21212212not a test
[user@localhost～]S gcc-lpthread dirtyc0w.c–o dirtyc0w
[user@localhost～]S./dirtyc0w fol m00000000
mmap e515c000
︿C
[user@localhost～]S cat fol
m00000000ot a test
[user@localhost～]S
as shown in the above results: the content of the fo1 file is replaced, and the user is proved to obtain root rights; the self-made system has loopholes and is at risk of being controlled by a third party user.
4. And performing vulnerability restoration by referring to the restoration patch of CVE-2016-5195, and restoring the homemade system by analyzing the modification scheme in the patch.
The patch mentions that the gup.c file content under the mm directory is replaced as follows:
"if ((flag & FOLL_WRITE) & ≡ pte _write (pt)) {" replaced by "if ((flag & FOLL_WRITE) & ≡can_follow_write_ pte (pte, flags)) {"
Also, "/flags = -poll_write; "replace with" |=foll_cow; "
The repair method capable of finding out the patch through the replacement mainly comprises the steps of adding a flag bit to prevent the error skip of the get_user_pages function; when the modification is performed, the modification record before the gup.c file needs to be checked first to see whether the previous code is affected. After the kernel is modified, the test script is executed again, and if the content of the file fo1 is not changed, the bug of the homemade system is proved to be repaired.
The vulnerability analysis and repair method of the homemade system provided by the invention can be applied to various homemade systems, and is especially applicable to Linux operating systems.
In the invention, the so-called "linux-3.10.0" is one version of the kernel of the open source computer operating system.
In the present invention, the "self-made operating system" is a system in which an open source kernel is secondarily developed.
In the present invention, the term "explorer" refers to an exploit, and specifically, codes that trigger a vulnerability (or several vulnerabilities) and further control a target operating system are collectively referred to as an explorer.
In the present invention, the english language of "cve", which is collectively called "Common Vulnerabilities & Exposures", gives a common name for security vulnerabilities or vulnerabilities that have been exposed, and a unique name for vulnerabilities and Exposures is determined, followed by numbering to distinguish specific vulnerabilities.
In the present invention, the term "open source operating system" refers to operating system software that exposes source code.
Although the present invention has been described with reference to the above preferred embodiments, it should be understood that the present invention is not limited to the above embodiments, and that various changes and modifications can be made herein without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (3)
1. A vulnerability analysis and repair method of a homemade system is characterized by comprising the following steps:
step S1: checking whether the kernel version of the homemade system is in the vulnerability influence range; if yes, executing step S3, and if not, executing step S2;
step S2: confirming whether the modification log influences the loophole, if not, the homemade system does not need to repair the loophole, and if so, executing step S3;
step S3: verifying an explloit, checking whether a bug exists on the homemade system, if so, repairing the bug through a patch, and if not, repairing the bug by the homemade system;
in the step S3, file contents to be modified for repairing the bug are given by comparing file differences before and after bug repair, so as to complete bug repair; and judging whether the vulnerability exists or not by analyzing the difference between the source code modification part related in the kernel vulnerability patch and the source code corresponding to the current homemade system.
2. The vulnerability analysis and repair method of self-made system as claimed in claim 1, further comprising step S4: if the bug is repaired, executing the exact file of the bug again, and verifying whether the bug is repaired successfully.
3. The vulnerability analysis and repair method of self-made system of claim 1, wherein: in step S3, before performing bug repair, the modification record before the patch file to be repaired is inspected to see whether the previous code is affected.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711239471.8A CN109858252B (en) | 2017-11-30 | 2017-11-30 | Vulnerability analysis and repair method for homemade system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201711239471.8A CN109858252B (en) | 2017-11-30 | 2017-11-30 | Vulnerability analysis and repair method for homemade system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109858252A CN109858252A (en) | 2019-06-07 |
| CN109858252B true CN109858252B (en) | 2023-04-25 |
Family
ID=66888259
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711239471.8A Active CN109858252B (en) | 2017-11-30 | 2017-11-30 | Vulnerability analysis and repair method for homemade system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109858252B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112016095B (en) * | 2020-08-20 | 2024-01-12 | 上海帆一尚行科技有限公司 | Method and device for verifying loopholes and electronic equipment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101393525A (en) * | 2007-09-17 | 2009-03-25 | 赛门铁克公司 | Systems and methods for patching computer programs |
| CN101799763A (en) * | 2009-02-10 | 2010-08-11 | 华为技术有限公司 | Method, device and system for patching kernel on line |
| CN105893850A (en) * | 2016-03-30 | 2016-08-24 | 百度在线网络技术（北京）有限公司 | Bug fixing method and device |
| CN106446691A (en) * | 2016-11-24 | 2017-02-22 | 工业和信息化部电信研究院 | Method and device for detecting integrated or customized open source project bugs in software |
| CN106598667A (en) * | 2016-12-12 | 2017-04-26 | 百度在线网络技术（北京）有限公司 | Method and device used for restoring kernel vulnerability |
| CN106919844A (en) * | 2017-02-14 | 2017-07-04 | 暨南大学 | A kind of android system vulnerability of application program detection method |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7845006B2 (en) * | 2007-01-23 | 2010-11-30 | International Business Machines Corporation | Mitigating malicious exploitation of a vulnerability in a software application by selectively trapping execution along a code path |
| US8819637B2 (en) * | 2010-06-03 | 2014-08-26 | International Business Machines Corporation | Fixing security vulnerability in a source code |
| KR101649909B1 (en) * | 2014-09-25 | 2016-08-22 | 한국전자통신연구원 | Method and apparatus for virtual machine vulnerability analysis and recovery |
-
2017
- 2017-11-30 CN CN201711239471.8A patent/CN109858252B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101393525A (en) * | 2007-09-17 | 2009-03-25 | 赛门铁克公司 | Systems and methods for patching computer programs |
| CN101799763A (en) * | 2009-02-10 | 2010-08-11 | 华为技术有限公司 | Method, device and system for patching kernel on line |
| CN105893850A (en) * | 2016-03-30 | 2016-08-24 | 百度在线网络技术（北京）有限公司 | Bug fixing method and device |
| CN106446691A (en) * | 2016-11-24 | 2017-02-22 | 工业和信息化部电信研究院 | Method and device for detecting integrated or customized open source project bugs in software |
| CN106598667A (en) * | 2016-12-12 | 2017-04-26 | 百度在线网络技术（北京）有限公司 | Method and device used for restoring kernel vulnerability |
| CN106919844A (en) * | 2017-02-14 | 2017-07-04 | 暨南大学 | A kind of android system vulnerability of application program detection method |
Non-Patent Citations (1)
| Title |
|---|
| 开源软件漏洞补丁的采集与整理;邹雅毅等;《河北省科学院学报》;20160930;第33卷(第03期);第18-22页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109858252A (en) | 2019-06-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP3036623B1 (en) | Method and apparatus for modifying a computer program in a trusted manner | |
| RU2377638C2 (en) | Effective program update | |
| US8443354B1 (en) | Detecting new or modified portions of code | |
| CN105786538B (en) | software upgrading method and device based on android system | |
| CN109255235B (en) | Mobile application third-party library isolation method based on user state sandbox | |
| US11238151B2 (en) | Method and apparatus for patching binary having vulnerability | |
| CN103390130A (en) | Rogue program searching and killing method and device based on cloud security as well as server | |
| Farhang et al. | An empirical study of android security bulletins in different vendors | |
| CN107330328B (en) | Method and device for defending against virus attack and server | |
| CN104933354A (en) | Trusted computing based white list static measurement method | |
| US8683450B2 (en) | Systems, methods, and media for testing software patches | |
| Duarte et al. | An empirical study of docker vulnerabilities and of static code analysis applicability | |
| CN108205491B (en) | NKV 6.0.0 system-based trusted technology compatibility testing method | |
| KR101649909B1 (en) | Method and apparatus for virtual machine vulnerability analysis and recovery | |
| CN110837644A (en) | System penetration testing method and device and terminal equipment | |
| CN102156649B (en) | Patch installation method and device thereof | |
| CN109858252B (en) | Vulnerability analysis and repair method for homemade system | |
| CN115758356A (en) | Method, storage medium and equipment for implementing credible static measurement on Android application | |
| CN118051918A (en) | Security vulnerability restoration management method and device | |
| Wi et al. | Diffcsp: Finding browser bugs in content security policy enforcement through differential testing | |
| KR101862382B1 (en) | Method and device for managing application data in Android | |
| Whittaker et al. | Neutralizing windows-based malicious mobile code | |
| US11886589B2 (en) | Process wrapping method for evading anti-analysis of native codes, recording medium and device for performing the method | |
| Shafana et al. | Exploitation analysis of buffer overflow in SL-Mail Server | |
| CN114237665A (en) | Patch updating method and device, computing equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |