Re: How to run fetchmail as daemon at startup
On Wed, 4 Apr 2007 20:22:55 +0200
Michelle Konzack <linux4michelle@freenet.de> wrote:
> Am 2007-03-23 09:38:31, schrieb Celejar:
> > > I do not like some of the design choices which were made with fetchmail.
> > > getmail does things a little differently, and for my purposes, better. In
> > > addition, most people find getmail easier to configure and use than
> > > fetchmail. Perhaps most importantly, getmail goes to great lengths to
> > > ensure that mail is never lost, while fetchmail (in its default
> > > configuration) frequently loses mail, causes mail loops, bounces
> > > legitimate messages, and causes many other problems.
>
> This is typical Bernstein bullshit!
?? The quote is Charles Cazabon's, not Dan Bernstein's.
>
> 1) I have never lost any messages since 1999/03
> 2) Never gotten mail loops
> (How can they if fetchmail fetch only messages)
> 3) Bounces are only done by the MTA or MDA not by fetchmail.
> 4) Which other problems?
>
> > > When people have pointed out problems in fetchmail's design and
> > > implementation, it's maintainer has frequently ignored them, or (worse
>
> What was ignored?
>
> > > yet) gone in the completely wrong direction in the name of "fixing" the
> > > problems. For instance, fetchmail's configuration file syntax has been
> > > criticized as being needlessly difficult to write; instead of cleaning up
> > > the syntax, the maintainer instead included a GUI
>
> Where is the problem with the syntax?
>
> > > configuration-file-writing program, leading to comments like:
>
> I do not like fetchmail-conf so I do not use it...
> I have my OWN X-GUI which I like since it do want I want!
>
> > > The punchline is that fetchmail sucks, even if it does have
> > > giddily-engineered whizbang configurator apps.
>
> No explanation WHY it sucks!
Cazabon is explaining, both before and after this comment, why he
thinks it sucks; your comment makes no sense. [Of course, you can
disagree that it sucks, but it's just plain silly and / or dishonest to
accuse him of offering "no explanation why it sucks"].
> > > As an example, Dan Bernstein, author of qmail and other software packages,
> > > once noted to the qmail list:
> > >
> > > Last night, root@xxxxxxxxxxxxxxxxx reinjected thirty old messages from
> > > various authors to qmail@xxxxxxxxxxxxxx
> > >
> > > This sort of idiocy happens much more often than most subscribers know,
> > > thanks to a broken piece of software by Eric Raymond called fetchmail.
> > > Fortunately, qmail and ezmlm have loop-prevention mechanisms that stop
> > > these messages before they are distributed to subscribers. The messages
> > > end up bouncing to the wrong place, thanks to another fetchmail bug, but
> > > at least the mailing list is protected.
>
> Not right, this is definitivly a bug in qmail!
> Which IS proved!
Proved by whom? What's the proof? Cite?
> > > --D. J. Bernstein
> > >
> > > The maintainer also ignored dozens of complaints about fetchmail's
> > > behaviour, stating (by fiat) that fetchmail was bug-free and had entered
> > > "maintenance mode", allowing him to ignore further bug reports.
>
> ??? fetchmail is actively developed and
> gotten many enhancements since 1999/03
New devs have apparently taken over fetchmail development [1]. They
themselves admit that:
> Fetchmail was handed over in a pretty poor shape, security-wise. It will happily talk to the network with root privileges, use sscanf() to read remotely received data into fixed-length stack-based buffers without length limitation and so on. A full audit is required and security concepts will have to be applied. Random bits are:
>
> * code talking to the network does not require root privileges and needs to run without root permissions
> * all input must be validated, all strings must be length checked, all integers range checked
> * all types will need to be reviewed whether they are signed or unsigned
> > > fetchmail's default configuration values frequently cause lost or
> > > misdirected mail, and seem to be chosen to cause maximum pain and
> > > inconvenience. From fetchmail's to-do file (emphasis mine):
> >
> > > Maybe refuse multidrop configuration unless "envelope" is _explicitly_
> > > configured ... This would prevent a significant class of
> > > shoot-self-in-foot problems.
>
> This happen since most ISP's do not know HOW to do multidrop.
> D.J. Bernstein should read the RFC's adgain!
>
> > > perhaps treat a delivery as "temporarily failed" ... This is so you
> > > don't lose mail if you configure the wrong envelope header.
>
> Never gotten such problems...
>
> > > fetchmail is famous for mangling messages it retrieves, rather than
> > > leaving them alone as a mail-handling program should. getmail will add
> > > trace information to messages (so you can see what happened, and when),
> > > but will otherwise leave message content alone.
>
> I have never a mangled messages and do not know,
> what bullshit he is talking about..
>
> > > In addition, fetchmail has a long history of security problems:
> > >
> > > * versions released before 20 June 2001 contain a buffer overflow, which
> > > can be remotely exploited (see www.securityfocus.com/bid/2877 for
> > > details). getmail is not vulnerable to buffer overflows, because
> > > buffers in Python are dynamically sized.
>
> Who use this old releases?
It is reasonable to be distrust an app with a long history of security
flaws, and see again the above quote from the new devs about the poor
security condition of fetchmail when they took it over. [The quote is
apparently from 2006, and IIUC, they imply that they have not quite
whipped it into shape yet. I may be misreading, though.]
> > > * Another remotely-exploitable security hole discovered in fetchmail in
> > > June 2002; versions prior to 5.9.10 (released in June 2002) are
> > > exploitable .
>
> Which?
CVE-2002-0146 [2]:
> fetchmail email client before 5.9.10 does not properly limit the maximum number of messages available, which allows a remote IMAP server to overwrite memory via a message count that exceeds the boundaries of an array.
> > > * Reading fetchmail's UPDATES file, it appears that another security
> > > problem was fixed in 5.9.12, where a server could crash fetchmail on
> > > 64-bit platforms. Also worrying is a mention that it includes a fix
> > > for "password shrouding".
>
> And? Getmail was crashing too on 64Bit (Opteron)!
Cite?
> > > * Another remotely-exploitable security hole in fetchmail discovered in
> > > September 2002; this hole lets an attacker run arbitrary code on the
> > > victim's computer.
>
> Oh... getmail had flaws too...
Namely?
> > > * Another remotely-exploitable security hole in fetchmail discovered in
> > > December 2002; once again, a remote attacker can run arbitrary code on
> > > the machine running fetchmail in its default configuration. See this
> > > advisory for details.
>
> Was very fast solved!
Wonderful.
> > > * January 2003: More buffer overflows in fetchmail let attackers run
> > > arbitrary code .
> > > * October 2003: Anyone can cause fetchmail to crash by sending you a
> > > message . Other problems are here , and I might have missed some .
>
> How this? -- I fetch per day over 400.000 Messages on my Intranet Server
> and it haver happen for many years.
>
> > > * Just in case you thought fetchmail was all better now, there's still
> > > new security problems being discovered in it. In December, 2005, it
> > > was revealed that anyone can send a fetchmail multidrop user a message
> > > that causes fetchmail to crash.
>
> HOW and WHERE?
You know, Michelle, you might want to do at least *some* research before
just spouting off. A brief glance at CVE finds this [3]:
> fetchmail before 6.3.1 and before 6.2.5.5, when configured for multidrop mode, allows remote attackers to cause a denial of service (application crash) by sending messages without headers from upstream mail servers.
>
> > > In July, 2004, it was noted that there may be at least 2 unfixed
> > > denial-of-service attacks, 2 unfixed remote-code-execution, 2 unfixed
> > > remote-user-access, and 3 unfixed remote-shell attacks against fetchmail.
> > > See http://www.mail-archive.com/euglug@euglug.org/msg00971.html for
> > > details
>
> Those are bullshit!
> I have tested and it does not happen since I use Debian/Woody (5.9.11)!!!
You have done pen testing and are absolutely convinced that the
Security Focus and CVE stuff is / was bogus?
> > > I've given up even trying to stay abreast of the various security holes in
> > > fetchmail, but others have noted continuing problems, including:
> > >
> > > * another arbitrary code execution vulnerability announced on 21 July
> > > 2005.
> > >
> > > The fetchmail authors' boneheaded decision to create a configuration-file
> > > GUI editor (rather than actually giving fetchmail a sane configuration
> > > syntax) also came back to bite them in the ass: in October 2005, it became
>
> The Syntax is working correctly!
Perhaps correctly as in according to spec, but do you mean 'sane' as in
intuitive and logical?
> > > known that fetchmailconf created its files in such a way that users'
> > > passwords could be read during file creation.
>
> I do not know about this...
It's on the Fetchmail home page [0]!
CVE-2005-3088: Fetchmailconf was found to open the configuration files
world-readable, writing data to them, and only then tightening up
permissions, which may cause password information to be visible to
other users. This bug affected fetchmail 6.2.0, 6.2.5 and 6.2.5.2. The
bug is fixed in fetchmail 6.2.5.4 and 6.3.0.
>
> > > But don't just take my word for it; see
> > > http://docs.freebsd.org/cgi/mid.cgi?200102172349.QAA11724 and
> > > http://esr.1accesshost.com/.
>
> Blahblah!
>
> > > getmail users have not had to worry about any of these security holes or
> > > design and implementation errors.
>
> "getmail" has lost many messages while I have tried out it on a test-server.
Has anyone else reported problems? I'd like to see some corroboration
and more details.
Celejar
[0] http://fetchmail.berlios.de/
[1] http://www.fetchmail.info/design-notes.html
[2] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2002-0146
[3] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4348
Reply to: