[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential Denial of Service Vulnerability in embedded commands - Bas
Re: Potential Denial of Service Vulnerability in embedded commands - Bash version 4.4.12(1) - Release
Tue, 7 Nov 2017 14:56:48 +0000
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 <address@hidden>
> On Tue, Nov 7, 2017 at 5:58 AM, Alex Nichols <address@hidden>
> > 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
> > appears to vary on different Linux distros. On Kali 2017.2 64 bit the
> > 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
> why stop there? Why not instead encrypt the file system and hold it for
> ransom? or delete it? Or steal credentials by uploading ~/.netrc,
> ~/.aws/credentials, ...
> You will find this problem in any program that allocates memory
> Try allocating a >2 GiB in python, ruby, perl, php, awk, ...