Date: Sun, 4 Apr 2004 23:55:57 +0200 (CEST) From: Serge van den Boom <svdb+freebsd-bugs@stack.nl> To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/65175: buffer overrun in timedc Message-ID: <20040404215557.545417F@toad.stack.nl> Resent-Message-ID: <200404042200.i34M0d01044055@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 65175 >Category: bin >Synopsis: buffer overrun in timedc >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun Apr 04 15:00:38 PDT 2004 >Closed-Date: >Last-Modified: >Originator: Serge van den Boom >Release: FreeBSD 4.9-STABLE i386 >Organization: M.C.G.V. Stack >Environment: System: FreeBSD toad.stack.nl 4.9-STABLE FreeBSD 4.9-STABLE #12: Fri Feb 6 12:18:35 CET 2004 jilles@vwww.stack.nl:/vwww.mnt/sources/4.x/obj/vwww.mnt/sources/4.x/sys/toad_vwww i386 >Description: There exists a buffer overrun in timedc, which is installed setuid root per default. In interactive mode, if you enter a command, a pointer to each of the arguments is stored in the global array 'margv'. The problem is that the array is declared with size 20, and no bounds checks are done when filling this array. Fortunately, the command string, from which the array is filled, is no longer than 200 characters, allowing for only a limited range of memory which can be overwritten. On the system where I examined this bug, nothing exploitable seems to be in this range [1], however using a different architecture or compiler/linker, this may be different. If such an exploit would be possible, this would not directly lead to root privileges, as these are given up as one of the first things in the program. It would however leave the attacker with an udp socket bound to a privileged port, and a raw icmp socket. [1] The command string itself IS within the overwritable range, and it is possible to overwrite its terminating '\0', which would cause the command line parsing to go on for too long. As there are not many variables after that in the memory page, and the end of the page is still a long way off, another '\0' will inevitably be encountered before any harm can be done. >How-To-Repeat: $ timedc timedc> a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a a >Fix: Delete timed/timedc and use ntpd/ntpdc. >Release-Note: >Audit-Trail: >Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040404215557.545417F>