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.
