Bug 738247 - unwanted information disclosure in message headers

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
Greetings to evolution team!

Just today I wanted to start using the program but uncovered a stopper, listed in subject.
To my huge surprise it has been reported almost three years ago and still completely ignored.

Josh.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Patrick O'Callaghan
On Fri, 2017-09-22 at 14:10 -0400, [hidden email] wrote:
> Greetings to evolution team!
>
> Just today I wanted to start using the program but uncovered a stopper, listed in subject.
> To my huge surprise it has been reported almost three years ago and still completely ignored.

What program? Please give the version you mean (Help->About if you mean
Evolution).

You don't explain what you mean by information disclosure, nor do you
give a reference to the previous report. If you are concerned about
this then kindly take the trouble to clarify.

poc
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
In reply to this post by d18jf98rw
On 09/22/2017 04:54 PM, Patrick O'Callaghan wrote:

>
> On Fri, 2017-09-22 at 14:10 -0400, [hidden email] wrote:
>
>> Greetings to evolution team!
>> Just today I wanted to start using the program but uncovered a stopper,
>> listed in subject.
>> To my huge surprise it has been reported almost three years ago and still
>> completely ignored.
>>
> What program? Please give the version you mean (Help->About if you mean
> Evolution).
> You don't explain what you mean by information disclosure, nor do you
> give a reference to the previous report. If you are concerned about
> this then kindly take the trouble to clarify.


Patrick,

From https://bugzilla.gnome.org/show_bug.cgi?id=738247 I see the following:
====
Product: evolution-data-server
Version: 3.24.x
Problem Description:
Local host name shows up in recipient email headers.
Sent from evolution:
Received: from [external IP] ([external IP:port] helo=myhost.mydomain.ext)

Sent from thunderbird:
Received: from [external IP] ([external IP:port] helo=[local IP])

helo message must be changed to avoid local host name disclosure.
====
Seems like a pretty extensive report. I have nothing to add other then my exact version is 3.24.5.

Josh.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Milan Crha
On Fri, 2017-09-22 at 17:36 -0400, [hidden email] wrote:
> Sent from evolution:
> Received: from [external IP] ([external IP:port]
> helo=myhost.mydomain.ext)
>
> Sent from thunderbird:
> Received: from [external IP] ([external IP:port] helo=[local IP])

        Hi,
what is better on local IP (which can be a public IP too), than using
a local host name, which might not be accessible (resolved) from
the outside? Is there related any shame on the chosen computer name?

I can understand the need to "stay anonymous" for spammers or the like,
but regular good citizens might not have a problem with this, maybe?

Looking around, the SMTP transport uses the name only if
g_resolver_lookup_by_address() returns anything for the address
returned by g_socket_connection_get_local_address(). There is no option
to skip this lookup.
        Bye,
        Milan

P.S.: for some reason, your reply to Patrick doesn't contain headers
for proper threading. Maybe your mail client needs a fix to include
In-Reply-To and References headers in replies. Just saying, no offense
meant.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
 
On Monday, September 25, 2017 3:41 AM, Milan Crha <[hidden email]> wrote:
 
> On Fri, 2017-09-22 at 17:36 -0400, [hidden email] wrote:
>> Sent from evolution:
>> Received: from [external IP] ([external IP:port]
>> helo=myhost.mydomain.ext)
>>
>> Sent from thunderbird:
>> Received: from [external IP] ([external IP:port] helo=[local IP])
> Hi,
> what is better on local IP (which can be a public IP too),

local IP is better.

> than using
> a local host name, which might not be accessible (resolved) from
> the outside? Is there related any shame on the chosen computer name?
>
> I can understand the need to "stay anonymous" for spammers or the like,
> but regular good citizens might not have a problem with this, maybe?

I would like not to discuss anything other then technical details of bug topic which are clear and simple: "unwanted information disclosure".
Simplest example is when a corporate user sends an email using public email server like yahoo/google/aol etc, their fully qualified host name may show up in helo part which is not always what they may want.

> Looking around, the SMTP transport uses the name only if
> g_resolver_lookup_by_address() returns anything for the address
> returned by g_socket_connection_get_local_address().
> There is no option to skip this lookup.
I strongly disagree with this statement because thunderbird does not do host name lookup and always uses IP address in helo part.

According to gnome bugzilla there was a bug 702703 with exactly the same unwanted information disclosure complain and was fixed by you, Milan, four years ago.

Regards,
Josh.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Milan Crha
On Mon, 2017-09-25 at 17:30 -0400, [hidden email] wrote:
> local IP is better.

        Hi,
maybe. It still exposes some details about the network, like what
internal IP range is in use.

I just tried with a Google account and the first Received header
contains "localhost.localdomain" with an IP of my ADSL router, not my
local address, neither my computer name, thus the server can change the
information too, possibly according to reverse DNS lookup. When you
look at this message, then it also doesn't show my local address,
neither the local computer name.

> Simplest example is when a corporate user sends an email using public
> email server like yahoo/google/aol etc, their fully qualified host
> name may show up in helo part which is not always what they may want.

Right, most people probably do not care, or do not know, but some
people do care. That's okay.

> > Looking around, the SMTP transport uses the name only if
> > g_resolver_lookup_by_address() returns anything for the address
> > returned by g_socket_connection_get_local_address().
> > There is no option to skip this lookup.
>
> I strongly disagree with this statement because thunderbird does not
> do host name lookup and always uses IP address in helo part.

I did not speak of Thunderbird, I said what Camel (part of evolution-
data-server) does in the SMTP provider.

> According to gnome bugzilla there was a bug 702703 with exactly the
> same unwanted information disclosure complain and was fixed by you,
> Milan, four years ago.

That was for Message-ID header, not for Received header. As far as I
can tell, that header can be influenced only with SMTP. I do not think
there's anything when using sendmail or an Exchange connector (neither
I tried NNTP).

Just to make it clear, I didn't say it cannot be changed, I even gave
pointers to involved functions in the SMTP Camel provider code, I only
think it's not that important for others as it is for you.

The bug 738247 has only the reporter, no duplicates, no CC'ed other
than Andre, whom takes care of bug triage, thus he doesn't count (I'm
sorry, Andre). Being there higher demand, it is fixed earlier probably,
but you see it's almost 3 years old and nobody else had been interested
to support the idea. In any case, feel free to propose a patch, that
may speed things up and you get credits for the fix. It might be as
simple as not resolve the local address. Then you can also try whether
it'll make any difference for the findings from the very top of this
email, because it's possible the change will not change anything (at
least for some servers).
        Bye,
        Milan
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
 
On Tuesday, September 26, 2017 2:31 AM, Milan Crha <[hidden email]> wrote:
 
> On Mon, 2017-09-25 at 17:30 -0400, [hidden email] wrote:
>> local IP is better.
> Hi,
> maybe. It still exposes some details about the network, like what
> internal IP range is in use.
exposing internal range is much safer then real hostname, in my opinion.
 
> I just tried with a Google account and the first Received header
> contains "localhost.localdomain" with an IP of my ADSL router, not my
Correct, your workstation does not have host name setup and by default it
sends "localhost.localdomain".
Change host name to abc.example.org and you'll see it in recipient's headers.
It means that if you send email to someone using your personal gmail AND property configured office workstation your email recipient will be able to tell where you work, this is just an example.

Where is the function responsible for helo message?

Regards,
Josh.

PS. The fact that pretty much nobody was ever interested in both unwanted information disclosure bugs just speaks for very little interest serious users have in evolution. I can only imagine what happens if someone decides to do a real audit...
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Milan Crha
On Tue, 2017-09-26 at 09:53 -0400, [hidden email] wrote:
> Where is the function responsible for helo message?

        Hi,
it's here:
https://git.gnome.org/browse/evolution-data-server/tree/src/camel/providers/smtp/camel-smtp-transport.c?h=gnome-3-24#n1388

> PS. The fact that pretty much nobody was ever interested in both
> unwanted information disclosure bugs just speaks for very little
> interest serious users have in evolution. I can only imagine what
> happens if someone decides to do a real audit...

That would be interesting to know (seriously, no sarcasm used). It
might help the project, which is a gain. And when you consider also
things like the Camel library can be used by other than just Evolution,
then there would be good benefits.
        Bye,
        Milan
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
On Tuesday, September 26, 2017 10:31 AM, Milan Crha <[hidden email]> wrote:
 
> On Tue, 2017-09-26 at 09:53 -0400, [hidden email] wrote:
>> Where is the function responsible for helo message?
> Hi,
> it's here:
> https://git.gnome.org/browse/evolution-data-server/tree/src/camel/providers/smtp/camel-smtp-transport.c?h=gnome-3-24#n1388

A piece of cake. Set name to NULL instead of g_resolver_lookup_by_address and let
https://git.gnome.org/browse/evolution-data-server/tree/src/camel/providers/smtp/camel-smtp-transport.c?h=gnome-3-24#n1401
fill in IP address. This will match thunderbird behavior.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
Here is the patch

 diff -up evolution-data-server-3.24.6/src/camel/providers/smtp/camel-smtp-transport.c.orig evolution-data-server-3.24.6/src/camel/providers/smtp/camel-smtp-transport.c
--- evolution-data-server-3.24.6/src/camel/providers/smtp/camel-smtp-transport.c.orig   2017-09-27 19:06:32.769883845 -0400
+++ evolution-data-server-3.24.6/src/camel/providers/smtp/camel-smtp-transport.c        2017-09-27 19:09:50.902330428 -0400
@@ -1385,14 +1385,6 @@ smtp_helo (CamelSmtpTransport *transport
        address = g_inet_socket_address_get_address (
                G_INET_SOCKET_ADDRESS (transport->local_address));

-       name = g_resolver_lookup_by_address (
-               resolver, address, cancellable, &local_error);
-
-       /* Sanity check. */
-       g_return_val_if_fail (
-               ((name != NULL) && (local_error == NULL)) ||
-               ((name == NULL) && (local_error != NULL)), FALSE);
-
        if (g_error_matches (local_error, G_IO_ERROR, G_IO_ERROR_CANCELLED))
                return FALSE;

Now behavior became exactly the same as in thunderbird.
However I would prefer name variable to be assigned to return address domain name.
No recipient needs to know neither sender's workstation IP address nor its real host name.

Josh.

On Tuesday, September 26, 2017 11:41 AM, [hidden email] wrote:
 

> On Tuesday, September 26, 2017 10:31 AM, Milan Crha <[hidden email]>
> wrote:
>  
>> On Tue, 2017-09-26 at 09:53 -0400, [hidden email] wrote:
>>> Where is the function responsible for helo message?
>> Hi,
>> it's here:
>> https://git.gnome.org/browse/evolution-data-server/tree/src/camel/providers/smtp/camel-smtp-transport.c?h=gnome-3-24#n1388
> A piece of cake. Set name to NULL instead of g_resolver_lookup_by_address
> and let
> https://git.gnome.org/browse/evolution-data-server/tree/src/camel/providers/smtp/camel-smtp-transport.c?h=gnome-3-24#n1401
> fill in IP address. This will match thunderbird behavior.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Pete Biggs

>
>
> No recipient needs to know neither sender's workstation IP address
> nor its real host name.
>
I would disagree with that.  The headers are mainly there for debugging
and auditing not for "informing" the end recipient - putting bogus
information in those headers just negates their primary purpose and
makes life difficult for admins. For instance, I work in a large
institution (no, it's not difficult to find out where) - if some MUA
obfuscated the senders host, I would class that program as not fit for
purpose - it's the sort of thing that spammers/phishers would do.

In reality you could extend your ultra privacy arguments to say that
the recipient doesn't need to see most of the headers, so why not strip
everything except the basic From/To/Subject/Date from the email before
it's delivered into the recipients mailbox?

P.

ps BTW, the senders IP address is usually inserted by the MTA, not the
MUA in the headers. Good luck with getting that changed.

_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

fmouse
In reply to this post by d18jf98rw
On Wed, 2017-09-27 at 21:41 -0400, [hidden email] wrote:
> No recipient needs to know neither sender's workstation IP address
> nor its real host name.

Normally, headers don't contain the "sender's workstation IP address"
unless the sender's MUA inserts it as a body header, and more often
than not this IP address is an RFC-1918 (unroutable) address which is
useless in identifying the sender.

All headers in an email are technically part of the body of the email
(sent after the "data" command in an SMTP dialog) and I have always
been led to understand that it's not the proper job of a MUA to muck
with these. RFC-2821 specifies that "When an SMTP server receives a
message for delivery or further processing, it MUST insert trace ...
information" (which includes "Received" headers) so information
received by the MUA _should_ contain not the sender's workstation IP,
but the IP of the SMTP server which handled the email for the sender.

a MUA may hide trace information from the recipient to simplify mail
reading, but it absolutely should not remove it, and in the case of
mail stored on a server, received via IMAP, it's doubtful that such
removal is even technically possible.

Trace headers can be spoofed, of course, and as a rule in tracing email
only the Received header inserted by the recipient's mail server can be
fully trusted. Needless to say, spoofed trace headers are NOT RFC-
compliant!

--
Lindsay Haisley       | "The only unchanging certainty
FMP Computer Services |    is the certainty of change"
512-259-1190          |
http://www.fmp.com    | - Ancient wisdom, all cultures

_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
In reply to this post by Pete Biggs
 
On Thursday, September 28, 2017 3:13 AM, Pete Biggs <[hidden email]> wrote:
 

> ps BTW, the senders IP address is usually inserted by the MTA, not the
> MUA in the headers. Good luck with getting that changed.

Pete,

You probably haven't read anything I've said before.
IP address is inserted by thunderbird MUA by HELO=my_IP_address
Hostname is inserted by evolution MUA by HELO=my_hostname

I don't like both cases but hostname, unless it is a default "localhost.localdomain" is worse then IP address, that is why I proposed a patch.

MTA will report EXTERNAL IP Address which is acceptable, since MTA behavior is well known. If someone wants to change it, they will use VPN.

Josh.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Andre Klapper
On Fri, 2017-09-29 at 17:06 -0400, [hidden email] wrote:
> You probably haven't read anything I've said before.

Hi Josh,

please see https://wiki.gnome.org/Foundation/CodeOfConduct
Thank you! :)
andre
--
Andre Klapper  |  [hidden email]
http://blogs.gnome.org/aklapper/
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

Berend De Schouwer
In reply to this post by d18jf98rw
On Fri, 2017-09-29 at 17:06 -0400, [hidden email] wrote:

>  
> On Thursday, September 28, 2017 3:13 AM, Pete Biggs <[hidden email]
> k> wrote:
>  
>
> > ps BTW, the senders IP address is usually inserted by the MTA, not
> > the
> > MUA in the headers. Good luck with getting that changed.
>
> Pete,
>
> You probably haven't read anything I've said before.
> IP address is inserted by thunderbird MUA by HELO=my_IP_address
> Hostname is inserted by evolution MUA by HELO=my_hostname

It is *provided* by the MUA to the MTA.  It is *inserted* in the
Received header by the MTA.  Nothing blocks the MTA from adding the MUA
IP address *despite* the information provided in the HELO message.

> I don't like both cases but hostname, unless it is a default
> "localhost.localdomain" is worse then IP address, that is why I
> proposed a patch.

Some MTAs might decide that you're playing games when the HELO is
wrong, and some might simply do a reverse DNS lookup or block your
access.

> MTA will report EXTERNAL IP Address which is acceptable, since MTA
> behavior is well known. If someone wants to change it, they will use
> VPN.

Outgoing MTAs can be configured to strip internal Received headers
completely at the border if you so choose.  Speak to your mail
administrator.


PS. It sounds like you want anon.penet.fi to return.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list
Reply | Threaded
Open this post in threaded view
|

Re: Bug 738247 - unwanted information disclosure in message headers

d18jf98rw
 
On Saturday, September 30, 2017 11:30 AM, Berend De Schouwer
<[hidden email]> wrote:
 

> On Fri, 2017-09-29 at 17:06 -0400, [hidden email] wrote:
>>  
>> On Thursday, September 28, 2017 3:13 AM, Pete Biggs <[hidden email]
>> k> wrote:
>>  
>>
>> > ps BTW, the senders IP address is usually inserted by the MTA, not
>> > the
>> > MUA in the headers. Good luck with getting that changed.
>>
>> Pete,
>>
>> You probably haven't read anything I've said before.
>> IP address is inserted by thunderbird MUA by HELO=my_IP_address
>> Hostname is inserted by evolution MUA by HELO=my_hostname
> It is *provided* by the MUA to the MTA.  It is *inserted* in the
> Received header by the MTA.  Nothing blocks the MTA from adding the MUA
> IP address *despite* the information provided in the HELO message.

Fine, I agree. Let HELO be *provided* by MUA and *inserted* as is by MTA as said
in RFC, I suppose. At least it is an observed behavior among all public mail
servers I have access to.
 
> PS. It sounds like you want anon.penet.fi to return.
Absolutely not. Another example of catching only a tail of conversation and
making wrong conclusion.

I said at the very beginning that I want evolution behave *exactly* as
thunderbird and offered a patch. That is all. I am not going to continue this discussion.

Josh.
_______________________________________________
evolution-list mailing list
[hidden email]
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-list