Linux 커널에서는 다음 취약점이 해결되었습니다. ptrace: 약간 더 건전한 'get_dumpable()' 논리 작업의 '덤프 가능성'은 근본적으로 작업의 메모리 이미지에 관한 것입니다. 작업 - 개념은 코어 덤프가 가능한지 여부에서 비롯됩니다. 연결된 mm이 없으면 의미가 없습니다. 그리고 거의 모든 사용자는 실제로 작업이 필요한 경우에만 이를 사용합니다. mm 포인터가 있습니다. 하지만 이상한 특별한 경우가 하나 있습니다: ptrace_may_access()는 'dumpable'을 사용하여 그 외 다양한 것들을 확인해보세요
Linux 커널에서는 다음 취약점이 해결되었습니다.
ptrace: 약간 더 건전한 'get_dumpable()' 논리
작업의 '덤프 가능성'은 근본적으로 작업의 메모리 이미지에 관한 것입니다. 작업 - 개념은 코어 덤프가 가능한지 여부에서 비롯됩니다. 연결된 mm이 없으면 의미가 없습니다.
그리고 거의 모든 사용자는 실제로 작업이 필요한 경우에만 이를 사용합니다. mm 포인터가 있습니다.
하지만 이상한 특별한 경우가 하나 있습니다: ptrace_may_access()는 'dumpable'을 사용하여 MM과는 완전히 독립적으로 다양한 다른 사항을 확인합니다(일반적으로 PTRACE_MODE_READ_FSCREDS와 같은 플래그를 명시적으로 사용합니다. 포함 더 이상 VM이 없는 스레드(대부분의 커널처럼 VM이 없었을 수도 있음) 스레드).
이 깃발이 디자인된 목적은 아니지만 그것이 바로 그것입니다.
ptrace 코드는 uid/gid가 일치하는지 확인하므로 다음을 수행해야 합니다. 커널 스레드 세부 정보를 보려면 uid-0이어야 하지만 이는 전통적인 "드롭 기능" 모델은 다음과 같은 경우에는 아무런 차이가 없습니다. 이 모든 것.
만약 당신이 MM 포인터, 스레드가 다음과 같은 경우 캐시된 "마지막 덤프 가능성" 플래그를 사용합니다. MM이 있었던 적이 있습니다. (커널 스레드의 경우 MM이 없으므로 0이 됩니다.) 설정), 재정의하려면 적절한 CAP_SYS_PTRACE 기능이 필요합니다.
왜 이 VPI인가 (설명가능 · 실험적)
VPI 산정 기준
| 영향도 | 71.00 |
| 악용 신호(PoC 존재) | ×1.20 |
| VPI | 85.20 |
VPI 공식 vpi-v1 기준