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
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 /
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:
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
That fix was commit dd9c3c2830cb8f8fd8491ce68c82698dc5538f50.
So this is observed / experienced DoS, right? Kurt, assuming the
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
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.
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>