Re: Integer Overflow in braces
Just FYI, if this were really a critical security issue, this is not how you should disclose it: https://www.reddit.com/r/netsec/comments/3h997d/bash_integer_overflow/ You have to first contact the maintainer in private, make sure the issue is acknowleged, fixed, and that the fix is available to most Bash users *before* disclosing anything. This just strikes me as a way to make yourself publicity. If you really want to help to fix Bash, instead of just complaining about some odd looking comments, provide patches... -- Eduardo Bustamante https://dualbus.me/
Re: Integer Overflow in braces
On Mon, Aug 17, 2015 at 6:15 PM, Eric Blake ebl...@redhat.com wrote: snip Fix your script to not do stupid things, like trying an insanely-large brace expansion, or trying an 'eval' (or similar) on untrusted user input. But don't call it a bash security hole that bash allows you to write stupid scripts. Good point. And, not meaning to be nasty, the security hole would be in the head of the person who allowed such a programmer to write mission critical code. I will assume that the OP was actually in a learning mode while doing unusual things which he knew better than to do, just to see what happens. Of course, reporting it as a bug wasn't really the right thing to do. Reminds me of a bug(?) in an online system which, when triggered, would cause the system to update the user's login password with an untypeable character. One clever programmer used this bug to punish people who ran his program without authorization. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org -- Schrodinger's backup: The condition of any backup is unknown until a restore is attempted. Yoda of Borg, we are. Futile, resistance is, yes. Assimilated, you will be. He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! John McKown
Re: Integer Overflow in braces
On Monday, August 17, 2015 04:15:50 PM Eric Blake wrote:
On 08/17/2015 09:58 AM, Pasha K wrote:
Hey Greg,
I wasn't particularly trying to actually generate that large amount of
strings in memory, I wa purposely trying to overflow the integer variable
nelemhoping to get Code Execution. This could potentially be a security
risk as shell shock was just more of a denial of service rather than
straight up code execution. However, just because I wasn't able to gain
control of the registers doesn't mean someone else with more skill can't.
This is not a security risk.
Shell shock was a security hole because the shell could be coerced into
executing user-supplied code WITHOUT a way for a script to intervene.
Any poorly-written shell script can do stupid things, including crashing
bash because it overflows the heap by trying to allocate memory for such
a stupidly large expansion. But unless the problem can be triggered
without a script (the way shell shock executed user code before even
starting to parse a script), then you can't exploit the problem to gain
any more access to the system than you already have by being able to run
a script in the first place.
Fix your script to not do stupid things, like trying an insanely-large
brace expansion, or trying an 'eval' (or similar) on untrusted user
input. But don't call it a bash security hole that bash allows you to
write stupid scripts.
IMHO the issue of whether the integer is allowed to overflow is separate from
the question of whether the resulting expansion is too big. Code that does
an `eval blah{0..$n}` is reasonably common and not necessarily stupid.
--
Dan Douglas
signature.asc
Description: This is a digitally signed message part.
Re: Integer Overflow in braces
On 08/17/2015 09:58 AM, Pasha K wrote: Hey Greg, I wasn't particularly trying to actually generate that large amount of strings in memory, I wa purposely trying to overflow the integer variable nelemhoping to get Code Execution. This could potentially be a security risk as shell shock was just more of a denial of service rather than straight up code execution. However, just because I wasn't able to gain control of the registers doesn't mean someone else with more skill can't. This is not a security risk. Shell shock was a security hole because the shell could be coerced into executing user-supplied code WITHOUT a way for a script to intervene. Any poorly-written shell script can do stupid things, including crashing bash because it overflows the heap by trying to allocate memory for such a stupidly large expansion. But unless the problem can be triggered without a script (the way shell shock executed user code before even starting to parse a script), then you can't exploit the problem to gain any more access to the system than you already have by being able to run a script in the first place. Fix your script to not do stupid things, like trying an insanely-large brace expansion, or trying an 'eval' (or similar) on untrusted user input. But don't call it a bash security hole that bash allows you to write stupid scripts. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Integer Overflow in braces
On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
IMHO the issue of whether the integer is allowed to overflow is separate from
the question of whether the resulting expansion is too big. Code that does
an `eval blah{0..$n}` is reasonably common and not necessarily stupid.
Yes, that's fine. But I don't actually understand what kind of overflow
Pasha K was actually trying to test for. He/she mentioned nelem, which
only appears in two places in the bash source code: once in indexed
arrays, and once in associative arrays. But there were no arrays in
the script being executed.
{0..} should produce an error because it runs out of
memory. So I would expect to see a malloc failure, or something similar.
If Pasha is saying that an integer overflow occurs before the malloc
failure, then that may or may not be interesting to Chet. If it crashes
bash, then it's not interesting to me, because the inevitable malloc
failure would have crashed it if the overflow didn't. It only becomes
interesting to me if the integer overflow causes some weird behavior to
happen BEFORE bash crashes.
Re: Integer Overflow in braces
On 8/18/15 9:12 AM, Dan Douglas wrote: Actually I think I spoke too soon. There's already some considerable logic in braces.c to check for overflow (e.g. around braces.c:390 shortly after declaration of the int). Looks like there were some changes in this code last year to beef it up a bit. (see commit 67440bc5959a639359bf1dd7d655915bf6e9e7f1). I suspect this is probably fixed in devel. Well, `fixed' is a tricky thing. There is code in bash-4.4 to use malloc instead of xmalloc -- which just aborts on failure -- but there is only so much you can do to protect someone from himself. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Integer Overflow in braces
On Tuesday, August 18, 2015 09:04:33 AM Greg Wooledge wrote:
On Tue, Aug 18, 2015 at 07:54:48AM -0500, Dan Douglas wrote:
IMHO the issue of whether the integer is allowed to overflow is separate
from
the question of whether the resulting expansion is too big. Code that
does
an `eval blah{0..$n}` is reasonably common and not necessarily stupid.
Yes, that's fine. But I don't actually understand what kind of overflow
Pasha K was actually trying to test for. He/she mentioned nelem, which
only appears in two places in the bash source code: once in indexed
arrays, and once in associative arrays. But there were no arrays in
the script being executed.
{0..} should produce an error because it runs out of
memory. So I would expect to see a malloc failure, or something similar.
If Pasha is saying that an integer overflow occurs before the malloc
failure, then that may or may not be interesting to Chet. If it crashes
bash, then it's not interesting to me, because the inevitable malloc
failure would have crashed it if the overflow didn't. It only becomes
interesting to me if the integer overflow causes some weird behavior to
happen BEFORE bash crashes.
Actually I think I spoke too soon. There's already some considerable logic in
braces.c to check for overflow (e.g. around braces.c:390 shortly after
declaration of the int). Looks like there were some changes in this code last
year to beef it up a bit. (see commit
67440bc5959a639359bf1dd7d655915bf6e9e7f1). I suspect this is probably fixed in
devel.
--
Dan Douglas
Re: Integer Overflow in braces
Hey Greg,
I wasn't particularly trying to actually generate that large amount of
strings in memory, I wa purposely trying to overflow the integer variable
nelemhoping to get Code Execution. This could potentially be a security
risk as shell shock was just more of a denial of service rather than
straight up code execution. However, just because I wasn't able to gain
control of the registers doesn't mean someone else with more skill can't.
On Monday, August 17, 2015, Greg Wooledge wool...@eeg.ccf.org wrote:
On Sat, Aug 15, 2015 at 08:53:55PM -0700, Pasha K wrote:
(gdb) r -c for x in {1..9223372036854775805}; do echo overflow; done
Brace expansion requires bash to generate and store ALL of those strings
in memory simultaneously. I seriously doubt any computer on earth has
enough virtual memory to hold what you've asked for here. (Unless I'm
miscounting, you've asked bash to generate over 900 quintillion strings
of length varying from 1 to 19 bytes in length (2 to 20 with NULs).)
If you want to count to a large number, use a C-style for loop instead
of a brace expansion.
for ((x=1; x=90; x++)); do ...; done
