Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Subject: OpenBSD 2.7 / NetBSD 1.4.2 mopd buffer overflow
From: Matt Power (mhpowerMIT.EDU)
Date: Tue Aug 08 2000 - 02:48:04 CDT

The mopd (Maintenance Operations Protocol loader daemon)
implementation in OpenBSD 2.7 and NetBSD 1.4.2 includes a step in
which the daemon receives a file name from a client elsewhere on the
network. I found one point at which the client can overflow a
buffer in the server by sending a long file name. Also, I found two
points at which the server uses the client-supplied file name directly
as part of a format string in a syslog(3) function call (this is
potentially problematic if the file name contains any % characters).

I reported these issues to the OpenBSD and NetBSD security contact
addresses at 00:04 UTC on 29 June 2000. I received a reply from the
OpenBSD project at 00:15 UTC on 29 June, and a reply from the NetBSD
Project at 03:05 UTC on 29 June.

An OpenBSD 2.7 security advisory was issued on 5 July -- see
http://www.openbsd.org/security.html#27 and its link to
http://www.openbsd.org/errata.html#mopd (which references a patch for
OpenBSD 2.7). Patches for NetBSD have also been written -- you may
wish to look at

There are other versions of mopd that you might possibly be using.
Download locations include


I suspect that currently all of these are vulnerable versions. To
check for the buffer-overflow problem yourself, look at the function
mopProcessDL in the file process.c. Older versions of the code declare
a 17-character buffer named pfile, and rely directly on a value of
tmpc (an unsigned char value obtained over the network from the
client) to determine how much data to write into this buffer,
regardless of whether the buffer is smaller than tmpc. To check for
the syslog problem, look for "syslog(LOG_INFO, line);".

I think OpenBSD and NetBSD are the only cases in which mopd is
installed by default in any common operating-system distribution.
There's no direct risk in having mopd installed; the potential risk
occurs only if a vulnerable version of mopd is running (mopd can be
one of the daemons started at boot time, or it could be started later
by root; it is not run from inetd). The risk may also commonly be
further limited by the inability of any machines outside of the local
Ethernet to get packets to the mopd. Finally, mopd would typically not
be running except on machines that act as a netboot server for certain
other pieces of hardware on a local network (e.g., some types of DEC
hardware, possibly also some types of Cisco hardware).

Matt Power