[Bug 271955] a CHAP challenge packet can overflow a buffer in ppp

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271955

            Bug ID: 271955
           Summary: a CHAP challenge packet can overflow a buffer in ppp
           Product: Base System
           Version: CURRENT
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: bugs@FreeBSD.org
          Reporter: rtm@lcs.mit.edu
 Attachment #242738 text/plain
         mime type:

Created attachment 242738
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242738&action=edit
send ppp a CHAP challenge packet that overflows a buffer

If a CHAP_CHALLENGE packet arrives with a challenge length greater
than 148 bytes, chap_Input() will call mbuf_Read() in a way that
writes beyond the 148-byte chap->challenge.peer buffer and into the
end of struct datalink, overwriting (among others) the datalink.bundle
pointer, which ppp subsequently dereferences.

Here's an example 288-byte Ethernet PPPOE frame:

xx xx xx xx xx xx yy yy yy yy yy yy 88 64 11 00 00 01 01 0c c2 23 01
02 01 0a ff ff ...

the "01 02" is code=CHAP_CHALLENGE and ID=2
the "01 0a" is the length = 266
the first "ff" is the length of the challenge (alen in the code below)

Here's the relevant code in chap_Input():

  u_char alen;
  ...;
        bp = mbuf_Read(bp, &alen, 1);
        ...;
        bp = mbuf_Read(bp, chap->challenge.peer + 1, alen);

I've attached a demo, pppoe21a.c, which produces a ppp core dump with
this backtrace:

#0  strlen () at /usr/src/lib/libc/amd64/string/strlen.S:47
#1  0x000000000022fb7c in chap_ChallengeInit (authp=0x800e45350) at chap.c:495
#2  0x000000000022f167 in chap_Input (bundle=0x28bbb0 <bundle_Create.bundle>, 
    l=0x800e5d600, bp=0x0) at chap.c:764
#3  0x000000000025edfc in Despatch (bundle=0x28bbb0 <bundle_Create.bundle>, 
    l=0x800e5d600, bp=0x800e45800, proto=49699) at link.c:381
#4  0x000000000025ecaf in link_PullPacket (l=0x800e5d600, 
    buf=0x800e60740 "\302#\001\002\001\n", '\377' <repeats 194 times>..., 
    len=268, b=0x28bbb0 <bundle_Create.bundle>) at link.c:323
#5  0x00000000002717f4 in physical_DescriptorRead (d=0x800e5e578, 
    bundle=0x28bbb0 <bundle_Create.bundle>, fdset=0x800e88140)
    at physical.c:569
#6  0x0000000000245825 in ether_DescriptorRead (d=0x800e5e578, 
    bundle=0x28bbb0 <bundle_Create.bundle>, fdset=0x800e88140) at ether.c:426
#7  0x000000000023f783 in datalink_Read (d=0x800e43000, 
    bundle=0x28bbb0 <bundle_Create.bundle>, fdset=0x800e88140)
    at datalink.c:474
#8  0x0000000000226433 in bundle_DescriptorRead (
    d=0x28bbb0 <bundle_Create.bundle>, bundle=0x28bbb0 <bundle_Create.bundle>, 
    fdset=0x800e88140) at bundle.c:546
#9  0x00000000002635c8 in DoLoop (bundle=0x28bbb0 <bundle_Create.bundle>)
    at main.c:661
#10 0x0000000000262abc in main (argc=4, argv=0x7fffffffe9e0) at main.c:535

(gdb) print authp->physical->dl->bundle
$3 = (struct bundle *) 0xffffffffffffffff

The 0xfff... comes from the payload of the packet.

-- 
You are receiving this mail because:
You are the assignee for the bug.