Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression invitation come from user's address : spoofing issue #35953

Closed
KsmoinO opened this issue Jul 30, 2019 · 12 comments
Closed

Regression invitation come from user's address : spoofing issue #35953

KsmoinO opened this issue Jul 30, 2019 · 12 comments

Comments

@KsmoinO
Copy link

KsmoinO commented Jul 30, 2019

Hello

The change #25470 causes my mail server to refuse sending mail.
In fact, I use an authenticated SMTP server which does not allow using "envelope mail from" address different from account one. This prevent SMTP spoofing.
Is it possible to apply one of the following:

  • add the possibility to avoid this change on SMTP server settings ?
  • use from headers instead of mail from envelope ?
  • permit each users ton configure their smtp settings to override default server one ?

As workaround I commented the line below in apps/dav/lib/CalDAV/Schedule/IMipPlugin.php
125 //->setFrom([$sender => $senderName])

Regards.

Steps to reproduce

Invite someone to calendar event.

Expected behaviour

Email is sent from email address configured as authenticated user in Settings --> Admin --> General -->Email Server-->From Address.

Actual behaviour

Email is sent from user address and refused by mail server (prevent spoofing issues)

Server configuration

Operating system:
Rasbian 9
Web server:
Apache 2.4
Database:
MariaDB 10
PHP version:
PHP 7
ownCloud version: (see ownCloud admin page)
ownCloud 10.2.1 (stable)
Updated from an older ownCloud or fresh install:
Updated from an older ownCloud
Where did you install ownCloud from:
Debian repository : https://download.owncloud.org/download/repositories/production/Debian_9.0/
Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
http://example.com/index.php/settings/integrity/failed 
paste the results into https://gist.github.com/ and puth the link here.

No errors have been found.

The content of config/config.php:

Log in to the web-UI with an administrator account and click on
'admin' -> 'Generate Config Report' -> 'Download ownCloud config report'
This report includes the config.php settings, the list of activated apps
and other details in a well sanitized form.

or 

If you have access to your command line run e.g.:
sudo -u www-data php occ config:list system
from within your ownCloud installation folder

*ATTENTION:* Do not post your config.php file in public as is. Please use one of the above
methods whenever possible. Both, the generated reports from the web-ui and from occ config:list
consistently remove sensitive data. You still may want to review the report before sending.
If done manually then it is critical for your own privacy to dilligently
remove *all* host names, passwords, usernames, salts and other credentials before posting.
You should assume that attackers find such information and will use them against your systems.

bin/occ config:list system
{
"system": {
"instanceid": "oc9580259263",
"passwordsalt": "REMOVED SENSITIVE VALUE",
"datadirectory": "/home/owncloud/data",
"dbtype": "mysql",
"version": "10.2.1.4",
"dbname": "owncloud",
"dbhost": "localhost",
"dbtableprefix": "oc_",
"dbuser": "REMOVED SENSITIVE VALUE",
"dbpassword": "REMOVED SENSITIVE VALUE",
"installed": true,
"maxZipInputSize": 10737418240,
"allowZipDownload": true,
"forcessl": true,
"logfile": "/var/log/owncloud/owncloud.log",
"loglevel": 0,
"logtimezone": "Europe/Paris",
"theme": "",
"maintenance": false,
"trusted_domains": [
"REMOVED SENSITIVE VALUE"
],
"mail_smtpmode": "smtp",
"preview_libreoffice_path": "/usr/bin/libreoffice",
"mail_smtphost": "REMOVED SENSITIVE VALUE",
"mail_smtpport": "587",
"mail_from_address": "REMOVED SENSITIVE VALUE",
"mail_domain": "REMOVED SENSITIVE VALUE",
"secret": "REMOVED SENSITIVE VALUE",
"mail_smtpauth": 1,
"trashbin_retention_obligation": "auto",
"updatechecker": false,
"mail_smtpname": "REMOVED SENSITIVE VALUE",
"mail_smtppassword": "REMOVED SENSITIVE VALUE",
"mail_smtpsecure": "tls",
"mail_smtpauthtype": "LOGIN",
"filelocking.enabled": true,
"memcache.local": "\OC\Memcache\APCu",
"memcache.locking": "\OC\Memcache\Redis",
"redis": {
"host": "localhost",
"port": 6379
}
}
}

List of activated apps:

If you have access to your command line run e.g.:
sudo -u www-data php occ app:list
from within your ownCloud installation folder.

bin/occ app:list
Enabled:

  • activity: 2.5.0
  • calendar: 1.6.2
  • configreport: 0.2.0
  • contacts: 1.5.5
  • dav: 0.4.0
  • federatedfilesharing: 0.4.0
  • files: 1.5.2
  • files_external: 0.7.1
  • files_pdfviewer: 0.11.0
  • files_sharing: 0.11.0
  • files_texteditor: 2.3.0
  • files_trashbin: 0.9.1
  • files_versions: 1.3.0
  • files_videoplayer: 0.10.1
  • firstrunwizard: 1.2.0
  • gallery: 16.1.1
  • market: 0.5.0
  • notifications: 0.5.0
  • twofactor_totp: 0.6.0
  • updatenotification: 0.2.1
    Disabled:
  • comments
  • encryption
  • external
  • federation
  • provisioning_api
  • security
  • systemtags
  • user_external

Are you using external storage, if yes which one: local/smb/sftp/...
No
Are you using encryption: yes/no
No
Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...
No

Client configuration

Browser:
Any
Operating system:
Any

Logs

Web server error log

Insert your webserver log here

N/A

ownCloud log (data/owncloud.log)

Insert your ownCloud log here

N/A

Browser log

N/A
@DeepDiver1975
Copy link
Member

Some what it the old was - some the new way 🤷‍♂️

One can come up with a PR which adds a config option to either set this header or not.

Voluntees are welcome. THX

@KsmoinO
Copy link
Author

KsmoinO commented Oct 23, 2019

One solution should be to do use variable in config/config.php ?

Example:
replacing:

$message->setReplyTo([$sender => $senderName])
                        ->setFrom([$sender => $senderName])
                        ->setTo([$recipient => $recipientName])
                        ->setSubject($subject)
                        ->setBody($iTipMessage->message->serialize(), $contentType);

with:

                $message->setReplyTo([$sender => $senderName])
                        ->setTo([$recipient => $recipientName])
                        ->setSubject($subject)
                        ->setBody($iTipMessage->message->serialize(), $contentType);
                if ($this->config->getSystemValue("mail_from_user_address", '')) {
                        $message->setFrom([$sender => $senderName]);
                }

Thus, the administrators would have the possibility to choose the way of sending mails.

@magicWF
Copy link

magicWF commented Dec 7, 2019

Hello,

I prefer the KsmoinO solution to give the administrator the choice of how to define the sender. By default, it should use the OC server as the sender.

The problem is when the OC-Server tries to send mails with foreign senders (domains for which the OC MTA is not responsible). In the worst case my OC server should send a mail to Apple or Google, which should originate from them. In order to reduce the amount of SPAM, the easiest method is not to accept mail from your own domain if it comes from foreign servers. This is done using sender verification techniques such as DMARC (RFC5322), SPF or DKIM.

@stale
Copy link

stale bot commented Sep 19, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the status/STALE label Sep 19, 2021
@KsmoinO
Copy link
Author

KsmoinO commented Sep 19, 2021

Issue still present

@KsmoinO
Copy link
Author

KsmoinO commented Sep 21, 2021

@janackermann why did you close this issue ?

@AlexAndBear
Copy link

Closed by accident, reopened

@AlexAndBear AlexAndBear reopened this Sep 21, 2021
@stale stale bot removed the status/STALE label Sep 21, 2021
@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@KsmoinO
Copy link
Author

KsmoinO commented Mar 21, 2022

Do not close please, Issue still present.

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

@github-actions
Copy link

This issue has been automatically closed.

@lubomirblazekcz
Copy link

Issue is still present!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants