Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 May 2013 12:31:08 -0400 (EDT)
From: Jan Lieskovsky <>
To:, Kurt Seifried <>
Cc: "Steven M. Christey" <>,
        Miroslav Lichvar <>,
Subject: Re: CVE Request -- gpsd 3.9 fixing a denial of
 service flaw

Thank you for your time && reply, Eric.

----- Original Message -----
> From: "Eric S. Raymond" <>
> To: "Kurt Seifried" <>
> Cc:, "Jan Lieskovsky" <>, "Steven M. Christey"
> <>, "Miroslav Lichvar" <>
> 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 <>:
> > 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:

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="">Eric S. Raymond</a>

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.