[Safety Notice]
Notice: [AD_LAB-04003] Linux 2.6. * Cable Capability LSM Module Process Privilege Trust Local Permissions Improvement Vulnerability
Category: Design error
Date: 12/20/2004
CVE number: NO
Threatened system:
Linux kernel 2.6. *
Unrelated system:
1. Vulnerability description
When the POSIX Energy (Capability) LSM is not compiled into the kernel, all existing ordinary users after inserting the Capability module (CommonCap.ko and Capability.ko)
The process will have all ROOT privileges!
2. Technical details
When the privileged operation is controlled by the Capability LSM module, the system is based on the process trust (CREDs) arbitrated privilege operations. When Capability is not compiled into the kernel, the kernel uses the default.
The recognition safety module (Security / Dummy.c) arbitration privilege operation, the mechanism is very simple, only check the process EUID, FSUID (when file system related privileges) is 0.
In this case, the Dummy module does not care about the trust of the process, and the trust of each process is copied. Chasing the source, the trust of each process is used in any process
Whether the household is a super user, the trust of the init process is copied, and the trust contains all the weights of the superuser process. This error is not in the case of privileged judgment according to user ID.
Stimulate. However, after inserting the Capability module, the privilege mechanism is converted to the process trust, and the trust of any process before that exists is consistent with the init process, causing these
The process has the privilege of superuser root. The essence of this error is to recalculate the trust of the existing process when loading the Capability module. test
The test shows that this error appears in the 2.6. * Linux kernel.
Example:
When the Capability module is not compiled into the kernel, (if you have compiled into the kernel, you must recompile the kernel after DISABLE. Before loading the Capability module,
General Mouters Allow a VIM editor, in the VIM input command:
: r / etc / shadow
Vim will respond to "Can't Open File / etc / shadow", this access to the root file operation is rejected.
Don't end Vim, go to other console to log in as root, insert the Capability module:
#Modprobe Capability
After the module is reproduced, go back to the VIM to try to open the shadow file again, and will find the ability to read and write in a normal user and save (W!) Shadow file! The fundamental reason is the letter of the VIM process
Renior contains power CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH, so it is possible to perform privileged operations that exceed access control policies.
Use the following command to view the trust of VIM:
$ CAT / Proc / 2454 / Status (2454 is the PID of the VIM process)
Name: Vim
State: s (Sleeping)
SleePAVG: 91%
TGID: 2454
PID: 2454
PPID: 1552
Tracerpid: 0
Uid: 500 500 500 500
GID: 500 500 500 500
FDSIZE: 256
GROUPS: 500
VMSIZE: 9356 KB
VMLCK: 0 KB
VMRSS: 2728 KB
Vmdata: 856 KB
VMSTK: 16 KB
Vmexe: 1676 KB
VMLIB: 3256 KB
Threads: 1
SigPnd: 0000000000000000000000000000000000000000
SHDPND: 000000000000000000
Sigblk: 0000000000000000
SIGIGN: 8000000000000003000
Sigcgt: 00000000EF824EFF
Capinh: 0000000000000000000000000000
CAPPRM: 00000000FFFFFFFF
CAPEFF: 00000000FFFFFEFF
The last 3 line is Vim trust, you can see that it has all CAPAbility power outside CAP_SETPCAP.
The above test is passed in 2.6. * And 2.5.72-LSM1.
Correction
Add the following code in Security / Capability.c
Static void recompute_capability_creds (struct task_struct * task)
{
IF (Task-> PID <= 1)
Return;
Task_lock (task);
Task-> Keep_capabilities = 0;
IF ((Task-> Uid && Task-> EUID && Task-> Suid) &&! task-> keep_capabilities)
CAP_CLEAR (TASK-> CAP_PERMITTED);
Else
Task-> CAP_PERMITTED = CAP_INIT_EFF_SET;
IF (Task-> EUID! = 0) {
CAP_CLEAR (TASK-> CAP_EFFECTIVE);
}
Else {
Task-> CAP_EFFECTIVE = CAP_INIT_EFF_SET;
}
IF (Task-> FSUID)
Task-> CAP_EFFECTIVE & = ~ CAP_FS_MASK;
Else
Task-> CAP_EFFECTIVE | = CAP_FS_MASK;
Task_unlock (task);
Return;
}
And in the existing Capability_init function adds the following code before it returns:
Struct Task_struct * task;
Read_lock (& Tasklist_lock);
For_each_process (task) {
Recompute_capability_creds (task);
}
Read_Unlock (& Tasklist_lock);
Return 0;
Repeat the eucalyptus test again, check the VIM trust
$ CAT / PROC / (PID of Vim) / Status
Name: Vim
State: s (Sleeping)
SleePAVG: 91%
TGID: 2864
PID: 2864
PPID: 1552
Tracerpid: 0
Uid: 500 500 500 500
GID: 500 500 500 500
FDSIZE: 256
GROUPS: 500
VMSIZE: 9360 KB
VMLCK: 0 KB
VMRSS: 2816 KB
Vmdata: 860 KB
VMSTK: 16 KB
Vmexe: 1676 KB
VMLIB: 3256 KB
Threads: 1
SigPnd: 0000000000000000000000000000000000000000
SHDPND: 000000000000000000
Sigblk: 0000000000000000
SIGIGN: 8000000000000003000
Sigcgt: 00000000EF824EFF
Capinh: 0000000000000000CAPPRM: 0000000000000000
CAPEFF: 0000000000000000
3. Thank you
Liangbin@venustech.com.cn found and announced the specific technical details of this vulnerability
Thanks to Qi Mingxing Technical Information Co., Ltd. Actively Defense Laboratory Partners and Harvest Project Team.
4. Declared:
The Information in this Bulletin Is Provided "As IS" without warranty of any
Kind. in no Event shall we be limited for any Damages Whatsoever Including Direct,
Indirect, Incidental, Consequential, Loss of Business Profits or Special Damages.
Terms of use.
Venustech Security Lab
Venustech Information Technology Co., Ltd (
http://www.venustech.com.cn)
Security
Trusted {Solution} provider
Service
