Re: CVE Request coreutils

[Vincent Danen <vdanen () redhat com>]

* [2013-01-22 08:25:23 +0100] Sebastian Krahmer wrote:

> Generally, I see your point. However sometimes services running as
> root 'sort' or 'uniq' user input e.g. via grepping logfiles etc,
> so there is indeed a real chance to indirectly trigger a privilege
> escalation. The past shows that segfaults can be turned into a
> code exec often. Its a stack overflow after all.

Do you believe this would be the case with modern GCC/Glibc hardening
though?  Wouldn't this just be rendered a crash?

But even then, if we're talking about logfiles (which is a reasonable
case) you'd have to be allowing user-controlled input to your logs,
which would mean you'd have another problem.

I'm also assuming, based on the comments in the first bug, that you need
a really large line (not just an entire file, but one line).  How likely
is it that you would be grepping a log file with ~10MB of data on one
line?

Perhaps root grepping/sorting/etc. a logfile is a valid use-case and
some user-supplied input could be stored in there (perhaps a crafted
apache url, etc. or maybe a local user running logger to inject a custom
log entry), but do these programs even allow for a ~10MB in length URL
or data?

(I've not looked, maybe they do?)

> On Mon, Jan 21, 2013 at 06:33:07PM -0700, Kurt Seifried wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 01/21/2013 01:39 PM, Vincent Danen wrote:
> > > * [2013-01-21 19:17:49 +0100] Moritz Muehlenhoff wrote:
> > >
> > >>> Can someone assign a CVE id for a buffer overflow in
> > >>> coreutils? Its the same code snippet (coreutils-i18n.patch) and
> > >>> it affects sort, uniq and join:
> > >>>
> > >>> https://bugzilla.novell.com/show_bug.cgi?id=798538
> > >>> https://bugzilla.novell.com/show_bug.cgi?id=796243
> > >>> https://bugzilla.novell.com/show_bug.cgi?id=798541
> > >>
> > >> Could you send the faulty patch to the list so that distros can
> > >> validate that they don't include it themselves?
> > >
> > > Red Hat/Fedora do include this patch, so it's more than just SUSE
> > > that ships them.  However, when I was looking at them last week,
> > > this struck me as just a non-exploitable crash and unless I'm
> > > missing something, I think it would be quite the stretch to call it
> > > a security flaw.
> >
> > Agreed, there is no significant impact of exploitation and there is no
> > real easy way to trick a victim into doing this (and even if you do,
> > so what? now if it was code exec we might be talking about something
> > interesting).
> >
> > - --
> > Kurt Seifried Red Hat Security Response Team (SRT)
> > PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.12 (GNU/Linux)
> >
> > iQIcBAEBAgAGBQJQ/exTAAoJEBYNRVNeJnmTrW0P/3B/L/SE7akzCPUU6TW9wy1L
> > Rpb8IIITLCz1qkb/gkUayUFJHQDjpEfmxNPJQWm1fJBrWI0bFr0wvHRuGHgyXZEA
> > Bl+js2w0uu7kAEEf1bHjZjf7zVHZ2tvoAdzi8ypLASZisxXwSa4acy++sqmPTrSf
> > oNOu3ChqG919VSLfD8Zf5AsGFs6G3tRzNEmYtvllt9liUFKgL6WsCNWNWUZdpWm2
> > crZPdyf343VvQcG5p7vYPEJLUBmnUSIauakssYPxGSp1vNBDNCC8xuVnyf1KOLfc
> > r3BHDPRX5ooe8EcoK/zgo1owK7tP9d7FT94gIsJte3OUOP5dq6LR/R0ZMMUsneNA
> > EjJScDCkh0hcZYCdJkqtah5aoAYI6IQvXJVtbwDM+rAvHfoMV2nkbWVZL0SgCMW/
> > B/hvhQJejFN3dd0wfiO5sQf5o2UxxYyIIpTE+GQP/pe8Q7F1BzR5nV87Jd3sWQY8
> > J873KRADBgt4RwbVUpI7dUL67UeRZCN4FiNtYYEuD5BeJWMSVoVXRHP7zBkx8GhG
> > vgfUc02+IyxS0HTO5HIxSJnLYOSa++SxJ4/w85aqcWPLrLHhL4s1k4GELPg/JhdW
> > Um35zAkcLNnxsxySCMIWZKEUTZ3xdpBspc3QVkw/IoyZpk+QhQTM2S/C3yWv4Q0z
> > xwHEEqesvl8l7UlpQ2mC
> > =rw4/
> > -----END PGP SIGNATURE-----
>
> --
>
> ~ perl self.pl
> ~ $_='print"\$_=\47$_\47;eval"';eval
> ~ krahmer () suse de - SuSE Security Team

--
Vincent Danen / Red Hat Security Response Team