From:	 Daniel Roethlisberger <daniel@roe.ch>
To:	 bugtraq@securityfocus.com
Subject: POP3Lite 0.2.3b minor client side DoS and message injection
Date:	 Mon, 3 Sep 2001 03:43:45 +0200


vulnerable
        POP3Lite <= 0.2.3b

not vulnerable
        POP3Lite >= 0.2.4

        

abstract

        POP3Lite is a modular POP3 daemon developed to be fast,
flexible and easy to use. It runs on Linux and *BSD.

POP3Lite fails to escape dots in messages it transfers to clients.
Clients popping their mail from a vulnerable POP3Lite can be sent
arbitrary server responses embedded in carefully crafted emails,
possibly leading to arbitrary message injection, lost messages, or
otherwise annoying client misbehaviour.



details

        POP3Lite 0.2.3b does not escape leading dots, as defined
in RFC 1939. This means that dots heading a line will be stripped
away by the client. Worse, message lines containing a single dot,
ie. the sequence CRLF.CRLF, are correctly misinterpreted as end of
message. The following line is then interpreted as the answer from
the server, causing most clients to abort mail transfer believing
an error occured. Depending on the client, this can result in no
messages being deleted from the server, which is quite a problem
for a non-technical user to resolve on his own.

However, apart from clients choking on email containing dots,
legit or not, it is possible for an email sender to inject
arbitrary server answers into the POP3 session of the target.
Assuming that the client will do the usual RETR DELE RETR etc.,
one can cause subsequent messages to be deleted from the server
even though the client never received them. We can even inject
arbitrary messages into the client. This means we can actually
fake anything we want, including fully constructed headers,
leaving no traces at all in the header of the faked mail.

In combination with anonymous email services such as Mixmaster all
this can be done completely anonymously. Apart of our trojaned
message, truncated at the CRLF dot CRLF, there will be no traces.
Make it look like spam and the user will happily hit delete on his
only piece of evidence with intact, real headers...

To illustrate this, imagine this message being sent to a victim
getting mail from a vulnerable POP3Lite:

  Date: Wed, 29 Aug 2001 19:31:41 -0400
  From: "Cash Plan" <cashplan62@hotmail.com>
  To: victim@victim.net
  Subject: DAILY CASH PLAN & COMPLETE BUSINESS SYSTEM

  Your DAILY CASH PLAN & COMPLETE BUSINESS SYSTEM
  THIS IS REAL !!  ON CD ROM!!

  ----FREE---------- FREE-------------- FREE--------------- FREE-----
  Stealth Mail Bomber " unlocked " No Registration Required
     Retails for $300 and up "This Bulk e-mail software will
                  ** EXPLODE YOUR BUSINESS **
  NO Tricks, NO Gimmicks, NO Changing Long Distance Carriers, NO Games
  ----FREE---------- FREE-------------- FREE--------------- FREE-----

  .
  +OK message deleted
  +OK 1234 octets
  Received: from mail.anything.com (123.123.123.123)
    by mail.victim.net with SMTP; 1 Apr 2001 00:42:00 -0000
  Date: Sat, 1 Apr 2001 00:23:00 -0000
  From: anyone@anything.com
  To: victim@victim.net
  Subject: anything

  bloerps

After the bloerps, POP3Lite will send a dot, indicating the end of
the message. However, the client already interpreted the first,
unescaped dot as end of message. For the client, the second, real
EOM sequence will mark the end of the injected message. The client
and server communication will continue, but the client will always
be one message "behind". The last message on the server will get
lost, instead there will be the injected message in the client.
The remnant of the trojaned message looks just like ordinary spam
now, and will surely be deleted. The exact client behaviour might
vary with clients, but this should work in one form or another
with any RFC compliant client.

In the unlikely case of POP3 clients with some kind of input
validation problem in the server response handling, it would of
course be possible to exploit them through (possibly anonymous)
email, too.



remedy

        Gergely Nagy <algernon@debian.org>, maintainer of
POP3Lite, has immediately fixed the problem upon notification,
and released the fixed POP3Lite 0.2.4 on August 23rd. Latest
source and binary distributions are available from:

  ftp://pop3lite.sourceforge.net/pub/pop3lite/

Fixed .deb's have been included in Debian unstable for some days
now. Debian testing still had a 0.2.3 last time I checked, and
stable does not include POP3Lite so far. I have no idea whether
other distributions ship it at all.

The problem is present in 0.2.3b, and probably some releases
before that. The author says the escaping was in there at some
point, but must have been accidentally removed later on. I do not
know which older versions had it, and which did not. Best update
to the latest release in any case.



Cheers,
Dan


-- 
   Daniel Roethlisberger <daniel@roe.ch>
   PGP Key ID 0x8DE543ED with fingerprint
   6C10 83D7 2BB8 D908 10AE  7FA3 0779 0355 8DE5 43ED