Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!usenet.stanford.edu!not-for-mail
From: Dan Douglas <ormaaj@gmail.com>
Newsgroups: gnu.bash.bug
Subject: Re: Integer Overflow in braces
Date: Tue, 18 Aug 2015 07:54:48 -0500
Lines: 61
Approved: bug-bash@gnu.org
Message-ID: <mailman.8513.1439902519.904.bug-bash@gnu.org>
References: <CABq52TYThGj9OtBn3xTti5scmA=WdnS7ULw3G6GMayPK6WR0+w@mail.gmail.com> <CABq52TbKZCK8ci5ra_N4pfVB3jXGCdf-ZCG=k35c+_fVehfzFg@mail.gmail.com> <55D26B26.2060008@redhat.com>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3429148.enCA8otJpH"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Cc: Greg Wooledge <wooledg@eeg.ccf.org>, Eric Blake <eblake@redhat.com>, Pasha K <pashakravtsov@gmail.com>
To: bug-bash@gnu.org
Envelope-to: bug-bash@gnu.org
User-Agent: KMail/5.0.41 alpha1 (Linux/4.2.0-rc7; KDE/5.14.0; x86_64; ; )
In-Reply-To: <55D26B26.2060008@redhat.com>
Precedence: list
Xref: csiph.com gnu.bash.bug:11362

--nextPart3429148.enCA8otJpH
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"

On Monday, August 17, 2015 04:15:50 PM Eric Blake wrote:
> On 08/17/2015 09:58 AM, Pasha K wrote:
> > Hey Greg,
> >=20
> > I wasn't particularly trying to actually generate that large amount of
> > strings in memory, I wa purposely trying to overflow the integer variab=
le
> > "nelem"hoping to get Code Execution. This could potentially be a securi=
ty
> > 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.
>=20
> This is not a security risk.
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20

IMHO the issue of whether the integer is allowed to overflow is separate fr=
om=20
the question of whether the resulting expansion is "too big". Code that doe=
s=20
an `eval "blah{0..$n}"` is reasonably common and not necessarily stupid.=20
=2D-=20
Dan Douglas
--nextPart3429148.enCA8otJpH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEABECAAYFAlXTKxgACgkQMmyDamdg+MxSVACeNjZUev4CLuOzgID3MR0UEx3I
uOYAn0ldWgld1ykOwjgESVtrgA/fDX/v
=kvSQ
-----END PGP SIGNATURE-----

--nextPart3429148.enCA8otJpH--