Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw

[Jan Lieskovsky <jlieskov () redhat com>]

Hello Eric,

  since there have doubts appeared:
    https://bugs.mageia.org/show_bug.cgi?id=9969#c2

which upstream patch has been the CVE-2013-2038 identifier assigned
to, could you confirm / disprove the latter?

* The true crash was in the NMEA(2000) driver, with upstream patch:
  http://git.savannah.gnu.org/cgit/gpsd.git/commit/?id=dd9c3c2830cb8f8fd8491ce68c82698dc5538f50

  This one should be referenced under CVE-2013-2038.

* While the hypothetical one was in the AIS driver, with upstream patch:
  http://git.savannah.gnu.org/cgit/gpsd.git/commit/?id=08edc49d8f63c75bfdfb480b083b0d960310f94f

  Upstream 3.9 announcement "Armor the AIS driver against an implausible overrun attack."
  would support this.

Thank you for your time && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Response Team

----- Original Message -----
> From: "Jan Lieskovsky" <jlieskov () redhat com>
> To: esr () thyrsus com, "Kurt Seifried" <kseifried () redhat com>
> Cc: "Steven M. Christey" <coley () linus mitre org>, "Miroslav Lichvar" <mlichvar () redhat com>,
> oss-security () lists openwall com
> Sent: Friday, May 3, 2013 6:31:08 PM
> Subject: Re: [oss-security] CVE Request -- gpsd 3.9 fixing a denial of service flaw
>
>
> Thank you for your time && reply, Eric.
>
> ----- Original Message -----
> > From: "Eric S. Raymond" <esr () thyrsus com>
> > To: "Kurt Seifried" <kseifried () redhat com>
> > Cc: oss-security () lists openwall com, "Jan Lieskovsky"
> > <jlieskov () redhat com>, "Steven M. Christey"
> > <coley () linus mitre org>, "Miroslav Lichvar" <mlichvar () redhat com>
> > Sent: Thursday, May 2, 2013 9:41:51 PM
> > Subject: Re: [oss-security] CVE Request -- gpsd 3.9 fixing a denial of
> > service flaw
> >
> > Kurt Seifried <kseifried () redhat com>:
> > > On 05/02/2013 03:58 AM, Jan Lieskovsky wrote:
> > > > @Eric - Eric, could you please help us to solve this doubt? (which
> > > > of the patches is the correct one to fix the above mentioned DoS /
> > > > security issue)
> >
> > There are two critical patches which solve two different DoSes (well,
> > one certain and one potential).  Yes, it's a strange coincidence that
> > both bugs were characterized at almost the same time after we haven't
> > had a crash bug since 2007.
> >
> > The crash bug was in the NMEA driver.  There's particular kind of malformed
> > packet, sometimes emitted by SiRFStar-III receivers, that looks like this:
> >
> > $GPGGA,030130$GPGLL,2638.1728,N,08011.3893,W,030131.000,A,A*41\r\n
> >
> > See the incomplete GGA without trailing \r\n  at the front?  Usually
> > that was harmless and would be silently discarded. Under rare circumstances
> > it could core dump (but not any more, I now have a regression test to check
> > this case).
> >
> > That fix was commit dd9c3c2830cb8f8fd8491ce68c82698dc5538f50.
>
> So this is observed / experienced DoS, right? Kurt, assuming the
> CVE-2013-2038 identifier:
>   http://www.openwall.com/lists/oss-security/2013/05/02/17
>
> has been assigned to this sub-case, correct?
>
> > The potential crash/DoS was in the AIS driver.
> >
> > The first stage of what it does is un-armor an AIVDM ASCII packet
> > representation into an equivalent binary packet which is then examined
> > for data at specific bit offsets.
> >
> > The un-armoring logic was not properly bounds-checked, potentially
> > opening up a hole. In theory, an overlong armored packet could be
> > crafted to overrun the binary-packet buffer.
> >
> > I'm not sure that one was exploitable; there are other properties of
> > the code (notably the bounds-checked maximum length of the AIVDM ASCII
> > packet buffer) that seem to guarantee the end of the binary packet
> > buffer could never be reached.
>
> Meaning this wouldn't be a DoS attack vector? (asking to know if a
> separate / second CVE identifier is needed for this case yet, or not)
>
> > I put in a check anyway, because (a) I could be wrong about that, (b)
> > supposing I'm right, that invariant could get silently broken by a future
> > code change.
> >
> > That was commit 08edc49d8f63c75bfdfb480b083b0d960310f94f, responding
> > to Savannah bug #38511.
>
> Application of the patch looks reasonable. Just would be good to know
> if it was applied just like a preventive measure (no DoS right now, just
> prevent its [possible] occurrence in the future in case of code change)
> or if under certain circumstances it might be used to DoS gpsd too?
>
> > Note: neither of these have privilege-escalation possibilities.  gpsd
> > needs root to initialize, but drops it long before either of these
> > code defects could fire.
>
> Ok, good.
>
> Thank you && Regards, Jan.
> --
> Jan iankko Lieskovsky / Red Hat Security Response Team
>
> > If you have any other questions, do not hesitate to ask.
> > --
> >             <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>