6 replaced http://unix.stackexchange.com/ with https://unix.stackexchange.com/
source | link

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporterdescription by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

5 Added timeline link.
source | link

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patchfirst attempted patch. That was clearly insufficient as was quickly found on several additional bugsseveral additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

4 Added one reference.
source | link

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

Question:

... can such a function definition ever be put in the environment via export -f <func> OR, is the first case the only way for putting a trailing commands to cause shellshock ?

Answer: The first case is the only way to trigger shellshock.

The vuln is triggered by an interpretation of environment variables, not of exported functions.

Look at the Symantec image here. Read the description by the bug-reporter.

The processing of environment variables that happen to contain (){...} are processed as function definitions. And: of such variables that have a trailing ;cmd, the command cmd is executed. The core issue is that the parsing of functions does not limit the interpretation of one executable token, and process the rest of the line included inside an exported var as an executable command.

Limiting the execution to only one part of the exported variable was the first attempted patch. That was clearly insufficient as was quickly found on several additional bugs.

So, no, the bug is not the result of failing to export a function definition correctly, and; to be read back (which happens to be in complete control of the shell). But is the result of several problems in the parsing of variable values that may be injected by an attacker.

In any case the initial reporter of the bug is a regular user of this site. It is quite probable that he comes around to take a look at this question.

3 Added two references.
source | link
2 Added two references.
source | link
1
source | link