Re: version string can cause overflow and affect eip/rip (needs length check in version string)

[Johan Nestaas]

> If you want to do this to yourself, why should bash stop you?

If at any point in the future a sequence of events allows someone to alter
the version string while a system or package is being built, it would be
more serious. Any code or side effect that would change the version string
might appear innocent, and it could easily fool anyone. Lots of bugs have
appeared just as innocent until they've been abused to great effect. Even
just the control of digits will have varying effects on different platforms.

I understand if no one feels the need to change it, but it seems easy
enough to add a length check or even just a comment. IMHO it's just not a
good idea for an input string to have an implicit length limit and to be
trusted that it will never once grow over 32 bytes in the software, at any
point in the future where bash is used.

Cheers,
Johan
On Sep 26, 2014 6:04 AM, "Chet Ramey" <chet.ramey@case.edu> wrote:

> On 9/26/14, 3:13 AM, Johan Nestaas wrote:
> > This isn't nearly as important as shellshock or whatever you want to call
> > it, but I found this while glancing at the source and the latest patch.
> > It's a funny little bug that I doubt could ever be useful for malicious
> > reasons, unless you can determine an address to jump to that is comprised
> > of all hex characters 30-39 (digits) due to the regex check on the
> version
> > string, and also if the "attacker" could set a version string.
> >
> > Still, a bad version string in a configure shouldn't allow someone to
> jump
> > to an arbitrary address in memory. Might be a good idea to add a length
> > check in configure or make.
>
> If you want to do this to yourself, why should bash stop you?
>
> Chet
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>                  ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, ITS, CWRU    chet@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>