Shellshock(CVE-2014-6271/7169) 버그는 언제 소개되었나요? 이 버그를 완전히 수정한 패치는 무엇인가요?

Question 1

긴 이야기 짧게

Shellshock 취약점이 완전히 수정되었습니다.

bash-2.05b 브랜치: 2.05b.10 이상(패치 10 포함)
bash-3.0 브랜치: 3.0.19 이상(패치 19 포함)
bash-3.1 브랜치: 3.1.20 이상(패치 20 포함)
bash-3.2 브랜치: 3.2.54 이상(패치 54 포함)
bash-4.0 브랜치: 4.0.41 이상(패치 41 포함)
bash-4.1 브랜치: 4.1.14 이상(패치 14 포함)
bash-4.2 브랜치: 4.2.50 이상(패치 50 포함)
bash-4.3 브랜치: 4.3.27 이상(패치 27 포함)

Bash에 이전 버전이 표시되면 운영 체제 공급업체에서 직접 패치할 수 있으므로 확인하는 것이 가장 좋습니다.

만약에:

env xx='() { echo vulnerable; }' bash -c xx

"취약성"을 보여도 여전히 취약합니다. 이것은 유일한 관련 테스트입니다(bash 파서가 여전히 노출되어 있는지 여부).어느환경 변수).

세부 사항.

^{이 버그는 1989년 8월 5일 Brian Fox가 도입한 내보내기/가져오기 기능의 초기 구현에 존재했으며} 보안 이전에 bash가 널리 사용되기 전인 약 한 달 후 bash-1.03에서 처음 릴리스되었습니다. 이는 큰 관심사이며 HTTP와 웹 또는 Linux도 존재합니다.

~에서1.05의 변경 내역:

Fri Sep  1 18:52:08 1989  Brian Fox  (bfox at aurel)

       * readline.c: rl_insert ().  Optimized for large amounts
         of typeahead.  Insert all insertable characters at once.

       * I update this too irregularly.
         Released 1.03.
[...]
Sat Aug  5 08:32:05 1989  Brian Fox  (bfox at aurel)

       * variables.c: make_var_array (), initialize_shell_variables ()
         Added exporting of functions.

일부 토론GNU 배쉬 오류그리고comp.unix.문제이 기능은 그 무렵에도 언급되었습니다.

그것이 어떻게 거기에 도달했는지 이해하기 쉽습니다.

bash는 환경 변수에 함수를 내보냅니다.

foo=() {
  code
}

가져올 때 해야 할 일은 =그것을 해석하기 위해 공백으로 바꾸는 것뿐입니다. 단, 맹목적으로 해석해서는 안 됩니다.

bash또 다른 문제는 (Bourne 쉘과 달리) 스칼라 변수와 함수의 네임스페이스가 다르다는 것입니다 . 사실, 당신이 가지고 있다면

foo() { echo bar; }; export -f foo
export foo=bar

bash둘 다 환경에 기꺼이 넣을 것이지만(예, 동일한 변수 이름을 가진 항목) 많은 도구(많은 쉘 포함)는 이를 전파하지 않습니다.

어떤 사람들은 BASH_환경 변수가 bash에만 관련되기 때문에 bash가 이를 위해 네임스페이스 접두사를 사용해야 한다고 생각합니다. 비슷한 기능을 가진 접두사를 rc사용하세요 .fn_

이를 달성하는 더 좋은 방법은 내보낸 모든 변수의 정의를 변수에 넣는 것입니다. 예를 들면 다음과 같습니다.

BASH_FUNCDEFS='f1() { echo foo;}
  f2() { echo bar;}...'

이것은 여전히 정리가 필요하지만 적어도 $BASH_ENV더 이상 쉽게 악용될 수는 없습니다 $SHELLOPTS...

bash함수 정의 이외의 내용이 해석되지 않도록 하는 패치가 있습니다 (https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081.html)은 다양한 Linux 배포판에 적용된 모든 보안 업데이트 중 하나입니다.

그러나 bash는 여전히 그 안에 있는 코드를 해석하므로 해석기의 모든 버그가 악용될 수 있습니다. 그런 오류 하나발견되었습니다(CVE-2014-7169)이지만 그 영향은 훨씬 작습니다. 그래서 곧 또 다른 패치가 있을 예정입니다.

bash가 어떤 변수에서든 코드를 해석하는 것을 방지하는 강화된 수정 사항이 있을 때까지(예: BASH_FUNCDEFS위의 방법 사용), 우리는 bash 구문 분석기의 버그에 의해 영향을 받지 않는다고 확신할 수 없습니다. 나는 그러한 강화된 수정 사항이 조만간 출시될 것이라고 믿습니다.

2014-09-28 편집

파서에서도 두 가지 버그가 발견되었습니다(CVE-2014-718{6,7})(대부분의 쉘은 특별한 경우를 대비해 파서에 버그가 있어야 하며 파서가 이를 수행하지 않으면 뭔가를 수행하지 않습니다). 신뢰할 수 없는 데이터에 노출되지 않고).

3가지 버그 7169, 7186, 7187이 모두 후속 패치에서 수정되었지만 Red Hat은 여전히 하드 픽스를 추진하고 있습니다. 패치에서는 기능을 BASH_FUNC_myfunc()다소 선제적인 Chet 설계 결정이라는 변수로 내보내도록 동작을 변경했습니다.

나중에 쳇공식 업스트림 bash 패치로 수정 사항을 릴리스하세요..

이 강화 패치 또는 그 변형은 이제 대부분의 주요 Linux 배포판과 Apple OS/X에서 사용할 수 있습니다.

이제 파서의 다른 두 가지 취약점을 포함하여 이 벡터를 통해 파서의 임의 환경 변수를 악용하는 것에 대한 우려가 제거되었습니다(CVE-2014-627{7,8}).나중에 밝혀졌는데작성자: Michał Zalewski(CVE-2014-6278은 CVE-2014-6271만큼 위험함) 다행히도 대부분의 사람들은 강화 패치를 설치할 시간이 있습니다.

파서의 버그도 수정되지만 파서는 더 이상 신뢰할 수 없는 입력에 쉽게 노출되지 않으므로 더 이상 큰 문제가 되지 않습니다.

보안 취약점이 수정되었지만 이 영역에서는 일부 변경 사항이 있을 수 있습니다. CVE-2014-6271에 대한 초기 수정 사항은 해당 이름이 포함된 함수 가져오기를 중단했기 때문에 이전 버전과의 호환성이 손상 .되었습니다 :. /이는 여전히 bash로 선언될 수 있지만 이로 인해 일관되지 않은 동작이 발생합니다. 해당 이름이 .포함된 기능이 일반적으로 사용 되므로 :패치는 최소한 환경에서 기능을 허용하도록 되돌아갈 가능성이 높습니다.

더 일찍 알아 보는 것은 어떨까요?

이것은 나도 알고 싶은 것입니다. 몇 가지 설명을 제공할 수 있습니다.

첫째, 보안 연구원(저는 전문 보안 연구원은 아닙니다)이 특별히 bash의 취약점을 찾고 있었다면 아마도 발견했을 것입니다.

예를 들어, 내가 보안 연구원이라면 내 접근 방식은 다음과 같습니다.

bash입력을 어디서 받고 어떻게 처리하는지 확인하세요 . 그리고 환경도 한눈에 알 수 있습니다.
bash통역사가 호출되는 위치와 데이터를 확인하세요 . 이번에도 눈에 띕니다.
수입내보내기 기능setuid/setgid 일 때 비활성화되는 기능 중 하나 bash이므로 더욱 명확해집니다.

이제 나는 누군가 bash(통역사)를 위협으로 보거나 위협이 그런 식으로 생성될 수 있다고 의심합니다.

인터프리터는 bash신뢰할 수 없는 입력을 처리하기 위한 것이 아닙니다.

껍데기스크립트(통역사가 아닌) 보안 관점에서 면밀히 조사되는 경우가 많습니다. 셸 구문은 매우 어색하고 신뢰할 수 있는 스크립트를 작성하는 데 많은 주의 사항이 있으므로(나나 다른 사람들이 분할+글로브 연산자를 언급하는 것을 본 적이 있거나 변수를 인용해야 하는 이유는 무엇입니까?) 처리하는 동안 보안 허점을 찾는 것이 매우 어렵습니다. 스크립트. 신뢰할 수 없는 데이터.

이것이 CGI 쉘 스크립트를 작성해서는 안 된다거나 대부분의 Unices에서 setuid 스크립트가 비활성화되어 있다는 말을 자주 듣는 이유입니다. 또는 전역적으로 쓰기 가능한 디렉터리에 있는 파일을 처리할 때는 각별한 주의를 기울여야 합니다(참조:CVE-2011-0441예를 들어).

초점은 인터프리터가 아닌 쉘 스크립트에 있습니다.

eval사용자 제공 파일에서 호출하여(해석을 위한 쉘 코드로 외부 데이터 제공) 쉘 인터프리터를 신뢰할 수 없는 데이터에 노출시킬 수 있지만 이를 악용하기 .위해 취약점이 필요하지는 않습니다 . bash분명히 해석을 위해 원시 데이터를 셸에 전달하면 셸이 이를 해석할 것입니다.

따라서 쉘은 신뢰할 수 있는 컨텍스트에서 호출됩니다. 해석할 고정된 스크립트를 제공하고 일반적으로 (신뢰할 수 있는 스크립트를 작성하는 것은 매우 어렵기 때문에) 처리할 고정된 데이터를 제공합니다.

예를 들어 웹 컨텍스트에서 셸은 다음과 같이 호출될 수 있습니다.

popen("sendmail -oi -t", "w");

무엇이 잘못될 수 있나요? 문제가 발생하면 셸 명령줄 자체를 구문 분석하는 방법이나 셸에 추가 데이터가 공급되는 방식이 아니라 sendmail에 공급되는 데이터에 관한 것입니다. 쉘에 전달된 환경 변수를 고려할 이유가 없습니다. 이렇게 하면 이름이 "HTTP_"로 시작하는 모든 환경 변수는 잘 알려진 CGI 환경 변수이거나 쉘 또는 sendmail과 아무 관련이 없다는 SERVER_PROTOCOL것을 알게 됩니다.QUERYSTRING

setuid/setgid를 실행하거나 sudo를 통해 실행하는 경우와 같은 권한 에스컬레이션 컨텍스트에서는 환경이 고려되는 경우가 많으며 과거에도 셸 자체가 아니라 권한을 상승시키는 항목에 대해 많은 취약점이 있었습니다. sudo(예를 들어 참조CVE-2011-3628).

예를 들어, bashsetuid에 의해 호출되거나 setuid 명령( mount예: 도우미 프로그램 호출)을 통해 호출되면 환경이 신뢰되지 않습니다. 특히 내보낸 함수는 무시됩니다.

sudo깨끗한 환경 수행: 기본적으로 화이트리스트에 포함된 환경을 제외한 모든 환경이 나열되며, 그렇게 하지 않도록 구성한 경우 쉘이나 다른 방식(예: PS4, BASH_ENV... SHELLOPTS)에 영향을 미치는 것으로 알려진 일부 환경이 나열됩니다. 또한 환경 변수를 블랙리스트에 추가합니다.콘텐츠(이것이 CVE-2014-6271이 를 통한 ()권한 상승을 허용하지 않는 이유입니다 sudo).

그러나 이는 환경을 신뢰할 수 없는 컨텍스트에도 적용됩니다. 즉, 해당 컨텍스트에서 악의적인 사용자가 이름과 값을 가진 모든 변수를 설정할 수 있습니다. 이는 웹 서버/ssh 또는 환경이 제어되는 CVE-2014-6271을 이용하는 모든 벡터에는 적용되지 않습니다(적어도 환경 변수의 이름은 제어됩니다...).

같은 변수를 차단하는 것이 중요 echo="() { evil; }"하지만 쉘 스크립트나 명령줄이 이를 명령으로 호출하지 않기 HTTP_FOO="() { evil; }"때문에 그렇지 않습니다. apache2는 OR 변수를 HTTP_FOO설정하지 않습니다 .echoBASH_ENV

그것은 명백하다일부상황에 따라 환경 변수를 블랙리스트에 추가해야 하는 경우도 있습니다.이름하지만 자신의 상황에 따라 블랙리스트에 올라야 한다고 생각하는 사람은 아무도 없습니다.콘텐츠(와는 별개로 sudo). 즉, 임의의 환경 변수가 코드 삽입의 벡터가 될 수 있다고 생각하는 사람은 아무도 없습니다.

기능이 추가되었을 때 수행된 광범위한 테스트에서 이를 포착할 수 있었는지 여부에 대해서는 그럴 가능성이 낮다고 생각합니다.

테스트할 때특징, 기능을 테스트합니다. 이 기능은 잘 작동합니다. 한 호출에서 함수를 내보내면 bash다른 호출에서 가져올 수 있습니다. 매우 철저한 테스트를 통해 동일한 이름의 변수 및 함수를 내보낼 때 또는 함수를 내보냈을 때와 다른 로케일로 가져올 때 문제가 드러날 수 있습니다.

그러나 취약점을 찾기 위해 기능 테스트를 수행할 필요는 없습니다. 보안 측면이 주요 초점이 되어야 하며 기능을 테스트하는 것이 아니라 메커니즘과 그것이 남용될 수 있는 방법을 테스트해야 합니다.

이것은 개발자(특히 1989년)가 자주 생각하는 것이 아니며 쉘 개발자는 자신의 소프트웨어가 네트워크에 의해 악용될 가능성이 없다고 생각할 수도 있습니다.

Answer