나는 사용자 프로그램이 의도적으로 Linux 커널 상태에 영향을 미칠 수 있는 방법이 많이 있다고 생각합니다.
- 시스템 호출을 호출하여
- 전화로지도()커널에 매핑된 메모리에 씁니다.
- 커널 모듈을 로드하여모듈 삽입.
다른 방법은 생각나지 않습니다. 하드웨어 인터럽트는 사용자 프로그램에 의해 시작되지 않기 때문에 고려되지 않습니다. 나는 둘 다라고 생각한다지도()그리고모듈 삽입시스템 호출이 사용되고 있으므로 사용자 프로그램은 커널 상태에 영향을 미치기 위해 시스템 호출에 의존해야 할 수도 있습니다. 내가 맞나요?
내가 옳다면 커널에 몇 가지 취약점이 있고 악의적인 사용자 프로그램이 이를 악용하여 커널을 공격하려고 한다고 가정해 보겠습니다. 우리의 검증이 항상 진실을 말한다면, 그러한 공격을 방어하기 위해 모든 시스템 호출을 검증할 수 있습니까?
답변1
또 다른 일이 생기네요중요한커널과의 인터페이스: /proc및 /sys가상 파일 시스템. 일반 파일을 보유하지는 않지만 해당 내용은 커널에 대한 직접적인 포털입니다. 해당 파일에 대한 작업은 커널이 할당한 메모리에서 직접 작업하는 것입니다. 예를 들어 모든 메모리 캐시를 삭제하려면 다음을 사용할 수 있습니다.
echo 3 > /proc/sys/vm/drop_caches
...커널이 즉시 반응합니다.
이제 프로그램은 파일 시스템과 상호 작용하기 위해 시스템 호출( , , open, 등)이 필요합니다. 그러나 이러한 모든 시스템 호출을 추적하는 방법은 여전히 있습니다. 커널은 추적 메커니즘을 제공합니다. 보다 구체적으로 시스템 호출 추적은 에 의해 처리됩니다. 이 가상 디렉터리에는 각 시스템 호출에 대한 두 개의 하위 디렉터리가 포함되어 있습니다. 예를 들어 개방형 시스템 호출을 사용하면 다음과 같습니다.readwrite/sys/kernel/debug/tracing/sys/kernel/debug/tracing/events/syscalls
sys_enter_opensys_exit_open
이 디렉터리 내에서 이름이 "1"인 파일을 찾을 수 있습니다 enable. 해당 파일에 "1"이 포함되어 있으면 open관련 이벤트(시작 또는 종료 호출)가 추적되고 있는 것입니다. 저는 주로 이 enter이벤트를 이용하지만, 여러분의 필요에 더 적합한 이벤트를 선택하실 수 있습니다.
시스템 호출 추적을 활성화하면 에서 로그를 찾을 수 있습니다 /sys/kernel/debug/tracing/trace. 이제 기억해주세요열려 있는시스템 호출 사용많은. 이는 Linux 시스템의 모든 것이 될 수 있는 프로그램과 파일 간의 궁극적인 게이트웨이입니다. 또한 기억하세요 ...
UNIX는 사용자가 어리석은 일을 하는 것을 방지하도록 설계되지 않았습니다. 왜냐하면 그렇게 하면 사용자가 현명한 일을 하는 것도 방지할 수 있기 때문입니다. — 더그 그윈
시스템에서 무슨 일이 일어나고 있는지 모니터링할 수는 있지만 커널은 사용자가 어리석은 일을 하는 것을 막으려고 하지 않습니다. 이는 시스템 관리자의 업무 중 더 많은 부분입니다.
관리 추적 메커니즘에는 다음 권한이 필요합니다 /sys/kernel/debug/tracing/trace. 추적을 활성화하고 작동하려면 루트 권한이 필요할 수 있습니다. 완료되면 추적을 비활성화하는 것을 잊지 마십시오.
답변2
때에 따라 다르지. "validate"은(는) 무슨 뜻인가요? 특정 프로세스에 의해 트리거된 시스템 호출만 모니터링하려는 경우 가능합니다... 일반적으로... 하지만 더 자세히 알고 싶다면 문제가 발생합니다... .들은 바가 없습니다. 이를 수행할 수 있는 모든 도구 중 하나입니다.
strace를 사용하면 특정 프로세스에 의해 어떤 시스템 호출이 트리거되는지 확인할 수 있습니다. 물론, 루트로 실행해야 합니다... 그러나 strace는 응용 프로그램의 활동 모니터링을 보호하므로 strace를 항상 성공적으로 실행하지는 않습니다. ptrace 호출은 삭제됩니다. 크롬으로 추적해 보세요. 알 수 있을 것입니다 ;)
strace가 충분하지 않은 경우 각 애플리케이션 바이너리를 분석하고 그것이 수행하는 작업을 수동으로 검사할 수 있습니다. 이것은 흥미로울 것입니다 :) (또는 물론 소스 코드를 얻고 이러한 모든 알고리즘을 사람이 읽을 수 있는 텍스트로 처리할 수 있습니다. 하지만 ASM을 사용할 수 있는데 왜 더 간단한 방법을 선택합니까 :))
답변3
이것은 좋은 첫 번째 근사치입니다. 사용자 공간과 커널 사이에는 강한 경계가 있으며,최대상호 작용에는 시스템 호출이 포함되어야 합니다. 이 모델은 strace문제 해결 도구로서 왜 그렇게 강력한지 이해하는 데 도움이 됩니다.
많은 수의 커널 취약점은 이러한 검증이 부족하기 때문일 수 있습니다. 이러한 유형의 검증에는 비용이 매우 많이 든다는 점을 이해하십시오. 이는 직접적인 하드웨어 액세스 등에 사용될 수 있는 언어의 경우 특히 그렇습니다. 이는 C와 같은 원시 언어를 사용할 때 특히 그렇습니다. 언어 설계가 그러한 검증에 원하는 것보다 훨씬 적은 도움을 제공하기 때문입니다.
잘 알려진 완화 방법은 다음과 같습니다.마이크로커널. 코드가 적으면 더 많은 검증이 가능합니다. 마이크로커널 아키텍처를 사용하면 많은 양의 장치 드라이버 코드가 훨씬 더 많이 포함될 수 있습니다. IOMMU와 MMU가 충분하다면 전적으로 그럴 수도 있습니다.
그러나 이 진술은 올바르지 않습니다.
올바른 용어를 사용하여 검색하면 반례가 되는 취약점을 많이 찾을 수 있다고 생각합니다. 아직 매핑되지 않은 메모리 범위에서 오류가 생성될 수 있습니다.
"Linux 커널 i386 SMP 페이지 오류 처리기 권한 에스컬레이션"[보안팀].
일반적으로 모든 아키텍처별 오류 코드를 확인해야 합니다. 여기에는 시스템 호출 및 페이지 폴트를 수신하는 코드가 포함됩니다. 그러나 부동 소수점 예외(0으로 나누기)와 같은 다른 유형의 오류도 있습니다.
또한 하드웨어 세부 정보로 인해 취약점이 발생할 수 있습니다. 코드를 확인하려고 할 때 특정 하드웨어 세부 정보를 알지 못할 수도 있습니다.