Menu
▾
▴
#94 security hole squirrelmail mails real userid
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.
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.
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.
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
Logged In: YES
user_id=81026
work in progress, see 847240 also
Logged In: YES
user_id=915040
Sounds good to me. I've downloaded your diff, will apply
it, and observe what happens.
Logged In: YES
user_id=225877
correction.
onetimepadencrypt function can be used to encrypt userid.
only passphrase is used instead of one time pad.
Logged In: YES
user_id=225877
Patch for 1.5.1cvs attached. Will write patch for stable
version tomorrow.
If you want to keep $skip_SM_header option, then mark it as
unacceptable for stable version and use only
hide_auth_header.diff for stable. $skip_SM_header=true is
too dangerous to novice admins. Only mad people keep loaded
guns next to children.
patch for devel
simple patch for stable
Logged In: YES
user_id=225877
fixed in SquirrelMail 1.4.5cvs. Used patch is attached.
final patch
Logged In: YES
user_id=1128943
Originator: NO
Using OneTimePadEncrypt to encrypt the header lets any user retrieve the value for the encode_header_key variable. As soon as the encrypted plaintext is known, (plain) ^ (crypt) shows the passwort.