Re: Re: CVE-Request - GNU Awk.

[Kurt Seifried <kseifried () redhat com>]

Is a SIGSEGV on it's own enough to justify a CVE? For some apps the answer
would be yes (e.g. a single threaded network service that crashes out). For
something like gawk I'm not so sure, it's a local utility that shouldn't
really be processing network data/untrusted data, but then I would have
said the same thing about bash (and then shellshock happened). I'm inclined
to err on the side of caution and give it an identifier, if nothing else
people using gawk on potentially dangerous input are more likely to see
this issue and check their scripts/etc. If Mitre doesn't give it a CVE I
can assign a DWF identifier to it.


On Mon, Mar 14, 2016 at 7:55 AM, Yuriy M. Kaminskiy <yumkam () gmail com>
wrote:

> On 14.03.2016 15:26, Tomas Hoger wrote:
>
> > On Mon, 14 Mar 2016 06:32:28 +0000 Steve Kemp wrote:
> >
> >    I reported two DoS bugs against GNU Awk to the debian
> > >   bug tracker recently, both of which are denial of service
> > >   attacks causing NULL-pointer deferences.
> > >
> > >    It would be useful to have a CVE identifiers assigned.
> >
> > Why should these get a CVE?  As you state in one of your reports:
> >
> >    While I appreciate that passing untrusted code to gawk is not a
> >    common thing to do, I do not believe that it should be possible to
> >    trigger a segfault though.
> >
> > Why should that be considered a valid / safe use case at all?  If
> > something makes awk run untrusted programs, there's code execution
> > problem already:
> >
> >    echo | awk '{ system("id") }'
>
> What if someone generates awk script using data from untrusted source, and
> avoids all theoretically-dangerous constructs (like system()), but their
> filter miss something theoretically-innocent that can trigger SIGSEGV (or
> worse) due to bug in gawk.


-- 

--
Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert () redhat com