Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 08 Jun 2023 15:41:47 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 271910] bad TY_ENDDISC option can cause ppp to write beyond end of buffer
Message-ID:  <bug-271910-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271910

            Bug ID: 271910
           Summary: bad TY_ENDDISC option can cause ppp to write beyond
                    end of buffer
           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 #242687 text/plain
         mime type:

Created attachment 242687
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D242687&action=
=3Dedit
send ppp an HDLC frame that causes it to overrun a buffer

This HDLC LCP Configure-Request frame:

  7e c0 21 01 01 00 06 13 02 6b 94 7e=20

causes ppp/lcp.c's LcpDecodeConfig() to call memcpy() with length =3D
0xffffffffffffffff here:

    case TY_ENDDISC:
          ...;
          memcpy(p->dl->peer.enddisc.address, opt->data + 1, opt->hdr.len -=
 3);

opt->hdr.len is the 02 in the frame above, so len - 3 is -1. opt->data
points into the input HDLC frame.

The "- 3" here can also lead to trouble:

      log_Printf(LogLCP, "%s %s\n", request,
                 mp_Enddisc(opt->data[0], opt->data + 1, opt->hdr.len - 3));

Here's a parsing of the frame:

    0x7e,
    0xc0, 0x21, // LCP
    0x01, 0x01, // code=3DConfigure-Request, ID=3D1
    0x00, 0x06, // length
    0x13, 0x02, // 0x13=3DMultilink-Endpoint-Discriminator, 2=3Dlength
    0x6b, 0x94, // HDLC checksum
    0x7e

Here's a backtrace from the attached demo program ppp3c.c:

#0  memcpy () at /usr/src/lib/libc/amd64/string/memmove.S:306
#1  0x00002433db2ed225 in LcpDecodeConfig (fp=3D0x243c0533f7e8,=20
    cp=3D0x243c05363165 "\002", end=3D0x243c05363167 "", mode_type=3D0,=20
    dec=3D0x243bfc109310) at /usr/src/usr.sbin/ppp/lcp.c:1216
#2  0x00002433db2e08f6 in FsmRecvConfigReq (fp=3D0x243c0533f7e8,=20
    lhp=3D0x243bfc1094a8, bp=3D0x243c05363100) at /usr/src/usr.sbin/ppp/fsm=
.c:496
#3  0x00002433db2dffd0 in fsm_Input (fp=3Dfp@entry=3D0x243c0533f7e8,=20
    bp=3Dbp@entry=3D0x243c05363100) at /usr/src/usr.sbin/ppp/fsm.c:1096
#4  0x00002433db2ebd0c in lcp_Input (bundle=3D<optimized out>,=20
    l=3D<optimized out>, bp=3D0x243c05363100) at /usr/src/usr.sbin/ppp/lcp.=
c:1305
#5  0x00002433db2ee16c in Despatch (
    bundle=3D0x2433db3144b0 <bundle_Create.bundle>, l=3D0x243c0533f600,=20
    bp=3D0x243c05363100, proto=3D<optimized out>)
    at /usr/src/usr.sbin/ppp/link.c:381
#6  link_PullPacket (l=3D0x243c0533f600, buf=3D<optimized out>,=20
    len=3D<optimized out>, b=3D0x2433db3144b0 <bundle_Create.bundle>)
    at /usr/src/usr.sbin/ppp/link.c:323
#7  0x00002433db2c7e25 in bundle_DescriptorRead (d=3D<optimized out>,=20
    bundle=3D0x2433db3144b0 <bundle_Create.bundle>, fdset=3D0x243c0536a140)
    at /usr/src/usr.sbin/ppp/bundle.c:546
#8  0x00002433db2f1704 in DoLoop (bundle=3D0x2433db3144b0 <bundle_Create.bu=
ndle>)
    at /usr/src/usr.sbin/ppp/main.c:661
#9  main (argc=3D3, argv=3D<optimized out>) at /usr/src/usr.sbin/ppp/main.c=
:535

(gdb) print/x *opt
$2 =3D {hdr =3D {id =3D 0x13, len =3D 0x2}, data =3D {0x0, 0x6, 0x13, 0x2, =
0x13, 0x2,=20
    0x6b, 0x94, 0xa5 <repeats 42 times>}}

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

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271910-227>