OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Daniel Roethlisberger (danielroe.ch)
Date: Sun Sep 02 2001 - 20:43:45 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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" <cashplan62hotmail.com>
      To: victimvictim.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: anyoneanything.com
      To: victimvictim.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 <algernondebian.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 <danielroe.ch>
       PGP Key ID 0x8DE543ED with fingerprint
       6C10 83D7 2BB8 D908 10AE  7FA3 0779 0355 8DE5 43ED