#94 security hole squirrelmail mails real userid

closed-fixed
None
1
2005-05-22
2003-11-22
Douglas Campbell
No

When sending composed mail, Squirrelmail 1.4.2
generates a "Received" line which contains a valid
login id and may contain a valid internal network
address for the system upon which it is run. Such
information is useful to hackers and should not
generally be made public.

Possible solution is to modify code in
Deliver.class.php at or about line 260 to remove
generation of the "Received" line associated with the
"SquirrelMail authenticated user". Note that the MTA
will generate a separate "Received" line indicating
reception of the mail from SquirrelMail (using the less
sensitive userid "apache" and the MTA's translation of
its hostname); hence the SquirrelMail-generated
"Received" line is redundant.

Discussion

1 2 3 > >> (Page 1 of 3)
  • Tomas Kuliavas
    Tomas Kuliavas
    2003-11-24

    Logged In: YES
    user_id=225877

    how do you make difference between user that uses
    unclesmrgol@domain.tld and user that sets
    unclesmrgol@domain.tld in user preferences.

     
  • Logged In: YES
    user_id=915040

    The affected line does NOT utilize any information set in
    squirrelmail options menu. For example, my e-mail address
    as set in options is unclesmrgol@domain.tld, but my real
    login id is wahoo. You will see text wahoo in received
    line, not the text specified in options. One way would be
    to use text obtained from options, but that opens way for
    one use to masquerade as another. But using an actual
    loginid from system is big security hole. Hence, one must
    use substitute for real userid which is related to the real
    userid. An obvious substitute, for those using sendmail, is
    for squirrelmail loginid to be a virtual user as specified
    in virtusertable, and to map that virtual user inside
    squirrelmail to the actual loginid for imap purposes. I
    don't know much about other MTAs, but since they are all
    trying to replace sendmail (the primal MTA), they should
    also implement virtusertable somehow.

    In addition, the offending received line contains the IP
    address of a location on the internal network where
    squirrelmail is being run. That is yet another security
    breach -- the topology of the internal network should never
    be visible to the Internet.

    My temporary solution, as stated above, is to remove the
    offending internal "Received" from the header until a more
    formal solution which addresses these issues can be defined
    I have implemented that solution on my mailserver and it works.

     
  • Logged In: YES
    user_id=915040

    Previous solution somewhat incorrect. Assumes squirrelmail
    knows about MTA configuration. We need a solution that lets
    us validate what user has entered in options menu against
    loginid, and then to substitute stuff in options menu for
    login id. I know how I'd do this on my own system (build
    special sql database pushed from mta machine to httpd
    machine, with data in virtusertable in form usable by
    squirrelmail), but don't know if that solution is general
    enough for squirrelmail community.

     
  • Tomas Kuliavas
    Tomas Kuliavas
    2003-11-25

    Logged In: YES
    user_id=225877

    This is not security bug. This is security feature.

    different example:

    You have two users. wahoo (you) and user2 (me). user2 logins
    into your mail system. changes his preferences to
    <you@domain.tld> and send insulting letter to your boss. How
    do to tell that this letter was send by me? Your webmail
    does not provide any headers that show my user id or ip
    address that i've used. Email comes the same way as your
    regular weekly reports. Same server, same email address,
    similar headers.

    I do that at the same time, when you are reading your mail.
    So imap logs show both users. You can check times of email
    and webserver access, but small problem there are n more
    users that worked with your server at that moment and your
    logs are huge. You say it was me, I say that I don't
    understand that you talking about. That day I just read
    couple of emails I've got and wrote one email to my gramma.
    Here it is, your server logged it. It is in my INBOX.Sent
    too and there is no email addressed to your boss.

    If I had to use system that does some tracking, I would have
    to use different email server. Then you can explain your
    boss that all your emails come from company's server and
    this was not your post.

    Any email that reaches sendmail or smtp comes from
    webserver's user. Webmail system has to use some information
    to track the user. It is possible that you can track users
    with some sendmail feature. But there are different email
    system setups.

    Webmail system works with IMAP server, not with SMTP server.
    System can track username that was used during login to IMAP
    server. Username is verified by user's authentication. Any
    other information would depend on your email system setup or
    is controlled by user.

    Leave the header on. If you want to hide information about
    posting ip address and username - mangle the header. Make it
    unreadable for people, that do not know "magic words" that
    decode information. Admin has to be able to detect which
    webmail user posted email and what ip address was used.

    user2 can send email not to your boss. He can send it to
    G.W.Bush or CIA. How do you tell which user used your
    webmail to send threats to national security?

     
  • Logged In: YES
    user_id=915040

    It is both a bug and a feature. I did try changing my from
    in options to unclesmrgol@ibm.com (i have no association
    with ibm) and my mailserver successfully sent the mail (in
    spite of not being configured to open relay, because the
    machine I tried this on was a trusted part of my internal
    network and hence able to relay).

    The bug part is when a userid usable for login escapes onto
    the Internet. The feature part is when the userid is used
    as authentication of an individual person. I'm saying below
    that you can get the same results without exposing an
    internal userid to the Internet by putting some
    authentication behind the options page, such that the only
    email addresses you can specify on the from line in options
    are ones your actual loginid maps to in a virtual user
    table. After which, the only stuff displayed on the
    Received: line is the from address specified in options and
    the name (not IP address) of the internal machine.

    I stand by my assertion that as things are, this is a
    security flaw in squirrelmail as much as your assertion that
    stuff specified in the options page is unverified by
    squirrelmail prior to its use.

     
  • Logged In: YES
    user_id=915040

    Nothing in the header is true, not even the to: line.
    Everything else can be (and has been) falsified by hackers,
    most notably the spammers that plague us all.

    Unfortunately, the only object that knows truth about an
    e-mail at present is the MTA. It knows the IP address of
    the originating machine (from the foreign address part of
    the connect()), and it knows the envelope recipient.

    Squirrelmail needs a valid loginid and password to
    authenticate to the IMAP server. The problem is that
    squirrelmail communicates one half of that privileged
    information to the Internet. So it knows some truth about a
    given user as well, but not something it ought to tell
    anyone. The big question is: Is there some way we can
    allow squirrelmail to do what it needs to do without
    revealing sensitive information?

     
  • Logged In: YES
    user_id=915040

    Previous solution somewhat incorrect. Assumes squirrelmail
    knows about MTA configuration. We need a solution that lets
    us validate what user has entered in options menu against
    loginid, and then to substitute stuff in options menu for
    login id. I know how I'd do this on my own system (build
    special sql database pushed from mta machine to httpd
    machine, with data in virtusertable in form usable by
    squirrelmail), but don't know if that solution is general
    enough for squirrelmail community.

     
  • Tomas Kuliavas
    Tomas Kuliavas
    2003-12-06

    Logged In: YES
    user_id=225877

    Patch provides functions that replace Recieved: line that
    contains username and ip address with X-Hashed-Addr and
    X-Hashed-Username headers.

    Crypto uses twoway complex rot encoding and salting.

    sample script that decodes string is provided.

    This is preliminary version. I still want to improve
    decoding, salting and forwarded from header. It is possible
    that it can be made in some better way.

    Patch is written for SquirrelMail v.1.4.2. You have to
    enable hashing by setting $hide_userdata in
    class/deliver/Deliver.class.php and changing $secret

     
  • Stefan Sels
    Stefan Sels
    2003-12-06

    Logged In: YES
    user_id=81026

    work in progress, see 847240 also

     
  • Stefan Sels
    Stefan Sels
    2003-12-06

    • assigned_to: nobody --> centaurix
    • status: open --> open-accepted
     
1 2 3 > >> (Page 1 of 3)