Shellshock Bash 취약점은 어떻게 발견되었나요?

Question

몇 분을 안심시키기 위해 저는 익스플로잇을 관찰하여 버그를 발견한 것이 아니며 공개되기 전에 이 버그가 익스플로잇되었다고 믿을 이유가 없습니다(물론 배제할 수는 없지만). bash님의 코드를 보고도 찾지 못했습니다 .

나는 당시 내 생각의 흐름을 정확히 기억한다고 말할 수 없습니다.

그것은 내가 찾은 일부 소프트웨어의 일부 동작에 대한 반성에서 비롯되었습니다.위험한(소프트웨어가 아닌 행동). 당신을 생각하게 만드는 행동의 종류:그건 좋은 생각이 아닌 것 같아.

이 경우 이름이 LC_. 아이디어는 사람들이 ssh다른 기계에 접속할 때 자신의 언어를 계속 사용할 수 있도록 하는 것입니다. 특히 UTF-8을 방정식에 포함할 때 현지화 처리가 얼마나 복잡한지 고려하기 시작할 때까지(그리고 많은 응용 프로그램에서 UTF-8이 얼마나 잘못 처리되는지 확인하기 전까지는) 좋은 아이디어입니다.

sshd 2014년 7월에 저는 이미 해당 구성 과 결합된 glibc 지역화 처리의 취약점을 보고했습니다 .다른 두 명위험한 행동bash껍질 의 (인증된) 공격자가 git 서버에 파일을 업로드할 수 있고 bashgit unix 사용자의 로그인 셸로 사용된 경우 git 서버를 해킹할 수 있습니다(CVE-2014-0475).

나는 ssh를 통해 서비스를 제공하는 사용자의 로그인 셸로 사용하는 것이 아마도 나쁜 생각이라고 생각했습니다. bash이 셸은 매우 복잡한 셸이고(필요한 것은 아주 간단한 명령줄을 구문 분석하는 것뿐일 때) 대부분의 잘못된 설계를 상속받았기 때문입니다. ksh의. bash해당 컨텍스트에서 (ssh 를 해석하기 위해) 사용되는 것과 관련된 몇 가지 문제를 이미 식별했기 때문에 ForceCommand잠재적으로 더 많은 문제가 있는지 궁금합니다.

AcceptEnv LC_*이름이 시작하는 모든 변수를 허용 LC_하고 나는 막연하게 기억했습니다.bash 내보낸 함수(ㅏ위험한비록 때때로 유용한 기능이지만) 이름이 다음과 같은 환경 변수를 사용하고 있었고 myfunction()거기에서 살펴볼 흥미로운 것이 없는지 궁금했습니다.

LC_something 기존 명령 이름이 아니기 때문에 실제로 문제가 될 수 없는 명령을 재정의하는 것이 최악의 방법이라는 이유로 무시하려고 했으나 어떻게 해야 할지 궁금해지기 시작했습니다.bash 수입됨해당 환경 변수.

예를 들어 변수가 호출되면 어떻게 될까요 LC_foo;echo test; f()? 그래서 좀 더 자세히 살펴보기로 했습니다.

ㅏ:

$ env -i bash -c 'zzz() { :;}; export -f zzz; env'
[...]
zzz=() {  :
}

myfunction()변수가 호출되지 않았다는 점에서 내 기억이 틀렸다는 사실이 밝혀졌습니다 myfunction. 값) 로 시작하는 것입니다 ().

그리고 간단한 테스트:

$ env 'true;echo test; f=() { :;}' bash -c :
test
bash: error importing function definition for `true;echo test; f'

변수 이름이 정리되지 않았으며 코드가 평가되었다는 의심을 확인했습니다.시작 시.

더 나쁘게, 훨씬 더 나쁘게,값다음 중 하나도 소독되지 않았습니다.

$ env 'foo=() { :;}; echo test' bash -c :
test

그런 뜻이었어어느환경 변수는 벡터일 수 있습니다.

그때 나는 문제의 정도를 깨달았고, HTTP( HTTP_xxx/ QUERYSTRING...env vars), 메일 처리 서비스, 나중에는 DHCP(아마도 긴 목록) 등을 통해서도 악용 가능하다는 것을 확인하고 이를 보고했습니다(신중하게). .

Answer 1