I was innocently attempting to read email today and was unable to `inc` my mail--getting a core dump. After jumping through many many hoops so that I could debug the problem, I discovered that there was a bug in matchc() which could cause ill-formatted email to overrun buffers. I don't *think* it could be abused to execute arbitrary commands, at least in the context I saw it operating, but I hope you agree that it must be fixed ASAP regardless. The specific bug is that matchc() only checks to see if the string being searched is out of bounds when the character in the search string is NOT the first character of the pattern: m_getfld.c: 730 for(;;) while (pc != *str++) if (str > es) return 0; The implication is if the search string ends with a lot of these pattern characters, it will happily run past the end (es). If, as it happened in my case, the pattern *does* happen to appear after es, the function will return an address greater than es. This larger address will be used for a length computation (m_getfld.c: 446) passed into memcpy (m_getfld.c: 486), and will thus overrun the destination buffer. Changing the test so that it always tests str > es fixed the bug. I did a little dance with where the increment occurs to prevent the logic from being any more complex than necessary. I'll actually provide two patches below. One minimal, one more clean (IMHO of course). Patches to come in subsequent attachments (sigh). The upstream bug I reported can be found at http://savannah.nongnu.org/bugs/index.php?func=detailitem&item_id=9721 Reproducible: Always Steps to Reproduce: 1. Get an email spool with an email ending in lots of line feeds where the email is just of the wrong size... (nontrivial :-) 2. inc 3. Actual Results: Core dump Expected Results: incorporate email Portage 2.0.50-r8 (default-x86-2004.0, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.6.7-gentoo-r7) ================================================================= System uname: 2.6.7-gentoo-r7 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium3 -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow X Xaw3d aalib acpi alsa apache2 apm arts audiofile avi berkdb caps cdr crypt cscope cups curl dga directfb doc emacs encode esd ethereal fdftk flac foomaticdb gd gdbm gif gmp gnome gphoto2 gpm gtk gtk2 hardened imagemagick imlib java joystick jpeg kde lcms ldap lesstif libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls nocardbus nocd oggvorbis opengl oss pam pdflib perl plotutils png postgres ppds prelude python qt quicktime readline samba sdl slang snmp socks5 speex spell sse ssl svga tcltk tcpd tetex theora tiff truetype unicode usb videos wmf x86 xinerama xml xml2 xmms xosd xv zlib"
No confirmation from upstream yet.
Please note that investigation of the nmh bug database suggests there has been no activity about submitted bugs since Sep 30, 2003 In other words, I'm not planning on holding my breath for word from upstream.
net-mail herd, please confirm / fix / comment on this.
Created attachment 36141 [details, diff] proposed patch1 the reporter forgot to attched the patches, so I attached his/her patches that he/she submitted to upstream.
Created attachment 36142 [details, diff] proposed patch2 @security: please take a look at the proposed patches and advise us which one is preferred. TIA.
Seth, please attached a plaintext file foo.txt so that we can reproduce with `inc -file foo.txt`. OTH, mailutils provide mh utilities, can you try it to see if it works for you?
Created attachment 36219 [details] Example mbox which will dump core Here is an example mailbox which will dump core on an unpatched system when `inc -file sample` I'll see if I cannot try mailutils "soon".
Seth, I can't reproduce this on my system (~x86. I don't have a x86 setup to test with.) May be someone else can confirm this bug. $ inc -file /tmp/sample.1 You already have the standard nmh directory "/home/langthang/Mail". Do you want to use it for nmh? y [Using existing directory] Incorporating new mail into inbox... 1+ 07/20 "Bounced mail" Returned mail: Data format error<<This is a mult 2 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF G 3 07/21 "PokerBook Info" Pokerbook Has Gone Public- Huge PR Campaign On I 4 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF G /tmp/sample.1 not zero'd $ emerge info Portage 2.0.51_pre13 (default-x86-2004.0, gcc-3.4.1, glibc-2.3.4.20040619-r0, 2.6.7-gentoo-r11 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz) ================================================================= System uname: 2.6.7-gentoo-r11 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz Gentoo Base System version 1.5.1 ccache version 2.3 [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.14.90.0.8-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=pentium4 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3.3/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=pentium4 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs cvs sandbox" GENTOO_MIRRORS="http://gentoo.oregonstate.edu" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.samerica.gentoo.org/gentoo-portage" USE="X acpi acpi4linux alsa apache2 apm autofs avi berkdb cdr cjk composite crypt cups directfb dnd dvd dvdr encode fam fbcon fbdev foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 guile imlib ipv6 java javascript jpeg kde libg++ libwww mad md5sum mikmod mmx motif mozilla mpeg mysql ncurses nls nptl oggvorbis oss pam pdflib perl png python qt quicktime readline samba sasl sdl slang spell sse ssl stroke svga tcltk tcpd truetype usb x86 xine xml xml2 xmms xosd xv xvid zlib"
How interesting. Apparently you need to have a special line in .mh_profile I tried it with a virgin profile and did not have the problem. Adding the line had the problem reappear. Try this: echo "inc: -audit .FromList" >> ~/.mh_profile Let me know if you still cannot see the problem.
Seth, bash-2.05b$ echo "inc: -audit .FromList" >> ~/.mh_profile bash-2.05b$ cat ~/.mh_profile Path: Mail inc: -audit .FromList bash-2.05b$ inc -file /tmp/sample.1 Incorporating new mail into inbox... 9+ 07/20 "Bounced mail" Returned mail: Data format error<<This is a mult 10 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF G 11 07/21 "PokerBook Info" Pokerbook Has Gone Public- Huge PR Campaign On I 12 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF G /tmp/sample.1 not zero'd
Wierd. I went two other systems, one was a RedHat 7.x (no, I don't control it) running nmh 1.0.4 plus a different gentoo system and replicated the problem on both. Here is the other gentoo system which I was able to replicate the problem. Gentoo Base System version 1.4.16 Portage 2.0.50-r9 (default-x86-1.4, gcc-3.3.3, glibc-2.3.3.20040420-r0, 2.4.26-gentoo-r3) ================================================================= System uname: 2.4.26-gentoo-r3 i686 AMD Athlon(TM) XP 1800+ Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.1/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://mirror.datapipe.net/gentoo http://gentoo.mirrors.pair.com/ ftp://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://mirror.datapipe.net/gentoo http://mirrors.tds.net/gentoo ftp://ftp.ussg.iu.edu/pub/linux/gentoo http://open-systems.ufl.edu/mirrors/gentoo http://gentoo.mirrored.ca/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X aalib alsa apm arts avi berkdb cdr crypt cups encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib java jpeg kde libg++ libwww mad mikmod motif mozilla mpeg ncurses nls oggvorbis opengl oss pam pdflib perl png postgres python qt quicktime readline sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
OK. I tracked down the probable reason why you are not getting the coredump. I ran my test on yet *another* gentoo system and failed once more to get the crash. My investigation showed that the cause is that a stat of a newly created file on that system obtained a st_blksize of 131072 I was quite pleased to have the compile a debugging version of glibc in order to track down how this was getting set :-( oldimap root> stat /home/xxxx/Mail/inbox/9 File: `/home/xxxx/Mail/inbox/9' Size: 0 Blocks: 0 IO Block: 131072 regular empty file Device: 803h/2051d Inode: 395584 Links: 1 Access: (0600/-rw-------) Uid: ( 0/ root) Gid: ( 500/ UNKNOWN) Access: 2004-07-26 18:58:24.373566456 -0400 Modify: 2004-07-26 18:58:24.373566456 -0400 Change: 2004-07-26 18:58:24.373566456 -0400 Whereas on the system which exhibited the coredump, the blocksize is 4K: not root> stat /home/xxxx/Mail/inbox/1 File: `/home/xxxx/Mail/inbox/1' Size: 53175 Blocks: 104 IO Block: 4096 regular file Device: 308h/776d Inode: 137573 Links: 1 Access: (0600/-rw-------) Uid: ( 512/ xxxx) Gid: ( 100/ users) Access: 2004-07-26 18:31:31.000000000 -0400 Modify: 2004-07-26 18:31:31.000000000 -0400 Change: 2004-07-26 18:31:31.000000000 -0400 This changing block size appears to be a "feature" of reiserfs as described in http://lwn.net/Articles/23001/ Thus you should be able to remount some filesystem to test this different blocksize. # This code should considerably speedup file appends in reiserfs, # given that callers would do than in large chunks. In order # to iincerease amount of applications that will do I/O in large # chunks, the "recommended i/o size" st_blksize field in result # returned by stat() is set to 128k. # There are some known-bad applications that break in this case # (ie. start to work very slow or even hang), particularly # kmail 3.04 (and earlier?) (consider upgrading to 3.1+) and # Berkeley DB seems to be at fault. # If you hit a slowdown problem that you believe is related to # increased "recommended i/o size", try to mount your fs with # nolargeio=1 mount option (remount should work too). # Of course in general you should better fix broken apps, not # disable this useful enchancement. For the record, these differences (-auditfile, st_blksize) almost certainly just adjust where the coredump would happen, and do not eliminate it. Also, inspection of the function in question should quickly convince you that it is indeed broken.
I can reproduce this bug on an ext3 partition. Revision bump to nmh-1.0.4-r3 and stable on x86. Thanks.
Sparc : please mark nmh-1.0.4-r3 stable
x86 & sparc stable after langthang's fix of the missing vi sandbox violation.
security: we need to determine if it is exploitable, and if we should issue a GLSA for it.
I note that the data being overflowed can only consist of one character. Probably just "\n" for traditional unix style mailboxen, or ^A for MMDF style mailboxen. This would seemingly reduce the possibilities of an exploit, but I certainly will not guarentee anything--I have not studied all of the users of matchc() or tried to guess what might be near the buffer in memory.
Can't reproduce here: > inc -file sample.1 Create folder "/home/plasmaroo/Mail/inbox"? y Incorporating new mail into inbox... 1+ 07/20 "Bounced mail" Returned mail: Data format error<<This is a multi-part message in MIME format. ------=_N 2 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF GEORGE TETE BILL AND EXCHANGE MANAGER, AF 3 07/21 "PokerBook Info" Pokerbook Has Gone Public- Huge PR Campaign On Its Way<<This is a multi-part message in 4 07/21 "Dr George Tete" FROM THE DESK OF GEORGE TETE<<FROM THE DESK OF GEORGE TETE BILL AND EXCHANGE MANAGER, A /home/plasmaroo/sample.1 not zero'd > stat Mail/inbox/4 File: `Mail/inbox/4' Size: 4135 Blocks: 16 IO Block: 4096 regular file Device: 901h/2305d Inode: 195507 Links: 1 Access: (0600/-rw-------) Uid: ( 1000/plasmaroo) Gid: ( 10/ wheel) Access: 2004-08-08 16:06:16.784586584 +0100 Modify: 2004-08-08 16:06:16.784586584 +0100 Change: 2004-08-08 16:06:16.784586584 +0100
> Can't reproduce here: > > inc -file sample.1 > Create folder "/home/plasmaroo/Mail/inbox"? y > Incorporating new mail into inbox... Hmm. I assume that you are using the older MH stuff. Did you have the -audit flag set? I believe you can put it on the command line as an alternate to the .mh_profile entry. echo "inc: -audit .FromList" >> ~/.mh_profile
Closing withoug GLSA. Seems unlikely that this can be exploited. Feel free to reopen and provide information for a GLSA.
