TL; DR
셸 쇼크 취약점이 완전히 수정되었습니다.
- 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에 이전 버전이 표시되면 OS 공급 업체가 스스로 패치 한 것일 수 있으므로 확인하는 것이 가장 좋습니다.
만약:
env xx='() { echo vulnerable; }' bash -c xx
"취약 함"을 표시하면 여전히 취약합니다. 즉 (bash는 파서가 여전히 코드에 노출되어 있는지 여부와 관련이 유일한 테스트입니다 모든 환경 변수).
세부.
버그는 5에 도입 내보내기 / 가져 오기 기능의 초기 구현에 있었던 일 브라이언 폭스 8 월 1989, 먼저 보안 전에, 나중에 배쉬는 널리 사용되지 않았습니다 한 번에 약 한달 bash는 - 1.03 출시 많은 관심사와 HTTP 및 웹 또는 Linux조차 존재했습니다.
1.05 의 ChangeLog에서 :
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.bash.bug 및 comp.unix.questions에 대한 일부 토론에서도 기능에 대해 언급합니다.
그것이 어떻게 도착했는지 이해하기 쉽습니다.
bash는 env vars에서 함수를 내 보냅니다.
foo=() {
code
}
그리고 수입시, =맹목적으로 해석해서는 안된다는 것을 제외하고는 공백으로 대체 된 것으로 해석하면됩니다.
bashBourne 쉘과 달리 스칼라 변수와 함수의 이름 공간이 다르다는 점에서도 깨졌습니다 . 실제로 있다면
foo() { echo bar; }; export -f foo
export foo=bar
bash 환경에 모두 행복하게 배치하지만 (같은 변수 이름의 항목이 있음) 많은 도구 (많은 셸 포함)가 전파하지 않습니다.
또한 bash는 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 편집
파서에서 추가로 2 개의 버그가 발견되었습니다 (CVE-2014-718 {6,7}) (대부분의 쉘은 파서가 구석 구석에 대한 파서에 버그를 갖도록되어 있습니다. 신뢰할 수없는 데이터에 노출되지 않았습니다).
다음 패치에서 3169 개의 버그 7169, 7186 및 7187이 모두 수정되었지만 Red Hat은 보안 강화를 위해 노력했습니다. 그들은 패치에서 동작을 변경하여 BASH_FUNC_myfunc()Chet의 디자인 결정을 선점하는 변수로 함수를 내보냈습니다 .
Chet은 나중에 공식적인 업스트림 bash 패치로이 수정을 발표했습니다 .
이 강화 패치 또는 그 변형은 현재 대부분의 주요 Linux 배포판에서 사용할 수 있으며 결국 Apple OS / X에 제공됩니다.
즉, 이제 두 파서 취약점을 포함하는 벡터를 통해 파서를 이용하는 임의 ENV var에 대한 관심 플러그 (CVE-2014-627 {7,8}) 후에 개시 하였다 마이클 잘레 스키 (거의 존재 CVE-2014-6278에 의해 고맙게도 CVE-2014-6271만큼 나쁨) 대부분의 사람들이 강화 패치를 설치할 시간이 지난 후
파서의 버그도 수정 될 것이지만, 파서가 더 이상 신뢰할 수없는 입력에 쉽게 노출되지 않기 때문에 더 이상 큰 문제가되지 않습니다.
보안 취약점이 수정되었지만 해당 영역에 일부 변경 사항이있을 수 있습니다. CVE-2014-6271에 대한 초기 수정이와 함께 오기 기능을 중지에 있음을 이전 버전과의 호환성 깨진있다 .거나 :또는 /자신의 이름을. 그것들은 여전히 bash에 의해 선언 될 수 있지만 일관성이없는 행동을합니다. 와 기능 때문에 .와 :이름에 일반적으로 사용되는, 그것은 가능성이 패치가 환경으로부터 적어도 사람들을 받아들이는 복원입니다.
왜 일찍 발견되지 않았습니까?
그것은 또한 내가 궁금했던 것입니다. 몇 가지 설명을 해줄 수 있습니다.
첫째, 보안 연구원 (및 전문 보안 연구원이 아님)이 특별히 bash의 취약점을 찾고 있었다면 아마도 발견했을 것입니다.
예를 들어, 내가 보안 연구원이라면 내 접근 방식은 다음과 같습니다.
bash입력을받는 위치 와 입력으로 수행되는 작업을보십시오. 그리고 환경은 명백합니다.bash인터프리터가 호출되는 장소 와 데이터를 확인하십시오. 다시, 눈에 띄는 것입니다.- 내 보낸 함수 의 가져 오기
bash는 setuid / setgid 일 때 비활성화되는 기능 중 하나이므로 보다 분명하게 볼 수 있습니다.
이제는 아무도 bash(통역사)를 위협으로 생각하지 않았 거나 위협이 그런 식으로 올 수 있다고 생각하지 않습니다.
bash통역은 신뢰할 수없는 입력을 처리하는 것은 아닙니다.
인터프리터가 아닌 쉘 스크립트 는 종종 보안 관점에서 면밀히 검토됩니다. 셸 구문은 매우 어색하며 신뢰할 수있는 스크립트를 작성하는 데는 많은 경고가 있습니다 (나 또는 다른 사람들이 split + glob 연산자를 언급했거나 변수를 인용해야하는 이유). 처리하는 스크립트에서 보안 취약점을 찾는 것이 일반적입니다 신뢰할 수없는 데이터.
그렇기 때문에 CGI 쉘 스크립트를 작성해서는 안된다는 말을 자주 들거나 대부분의 Unices에서 setuid 스크립트가 비활성화되어 있습니다. 또는 세계 쓰기 가능 디렉토리에서 파일을 처리 할 때 특히주의해야합니다 (예 : CVE-2011-0441 참조 ).
인터프리터가 아닌 쉘 스크립트에 중점을 둡니다.
신뢰할 수없는 데이터를 통해 (쉘 코드를 해석하는 외국 데이터를 공급)에 당신은 쉘 인터프리터를 노출 할 수 있습니다 eval하거나 .또는 사용자 제공 파일에 전화,하지만 당신의 취약점을하지 않아도 bash을 악용 할 수 있습니다. 쉘이 해석하기 위해 비위생 데이터를 전달하면 해석 할 것임이 분명합니다.
따라서 쉘은 신뢰할 수있는 컨텍스트에서 호출됩니다. 해석 할 고정 스크립트가 제공되고 처리 할 고정 데이터를 (안정적인 스크립트를 작성하기가 어렵 기 때문에) 그렇지 않은 경우가 더 많습니다.
예를 들어, 웹 컨텍스트에서 쉘은 다음과 같은 방식으로 호출 될 수 있습니다.
popen("sendmail -oi -t", "w");
무엇이 잘못 될 수 있습니까? 문제가있는 경우 해당 쉘 명령 행 자체의 구문 분석 방법이나 해당 쉘에 추가 데이터가 공급되는 것이 아니라 해당 센드 메일에 공급 된 데이터에 관한 것입니다. 해당 쉘에 전달 된 환경 변수를 고려할 이유가 없습니다. 그리고 그렇게하면 이름이 "HTTP_"로 시작 SERVER_PROTOCOL하거나 QUERYSTRING쉘이나 sendmail 과 관련이 있거나 없는 CGI env vars라는 이름의 모든 env var입니다 .
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; }", 와 같은 변수는 차단 하지 않는 것이 중요합니다 HTTP_FOO. 그리고 apache2는 결코 변수 echo또는 BASH_ENV변수 를 설정하지 않을 것 입니다.
일부 환경 변수는 이름을 기반으로 일부 컨텍스트에서 블랙리스트로 작성되어야하는 것은 분명 하지만 아무도 자신의 컨텐츠를 기반으로 블랙리스트로 작성해야한다고 생각한 사람은 없습니다 (제외 sudo). 즉, 임의의 env var가 코드 삽입을위한 벡터가 될 수 있다고 생각한 사람은 아무도 없습니다.
기능이 추가되었을 때의 광범위한 테스트로 인해 문제가 발생했는지 여부는 거의 없을 것입니다.
기능 을 테스트 할 때 기능 을 테스트합니다. 기능이 잘 작동합니다. 한 번의 bash호출로 함수를 내 보내면 다른 곳에서 가져옵니다. 동일한 이름을 가진 변수와 함수를 내보내거나 내 보낸 것과 다른 로케일로 함수를 가져올 때 매우 철저한 테스트에서 문제가 발견 될 수 있습니다.
그러나 취약점을 발견하기 위해서는 반드시 수행해야 할 기능 테스트가 아닙니다. 보안 측면이 주요 초점이되어야했으며 기능을 테스트하는 것이 아니라 메커니즘과 악용 방법을 테스트하고있을 것입니다.
개발자들 (특히 1989 년)이 종종 마음에두고있는 것이 아니며, 자신의 소프트웨어가 네트워크로 악용 될 수 없다고 생각하기 위해 쉘 개발자가 변명 될 수 있습니다.