- This topic has 0개 답변, 1명 참여, and was last updated 8 years, 8 months 전에 by
태랑. This post has been viewed 10716 times
-
-
vulnerability in Linux kernel keychain management (CVE-2016-0728)
전 세계 수천만대에 달하는 리눅스 서버, PC는 물론 안드로이드4.0 킷캣 이후 버전에
영향을 줄 수 있는 제로데이 취약점이 발견돼 보안패치가 시급하다.
19일(현지시간) 이스라엘 보안회사인 퍼셉션포인트는 자사 블로그에 이러한 내용을 밝히고,
여러 리눅스 배포팀들과 협력해 실제로 취약점이 어떻게 작동할 수 있는지에 대해 여러
개념증명(POC)한 내용을 깃허브에 올렸다.
이 취약점(CVE-2016-0728)은 2012년부터 배포되기 시작한 리눅스 커널 버전 3.0 이상과
안드로이드4.4 킷캣 이상 버전에 영향을 줄 수 있다.취약점은 리눅스 커널에서 구동되는 '키링(keyring)'이라는 기능에서 발견됐다. 키링은 리눅스 커널 내에서
보안 관련 데이터, 인증키, 암호화키, 기타 데이터들을 보관하거나 캐시 형태로 저장하는 역할을 한다.
문제가 된 것은 이러한 저장공간에 오버플로와 같은 공격수법을 동원해 공격자가 이미 알고 있는 키나
악성코드를 삽입할 수 있다는 점이다. 캐시 형태로 저장된 암호화키, 인증키 등을 유출시켜 관리자 권한을
획득할 수도 있다.
미국 지디넷에 따르면 현재 리눅스 배포업체 중 하나인 레드햇은 '레드햇 엔터프라이즈 리눅스5'에서
이러한 취약점을 해결하는 보안업데이트를 제공하고 있으나 구글에서는 아직 이러한 문제에 대한
해결책을 마련했는지에 대해 알려진 내용이 없다.출처 zdnet : http://www.zdnet.co.kr/news/news_view.asp?artice_id=20160120100531&type=det&re=
-----------------------------------------------------------------------
Trying out exploit code
You can try proof-of-concept code to find out if your kernel is secure or not.
Use the wget command to grab the sample code:$ wget https://gist.githubusercontent.com/PerceptionPointTeam/18b1e86d1c0f8531ff8f/raw/5a90e6f98de85f35708087620de73bed3bf16880/cve_2016_0728.c
Compile it as follows (make sure you install the gcc compiler and keyutils developers libraries):
$ gcc cve_2016_0728.c -o cve_2016_0728 -lkeyutils -Wall
Run it as follows:
$ ./cve_2016_0728 PP_KEY
------------------------------------------------------------------------
https://access.redhat.com/articles/2131021Use after free vulnerability in Linux kernel
keychain management (CVE-2016-0728)
Updated an hour ago -In January 19th 2016 a vulnerability was discovered in the
Linux kernel. This vulnerability could allowed a
regular user to
escalate privileges.Red Hat has been made aware of a vulnerability affecting the
kernel that ships with Red Hat Enterprise Linux 7 kernel
and
derivatives. CVE-2016-0728
documents and exploit that could allow a skilled attacker to execute
arbitrary code
and also be used to escalate their privileges on the
system. The attacker must be able to run custom code on the
account; in
the most common configuration, this requires them to have a login and
shell account on the target system.Diagnostic Steps:
This issue was introduced in commit 3a50597de8635cd05133bd12c95681c82fe7b878
, which was introduced in the
kernel version 3.10. All Red Hat
Enterprise Linux kernels after this version are affected.
This document
will be updated with versions containing the fix when available.The version of the kernel a system is running can be confirmed with the uname command:
# uname -r 3.10.0-327.el7.x86_64 Major Release State Red Hat Enterprise Linux 4 Not affected Red Hat Enterprise Linux 5 Not affected Red Hat Enterprise Linux 6 Not affected Red Hat Enterprise Linux 7 Affected Red Hat Enterprise Linux 7 for Real Time Affected Red Hat Enterprise MRG 2 Affected
How does this impact systems:
Users must have an account on the system, or be able to instruct the system to run code on their behalf.
The attack is not immediate and may take some time to run; the system shows key usage counts climbing and then eventually wrapping to negative. The below command displays the keys file with a usage count of 50076394, proving an attack is in process.
$ cat /proc/keys | grep TEST_KEY 01cca8cf I--Q--- 50076394 perm 3f3f3f3f 0 0 keyring TEST_KEY: empty
No log events are generated when this faults if the attack is successful.I believe my system may have been compromised due to this vulnerability, what should I do?
If you have run the diagnostic steps in this article, and your system still appears to be vulnerable,
or you believe your system has been compromised, open a support case with Red Hat or contact
Red Hat support by phone.
Frequently Asked Questions
Q) What is a "Use after free" and how can it be exploited ?
A) The kernel uses reference counters to keep track of how many different parts of the code are using a certain
kernel object. In this case, it would be a user created keyring object. When the counter is set to zero,
the kernel knows that it can free the object. When the kernel attempts to acquire a keyring object, it uses a matching
key_get() and when releasing uses a matching key_put() function call (when it has completed using the object).
The error in this vulnerability was failing to call the key_put() function when handling an error path.
When the number of calls to acquire the key object do not match the release requests,
it causes the integer value of counter to wrap around from maximum value to zero. When the condition of the
counter being zero is met, the object is released but references to it in memory can still exist.
This situation that makes a reference counter overflow equivalent to the well-known "use-after-free" bug class.
Other parts of the kernel are able to allocate this freed memory for use. By overwriting the correct memory locations
with instructions, an attacker can use this previously freed memory space as the payload for when a function in
this memory could be called. The payload in this circumstance is spawning a new shell with elevated privileges.
Q) Sites on the internet have mentioned that the exploit can be prevented with the command:
# echo 1 > /proc/sys/kernel/keys/maxkeys
A) This limit only applies to user-created keys, not keys created by root. Each user gets a session keyring via pam (as root) when logged in. At this time there is no work around.
Q) Is there an alternative mitigation till I can schedule a reboot ?
A) Frank Ch. Eigler created a systemtap workaround in Comment #13 of the vulnerability bug and comment #14.
Please follow the instructions from the bugzilla comments.Q) Do I have to reboot after installing the kernel update ?
A) Yes.
Q) Does SELinux mitigate this issue ?
A) No.
References:
Perception points analysis
Red Hat's Bugzilla on CVE-2016-0278오픈소스를 응원합니다 Blog https://hoing.io
Senior Database Administrator(MySQL, Oracle)사이트 이용 문의 사항은 댓글이나 admin@fedoralinux.or.kr 로 메일주세요
- 답변은 로그인 후 가능합니다.