Remote vulnerability in gnuserv/XEmacsFeb 02, 2001, 23:12 (1 Talkback[s])
(Other stories by Jan Vroonhof)
Date: Fri, 2 Feb 2001 14:13:35 +0000
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.
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 firstname.lastname@example.org. 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.
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.
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 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.
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, 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.
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.
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
Jan Vroonhof email@example.com
Footnotes:  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.  With permission form Andy Norman