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 > > "nelem"hoping 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.
