Description of problem: Version-Release number of selected component (if applicable): arpwatch-2.1a15-42.fc27.x86_64 How reproducible: Steps to Reproduce: 1. dnf install arpwatch; systemctl start arpwatch 2. 3. Actual results: dies after a while with signal 6 (SIGABRT) ... see syslog: Apr 5 05:30:39 HOST audit[14735]: ANOM_ABEND auid=4294967295 uid=77 gid=77 ses=4294967295 subj=system_u:system_r:arpwatch_t:s0 pid=14735 comm="arpwatch" exe="/usr/sbin/arpwatch" sig=6 res=1 Apr 5 05:30:39 HOST systemd[1]: arpwatch.service: Main process exited, code=killed, status=6/ABRT Apr 5 05:30:39 HOST systemd[1]: arpwatch.service: Unit entered failed state. Apr 5 05:30:39 HOST audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=arpwatch comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' Apr 5 05:30:39 HOST systemd[1]: arpwatch.service: Failed with result 'signal'. Expected results: not dead Additional info: # gdb /usr/sbin/arpwatch GNU gdb (GDB) Fedora 8.0.1-36.fc27 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 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-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/arpwatch...Reading symbols from /usr/lib/debug/us done. (gdb) run -d Starting program: /usr/sbin/arpwatch -d ... *** buffer overflow detected ***: /usr/sbin/arpwatch terminated Program received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 } Missing separate debuginfos, use: dnf debuginfo-install libpcap-1.8.1-6.fc27.x86_64 (gdb) where #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff7814c41 in __GI_abort () at abort.c:79 #2 0x00007ffff7855f17 in __libc_message (action=<optimized out>, fmt=fmt@entry=0x7ffff795b42d "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:181 #3 0x00007ffff78e555e in __GI___fortify_fail_abort (need_backtrace=need_backtrace@entry=true, msg=msg@entry=0x7ffff795b3aa "buffer overflow detected") at fortify_fail.c:33 #4 0x00007ffff78e5591 in __GI___fortify_fail (msg=msg@entry=0x7ffff795b3aa "buffer overflow detected") at fortify_fail.c:44 #5 0x00007ffff78e3440 in __GI___chk_fail () at chk_fail.c:28 #6 0x00007ffff78e26d2 in __strcpy_chk (dest=dest@entry=0x5555559608d6 "", src=src@entry=0x55555595f4d8 "A-VERY-LONG-HOSTNAME-IS_HERE-XXXXXXX", destlen=destlen@entry=34) at strcpy_chk.c:30 #7 0x0000555555557811 in strcpy (__src=0x55555595f4d8 "A-VERY-LONG-HOSTNAME-IS_HERE-XXXXXXX", __dest=0x5555559608d6 "") at /usr/include/bits/string_fortified.h:90 #8 elist_alloc (a=a@entry=2972297408, e=e@entry=0x7ffff771f194 "\204\307\352=\a\016\006\b\001", t=1522904662, h=0x55555595f4d8 "A-VERY-LONG-HOSTNAME-IS_HERE-XXXXXXX", h@entry=0x0) at ./db.c:287 #9 0x0000555555557b92 in ent_add (a=2972297408, e=0x7ffff771f194 "\204\307\352=\a\016\006\b\001", t=<optimized out>, h=0x0) at ./db.c:117 #10 0x000055555555742a in process_ether (u=<optimized out>, h=0x7fffffffdb40, p=0x7ffff771f18e "\377\377\377\377\377\377\204\307\352=\a\016\006\b\001") at ./arpwatch.c:502 #11 0x00007ffff7b9b716 in pcap_handle_packet_mmap () from /lib64/libpcap.so.1 #12 0x00007ffff7b9c3c4 in pcap_read_linux_mmap_v3 () from /lib64/libpcap.so.1 #13 0x00007ffff7ba471d in pcap_loop () from /lib64/libpcap.so.1 #14 0x0000555555556784 in main (argc=2, argv=0x7fffffffdeb8) at ./arpwatch.c:433 (gdb) The "A-VERY-LONG-HOSTNAME-IS_HERE-XXXXXXX" is 37 chars long. The max length of a DNS name part is 63 according to a quick google, and tallies with MAXHOSTNAMELEN being 64 in various header files. but the code seems to have a 34 byte buffer for names... struct einfo { u_char e[6]; /* ether address */ char h[34]; /* simple hostname */ time_t t; /* timestamp */ }; and the strcpy below is the one failing: if (h != NULL && !isdigit((int)*h)) strcpy(ep->h, h); The code should really either malloc the appropriate length buffer or at least use strncpy to limit to the defined buffer size, and if fixed size, it should be MAXHOSTNAMELEN+1 A workaround is to shorten long host names in the DNS, but that's ugly, and this bug is potentially exploitable.
The following patch seems to work: *** db.c.orig Sun Oct 1 10:39:58 2000 --- db.c Thu Apr 5 15:52:56 2018 *************** *** 41,46 **** --- 41,47 ---- #include <string.h> #include <syslog.h> #include <unistd.h> + #include <limits.h> #include "gnuc.h" #ifdef HAVE_OS_PROTO_H *************** *** 62,68 **** /* Ethernet info */ struct einfo { u_char e[6]; /* ether address */ ! char h[34]; /* simple hostname */ time_t t; /* timestamp */ }; --- 63,69 ---- /* Ethernet info */ struct einfo { u_char e[6]; /* ether address */ ! char h[HOST_NAME_MAX+1];/* simple hostname */ time_t t; /* timestamp */ }; *************** *** 283,290 **** BCOPY(e, ep->e, 6); if (h == NULL && !initializing) h = getsname(a); ! if (h != NULL && !isdigit((int)*h)) ! strcpy(ep->h, h); ep->t = t; return (ep); } --- 284,293 ---- BCOPY(e, ep->e, 6); if (h == NULL && !initializing) h = getsname(a); ! if (h != NULL && !isdigit((int)*h)) { ! strncpy(ep->h, h, sizeof(ep->h)); ! ep->h[sizeof(ep->h)-1] = 0; ! } ep->t = t; return (ep); }
problem still evident in fc28. same patch applies to arpwatch-2.1a15-42.fc28.x86_64 and fixes the issue
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Problem still evident in fc30.
arpwatch-2.1a15-45.fc31.x86_64 has the same issue.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.
I have just taken ownership of this package in Fedora after it was orphaned by the previous maintainer. I see that the new upstream version, 3.1, has increased the size of the h field to 64 bytes, as well as started using strncpy() to fill it, in an attempt to fix this issue. That seems almost consistent with the patch offered here (well, HOST_NAME_MAX+1 is 65, but as noted 63+1=64 should be enough in practice). I plan to backport a patch based on the 3.1 code in the next few days, and release it as a security update for all supported Fedora versions. After that, I will work on https://bugzilla.redhat.com/show_bug.cgi?id=1857980, packaging version 3.1. It will take a little time to review the changes and figure out which patches need to be carried forward. Thanks for reporting this, and for keeping the bug report updated.
FEDORA-2020-8e115f0c7a has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e115f0c7a
FEDORA-2020-9c2f330b5a has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c2f330b5a
FEDORA-2020-193da8cf44 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-193da8cf44
Updates are in Rawhide, and are on their way to testing for all supported Fedora releases. I did not take time to reproduce the bug in my own environment, so testing of the update by someone who is currently seeing this bug would be appreciated.
FEDORA-2020-8e115f0c7a has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8e115f0c7a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8e115f0c7a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-9c2f330b5a has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-9c2f330b5a` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-9c2f330b5a See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-193da8cf44 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-193da8cf44` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-193da8cf44 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
This message is a reminder that Fedora 31 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '31'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 31 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
FEDORA-2020-8e115f0c7a has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-9c2f330b5a has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-193da8cf44 has been pushed to the Fedora 31 stable repository. If problem still persists, please make note of it in this bug report.