Bash의 Shellshock 취약성 뒤에있는 동작이 문서화되어 있습니까? 아니면 의도적입니까?

Bash의 Shellshock 취약성 뒤에있는 동작이 문서화되어 있습니까? 아니면 의도적입니까?

---

Bash가 환경 변수를 해석 하는 방식에 대한 최근 취약점 CVE-2014-6271 이 공개되었습니다 . 익스플로잇은 Bash가 일부 환경 변수 선언을 함수 정의로 구문 분석하는 데 의존하지만 정의에 따라 코드를 계속 실행합니다.

$ x='() { echo i do nothing; }; echo vulnerable' bash -c ':'
vulnerable

그러나 나는 그것을 이해하지 못한다. 환경 변수를 함수로 해석하는 것에 대해 Bash 매뉴얼에서 찾을 수 없었던 것은 전혀 없습니다 ( 상속 함수 제외는 예외입니다 ). 실제로 적절한 명명 된 함수 정의는 값으로 처리됩니다.

$ x='y() { :; }' bash -c 'echo $x'
y() { :; }

그러나 부패한 사람은 아무것도 인쇄하지 않습니다.

$ x='() { :; }' bash -c 'echo $x'

$ # Nothing but newline

손상된 함수는 이름이 지정되지 않았으므로 호출 할 수 없습니다. 이 취약점은 순수한 구현 버그입니까, 아니면 여기에 의도 한 기능이 있지만 볼 수 없습니까?

최신 정보

Barmar의 의견에 따라 함수의 이름이 매개 변수 이름이라고 가정했습니다.

$ n='() { echo wat; }' bash -c 'n'
wat

맹세 할 수는 있지만, 충분히 노력하지 않은 것 같습니다. 이제 반복 가능합니다. 다음은 좀 더 테스트입니다.

$ env n='() { echo wat; }; echo vuln' bash -c 'n'
vuln
wat
$ env n='() { echo wat; }; echo $1' bash -c 'n 2' 3 -- 4

wat

… 확실히 args는 익스플로잇이 실행될 때 설정되지 않았습니다.

어쨌든, 내 질문에 대한 기본적인 대답은 예, 이것이 Bash가 상속 된 함수를 구현하는 방법 입니다.

---

이것은 구현 버그처럼 보입니다.

내 보낸 함수가 작동하는 방식 bash은 특수한 형식의 환경 변수를 사용한다는 것입니다. 함수를 내보내는 경우 :

f() { ... }

다음과 같은 환경 변수를 정의합니다.

f='() { ... }'

아마도 새로운 셸이 값이로 시작하는 환경 변수를 발견 ()하면 변수 이름을 앞에 추가하고 결과 문자열을 실행하는 것입니다. 버그는 여기 에 함수 정의 이후 의 모든 실행도 포함된다는 것입니다.

설명 된 수정 사항은 결과를 구문 분석하여 유효한 함수 정의인지 확인하는 것입니다. 그렇지 않은 경우 잘못된 함수 정의 시도에 대한 경고를 인쇄합니다.

이 기사 는 버그의 원인에 대한 설명을 확인합니다. 또한 수정이 해결하는 방법에 대해 좀 더 자세히 설명합니다. 값을 더 신중하게 구문 분석 할뿐만 아니라 내 보낸 함수를 전달하는 데 사용되는 변수는 특별한 명명 규칙을 따릅니다. 이 명명 규칙은 CGI 스크립트 용으로 생성 된 환경 변수에 사용되는 것과 다르므로 HTTP 클라이언트는이 문에 발을 들여 놓을 수 없습니다.

---

다음과 같은:

x='() { echo I do nothing; }; echo vulnerable' bash -c 'typeset -f'

인쇄물

vulnerable
x () 
{ 
    echo I do nothing
}
declare -fx x

Bash가를 구문 분석 한 후 x=...함수로 발견하고 내보내고 declare -fx x선언 후 명령을 실행하고 허용 한 것 같습니다.

echo vulnerable

x='() { x; }; echo vulnerable' bash -c 'typeset -f'

인쇄물:

vulnerable
x () 
{ 
    echo I do nothing
}

및 실행 x

x='() { x; }; echo Vulnerable' bash -c 'x'

인쇄물

Vulnerable
Segmentation fault: 11

segfaults-무한 재귀 호출

이미 정의 된 함수를 재정의하지 않습니다.

$ x() { echo Something; }
$ declare -fx x
$ x='() { x; }; echo Vulnerable' bash -c 'typeset -f'

인쇄물:

x () 
{ 
    echo Something
}
declare -fx x

예를 들어 x는 이전에 (올바르게) 정의 된 함수로 유지됩니다.

Bash의 4.3.25(1)-release경우 취약성이 닫혀 있으므로

x='() { echo I do nothing; }; echo Vulnerable' bash -c ':'

인쇄물

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

하지만- 이상한 것 (적어도 나에게는)

x='() { x; };' bash -c 'typeset -f'

여전히 인쇄

x () 
{ 
    x
}
declare -fx x

그리고

x='() { x; };' bash -c 'x'

분할 오류도 있으므로 여전히 이상한 함수 정의를 받아들입니다.

---

Bash 코드 자체를 살펴볼 가치가 있다고 생각합니다. 패치 는 문제에 대한 약간의 통찰력을 제공합니다. 특히,

*** ../bash-4.3-patched/variables.c 2014-05-15 08:26:50.000000000 -0400
--- variables.c 2014-09-14 14:23:35.000000000 -0400
***************
*** 359,369 ****
      strcpy (temp_string + char_index + 1, string);

!     if (posixly_correct == 0 || legal_identifier (name))
!       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);
!
!     /* Ancient backwards compatibility.  Old versions of bash exported
!        functions like name()=() {...} */
!     if (name[char_index - 1] == ')' && name[char_index - 2] == '(')
!       name[char_index - 2] = '\0';

      if (temp_var = find_function (name))
--- 364,372 ----
      strcpy (temp_string + char_index + 1, string);

!     /* Don't import function names that are invalid identifiers from the
!        environment, though we still allow them to be defined as shell
!        variables. */
!     if (legal_identifier (name))
!       parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST|SEVAL_FUNCDEF|SEVAL_ONECMD);

      if (temp_var = find_function (name))

Bash가 함수를 내보낼 때 다음과 같이 환경 변수로 표시됩니다.

$ foo() { echo 'hello world'; }
$ export -f foo
$ cat /proc/self/environ | tr '\0' '\n' | grep -A1 foo
foo=() {  echo 'hello world'
}

When a new Bash process finds a function defined this way in its environment, it evalutes the code in the variable using parse_and_execute(). For normal, non-malicious code, executing it simply defines the function in Bash and moves on. However, because it's passed to a generic execution function, Bash will correctly parse and execute additional code defined in that variable after the function definition.

You can see that in the new code, a flag called SEVAL_ONECMD has been added that tells Bash to only evaluate the first command (that is, the function definition) and SEVAL_FUNCDEF to only allow functio0n definitions.

---

In regard to your question about documentation, notice here in the commandline documentation for the env command, that a study of the syntax shows that env is working as documented.

• There are, optionally, 4 possible options
• An optional hyphen as a synonym for -i (for backward compatibility I assume)
• Zero or more NAME=VALUE pairs. These are the variable assignment(s) which could include function definitions.
• Note that no semicolon (;) is required between or following the assignments.
• The last argument(s) can be a single command followed by its argument(s). It will run with whatever permissions have been granted to the login being used. Security is controlled by restricting permissions on the login user and setting permissions on user-accessible executables such that users other than the executable's owner can only read and execute the program, not alter it.

[ spot@LX03:~ ] env --help
Usage: env [OPTION]... [-] [NAME=VALUE]... [COMMAND [ARG]...]
Set each NAME to VALUE in the environment and run COMMAND.

  -i, --ignore-environment   start with an empty environment
  -u, --unset=NAME           remove variable from the environment
      --help     display this help and exit
      --version  output version information and exit

A mere - implies -i.  If no COMMAND, print the resulting environment.

Report env bugs to bug-coreutils@gnu.org
GNU coreutils home page: <http://www.gnu.org/software/coreutils/>
General help using GNU software: <http://www.gnu.org/gethelp/>
Report env translation bugs to <http://translationproject.org/team/>

ReferenceURL : https://stackoverflow.com/questions/26022248/is-the-behavior-behind-the-shellshock-vulnerability-in-bash-documented-or-at-all