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
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"
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 `
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.
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
On Mon, Aug 17, 2015 at 6:15 PM, Eric Blake wrote:
>
> 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.
>
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 shoc
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
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
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -D
CONF_VENDOR='unknown' -DLOCALEDIR='/usr/local/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./incl
10 matches
Mail list logo
