From owner-freebsd-usb@freebsd.org Tue Jun 25 12:04:18 2019 Return-Path: Delivered-To: freebsd-usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC87415CA816 for ; Tue, 25 Jun 2019 12:04:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 51B8387736 for ; Tue, 25 Jun 2019 12:04:17 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 1224815CA814; Tue, 25 Jun 2019 12:04:17 +0000 (UTC) Delivered-To: usb@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9A2215CA813 for ; Tue, 25 Jun 2019 12:04:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67C0A87731 for ; Tue, 25 Jun 2019 12:04:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 75D32C778 for ; Tue, 25 Jun 2019 12:04:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x5PC4FEX048235 for ; Tue, 25 Jun 2019 12:04:15 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x5PC4Fim048221 for usb@FreeBSD.org; Tue, 25 Jun 2019 12:04:15 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: usb@FreeBSD.org Subject: [Bug 238801] usbdump -r bad read Date: Tue, 25 Jun 2019 12:04:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: usb X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: areiter@veracode.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: usb@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 12:04:18 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238801 Bug ID: 238801 Summary: usbdump -r bad read Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: usb Assignee: usb@FreeBSD.org Reporter: areiter@veracode.com Created attachment 205325 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D205325&action= =3Dedit crash sample Background: With some spare time, I randomly decided to apply AFL to `usbdu= mp -r `. To get it going, I used a seed file of 10240 bytes from /dev/ra= ndom and additionally augmented the source to avoid the magic value check and the major/minor checks that one sees in usbdump.c:init_rfile(struct usbcap *). = With those changes, AFL under VMWare will find this crash in seconds. From the q= uick diagnosis, it seems to be a bad memory access and the following is based on June 24 2019 usbdump.c from CURRENT copied into a 12.O-RELEASE tree and bui= lt (so one is aware) and print_packets() looking to be the culprit: [arr@gunther ~]$ gdb /usr/obj/usr/src/amd64.amd64/usr.sbin/usbdump/usbdump.= full GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD] Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-portbld-freebsd12.0". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.sbin/usbdump/usbdump.full...done. (gdb) r -r usbdump_read_sample Starting program: /usr/obj/usr/src/amd64.amd64/usr.sbin/usbdump/usbdump.ful= l -r usbdump_read_sample Program received signal SIGBUS, Bus error. strlen (str=3D0x180011000000e2 ) at /usr/src/lib/libc/string/strlen.c:101 101 va =3D (*lp - mask01); (gdb) bt #0 strlen (str=3D0x180011000000e2 ) at /usr/src/lib/libc/string/strlen.c:101 #1 0x0000000800397539 in __vfprintf (fp=3D, locale=3D0x8004= 084e8 <__xlocale_global_locale>, fmt0=3D, ap=3D) at /usr/src/lib/libc/stdio/vfprintf.c:854 #2 0x0000000800395144 in vfprintf_l (fp=3D0x8004098e8, locale=3D0x8004084e8 <__xlocale_global_locale>, fmt0=3D0x200b12 "%.*s.%06ld usbus%d.%d %s-%s-EP=3D%08x,SPD=3D%s,NFR=3D%d,SLEN=3D%d,IVAL=3D%d%s%s\n", ap=3D0x7fffff= ffe720) at /usr/src/lib/libc/stdio/vfprintf.c:285 #3 0x00000008003e21c4 in printf (fmt=3D0x1 ) at /usr/src/lib/libc/stdio/printf.c:57 #4 0x0000000000203432 in print_apacket (ptr=3D, ptr_len=3D, hdr=3D) at /usr/src/usr.sbin/usbdump/usbdump.c:495 #5 print_packets (data=3D0x800644000 "\f;2\331\366\067\335\233\225\377\262!\226\237\066d\001\245SSSS", datalen=3D) at /usr/src/usr.sbin/usbdump/usbdump.c:631 #6 0x0000000000203104 in read_file (p=3D) at /usr/src/usr.sbin/usbdump/usbdump.c:676 #7 0x0000000000202e1d in main (argc=3D3, argv=3D0x7fffffffeab8) at /usr/src/usr.sbin/usbdump/usbdump.c:888 (gdb) up 5 #5 print_packets (data=3D0x800644000 "\f;2\331\366\067\335\233\225\377\262!\226\237\066d\001\245SSSS", datalen=3D) at /usr/src/usr.sbin/usbdump/usbdump.c:631 631 print_apacket(&temp, ptr + (gdb) list 605 600 if (next <=3D ptr) 601 err(EXIT_FAILURE, "Invalid length"); 602 } 603 } 604 605 static void 606 print_packets(uint8_t *data, const int datalen) 607 { 608 struct header_32 temp; 609 uint8_t *ptr; (gdb) 610 uint8_t *next; 611 612 for (ptr =3D data; ptr < (data + datalen); ptr =3D next) { 613 614 const struct header_32 *hdr32; 615 616 hdr32 =3D (const struct header_32 *)ptr; 617 618 temp.ts_sec =3D le32toh(hdr32->ts_sec); 619 temp.ts_usec =3D le32toh(hdr32->ts_usec); (gdb) 620 temp.caplen =3D le32toh(hdr32->caplen); 621 temp.datalen =3D le32toh(hdr32->datalen); 622 temp.hdrlen =3D hdr32->hdrlen; 623 temp.align =3D hdr32->align; 624 625 next =3D ptr + roundup2(temp.hdrlen + temp.caplen, temp.align); 626 627 if (next <=3D ptr) 628 err(EXIT_FAILURE, "Invalid length"); 629 (gdb) 630 if (verbose >=3D 0 || r_arg !=3D NULL || b_arg !=3D= NULL) { 631 print_apacket(&temp, ptr + 632 temp.hdrlen, temp.caplen); 633 } 634 pkt_captured++; 635 } 636 } To fix the crash input to be realistic, I set the magic value, major value = to 0, and minor value (of 3, versus 2) for the struct usbcap_filehdr. I only tested with minor value set to 3 and not 2, but it would seem, regardless, = to likely want to adjust how that parsing is done. Attached is the input sampl= e. I have not worked up a patch, but mostly because I did this in some spare cycles and I do not really know this code so well to produce a solution. :(= I know that is not very helpful, but figured I should at least file the bug. --=20 You are receiving this mail because: You are the assignee for the bug.=