oss-sec mailing list archives
Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw
From: Jan Lieskovsky <jlieskov () redhat com>
Date: Tue, 7 May 2013 04:56:04 -0400 (EDT)
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 TeamIf you have any other questions, do not hesitate to ask. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
Current thread:
- CVE Request -- gpsd 3.9 fixing a denial of service flaw Jan Lieskovsky (May 02)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Kurt Seifried (May 02)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Eric S. Raymond (May 02)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Jan Lieskovsky (May 03)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Jan Lieskovsky (May 07)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Eric S. Raymond (May 07)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Eric S. Raymond (May 02)
- Re: CVE Request -- gpsd 3.9 fixing a denial of service flaw Kurt Seifried (May 02)