Bugzilla Bug 84680

a char * overflowable in rxvt with an escape code + text sequence.

doing:
$ cat evil_file

Overflows the string buffer in command.C:3539

Should be exploitable fairly easily. You can write whatever you like to 6144 bytes on the stack after the end of the allocated space for the string variable.

Fix is below:

--- command.C.orig	2005-03-10 01:18:28.180103872 +0000
+++ command.C	2005-03-10 01:18:43.840723096 +0000
@@ -3559,7 +3559,7 @@
 
       seen_esc = false;
 
-      if (n >= sizeof (string) - 1)
+      if ((n * sizeof(*string)) >= sizeof (string) - 1)
         // stop at some sane length
         return NULL;

Every version we carry is vulnerable.

$ perl -e 'print "^[P" . ("x" x 5000)' > /tmp/evil_file
$ cat /tmp/evil_file

gotta sleep now so haven't looked into this/thought about consequences as much as I might. will look at it again tomorrow.

taviso pointed out that I was on drugs (well, very tired) and that not very
version we carry is vulnerable. The problem exists in the ebuilded versions for
4.8 and higher, no stable versions are affected. The patch is against 4.7 but
should apply happily to other versions (probably with an offset).

This is a shiney new version of the fix which should perform better (every time
a esc+P is received...woo-hoo...) and also avoids the chance of integer
promotion problems by fixing up the type of n.

Fix was discussed/developed with help from Yoann Vandoorselaere. Any bugs are
mine.

rob@leet /tmp/rxvt-unicode-4.7/src $ diff -u command.C command.C.new 
--- command.C   2004-12-29 19:09:31.000000000 +0000
+++ command.C.new       2005-03-10 10:53:09.696945440 +0000
@@ -3535,7 +3535,7 @@
 {
   unicode_t ch;
   bool seen_esc = false;
-  unsigned int n = 0;
+  size_t n = 0;
   wchar_t string[STRING_MAX];

   while ((ch = cmd_getc ()) != NOCHAR)
@@ -3559,7 +3559,7 @@

       seen_esc = false;

-      if (n >= sizeof (string) - 1)
+      if (n >= (sizeof (string) / sizeof(*string)))
         // stop at some sane length
         return NULL;

confirmed in >=4.8, that patch fixes the issue here.

Current stable version is unaffected. 

Good catch Rob :)

emailed upstream and cc'd security@g.o

Thx Rob.

Mamoru please fix unstable versions if upstream does not release a fixed version soon.

(Sorry I'm now in Taiwan and replying late)
I'm not maintaining x11-terms/rxvt-unicode but x11-terms/rxvt.
latexer: could you have a look at it? thanks.

upstream are releasing a fixed version after cebit :)

My patch mistakenly drops something it shouldn't. Corrected path below:

rob@leet /tmp/rxvt-unicode-4.7/src $ diff -u command.C command.C.new 
--- command.C	2004-12-29 19:09:31.000000000 +0000
+++ command.C.new	2005-03-10 10:53:09.696945440 +0000
@@ -3535,7 +3535,7 @@
 {
   unicode_t ch;
   bool seen_esc = false;
-  unsigned int n = 0;
+  size_t n = 0;
   wchar_t string[STRING_MAX];
 
   while ((ch = cmd_getc ()) != NOCHAR)
@@ -3559,7 +3559,7 @@
 
       seen_esc = false;
 
-      if (n >= sizeof (string) - 1)
+      if (n >= ((sizeof (string) / sizeof(*string)) - 1))
         // stop at some sane length
         return NULL;

Upstream pointed this out, so they are aware ;)

I added 5.3 to the tree, which should contain the fixes. KEYWORDS are ~x86
~sparc ~amd64 ~ppc. Note that ~mips is stuck at 5.1 pending bug #82737 (just a
use.mask).

Release public @ http://dist.schmorp.de/rxvt-unicode/Changes
4.8 is affected and stable on ppc so it's not ~, we need a GLSA.

ppc: please test and mark x11-terms/rxvt-unicode-5.3 stable

stable on ppc 

Ready for GLSA.

This is CAN-2005-0764

GLSA drafted. The CVE id apparently is not reserved yet.

GLSA 200503-23