분리된 화면 세션에서 루트 셸을 실행해도 안전합니까?

스크린 세션에 루트 셸이 있고(분리 여부, 비밀번호로 보호 여부) screen실행 파일이 setxid가 아닌 경우 액세스 권한을 얻은 공격자가 해당 셸에서 명령을 실행할 수 있습니다. 다른 방법이 없으면 이렇게 할 수 있어요길그림 과정.

screen이 setuid 또는 setgid이고 세션이 분리되고 암호로 보호되는 경우 원칙적으로 해당 셸에서 명령을 실행하려면 화면 암호가 필요합니다. 이 원칙이 사실이라면 단순히 귀하의 계정을 손상시킨 누군가가 트로이 목마를 설치하고 귀하가 비밀번호를 입력할 때까지 기다려야 할 것입니다. 그러나 공격 표면(즉, 버그나 잘못된 구성으로 인해 문제가 발생할 수 있는 곳의 수)은 매우 넓습니다. 기본 시스템 보안 기능 외에도 다음을 신뢰합니다.

• 비밀번호 확인이 올바른지 확인하는 화면입니다.
• 다른 수단을 통해 세션에 접근하는 것을 방지하는 화면입니다.
• 운영 체제 액세스 제어 메커니즘(예: 파이프에 대한 권한)을 올바르게 사용하기 위한 화면입니다.
• 커널은 ptrace 보안 검사(취약성의 일반적인 원인)를 올바르게 수행합니다.
• 실행 중인 쉘은 어리석은 작업을 수행하지 않습니다.
• 다른 일부 기능은 당신을 물지 않을 것입니다.

"당신을 물지 않을 다른 기능들": 예, 그것은 모호합니다. 하지만 항상 안전 문제가 있습니다. 이것이 단지 희망사항이라고 생각할 수도 있지만, 정말로 그것에 대해 생각해 보셨나요? 예를 들어…

터미널 장치에 쓸 수 있는 한, 셸의 입력에 데이터를 주입할 수 있습니다. 내 컴퓨터 화면의 기본 구성에서:

printf '\ekfoo\017bar\e\\' >/dev/pts/33
printf '\e[21t' >/dev/pts/33

␛]lfoobar␛l이는 쉘의 입력 스트림에 삽입됩니다 . \ek응용 프로그램(또는 터미널 장치에 쓸 수 있는 모든 것)이 창 제목을 설정할 수 있도록 하는 제어 시퀀스입니다(참조:화면 매뉴얼의 "Windows 이름 지정" 섹션), \e[21t터미널이 애플리케이션의 표준 입력에 대한 제목을 보고하도록 합니다(Screen은 이 시퀀스를 문서화하지 않지만 구현합니다 CSI Ps ; Ps ; Ps ; t.xterm 제어 시퀀스 목록. 실제로 화면 4.0.3에서는 보고서 제목에서 모든 제어 문자가 제거되므로 쉘은 개행 없이 읽습니다 lfoobar( ␛]편집 명령에 바인딩되지 않은 것으로 가정). 따라서 공격자는 실제로 이 방법으로 명령을 실행할 수는 없지만 명령 chmod u+s /bin/sh뒤에 공백이 많이 있거나 프롬프트처럼 보이는 등 명령을 추가할 수 있습니다.

Screen은 여러 가지 다른 유사한 위험 제어 시퀀스를 구현하고 있으며 해당 취약점의 잠재력이 무엇인지 모르겠습니다. 그러나 이제는 화면 세션 암호가 제공하는 보호 기능이 그다지 훌륭하지 않다는 것을 알 수 있기를 바랍니다. sudo와 같은 전문 보안 도구는 취약점이 있을 가능성이 훨씬 적습니다.

"루트가 아닌 사용자 계정이 손상될 가능성"이 상당히 높기 때문에 이것이 보안 문제라고 생각합니다.

그러나 그 외에도 다른 위험이 증가합니다. 예를 들어, 이제 스크린 소켓 디렉터리( /var/run/screen내 시스템에 있지만 /tmp가끔 사용함) 에서 권한을 변경할 수 있는 이론적 취약점이 발생했습니다 . 이 취약점은 이제 다른 방법으로는 불가능할 수 있는 루트 권한을 얻을 수 있는 경로를 제공합니다.

sudo.sudo su -​당신은 이미완벽한). 전체 권한이 있는 세션으로 전환하는 대신 모든 명령에 대해 의도적인 에스컬레이션을 요구하여 사고를 예방하는 데 도움이 됩니다.

화면에서 생성된 파이프는 소유자만 액세스할 수 있으므로 보안 문제가 되지 않습니다.