Bugzilla Bug 178003

Buffer overflows in mutt_gecos_name

--- muttlib.c.orig      Thu Jun  8 13:51:03 2006
+++ muttlib.c   Thu May  3 13:41:28 2007
@@ -532,16 +532,19 @@ char *mutt_gecos_name (char *dest, size_t destlen, str

   pwnl = strlen (pw->pw_name);

-  for (idx = 0; dest[idx]; idx++)
+  for (idx = 0; dest[idx] && idx < destlen - 1; idx++)
   {
     if (dest[idx] == '&')
     {
-      memmove (&dest[idx + pwnl], &dest[idx + 1],
+      /* Don't move if destination is outside buffer. */
+      if (idx + pwnl < destlen)
+        memmove (&dest[idx + pwnl], &dest[idx + 1],
               MAX(destlen - idx - pwnl - 1, 0));
       memcpy (&dest[idx], pw->pw_name, MIN(destlen - idx - 1, pwnl));
       dest[idx] = toupper ((unsigned char) dest[idx]);
     }
   }
+  dest[idx] = '\0';

   return dest;
 }

Related changesets:
http://dev.mutt.org/hg/mutt/rev/47d08903b79b

net-mail please advise and patch as necessary.

Sooo....

Basically an overflow can be caused when mutt tries to expand "&" in real name
gecos field to uppercase login, and real name string length plus login name
length is more than 256 characters.

This can be reached viea two vectors -- at startup, it expands the real name of
the user launching mutt. This is only under control of the user, so to exploit
it he would have to voluntarily malform his real name field, all he'll get
would be to execute code as himself. No security impact here.

Second "attack" vector is alias expansion. If mutt user has an alias for a
local user, in form 'alias aliasname username # and thus not "alias aliasname
User Name <username>"' mutt does exactly the same thing for username. It is
questionable how likely is it for a local user to exist in someone's alias file
and have a malicious realname though.

One more thing is that realname should be long enough to make it possible for
an ASCII shellcode to fit there, and thus will be even more unlikely to exist
without permission of the operator of a system (who can do anything anyways)
and even if it existed it would be very suspicious, and thus unlikely to make
it into anyone's alias table. Therefore security impact is either none, or
veeeery limited.

# USERNAME=$(perl -e 'print "a" x 31')
# useradd -c "$(perl -e 'print "x" x 250') &" $USERNAME
# echo alias billg $USERNAME >~/.muttrc
# mutt billg
Segmentation fault (core dumped)
#

31 seems to be a limit for a login name, at least on my box.
Never seen an ASCII shellcode that would fit there.

Wait a second... you can use more than one "&" in a realname field.
This removes the 31-character limit.

hey net-mail .. unlike lkundrak i spent no time looking at it, but i would
sleep better with this patch applied. please provide a fixed ebuild.

It is easier if I get the mail myself :)

Anyway, mutt-1.5.16 should fix this. I just commited it to the tree.

- ferdy

Thanks ferdy. we'll handle stabilization here.
Arches, please test and mark stable mail-client/mutt-1.5.16:
target keywords are "alpha amd64 hppa ia64 mips ppc ppc64 sparc x86 ~x86-fbsd"

 * Cannot find $EPATCH_SOURCE!  Value for $EPATCH_SOURCE is:
 *
 *   /usr/portage/mail-client/mutt/files/mutt-1.5.16-parallel-make.patch
 *   ( mutt-1.5.16-parallel-make.patch )

Oops!

Should be fixed now. Sorry.

[ebuild     U ] mail-client/mutt-1.5.16 [1.5.13-r1] USE="berkdb crypt gdbm
gnutls idn imap nls nntp sasl ssl -debug -gpgme -mbox -pop (-qdbm) -sidebar%
-smime -smtp% -vanilla (-buffysize%) (-cjk%*)" 0 kB [1]

[...]

>>> Unpacking mutt-1.5.16-gentoo-patches.tar.bz2 to /dev/shm/portage/mail-client
/mutt-1.5.16/work
 * Applying mutt-1.5.16-parallel-make.patch ...                           [ ok
]
 * Applying 01-collapse_flagged.patch ...                                 [ ok
]
 * Applying 02-compressed.patch ...                                       [ ok
]
 * Applying 03-imap_fcc_status.patch ...                                  [ ok
]
 * Applying 04-mbox_hook.patch ...                                        [ ok
]
 * Applying 05-pgp_timeout.patch ...                                      [ ok
]
 * Applying 06-nntp.patch ...

 * Failed Patch: 06-nntp.patch !
 *  (
/dev/shm/portage/mail-client/mutt-1.5.16/work/mutt-1.5.16-gentoo-patches/0
6-nntp.patch )

Stable for HPPA.

x86 stable

There was a problem in the nntp patch which I fixed in the -r1 patchset.

- ferdy

ppc stable

alpha/ia64 stable

sparc stable.

ppc64 stable

amd64 stable

Hi,

according to comment #2 which very clearly explains the possible attack
vectors, i don't want to send a GLSA for that minor issue. It's a local buffer
overflow and has a security impact only if the user is really to dumb that he
will add a doubtlessly strange username in his alias file.

CVE-2007-1558 has not a high security impact imho, it's partial information
leakage.

So -> noglsa.

p-y? security? agree?

mips stable.

I agree that this particular issue isn't serious, but if you consider it with
the other two (temp file on bug #154310 and APOP issue on bug #175023), I think
we should have a glsa. And about the APOP issue, I disagree with you about the
impact of the information leakage. Assuming that most users use a non secure
password (likely to be a dictionnary word), disclosing the 3 first letters
makes the password much easier to find...

Despite the other mutt bugs I tend to agree with Falco here. I don't even think
it is worth mentioning in the other GLSA.

I agree, no glsa, this is not significant.

okay so finally closing without GLSA.