Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
Hi All, I’m an Ethical Hacking student at Coventry university and while doing some exploit development on my Linux boxes I stumbled across a bug in the bash 4.4.12(1) - release. In order to trigger the bug I executed the command *`*cat sploit.buf*`* where sploit.buf is a just over 2GB file of ‘A’ characters. When this command is executed the bash terminal crashes with the following error “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error message appears to vary on different Linux distros. On Kali 2017.2 64 bit the error message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate 18446744071562067968 bytes (4296613888 bytes allocated)”. This bug may present a potential security risk as a malicious user may be able to crash a users bash session by tricking them into executing a malicious bash script. I will be adhering to the ICS-CERT Vulnerability Disclosure Policy and look forward to further discussing and resolving this bug Regards, Alex
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
On Tue, Nov 07, 2017 at 11:58:40AM +, Alex Nichols wrote: > In order to trigger the bug I executed the command *`*cat sploit.buf*`* > This bug may present a potential security risk as a malicious user may be > able to crash a users bash session by tricking them into executing a > malicious bash script. Then it's a social engineering attack, not a security vulnerability in bash. There are plenty of commands that would be extremely damaging if someone with malicious intent tricks you into running them. Not just the classic fork bomb that looks like a totem pole, either. Even something as basic as rm is potentially devastating, and can be obfuscated (for instance, as $'\162\155').
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
On Tue, Nov 7, 2017 at 5:58 AM, Alex Nichols wrote: [...] > In order to trigger the bug I executed the command *`*cat sploit.buf*`* > where sploit.buf is a just over 2GB file of ‘A’ characters. When this > command is executed the bash terminal crashes with the following error > “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes > (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error message > appears to vary on different Linux distros. On Kali 2017.2 64 bit the error > message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate > 18446744071562067968 bytes (4296613888 bytes allocated)”. [...] This is a normal memory exhaustion problem. You are asking bash to allocate over 2 GiB of heap memory, and your system is unable to provide that amount of memory. > This bug may present a potential security risk as a malicious user may be > able to crash a users bash session by tricking them into executing a > malicious bash script. [...] This is not a security issue. If you can trick a user into running this script, why stop there? Why not instead encrypt the file system and hold it for ransom? or delete it? Or steal credentials by uploading ~/.netrc, ~/.ssh/id_rsa, ~/.aws/credentials, ... You will find this problem in any program that allocates memory dynamically. Try allocating a >2 GiB in python, ruby, perl, php, awk, ...
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
Thank you for taking the time to respond to my email. I accept that this is likely not a security issue outside of being a social engineering attack, but the buggy behaviour that i'm curious about is that in each case the allocation should only have been of 2147483647 bytes in size (the size of the file i was using cat on). but instead, according to the error, bash had attempted to allocate far more memory than was required which is what caused the crash. for example the Kali example attempted to allocate 18446744071562067968 bytes or roughly 18446744071 GB of memory. Its also worth noting that the Kali example should have been able to have allocated more than enough memory to hold the 2GB file since it was able to allocate up to 4296613888 bytes of heap memory when it crashed. On Tue, Nov 7, 2017 at 2:21 PM, Eduardo Bustamante wrote: > On Tue, Nov 7, 2017 at 5:58 AM, Alex Nichols > wrote: > [...] > > In order to trigger the bug I executed the command *`*cat sploit.buf*`* > > where sploit.buf is a just over 2GB file of ‘A’ characters. When this > > command is executed the bash terminal crashes with the following error > > “Bash: xrealloc: .././subst.c:5977: cannot allocate 1073741824 bytes > > (2149011456 bytes allocated)”, on Ubuntu 17.10 64 bit. This error > message > > appears to vary on different Linux distros. On Kali 2017.2 64 bit the > error > > message is ” Bash: xrealloc: .././subst.c:5977: cannot allocate > > 18446744071562067968 bytes (4296613888 bytes allocated)”. > [...] > > This is a normal memory exhaustion problem. You are asking bash to allocate > over 2 GiB of heap memory, and your system is unable to provide that amount > of memory. > > > This bug may present a potential security risk as a malicious user may be > > able to crash a users bash session by tricking them into executing a > > malicious bash script. > [...] > > This is not a security issue. If you can trick a user into running this > script, > why stop there? Why not instead encrypt the file system and hold it for > ransom? or delete it? Or steal credentials by uploading ~/.netrc, > ~/.ssh/id_rsa, > ~/.aws/credentials, ... > > You will find this problem in any program that allocates memory > dynamically. > Try allocating a >2 GiB in python, ruby, perl, php, awk, ... >
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
On 11/7/17 6:58 AM, Alex Nichols wrote: > Hi All, > > > I’m an Ethical Hacking student at Coventry university and while doing some > exploit development on my Linux boxes I stumbled across a bug in the bash > 4.4.12(1) - release. As others have explained, this is not a bug, nor is it any kind of security problem. You have requested more memory than your operating system can supply. The memory allocation request fails, and bash exits. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
On 11/7/17 9:56 AM, Alex Nichols wrote: > Thank you for taking the time to respond to my email. > I accept that this is likely not a security issue outside of being a social > engineering attack, but the buggy behaviour that i'm curious about is that > in each case the allocation should only have been of 2147483647 bytes in > size (the size of the file i was using cat on). but instead, according to > the error, bash had attempted to allocate far more memory than was required > which is what caused the crash. for example the Kali example attempted to > allocate 18446744071562067968 bytes or roughly 18446744071 GB of memory. > Its also worth noting that the Kali example should have been able to have > allocated more than enough memory to hold the 2GB file since it was able to > allocate up to 4296613888 bytes of heap memory when it crashed. That depends on the behavior of the memory allocator under Kali. Bash's power-of-two malloc sometimes causes requests to correspondingly exceed the requested size, but any allocator (or allocation strategy) will eventually exceed the available memory. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Claim `declare' as a special command in manual?
For now the `declare' command is under SHELL BUILTIN COMMANDS in the man
page so people may think bash parses the command line parameters the same
way as other built-in commands which is not true.
[STEP 100] # echo $BASH_VERSION
4.4.12(4)-release
[STEP 101] # declare -a arr=()
[STEP 102] # echo declare -a arr=()
bash: syntax error near unexpected token `('
[STEP 103] #
It seems to me bash internally parses the `declare' command specially and
(logically) convert `declare -a arr=()' to two statements `declare -a arr'
and `arr=()'.
So does it make sense to move `declare' out of the SHELL BUILTIN COMMANDS
and put it in a separate section? Or at least explicitly state that
`declare' is special?
-clark
Re: remove empty '' in ${var@Q} result?
On Mon, Oct 30, 2017 at 8:35 PM, Greg Wooledge wrote:
>
> What's the bug? They are equivalent.
>
It's not a bad thing if we can make the language a bit more elegant unless
the cost is not worth it.
>
> If you mean "I would like bash to perform a second optimization pass
> over the result of ${var@Q} so that it's prettier in my degenerate edge
> cases", I suspect there are better uses of Chet's time, but it's his call.
>
It's not necessarily to perform a second pass parsing.
-clark
Re: remove empty '' in ${var@Q} result?
On Tue, Oct 31, 2017 at 3:53 PM, Clark Wang wrote: > On Tue, Oct 31, 2017 at 3:25 PM, Clark Wang wrote: > >> On Mon, Oct 30, 2017 at 10:41 PM, Chet Ramey wrote: >> >>> >>> This is an effect of using single quotes in the @Q operator. If you want >>> to single-quote a string containing single quotes, this is how you do it. >>> >> >> I made a patch (also attached). Please see if it's ok. >> > > Updated by dealing with empty strings (and malloc'ing 2 more bytes) though > I'm not sure if it's necessary since the func sh_quote_reusable() already > handles empty strings. > Hi Chet, do you have a look at my patch?
[no subject]
ubject: [50 character or so descriptive subject here (for reference)] Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux nhcentos 3.10.0-693.el7.x86_64 #1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 46 Release Status: release Description: [Detailed description of the problem, suggestion, or complaint.] Repeat-By: [Describe the sequence of events that causes the problem to occur.] Fix: [Description of how to fix the problem. If you don't know a fix for the problem, don't include this section.]
