이번 주 동안 Linux Kernel의 다양한 문제에 대한 몇 가지 솔루션이 출시되었습니다., 그러나 다른 몇 가지도 발견되었으며, 그중 Wanpeng Li는 최근 Linux 커널에서 두 개의 서비스 거부 (DOS)를 발견했습니다.
이것으로 로컬 공격자가 null 포인터를 사용하여 오류를 참조하여 DOS 상태를 트리거 할 수 있습니다.
첫 번째 취약점, 일반적인 취약성 및 노출에 대한 번호 CVE-2018-19406, Linux 커널 kvm_pv_send_ipi 함수에 존재하며 arch / x86 / kvm / lapic.c 파일에 정의되어 있습니다.
Linux Kernel 2018에 CVE-19406-4.19.2 취약점이 존재합니다. 공격자가 수리되지 않은 장치에서 정교한 시스템 호출을 사용하여 DOS 상태를 달성하도록 허용. 이 문제의 원인은 APIC (Advanced Programmable Interrupt Controller)가 제대로 초기화되지 않았기 때문입니다.
Wanpeng Li는 다음과 같이 썼습니다.
“이유는 apic 맵이 아직 초기화되지 않았기 때문입니다. testcase는 vmcall에 의해 pv_send_ipi 인터페이스를 활성화하여 kvm-> arch.apic_map이 참조되지 않습니다. "이 패치는 apic map이 NULL인지 아닌지 확인하고 만약 그렇다면 즉시 수정합니다."
Wanpeng Li가 발견 한 두 번째 취약점은 공격자가 장치에 물리적으로 액세스 할 수있는 상황으로 제한됩니다.
이 문제는 국가 취약성 데이터베이스에서 CVE-2018-19407로 번호가 매겨져 있으며 Linux 커널 86의 arch / x86 / kvm / x4.19.2.c에있는 vcpu_scan_ioapic 함수에 표시되어 로컬 사용자가 ioapic이 초기화되지 않은 상황에 도달하는 설계된 시스템 호출을 통한 서비스 거부 (NULL 포인터) 편차 및 BUG).
Linux 커널 CVE-2018-18955에 영향을 미치는 또 다른 취약점
또한, 또한 이번 주에 취약점이 발견되었습니다. (CVE-2018-18955)를 사용자 네임 스페이스의 uid / gid 변환 코드에 추가합니다.
기본 식별자 세트에 격리 된 컨테이너 (CAP_SYS_ADMIN)에서 관리자 권한이있는 권한이없는 사용자가 보안 제한을 우회하고 현재 식별자 네임 스페이스 외부의 리소스에 액세스 할 수 있습니다.
예를 들어 컨테이너 및 호스트 환경에서 공유 파일 시스템을 사용하는 경우 i-node에 대한 직접적인 어필을 통해 기본 환경에서 / etc / shadow 파일의 내용을 읽을 수 있습니다.
취약점은 커널 4.15 이상 버전을 사용하는 배포판에 존재합니다. 예를 들어 Ubuntu 18.04 및 Ubuntu 18.10, Arch Linux 및 Fedora (수정이 포함 된 커널 4.19.2는 Arch 및 Fedora에서 이미 사용 가능)
RHEL 및 SUSE는 영향을받지 않습니다. Debian 및 Red Hat Enterprise Linux에서 사용자 공간 지원은 기본적으로 활성화되어 있지 않지만 Ubuntu 및 Fedora에 포함되어 있습니다.
이 취약점은 작년 4.15 월에 소개 된 Linux 커널 코드 XNUMX의 버그로 인해 발생합니다.
이 문제는 버전 4.18.19, 4.19.2 및 4.20-rc2에서 수정되었습니다.
취약점 커널 파일 /user_namespace.c에 정의 된 map_write () 함수에 있습니다. 5 개 이상의 UID 또는 GID 범위를 사용하는 중첩 된 사용자 식별자 공간의 잘못된 처리로 인해 발생합니다.
이러한 조건에서 네임 스페이스에서 커널 (순방향 맵) 로의 uid / gid 식별자 변환은 올바르게 작동하지만 역변환 (커널에서 식별자 공간으로의 역맵) 중에는 수행되지 않습니다.
사용자 ID 0 (루트)이 순방향 변환 중에 커널의 식별자 0에 올바르게 매핑되지만 inode_owner_or_capable () 및 privileged_wrt_inode_uidgid () 검사에 사용 된 역변환 중 실제 상황을 반영하지 않는 상황이 발생합니다.
따라서 inode에 액세스 할 때 커널은 식별자 0이 기본 사용자 ID 집합에서 사용되지 않고 별도의 네임 스페이스에서 사용된다는 사실에도 불구하고 사용자에게 적절한 권한이있는 것으로 간주합니다.