터미널에서 이스케이프 시퀀스 공격을 피하는 방법?


29

CVE-2009-4487 (로그 파일의 이스케이프 시퀀스 위험에 대한 정보)에 대한 세부 정보를 읽는 것이 약간 놀랍습니다.

CVE-2009-4487 을 인용하려면 :

nginx 0.7.64는 인쇄 할 수없는 문자를 삭제하지 않고 로그 파일에 데이터를 기록하므로 원격 공격자가 터미널 에뮬레이터의 이스케이프 시퀀스가 ​​포함 된 HTTP 요청을 통해 창의 제목을 수정하거나 임의의 명령을 덮어 쓰거나 파일을 덮어 쓸 수 있습니다.

분명히 이것은 실제로 nginx의 보안 허점이 아니라 터미널 에뮬레이터의 문제입니다.

물론 cat터미널에 로그 파일을 보내는 것은 우연히 만 발생하지만 로그 파일을 grep만드는 것은 매우 일반적입니다. less아마도 이스케이프 시퀀스를 삭제하지만 쉘 명령이 이스케이프 시퀀스를 변경하지 않는 것을 아는 사람은 ...

나는 바니쉬 응답 에 동의하는 경향이 있습니다 .

일반적으로 터미널-응답-탈출의 지혜는 일정한 간격으로 의문을 제기했지만 주요 터미널 에뮬레이션 프로그램 중 어느 것도 이러한 시퀀스를 버리는 데 적합한 것으로 보지 못했을 것입니다. [..] 로그 파일을 작성하는 모든 프로그램을 비난하는 대신, 보안 관점에서 터미널 에뮬레이션 프로그램이 어리석은 일을 멈추게하여이 문제와 다른 보안 문제를 한 번 해결하는 것이 훨씬 생산적입니다. 그리고 모두를 위해.

따라서 내 질문 :

더 이상 이스케이프 시퀀스를 통해 명령을 실행하거나 파일을 덮어 쓸 수 없도록 xterm을 어떻게 보호 할 수 있습니까?

이 공격에 대비하여 X 용 터미널 에뮬레이터는 무엇입니까?


4
많은 이스케이프 시퀀스는 합법적 인 일을 수행합니다 (xterm 이름 바꾸기 / 크기 변경 등). 그러나 누구나 명령실행하거나 파일을 덮어 쓰는 이스케이프 시퀀스를 식별 할 수 있습니까?
krubo


Security SE에 대한 웹 브라우저에서 붙여 넣기 제어 문자에 대한 비슷한 문제 : 이러한 종류의 클립 보드 악용으로부터 어떻게 자신을 보호 할 수 있습니까? tl; dr : 2013/2015 이후에 릴리스 된 xterm / vte 기반 터미널을 사용하는 경우 기본적으로 제어 문자를 필터링 할 때이로부터 보호됩니다.
maxschlepzig

답변:


27

VT100 터미널 (모든 최신 터미널 에뮬레이터가 어느 정도 에뮬레이션)은 많은 문제가있는 명령을 지원했지만 최신 에뮬레이터 또는 배포는 문제가 많고 덜 유용한 명령을 비활성화합니다. 잠재적으로 위험한 이스케이프 시퀀스 의 전체 목록은 다음과 같습니다 (어떤 방식으로도 디스플레이를 읽을 수 없도록하는 것은 포함하지 않음).

  • rxvt 및 Eterm의 임의 로그 파일 명령은 HD Moore에 의해보고되었습니다 . 이들은 실제로 주요 버그이며, 다행스럽게도 오랫동안 수정되었습니다.
  • 리턴 터미널 상태라고도하는 answerback 명령은 ENQ( Ctrl+E)에 의해 호출됩니다 . 사용자가 입력 한 것처럼 터미널에 텍스트를 삽입합니다. 그러나,이 텍스트는 공격자의 통제하에되지 않습니다 : 그것은 터미널의 자신의 이름과 같은 일반적으로 뭔가 xtermscreen. 내 시스템 (Debian squeeze)에서 xterm은 기본적으로 빈 문자열을 반환합니다 ( answerbackString리소스에 의해 제어 됨 ).
  • 장치 속성 보내기 명령 ESC [ c및 친구. 터미널은 숫자와 ASCII 문장 부호 만 포함 할 수 ESC [ … c있는 것으로 응답합니다 . 이 기능은 일부 터미널 기능을 쿼리하는 방법으로, 대부분 사용되지 않지만 이전 응용 프로그램에서 사용되었을 수 있습니다. 다시 말하지만 터미널의 응답은 사용자 입력과 구별 할 수 없지만 공격자는 제어 할 수 없습니다. 제어 순서는 기능 키처럼 보일 수 있지만 사용자가 비정상적인 구성을 가지고있는 경우에만 가능합니다 (내가 본 일반적인 설정 중 어느 것도 터미널 응답의 접두사 인 유효한 기능 키 이스케이프 시퀀스가 ​​없습니다).
  • 다양한 장치 제어 기능 (로 시작하는 DCS 이스케이프 ESC P)
    • DECUDK전형적인 터미널 에뮬레이터에서 (사용자 정의 키 설정)을 통해 어떤 피해를 입을 수 있는지 모르겠습니다 .
    • DECRQSS(Request Status String)은 터미널이 이스케이프 시퀀스로 응답하는 또 다른 명령이며 이번에는 \eP; \eP유효한 키 ( Alt+ Shift+ P) 이므로 문제가 될 수 있습니다 .
    • : 텀은 두 가지 실험적인 기능을 가지고 ESC P + p …ESC P + q …, 취득 및 설정 TERMCAP 문자열을. 설명에서 이것은 최소한 기능 키의 효과를 수정하는 데 사용될 수 있습니다.
  • 여러 상태 보고서 명령 : ESC [ … n(장치 상태 보고서). 터미널은 이스케이프 시퀀스로 응답합니다. 이 이스케이프 시퀀스의 대부분은 기능 키 이스케이프 시퀀스와 일치하지 않습니다. 문제는 다음과 같습니다.보고 대상 ESC [ 6 n은 숫자 시퀀스의 위치 및 숫자 형식 이며 일부 수정 자 에서처럼 보일 수 있습니다.ESC [ x ; y RxyF3
  • 창 조작 명령 ESC [ … t.
    • 이들 중 일부는 xterm 창의 크기를 조정하거나 아이콘 화하는 등의 작업을 수행 할 수 있습니다.
    • 이들 중 일부는 터미널이 이스케이프 시퀀스로 응답하게합니다. 이러한 이스케이프 시퀀스의 대부분은 위험이 적지 만 두 가지 위험한 명령이 있습니다. 터미널 창의 아이콘 레이블과 제목에 대한 답변 ESC [ 2 0 t과 대답을 ESC [ 2 1 t포함하며 공격자는이 명령을 선택할 수 있습니다.
    • 최소한 데비안 압축에서는 xterm은 기본적으로이 명령을 무시합니다. allowWindowOps리소스 를 설정하거나 리소스를 통해 선택적으로 활성화 할 수 있습니다 disallowedWindowOps. Ubuntu 10.04의 그놈 터미널은 기본적으로 제목 응답을 구현합니다. 다른 터미널이나 버전을 확인하지 않았습니다.
  • 터미널 제목 또는 아이콘 이름을 설정하는 명령입니다. xterm 및 대부분의 다른 X 터미널에서는 입니다. 화면에서 이스케이프 시퀀스는 입니다. 이 명령에 대한 우려가 과대 평가 된 것으로 나타났습니다. 그들은 약간의 장난을 허용하지만 모든 웹 페이지에는 같은 문제가 있습니다. 수업이 아닌 제목만을 기준으로 창에서 행동하는 것은 신뢰할 수없는 당사자가 이름을 지정한 파일을 열거 나 쉘 스크립트에서 변수 확장을 인용하지 않거나 코에 멍청한 개를 두드리는 것과 비슷합니다 물린 경우 불평하지 마십시오.ESC ] digit ; title ESC \ESC k title ESC \

나는 바니쉬의 반응이 불분명하다는 것을 안다. 그것은 책임을 바꾸려고하거나 보안 나치 모드 (진정한 여부에 관계없이 모든 보안 문제가 블랙 볼링을 정당화 함) 인 것처럼 느껴집니다.

일반적으로 터미널-응답-탈출의 지혜는 일정한 간격으로 의문을 제기했지만 주요 터미널 에뮬레이션 프로그램 중 어느 것도 이러한 시퀀스를 버리는 데 적합한 것으로 보지 못했을 것입니다. (…)
로그 파일을 작성하는 모든 프로그램을 비난하는 대신, 보안 관점에서 터미널 에뮬레이션 프로그램이 어리석은 일을 멈추게하여이 문제와 다른 보안 문제를 한 번 해결하는 것이 훨씬 생산적입니다. 모든.

많은 답변이 유용한 기능입니다. 응용 프로그램은 커서 위치 및 창 크기와 같은 것을 알아야합니다. 창 제목을 설정하는 것도 매우 유용합니다. 이것에 대한 ioctl호출 에만 전적으로 의존 할 수는 있지만, 이러한 ioctl호출을하고 파일 디스크립터에 전달하는 유닉스 스타일의 텍스트로 변환 하려면 추가 코드와 유틸리티가 필요 했을 것입니다. 이러한 인터페이스를 변경하면 많은 이점이 있지만 많은 작업이 필요합니다.

텍스트 파일에는 제어 문자와 같은 비 인쇄 문자가 포함되지 않아야합니다. 로그 파일은 일반적으로 텍스트 파일이어야합니다. 로그 파일에는 제어 문자가 포함되지 않아야합니다.

파일에 이스케이프 시퀀스가 ​​포함되어 있는지 걱정되는 경우 편집기에서 파일을 열거 나 또는 옵션 less없이 파일을 보거나을 통해보십시오 .-r-Rcat -v


2
"이것에 대한 ioctl 호출에 전적으로 의존하는 것이 가능할 것입니다."하지만 앱과 터미널 사이에 실제로 직렬 케이블이 있다면 어떨까요?
mmv-ru

5

그렇게 간단하지는 않습니다. 많은 사람들이 xterm제목 등을 프롬프트 등의 일부로 설정하는 코드를 가지고 있으며 , 아주 좋은 이유로 ( shutdown잘못된 터미널 창에서 잘못된 기계를 가진 사람이 알려줄 수 있기 때문에!). 따라서 올바르게 수정하면 보안 컨텍스트가 도입되어 쉘과 터미널 에뮬레이터 및 아마도 사람들의 도트 파일 간의 상호 작용이 심각하게 복잡해집니다. 또는 터미널에 표시 될 수있는 모든 것을 위생적으로 처리하는 저임금 솔루션으로 갈 수 있습니다. 이것은 제어 문자를 이스케이프 처리하는 데 크게 줄어 듭니다. 로그 파일에서 누군가 쉘 코드를 주입하려고 시도 할 수 있기 때문에 어쨌든 눈에 띄게하기 위해 수행해야합니다.

(제외 적으로, punycode 는 같은 종류의 문제의 더 심각한 사례이며 그럼에도 불구하고 공식 표준이되었습니다. 때로는 보안이 통제 할 수없는 안전하지 않은 설계를 완화하기 위해 보안이 제공되기도합니다.)


1
x 용어는 이스케이프 시퀀스를 통해 제목을 변경할 수 있지만 파일 을 덮어 쓰고 이스케이프 시퀀스를 통해 임의의 명령실행할 수는 없습니다 . 그것은 앞으로 나아갈 것입니까?
maxschlepzig 2018 년

1
이를 수행하는 직접적인 방법은 몇 년 동안 비활성화되었습니다. 간접적 인 방법은 여전히 ​​남아 있지만 최소한 추가 단계 (예 : 사용자가 프로그래밍 된 기능 키를 호출하도록하는 사회 공학적 공격)가 필요합니다. 그러나 제목 표시 줄은 CVE에서 구체적으로 언급되었는데, 이는 아마도 사용자가 잘못된 장소에서 무언가를하도록 혼동하는 공격의 일부일 것입니다. 현대의 가장 큰 걱정은 임의의 텍스트를 쉘에 보내도록 프로그래밍 할 수있는 것, 그리고 공격자가 터미널 에뮬레이터가 무엇을 할 수 있는지 알아낼 수있는 응답입니다.
geekosaur

그러나 페이스 바니시는 페이스 포트가 소프트웨어가 최소한으로 포팅되는 적절한 상업적 환경에서 여전히 사용되고 있으며, 적절한 변경을 위해 치아를 당기는 것보다 훨씬 더 많은 시간이 걸립니다.
geekosaur 2016 년
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.