🇰🇷 한글 설명
Linux 커널의 idmapped mount 환경에서 mincore() 및 madvise(MADV_PAGEOUT) 함수가 파일 소유권 확인 시 올바른 mount idmap을 사용하지 않는 취약점입니다. 이로 인해 idmap을 통해 소유권이 변경된 파일에 대해 소유자 권한 체크가 비정상적으로 실패하는 문제가 발생합니다.
💡 쉬운 설명
파일의 주인(소유자)이 누구인지 확인하는 과정에서 시스템이 엉뚱한 기준을 사용하여, 실제 주인임에도 불구하고 권한이 없다고 오판하는 문제입니다. 이는 보안상 치명적인 공격보다는 시스템의 권한 관리 로직이 일관되지 않게 작동하는 결함에 가깝습니다.
🇺🇸 원문 (English)
In the Linux kernel, the following vulnerability has been resolved:
mm: do file ownership checks with the proper mount idmap
Ever since idmapped mounts were introduced, inode ownership checks (for
side-channel protection) in mincore() and madvise(MADV_PAGEOUT) were done
against the nop_mnt_idmap, which completely ignores the file's mount's
idmap. This results in odd edgecases like:
1) mount/bind-mount with an idmap userA:userB:1
2) userB runs an owner_or_capable() check on file that is owned by userA
on-disk/in-memory, but owned by userB after idmap translation
3) owner_or_capable() mysteriously fails as the correct idmap wasn't supplied
In the case of mincore/madvise MADV_PAGEOUT, this is usually benign,
because file_permission(file, MAY_WRITE) will probably succeed, as it uses
the proper idmap internally, but it does not need to be the case on e.g a
0444 file where even the owner itself doesn't have permissions to write to
it.
Since this is clearly not trivial to get right, introduce a
file_owner_or_capable() that can carry the correct semantics, and switch
the various users in mm to it.
The issue was found by manual code inspection & an off-list discussion
with Jan Kara.
📍 영향받는 시스템
idmapped mounts 기능이 활성화된 Linux kernel (패치 적용 전 버전)
⚔️ 공격 벡터
특정 idmap 설정이 적용된 바인드 마운트 환경에서 권한 체크 로직을 우회하거나 오작동 유도
🛡️ 대응 방법
Linux 커널을 최신 보안 패치가 적용된 버전으로 업데이트하여 file_owner_or_capable() 함수가 적용된 버전을 사용하십시오.
🔧 검증 코드
출력된 커널 버전을 확인하여 해당 취약점이 해결된 최신 패치 버전인지 확인하십시오.