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
