3.2. Severity
Low.
3.3. Problem
Functions like read-passwd do not clear the the history of
recently typed keys. In fact, there is no way to do that from
Emacs Lisp.
3.4. Impact
Passwords might be recovered by someone who has got access to the
console on which Emacs is running, subverting password expiring
as, for example, provided by Mailcrypt. (Usually, there are many
other ways to obtain passwords if you can type C-h l inside a
foreign Emacs, though.)
3.5. Solution
The patch below adds code to clear-this-command-keys which will
erase the vector containing the last 100 events. In the past,
this function was already used as if it behaved that way.
4. Acknowledgements
Helmut Waitzmann for rediscovering the PTY permissions problem
and testing the HP-UX patch. Gerd Moellmann of the Emacs
development team for the patch to clear-this-command-keys and
helpful comments.
5. Patch against Emacs 20.6
The patch below is against GNU Emacs 20.6, as available at GNU
FTP mirrors. Note that you have to run autoconf to recreate the
configure script (including it would have enormously increased
the size of the patch).
diff --unified --recursive emacs-20.6-orig/configure.in
emacs-20.6/configure.in
--- emacs-20.6-orig/configure.in Sat Feb 26 13:07:02 2000
+++ emacs-20.6/configure.in Fri Mar 10 19:13:05 2000
@@ -1636,6 +1636,11 @@
strerror fpathconf select mktime euidaccess getpagesize tzset setlocale \
utimes setrlimit setpgid getcwd shutdown strftime)
+# Check for UNIX98 PTYs.
+# getpt is a glibc addition which emulates the master device on
+# systems without kernel support.
+AC_CHECK_FUNCS(grantpt unlockpt getpt ptsname)
+
# Check this now, so that we will NOT find the above functions in ncurses.
# That is because we have not set up to link ncurses in lib-src.
# It's better to believe a function is not available
diff --unified --recursive emacs-20.6-orig/src/config.in emacs-20.6/src/config.in
--- emacs-20.6-orig/src/config.in Mon Apr 26 07:19:44 1999
+++ emacs-20.6/src/config.in Fri Mar 10 19:13:05 2000
@@ -235,6 +235,14 @@
#undef HAVE_SHUTDOWN
#undef HAVE_STRFTIME
+/* UNIX98 PTY support functions
+ getpt is a glibc addition which emulates the master device on
+ systems without kernel support. */
+#undef HAVE_GRANTPT
+#undef HAVE_UNLOCKPT
+#undef HAVE_GETPT
+#undef HAVE_PTSNAME
+
#undef LOCALTIME_CACHE
#undef HAVE_INET_SOCKETS
diff --unified --recursive emacs-20.6-orig/src/keyboard.c
emacs-20.6/src/keyboard.c
--- emacs-20.6-orig/src/keyboard.c Thu Nov 18 05:57:32 1999
+++ emacs-20.6/src/keyboard.c Fri Mar 10 19:13:05 2000
@@ -8318,10 +8318,18 @@
DEFUN ("clear-this-command-keys", Fclear_this_command_keys,
Sclear_this_command_keys, 0, 0, 0,
- "Clear out the vector that `this-command-keys' returns.")
+ "Clear out the vector that `this-command-keys' returns.\n\
+Clear vector containing last 100 events.")
()
{
+ int i;
+
this_command_key_count = 0;
+
+ for (i = 0; i < XVECTOR (recent_keys)->size; ++i)
+ XVECTOR (recent_keys)->contents[i] = Qnil;
+ total_keys = 0;
+ recent_keys_index = 0;
return Qnil;
}
diff --unified --recursive emacs-20.6-orig/src/s/aix4.h
emacs-20.6/src/s/aix4.h
--- emacs-20.6-orig/src/s/aix4.h Sat Jul 25 08:45:27 1998
+++ emacs-20.6/src/s/aix4.h Fri Mar 17 20:44:08 2000
@@ -12,3 +12,33 @@
/* Specify the type that the 3rd arg of `accept' points to.
It is just a guess which versions of AIX need this definition. */
#define SOCKLEN_TYPE int
+
+#if defined(HAVE_GRANTPT) && defined(HAVE_UNLOCKPT) &&
defined(HAVE_PTSNAME)
+/* UNIX98 PTYs are available.
+ Added by Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>,
+ RUS-CERT, University of Stuttgart. Based on Emacs code for DGUX. */
+
+/* Most of the #defines are already provided by aix3-1.h. */
+
+/* This sets the name of the slave side of the PTY. grantpt(3) and
+ unlockpt(3) may fork a subprocess, so keep sigchld_handler() from
+ intercepting that death. */
+
+#undef PTY_TTY_NAME_SPRINTF
+#define PTY_TTY_NAME_SPRINTF \
+ { \
+ char *ptsname(), *ptyname; \
+ \
+ sigblock(sigmask(SIGCHLD)); \
+ if (grantpt(fd) == -1) \
+ fatal("could not grant slave pty"); \
+ if (unlockpt(fd) == -1) \
+ fatal("could not unlock slave pty"); \
+ sigunblock(sigmask(SIGCHLD)); \
+ if (!(ptyname = ptsname(fd))) \
+ fatal ("could not enable slave pty"); \
+ strncpy(pty_name, ptyname, sizeof(pty_name)); \
+ pty_name[sizeof(pty_name) - 1] = 0; \
+ }
+
+#endif diff --unified --recursive emacs-20.6-orig/src/s/gnu-linux.h
emacs-20.6/src/s/gnu-linux.h
--- emacs-20.6-orig/src/s/gnu-linux.h Wed Jan 26 14:28:40 2000
+++ emacs-20.6/src/s/gnu-linux.h Fri Mar 17 20:44:31 2000
@@ -307,3 +307,49 @@
#ifdef DOUG_LEA_MALLOC
#undef REL_ALLOC
#endif
+
+#if defined(HAVE_GRANTPT) && defined(HAVE_UNLOCKPT) &&
defined(HAVE_PTSNAME)
+/* UNIX98 PTYs are available.
+ Added by Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>,
+ RUS-CERT, University of Stuttgart. Based on Emacs code for DGUX. */
+
+#define PTY_ITERATION for (i = 0; i < 1; i++)
+/* no iteration at all */
+
+/* Use getpt() if it's available, because it provides Unix98 PTY
+ emulation for kernels which doesn't support it natively. */
+
+#ifdef HAVE_GETPT
+#define PTY_OPEN \
+ do { \
+ fd = getpt(); \
+ if (fcntl (fd, F_SETFL, O_NDELAY) == -1) \
+ fatal ("could not set master PTY to non-block mode"); \
+ } while (0)
+
+#else
+/* the master PTY device */
+#define PTY_NAME_SPRINTF strcpy (pty_name, "/dev/ptmx");
+#endif
+
+/* This sets the name of the slave side of the PTY. grantpt(3) and
+ unlockpt(3) may fork a subprocess, so keep sigchld_handler() from
+ intercepting that death. */
+
+#define PTY_TTY_NAME_SPRINTF \
+ { \
+ char *ptsname(), *ptyname; \
+ \
+ sigblock(sigmask(SIGCHLD)); \
+ if (grantpt(fd) == -1) \
+ fatal("could not grant slave pty"); \
+ if (unlockpt(fd) == -1) \
+ fatal("could not unlock slave pty"); \
+ if (!(ptyname = ptsname(fd))) \
+ fatal ("could not enable slave pty"); \
+ strncpy(pty_name, ptyname, sizeof(pty_name)); \
+ pty_name[sizeof(pty_name) - 1] = 0; \
+ sigunblock(sigmask(SIGCHLD)); \
+ }
+
+#endif diff --unified --recursive emacs-20.6-orig/src/s/hpux.h
emacs-20.6/src/s/hpux.h
--- emacs-20.6-orig/src/s/hpux.h Mon Jan 15 10:16:40 1996
+++ emacs-20.6/src/s/hpux.h Wed Mar 29 08:40:52 2000
@@ -228,6 +228,59 @@
/* This is needed for HPUX version 6.2; it may not be needed for 6.2.1. */
#define SHORT_CAST_BUG
+#if defined(HAVE_GRANTPT) && defined(HAVE_UNLOCKPT) &&
defined(HAVE_PTSNAME)
+/* UNIX98 PTYs are available.
+ Added by Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>,
+ RUS-CERT, University of Stuttgart. Based on Emacs code for DGUX. */
+
+#ifdef emacs
+#include <grp.h>
+#include <sys/stropts.h>
+#endif
+
+#define PTY_ITERATION for (i = 0; i < 1; i++)
+/* no iteration at all */
+
+/* the master PTY device */
+#define PTY_NAME_SPRINTF strcpy (pty_name, "/dev/ptmx");
+
+/* This sets the name of the slave side of the PTY. grantpt(3) and
+ unlockpt(3) may fork a subprocess, so keep sigchld_handler() from
+ intercepting that death. grantpt() behavior on HP-UX differs from
+ what's specified in the man page: the group of the slave PTY is set
+ to the user's primary group, and we fix that. */
+
+#define PTY_TTY_NAME_SPRINTF \
+ { \
+ char *ptsname(), *ptyname; \
+ struct group *getgrnam (), *tty_group = getgrnam ("tty"); \
+ if (tty_group == NULL) \
+ fatal ("group tty not found"); \
+ \
+ sigblock(sigmask(SIGCHLD)); \
+ if (grantpt(fd) == -1) \
+ fatal("could not grant slave pty"); \
+ if (!(ptyname = ptsname(fd))) \
+ fatal ("could not enable slave pty"); \
+ strncpy(pty_name, ptyname, sizeof(pty_name)); \
+ pty_name[sizeof(pty_name) - 1] = 0; \
+ if (chown (pty_name, (uid_t) -1, tty_group->gr_gid) == -1) \
+ fatal ("could not chown slave pty"); \
+ if (unlockpt(fd) == -1) \
+ fatal("could not unlock slave pty"); \
+ sigunblock(sigmask(SIGCHLD)); \
+ }
+
+/* Push various streams modules onto a PTY channel. */
+
+#define SETUP_SLAVE_PTY \
+ if (ioctl (xforkin, I_PUSH, "ptem") == -1) \
+ fatal ("ioctl I_PUSH ptem", errno); \
+ if (ioctl (xforkin, I_PUSH, "ldterm") == -1) \
+ fatal ("ioctl I_PUSH ldterm", errno);
+
+#else /* no UNIX98 PTYs */
+
/* This is how to get the device name of the tty end of a pty. */
#define PTY_TTY_NAME_SPRINTF \
sprintf (pty_name, "/dev/pty/tty%c%x", c, i);
@@ -235,6 +288,8 @@
/* This is how to get the device name of the control end of a pty. */
#define PTY_NAME_SPRINTF \
sprintf (pty_name, "/dev/ptym/pty%c%x", c, i);
+
+#endif /* UNIX 98 PTYs */
/* This triggers a conditional in xfaces.c. */
#define XOS_NEEDS_TIME_H
(5023253) ------------------------------------------(Ombruten)
5026137 2000-04-20 02:32 /42 rader/ Postmaster
Mottagare: Bugtraq (import) <10532>
Ärende: Re: RUS-CERT Advisory 200004-01: GNU Emacs 20
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: bugtraq@securityfocus.com
Message-ID: <200004191847.LAA17706@dilvish.speed.net>
Date: Wed, 19 Apr 2000 11:47:35 -0700
Reply-To: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
X-To: bugtraq@securityfocus.com
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Message from "RUS-CERT, University of Stuttgart"
<cert@UNI-STUTTGART.DE> of "Tue, 18 Apr 2000 14:17:05 +0200."
<tg4s8zioxq.fsf@mercury.rus.uni-stuttgart.de>
"RUS-CERT, University of Stuttgart" <cert@UNI-STUTTGART.DE> writes:
> ____________________________________________________________
>
> RUS-CERT Advisory 200004-01: GNU Emacs 20
>
> RUS-CERT, University of Stuttgart
>
> 2000-04-18
>
> Summary
>
> Several vulnerabilities were discovered in all Emacs versions up
> to 20.6, namely:
[...]
As an XEmacs user, I would have liked to have seen one of the
following statements:
* These vulnerabilities only apply to GNU Emacs, not XEmacs.
* We do not know if these vulnerabilities also apply to XEmacs.
* These vulnerabilities apply to equally to GNU Emacs and XEmacs.
----------------------------------------------------------------------
Dan Harkless | To prevent SPAM contamination, please
dan-bugtraq@dilvish.speed.net | do not mention this private email
SpeedGate Communications, Inc. | address in Usenet posts. Thank you.
(5026137) ------------------------------------------(Ombruten)
5028070 2000-04-20 18:16 /31 rader/ Postmaster
Mottagare: Bugtraq (import) <10542>
Ärende: Re: RUS-CERT Advisory 200004-01: GNU Emacs 20
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-URL: http://black-ice.cc.vt.edu/~valdis/
X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#;3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t
^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[<!v4-0bVIpaxF#-
%9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
Message-ID: <200004200226.e3K2QLB28944@black-ice.cc.vt.edu>
Date: Wed, 19 Apr 2000 22:26:17 -0400
Reply-To: Valdis.Kletnieks@VT.EDU
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Valdis.Kletnieks@VT.EDU
X-To: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Your message of "Wed, 19 Apr 2000 11:47:35 PDT."
<200004191847.LAA17706@dilvish.speed.net>
On Wed, 19 Apr 2000 11:47:35 PDT, Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET> said:
> > RUS-CERT Advisory 200004-01: GNU Emacs 20
> * We do not know if these vulnerabilities also apply to XEmacs.
This about sums it up. The advisory *was* seen on the XEmacs
developer's list. It's still unclear whether the XEmacs support for
Unix98 pty's has the same problems as the Emacs version. I'll make
sure there's a follow-up as soon as there's more concrete information.
Valdis Kletnieks
Operating Systems Analyst
Virginia Tech
(5028070) ------------------------------------------(Ombruten)
5028084 2000-04-20 18:26 /58 rader/ Postmaster
Mottagare: Bugtraq (import) <10543>
Ärende: Re: RUS-CERT Advisory 200004-01: GNU Emacs 20
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <14590.32213.640938.691566@cerise.sensei.co.uk>
Date: Thu, 20 Apr 2000 04:47:33 +0100
Reply-To: Glynn Clements <glynn@SENSEI.CO.UK>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Glynn Clements <glynn@SENSEI.CO.UK>
X-To: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <200004191847.LAA17706@dilvish.speed.net>
Dan Harkless wrote:
> > RUS-CERT Advisory 200004-01: GNU Emacs 20
>
> As an XEmacs user, I would have liked to have seen one of the following
> statements:
>
> * These vulnerabilities only apply to GNU Emacs, not XEmacs.
>
> * We do not know if these vulnerabilities also apply to XEmacs.
>
> * These vulnerabilities apply to equally to GNU Emacs and XEmacs.
I guess that it would be option 2.
> On the systems listed above, when a new subprocess is created
> using the builtin Lisp function start-process, Emacs doesn't set
> proper permissions for the slave PTY device.
On XEmacs, start-process only uses a pty if process-connection-type is
"t", otherwise it uses (unnamed) pipes.
> 2. Unsafe creation of temporary files
>
> 2.1. Scope
>
> All Unix-like Emacs platforms on which public directories are
> used to store temporary files.
Recent versions of XEmacs honour $TMPDIR, so there shouldn't be any
need to use public directories.
> 3.3. Problem
>
> Functions like read-passwd do not clear the the history of
> recently typed keys. In fact, there is no way to do that from
> Emacs Lisp.
Ditto for XEmacs.
--
Glynn Clements <glynn@sensei.co.uk>
(5028084) ------------------------------------------
5028121 2000-04-20 18:50 /35 rader/ Postmaster
Mottagare: Bugtraq (import) <10546>
Ärende: Re: RUS-CERT Advisory 200004-01: GNU Emacs 20
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@securityfocus.com
User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Message-ID: <tgpurloudk.fsf@mercury.rus.uni-stuttgart.de>
Date: Thu, 20 Apr 2000 13:59:51 +0200
Reply-To: Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Florian Weimer <Florian.Weimer@RUS.UNI-STUTTGART.DE>
X-To: Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET>
X-cc: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Dan Harkless's message of "Wed, 19 Apr 2000 11:47:35 -0700"
Dan Harkless <dan-bugtraq@DILVISH.SPEED.NET> writes:
> As an XEmacs user, I would have liked to have seen one of the following
> statements:
> * These vulnerabilities apply to equally to GNU Emacs and XEmacs.
This seems to be the case. I've just looked briefly at XEmacs 20.4
and some versions of the 21.1 branch, and they seem to be quite
similar to GNU Emacs in this regard.
The XEmacs development team has already been contacted, and they will
certainly be able to clarify this.
--
Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5
(5028121) ------------------------------------------
5028248 2000-04-20 20:10 /40 rader/ Postmaster
Mottagare: Bugtraq (import) <10553>
Mottagare: Håna dem! <214>
Sänt: 2000-04-21 07:26
Sänt av Peter Bortas
Ärende: GNU/Linux
------------------------------------------------------------
Approved-By: aleph1@SECURITYFOCUS.COM
Delivered-To: bugtraq@lists.securityfocus.com
Delivered-To: BUGTRAQ@SECURITYFOCUS.COM
X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@gnu.or
using -f
Message-ID: <200004200517.XAA22589@wijiji.santafe.edu>
Date: Wed, 19 Apr 2000 23:17:32 -0600
Reply-To: rms@gnu.org
Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
From: Richard Stallman <rms@gnu.org>
X-To: cert@UNI-STUTTGART.DE, BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
Thanks for telling us a fix for the PTY problem. We will probably
make an Emacs 20.7 release with a fix for this; but first we need
to get legal papers for the changes. That is no problem for
the changes written by Gerd, but who are the authors of the rest,
and how can we contact them?
I'd like to ask you to do one other thing for us--a matter of
terminology.
Affected systems:
Linux (both libc and glibc)
Linux is the kernel; the system as a whole is basically the GNU
operating system. We're the system's principal developer; would you
please give us a share of the credit, by calling the system
"GNU/Linux"? The GNU Project was the principal developer of this
system, so it seems fair to give us at least an equal share of the
current.
Note that all versions of GNU/Linux use a version of GNU libc. The
so-called "Linux libc" was a modified version of GNU libc version 1.
This is another example of how we don't get credit for our work
because people call it "Linux".
See http://www.gnu.org/gnu/linux-and-gnu.html for more
explanation.
(5028248) ------------------------------------------