SUMMARY
All currently available versions of gnuserv for unix prior to 3.12 are
vulnerable to remote exploit due to a buffer overflow and weak
security. Gnuserv is a remote control facility for Emacsen. Gnuserv
ships with XEmacs but is also available stand-alone from various
sources for use with GNU Emacs.
VULNERABILITY
An attacker can excute remote commands with the uid of the user that
is running gnuserv.
DISCOVERER AND ACKNOWLEDGEMENTS
This problem was discovered by Klaus Frank
<[EMAIL PROTECTED]>. Klaus provided a fix as
well. Many thanks to Klaus for bringing this to attention of the
XEmacs and gnuserv maintainers.
I also with to thank Vince Shelton and Martin Schwenke for putting
fixed releases of XEmacs and gnuserv on the net quickly.
DETAIL
gnuserv/gnuclient is a pair of utility programs used to
sent commands to an already running Emacs process. gnuserv
is the helper binary used by the running Emacs to listen
for commands. It must be started explicitly using the gnuserv-start
command.[1]
gnuserv can use several different communication mechanisms, one of
them being a tcp port. This can be switched off at compile time, but
defaults to on. If enabled gnuserv binds to a user specified TCP port,
with the default being (21490 + uid). Note that (if enabled) gnuserv
_always_ listens for TCP connections, even if one of the other
mechanisms is normally used by the user.
Connections on the gnuserv port are authenticated either against a
list of trusted hosts or using a MIT-MAGIC-COOKIE based system.
(MIT-MAGIC_COOKIE authentication can be switched of, but again is the
default.)
The problem lies in the fact that the gnuserv program trusts the
remote sides specification for the lenght of the cookie without
any sanity checking. This allows the attacker to
1. Overflow the buffer used to hold a copy of the cookie.
2. Force the comparison of the cookies to be restricted to
a prefix of a length chosen by him, e.g. 1 byte, making
bruteforcing the authentication trivial.
Both problems are sufficient to give any attacker easy access
to running arbitrary commands under the uid of the user running
gnuserv.
VULNERABLE VERSIONS
Unfortunately gnuserv has rather a complicated history:
gnuserv was origionally written by Andy Norman (ange). The problematic
Xauth based authentication was later added by somebody else. As ange
effectively stopped maintaining his version (gnuserv-2.1alpha.tar.gz)
various people have put up their own modified copies. That includes
among others the version shipped with XEmacs and fgnuserv by Noah
Friedman, which is an easier to compile stand-alone version.
After a recent rewrite we made the XEmacs version the official
verion[2], and bumped the version number to the 3.x range. Martin
Schwenke has made a backport of this version for use with Emacs
using fgnuserv's build mecahnism.
All of the above versions should be assumbed vulnerable, including
those shipped with XEmacs 21.1.x for x < 14. As a test run
strings gnuserv | grep "gnuserv version"
If this gives either nothing or a version below 3.12, then you are
vulnerable.
NOT VULNERABLE
There is a seperate fork for gnuserv on windows for use with NTEmacs.
This is not vulnerable as it uses a completely different communication
channel. This is, however, unconfirmed.
FIXED VERSION
A fix by Klaus Frank is in gnuserv 3.12.
If you are using XEmacs we suggest upgrading to XEmacs 21.1.14
that contains this version (or 21.2.35 if you are running betas).
This version can be had from
http://www.xemacs.org/Releases/21.1.14.html
or mirrors.
If you are using a standalone gnuserv with GNU Emacs on unix we
suggest getting Martin Schwenkes fixed version from
http://www.linuxcare.com.au/people/martins/hacks/emacs/src/gnuserv-3.12.1.tar.gz
REFERENCES
This is the vulnerability indicated in Mandrake Advisory MDKSA-2001:019
Jan Vroonhof <[EMAIL PROTECTED]>
Gnuserv feel-responsible-for-person
Footnotes:
[1] However I have seen many icons for XEmacs in UI's start
"xemacs -f gnuserv" so it is not always obvious to the
user he is running gnuserv.
[2] With permission form Andy Norman
