How To Using Kspice for Oracle Linux 10 Security -part2

테크넷 마스터 김재벌 입니다.

 

지난번 part1에 이어서 Ksplice 의 익스플로잇 탐지 및 차단 기능을 살펴 보겠습니다.

 

Kplice는 라이브 패치로 유명한 오라클 리눅스의 핵심 보안 기능이지만, 라이브 패치 기능이 아닌 익스플로잇 탐지 및 차단 기능도 가지고 있다는 사실... 사실 이 부분은 잘 알려져 있지 않죠.

워낙 라이브 패치가 강한 임팩트를 주다 보니~~말이죠..

출처: https://solatech.tistory.com/573 [김재벌(Suk's)의 IT 이야기:티스토리]

 

1.알려진 익스플로잇 탐지 (Known Exploit Detection)

CVE 익스플로잇 시도를 실시간 감지하며, 이를 관리자에게 경고합니다. 

Ksplice Enhanced Client 는 단순 패치 적용을 넘어 익스플로잇 탐지 기능을 제공합니다.

새로운 CVE가 발견되면 오라클이 커널 코드에 트립와이어(Tripwire)를 추가하여, 공격자가 취약점을 공격하려고 시도할 때 즉시 오류 처리로 기록합니다. 패치 전에도 이를 사전에 탐지하고 공격 시도를 기록할 수 있습니다.

 

탐지이벤트 모니터링

# Ksplice Enhanced Client 설치 확인 rpm -q uptrack-updates # 익스플로잇 탐지 이벤트 확인 sudo uptrack-show --exploits # → 탐지된 익스플로잇 시도 목록 출력 # 커널 오류 및 Ksplice 경고 실시간 모니터링 sudo journalctl -k -f | grep -i "ksplice\|exploit\|tripwire" # Audit 로그에서 Ksplice 관련 이벤트 확인 sudo ausearch -k ksplice --start recent # 탐지 이벤트를 이메일로 알림 (uptrack.conf 설정) sudo vi /etc/uptrack/uptrack.conf # [Main] # email = admin@example.com # autoinstall = yes # install_on_reboot = yes

 

2.OOPS Limit - Null-Deref 익스플로잇 클래스 차단

UEK 커널의 OOPS Limit 카운터 적용을 통해 커널 익스플로잇 기법 무력화

OOPS Limit에 대해서는 하단에서 좀 더 상세한 부여설명을 정리해 보겠습니다만, 일단, 구글 프로젝트 제로팀이 2023년에 발표한 Null Pointer dereference 악용 기법에 대한 방어 방법으로 리눅스 커널 커뮤니티에서 OOP Limit을 적용하여 방어하는 메카니즘을 적용했습니다.

오라클 리눅스가 이를 반영하여  OOPS Limit 제한을 적용했다는 뜻입니다.

보다 시스템을 강화하려면 조금 더 낮은 수치를 적용하여 시스템을 하드닝(System Hardening) 하도록 구성할 수 있습니다.

공격자가 UAF(Use-After-Free) 조건을 만들기 위해 약 2^32번 OOPS를 유발하도록 시도하는데, 제한에 도달하면 커널이 패닉을 일으켜 익스플로잇을 차단합니다. Ksplice를 이용하여 재부팅 없이 적용이 가능합니다.

# 현재 Oops 제한값 확인 cat /proc/sys/kernel/oops_limit # 기본값: 10000 # 값 조정 (더 낮게 설정할수록 보안 강화) sudo sysctl -w kernel.oops_limit=500 # 영구 적용 (/etc/sysctl.d/) echo "kernel.oops_limit = 500" | \   sudo tee /etc/sysctl.d/99-oops-limit.conf sudo sysctl --system # Oops 카운터 현재값 확인 cat /proc/sys/kernel/oops_count # 커널 메시지에서 Oops 이벤트 확인 sudo dmesg | grep -i "oops\|null pointer"

 

[노트] Null-Deref와 OOPS Limit  "OOPS Limit"를 통한 Null-Deref 익스플로잇 클래스 차단은 Linux 커널 보안 역사에서 매우 영리하고도 중요한 방어 메커니즘 중 하나입니다. 과거에는 커널에서 Null Pointer Dereference(Null-Deref, 널 포인터 역참조)가 발생하면 보안 취약점이 아닌 단순한 안정성 버그(Crash)로 치부되곤 했습니다. 현대 OS는 일반 사용자가 0번지 주소(Null)에 접근하거나 메모리를 매핑하는 것을 원천 차단(mmap_min_addr 등)하기 때문에, 공격자가 이를 이용해 악성 코드를 실행하는 것이 불가능하다고 믿었기 때문입니다. 하지만 공격자들은 시스템을 완전히 crash(Panic)내지 않고 시스템을 복구하려는 커널의 친절한(?) 특성을 역이용하는 새로운 익스플로잇 기법을 개발했고, 이를 막기 위해 도입된 시스템이 바로 OOPS Limit입니다. 1. 공격의 원리 :  Kernel OOPS의 허점 악용 리눅스 커널은 실행 중 Null-Deref 같은 오류를 만나면 두 가지 방식으로 대응합니다.  1) Kernel Panic: 커널 전체가 완전히 동작을 멈추고 시스템이 다운됩니다.  2) Kernel OOPS: 오류가 발생한 프로세스(태스크)만 강제 종료(Kill)하고, 커널 자체는 어떻게든 정상 메모리와 자원을 수습하여 계속 작동합니다. 구글 프로젝트 제로(Google Project Zero) 등의 보안 연구원들은 "Kernel OOPS가 발생할 때, 커널이 미처 정리하지 못하고 누출(Leak)하는 자원이 있다"는 점에 주목했습니다. reference count(참조 계수) 오버플로우 공격 순서 1) 공격자가 특정 커널 오브젝트의 참조 계수(refcount)를 올리는 시스템 콜을 호출합니다. 2) 계수가 올라간 상태에서, 의도적으로 Null-Deref 취약점을 유발해 Kernel OOPS를 발생시킵니다. 3) OOPS 핸들러가 작동하면서 해당 프로세스는 강제 종료되지만, 정상적인 자원 해제 루틴이 생략되면서 올라간 참조 계수가 감소하지 않고 그대로 유지(Leak)됩니다. 공격자는 이 과정을 $2^{32}$번(약 42억 번) 반복합니다. 결국 32비트 참조 계수가 오버플로우(Overflow)되어 0으로 돌아가고, 커널은 이 오브젝트가 더 이상 사용되지 않는다고 판단해 메모리에서 해제합니다. 하지만 실제로는 여전히 다른 프로세스가 이 오브젝트를 참조하고 있으므로, 치명적인 UAF(Use-After-Free, 해제된 메모리 재사용) 취약점으로 이어져 결국 관리자(Root) 권한을 획득하게 됩니다. 💡 참고: 환경에 따라 수억~수십억 번의 OOPS를 유발하는 데 수일에서 수주일이 걸리기도 하지만, 시스템이 다운되지 않고 버티기 때문에 시간만 주어지면 완벽하게 성공하는 강력한 익스플로잇 클래스(공격 기법)입니다. 2. 방어 메커니즘: OOPS Limit (최대 횟수 제한) 이 새로운 공격 클래스를 차단하기 위해 리눅스 커널 커뮤니티는 2022년 말(Linux 커널 v6.2 및 안정화 버전에 백포트) "exit: Put an upper limit on how often we can oops"라는 패치를 적용했습니다.  이 기능이 바로 OOPS Limit입니다. 작동 방식 커널 내부에 OOPS가 발생하는 횟수를 세는 글로벌 카운터를 둡니다. 시스템이 켜진 후 OOPS 발생 횟수가 지정된 임계값(Limit)에 도달하면, 커널은 시스템이 공격받고 있거나 심각한 결함이 있다고 판단하여 스스로 Kernel Panic을 가동해 시스템을 완전히 다운시켜 버립니다. 기본 임계값: 통상적으로 10,000번으로 설정되어 있습니다. 효과: 공격자가 참조 계수를 오버플로우시키기 위해 42억 번 OOPS를 내야 하는데, 만 번 남짓 도달하는 순간 시스템이 쾅! 하고 뻗어버리므로 공격 진행 자체가 불가능해집니다. 결과적으로 OOPS Limit는 취약점 자체를 수정하는 것이 아니라, 취약점을 활용해 공격을 성립시키기 위해 필수적인 '반복적인 OOPS 유발 단계'를 원천 차단하는 완화 기법(Mitigation)입니다. 완벽한 버그 수정은 아닐지라도, 특정 익스플로잇 클래스 전체를 무력화시키는 매우 효율적인 방어벽 역할을 하고 있습니다.

 

 

간단해 보이지만, 강력한 보안 기능을 탑재하고 있습니다. :-)