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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
