Re: [Imap-uw] Possible buffer overflow in mailutil
After completing a major update of our NetApp NFS mounted mbox format based mail system over a year ago to iSCSI based MIX folders (behind a perdition proxy) I have no desire to switch again from something that is working perfectly for 60K users. Panda imap was available to me when I simply asked Mark if I could have a copy of it. He said sure and then told me his super secret way of obscuring the download point :-) Perhaps you need to ask more directly as I did, at least it worked for me. Who knows how things will change a year from now so unless your still using mbox format I see no reason to make work for myself just yet. David Chris Picciotto wrote: But Panda imap is simply not available. Therefore, UW-Imap is effectively non-existent. I was a long time fan of UW-imap, but Dovecot (with maildir backend) is probably the way go. My 2 cents. -Original Message- From: imap-uw-boun...@mailman2.u.washington.edu [mailto:imap-uw-boun...@mailman2.u.washington.edu] On Behalf Of Mark Crispin Sent: Sunday, May 31, 2009 5:50 PM To: Aaron W. LaFramboise Cc: UW IMAP Software Interest List Subject: Re: [Imap-uw] Possible buffer overflow in mailutil On Sun, 31 May 2009, Aaron W. LaFramboise wrote: Given this state of affairs, is there some particular piece of software that you would recommend we switch to? Panda IMAP: http://panda.com/imap/ Cyrus IMAP: http://cyrusimap.web.cmu.edu/ Dovecot: http://www.dovecot.org/ The author of Dovecot has some protocol compliance information that is of interest: http://imapwiki.org/ImapTest/ServerStatus -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw -- David Severance Network and Academic Computing Services (949) 824-7552 s...@uci.edu ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
RE: [Imap-uw] Possible buffer overflow in mailutil
On Sun, 31 May 2009, Chris Picciotto wrote: But Panda imap is simply not available. Several sites run Panda IMAP. It is available. Therefore, UW-Imap is effectively non-existent. The one statement does not follow from the other, but that doesn't matter. UW is indeed out of the IMAP business; and pretty much out of the open standards email business as well. I was a long time fan of UW-imap, but Dovecot (with maildir backend) is probably the way go. Dovecot is a reasonable choice. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
On Mon, 1 Jun 2009, Mike Peachey wrote: While I don't personally advocate its use, I find it hilarious you failed to mention Courier IMAP :) Courier is quite non-compliant with the IMAP specification: http://imapwiki.org/ImapTest/ServerStatus Its author is on record as refusing to fix these problems. Cyrus has some issues as well, but not as bad and most have subsequently been fixed. If he had asked about commercial servers, I would have included Isode M-Box and CommuniGate Pro. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
Mon 01 Jun 2009 04:49:30 GMT Mark Crispin wrote: > On Sun, 31 May 2009, Aaron W. LaFramboise wrote: >> Given this state of affairs, is there some particular piece of >> software that you would recommend we switch to? > > Panda IMAP: > http://panda.com/imap/ > > Cyrus IMAP: > http://cyrusimap.web.cmu.edu/ > > Dovecot: > http://www.dovecot.org/ While I don't personally advocate its use, I find it hilarious you failed to mention Courier IMAP :) FWIW after months of investigations I settled on Dovecot. -- Kind Regards, __ Mike Peachey, IT Tel: +44 114 281 2655 Fax: +44 114 281 2951 Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371 - Registered In England http://www.jennic.com __ ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
RE: [Imap-uw] Possible buffer overflow in mailutil
But Panda imap is simply not available. Therefore, UW-Imap is effectively non-existent. I was a long time fan of UW-imap, but Dovecot (with maildir backend) is probably the way go. My 2 cents. -Original Message- From: imap-uw-boun...@mailman2.u.washington.edu [mailto:imap-uw-boun...@mailman2.u.washington.edu] On Behalf Of Mark Crispin Sent: Sunday, May 31, 2009 5:50 PM To: Aaron W. LaFramboise Cc: UW IMAP Software Interest List Subject: Re: [Imap-uw] Possible buffer overflow in mailutil On Sun, 31 May 2009, Aaron W. LaFramboise wrote: > Given this state of affairs, is there some particular piece of software that > you would recommend we switch to? Panda IMAP: http://panda.com/imap/ Cyrus IMAP: http://cyrusimap.web.cmu.edu/ Dovecot: http://www.dovecot.org/ The author of Dovecot has some protocol compliance information that is of interest: http://imapwiki.org/ImapTest/ServerStatus -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
On Sun, 31 May 2009, Aaron W. LaFramboise wrote: Given this state of affairs, is there some particular piece of software that you would recommend we switch to? Panda IMAP: http://panda.com/imap/ Cyrus IMAP: http://cyrusimap.web.cmu.edu/ Dovecot: http://www.dovecot.org/ The author of Dovecot has some protocol compliance information that is of interest: http://imapwiki.org/ImapTest/ServerStatus -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
Mark Crispin wrote: Given this and the fact that UW IMAP is a dead project, I think that it's pretty silly to worry about this particular issue. OK, this is probably as strong as a signal as I'm going to get that its time to abandon ship. Over the past year, there appears to have been no serious efforts to continue UW IMAP on a collaborative open source basis. Given this state of affairs, is there some particular piece of software that you would recommend we switch to? ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
On Thu, 28 May 2009, Bjoern Voigt wrote: My question is: Are you planning to write a fix or do you plan to accept a fix for the buffer overflow bug? I have nothing to do with fixing bugs in UW IMAP, and have had nothing to do with that for over a year. There are more serious problems that have discovered in UW IMAP since development ended a year ago, yet remained unfixed: http://panda.com/imap Given this and the fact that UW IMAP is a dead project, I think that it's pretty silly to worry about this particular issue. As far as Linux distributions go, I think that they too have more important things to fix. For example: I just spent the past 12 hours repeatedly rebooting (via power cycle) a 64-bit Linux system because Ubuntu switched to a new whiz-bang audio driver that can lock up the CPU. Numerous applications became slower (in the case of one rendering engine, three orders of magnitude slower!) in newer versions of Linux because some pinhead "improved" glibc so that threading mutexes are in place even when the application is not built to do threading. If you're lucky, the man pages were updated to tell you about the xxx_unlocked() variants that don't do these useless mutexes. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
Mark Crispin wrote: > On Wed, 27 May 2009, Bjoern Voigt wrote: >> Anyway, I think, the bug should be fixed for the next release of UW >> Imap, Alpine etc. Who can do this? I can help with a patch and with some >> testing it this is helpful. > > I fail to see why this is important. The fix is obvious and trival, > but I don't see why it is worth wasting time. Ok, I did not say, that the bug is important. I said, that Linux with Glibc2 is important. And I said, that I wish that the bug will be fixed in the next release. The bug could be seen as a low priority bug. I can agree with this. > You agree that this is not a security issue; by its nature getpass() > is only usable in shell programs and the interactive prompt makes it > unsuitable for scripts. > > It does not affect Alpine. It only affects mtest (which has other > issues and is only a sample program) and mailutil. > > mailutil has a 1024 byte buffer. How many people have passwords that > are that long? So the only crash will be if someone deliberately > makes it crash, and to accomplish what purpose? I think, if a user can crash an application with a special input, the program has a bug. We are in the good situation, that the bug is low priority, that the bug is not security related and that it is trivial to fix it. But I wonder a bit about this discussion. I believe that fixing the buffer overflow with a simple replacement of strcpy() with strncpy() in function mm_login, a bit testing and writing a commit message takes less time than this discussion. ;-) Fixing the Solaris 10 problem would take a bit more time for me, because I haven't already incorporated into the OS-dependency things in UW-Imapd. Tim wrote that UW probably no longer maintains UW Imapd and Alpine. So, is there a plan how new versions of Alpine and UW Imapd will be released? My question is: Are you planning to write a fix or do you plan to accept a fix for the buffer overflow bug? If I know this, we may want to decide, if it's reasonable to write bug reports for some Linux distributions (I have openSUSE and Ubuntu) and for Solaris. Greetings, Björn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
On Wed, 27 May 2009, Bjoern Voigt wrote: Anyway, I think, the bug should be fixed for the next release of UW Imap, Alpine etc. Who can do this? I can help with a patch and with some testing it this is helpful. I fail to see why this is important. The fix is obvious and trival, but I don't see why it is worth wasting time. You agree that this is not a security issue; by its nature getpass() is only usable in shell programs and the interactive prompt makes it unsuitable for scripts. It does not affect Alpine. It only affects mtest (which has other issues and is only a sample program) and mailutil. mailutil has a 1024 byte buffer. How many people have passwords that are that long? So the only crash will be if someone deliberately makes it crash, and to accomplish what purpose? -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
In regard to: Re: [Imap-uw] Possible buffer overflow in mailutil, Bjoern...: Mark Crispin wrote: Thank you for reporting this. This is only an issue in glibc2 on some Linux systems. In other C libraries, the data returned by getpass() is limited to PASS_MAX. The author of glibc2 apparently thought that it would help his ideology to abolish the use of such functions by making glibc2's getpass() return a limitless string. Yes, but Linux and Glibc2 are important. I also found that getpass() works different on different systems. On Solaris 10 getpass() only returns at most 8 characters! So getpass() seems to be an unusable function on Solaris 10, but this is another aspect of the problem. Until the late 90s, most UNIX systems only supported a maximum of 8 characters for the password (you could input more, but only the first 8 were significant). getpass() originated from those days, so it will return a maximum of 8 characters. On Solaris, there's a getpassword() function that will return more. The 8 character limit is gone on most modern systems. Anyway, I think, the bug should be fixed for the next release of UW Imap, Alpine etc. Who can do this? I can help with a patch and with some testing it this is helpful. UW laid off quite a few staff last year because of budget issues, and IMAPd and alpine have been greatly impacted because of that. At the time the layoffs were announced, it seemed that UW IMAP and Alpine probably would no longer be maintained by UW. I don't know if that's changed at all, but with Mark gone UW IMAP certainly isn't seeing the kind of attention it had before. Mark has his own fork of UW IMAP now. If an IMAP daemon compatible with UW IMAPd is important to you and you have the budget, you might want to consider that version. He's made a number of improvements to his version that are not present in UW IMAPd. Tim -- Tim Mooney moo...@dogbert.cc.ndsu.nodak.edu Enterprise Computing & Infrastructure 701-231-1076 (Voice) Room 242-J6, IACC Building 701-231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
Mark Crispin wrote:
> Thank you for reporting this.
>
> This is only an issue in glibc2 on some Linux systems. In other C
> libraries, the data returned by getpass() is limited to PASS_MAX. The
> author of glibc2 apparently thought that it would help his ideology to
> abolish the use of such functions by making glibc2's getpass() return
> a limitless string.
Yes, but Linux and Glibc2 are important. I also found that getpass()
works different on different systems. On Solaris 10 getpass() only
returns at most 8 characters! So getpass() seems to be an unusable
function on Solaris 10, but this is another aspect of the problem.
You can find out, how getpass() function works on your system with this
little test program:
#include
#include
int main()
{
printf("You entered: %s\n", getpass("password: "));
return 0;
}
> Since mailutil is an auxillary shell tool and not a security program,
> I don't think that there is a particular priority to protect it from
> user abuse.
Yes, I agree, that this should not be considered as a security problem.
Especially the interactive password prompt makes the tool often unusable
for scripts. (I would like to see a mailutil tool, which uses the
password manager functions of Alpine. Currently I patched mailutil for
my scripting purpose. At this point I also found the problem.)
Anyway, I think, the bug should be fixed for the next release of UW
Imap, Alpine etc. Who can do this? I can help with a patch and with some
testing it this is helpful.
Greetings,
Björn
___
Imap-uw mailing list
Imap-uw@u.washington.edu
http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Possible buffer overflow in mailutil
Thank you for reporting this. This is only an issue in glibc2 on some Linux systems. In other C libraries, the data returned by getpass() is limited to PASS_MAX. The author of glibc2 apparently thought that it would help his ideology to abolish the use of such functions by making glibc2's getpass() return a limitless string. Since mailutil is an auxillary shell tool and not a security program, I don't think that there is a particular priority to protect it from user abuse. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
