The Stack Overflow podcast is back! Listen to an interview with our new CEO.
4 added 17 characters in body
source | link

We can see a for loop over all the environment variables given to the function, and then an if about whether we are in privileged mode, but that is disabled most times. The "not verify that the fragment is merely a function definition" vulnerabilitypart is in the parse_and_execute line. The function description from builtins/evalstring.c:

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the invocation of'echo date' string that's also given to bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

We can see a for loop over all the environment variables given to the function, and then an if about whether we are in privileged mode, but that is disabled most times. The "not verify that the fragment is merely a function definition" vulnerability is in the parse_and_execute line. The function description from builtins/evalstring.c:

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the invocation of bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

We can see a for loop over all the environment variables given to the function, and then an if about whether we are in privileged mode, but that is disabled most times. The "not verify that the fragment is merely a function definition" part is in the parse_and_execute line. The function description from builtins/evalstring.c:

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the 'echo date' string that's also given to bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

3 added 407 characters in body
source | link

From wikipedia explanationWikipedia:

CVE-2014-7169

CVE-2014-7169 bases on a function parsing issue that has been pointed out by Tavis Ormandy. The fix of parse.y seems very simple, but its trickier than CVE-2014-6271:

/* Called from shell.c when Control-C is typed at top level.  Or
   by the error rule at top level. */
void
reset_parser ()
  [...]
  FREE (word_desc_to_read);
  word_desc_to_read = (WORD_DESC *)NULL;
+ eol_ungetc_lookahead = 0;
+
  current_token = '\n'; /* XXX */
  last_read_token = '\n';
  token_to_read = '\n';

The eol_ungetc_lookahead variable is explained at its definition:

/* This implements one-character lookahead/lookbehind across physical input
   lines, to avoid something being lost because it's pushed back with
   shell_ungetc when we're at the start of a line. */
static int eol_ungetc_lookahead = 0;

Its read inside the shell_getc function, and if its set, its (one-character) content is read instead.

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the invocation of bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

Further resources on the oss-sec mailing list.

From wikipedia explanation:

From Wikipedia:

CVE-2014-7169

CVE-2014-7169 bases on a function parsing issue that has been pointed out by Tavis Ormandy. The fix of parse.y seems very simple, but its trickier than CVE-2014-6271:

/* Called from shell.c when Control-C is typed at top level.  Or
   by the error rule at top level. */
void
reset_parser ()
  [...]
  FREE (word_desc_to_read);
  word_desc_to_read = (WORD_DESC *)NULL;
+ eol_ungetc_lookahead = 0;
+
  current_token = '\n'; /* XXX */
  last_read_token = '\n';
  token_to_read = '\n';

The eol_ungetc_lookahead variable is explained at its definition:

/* This implements one-character lookahead/lookbehind across physical input
   lines, to avoid something being lost because it's pushed back with
   shell_ungetc when we're at the start of a line. */
static int eol_ungetc_lookahead = 0;

Its read inside the shell_getc function, and if its set, its (one-character) content is read instead.

The command rm echo; env -i X='() { function a .>\' bash -c 'echo date'; cat echo first creates a syntax error with the . character (you can also use other characters here, like a or =), and then uses the insufficient cleanup of the eol_ungetc_lookahead variable in the reset_parser function to inject the > character into the invocation of bash. Its equivalent to rm echo; bash -c '> echo date'; cat echo.

Further resources on the oss-sec mailing list.

2 added 407 characters in body
source | link

In the source code, we can see thisthe importing of the function variables in variables.c:

So everything that's passed to the function gets executed as if it would be an ordinary bash command. The flags SEVAL_NONINT and SEVAL_NOHIST are self-explanatory (explanation of interactivity, NOHIST doesn't add the definition to your bash history) don't prevent passing other things than function definitions. The patch introduces flags SEVAL_FUNCDEF and SEVAL_ONECMD that can be passed in the flags field to parse_and_execute:

In the source code, we can see this in variables.c:

The patch introduces flags SEVAL_FUNCDEF and SEVAL_ONECMD that can be passed in the flags field to parse_and_execute:

In the source code, we can see the importing of the function variables in variables.c:

So everything that's passed to the function gets executed as if it would be an ordinary bash command. The flags SEVAL_NONINT and SEVAL_NOHIST are self-explanatory (explanation of interactivity, NOHIST doesn't add the definition to your bash history) don't prevent passing other things than function definitions. The patch introduces flags SEVAL_FUNCDEF and SEVAL_ONECMD that can be passed in the flags field to parse_and_execute:

1
source | link