suhosin[211704]: ALERT - mail() - double newline in headers, possible injection, mail dropped (attacker '0.0.0.0', file '/var/www/sites/all/modules/backup_migrate/includes/destinations.email.inc', line 138)

Should be easily solved by using a simple trim() around the $this->to value:


    // Line 138 in ./backup_migrate/includes/destinations.email.inc
    mail(trim($this->to), $this->subject, "", $mime);

Regards
Richard

Comments

ronan’s picture

Version: 7.x-2.2 » 7.x-2.x-dev
Status: Active » Fixed

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

vegantriathlete’s picture

Version: 7.x-2.x-dev » 6.x-2.8
Issue summary: View changes
Status: Closed (fixed) » Needs work

I am still receiving this error message in 6.x-2.8. suhosin[19619]: ALERT - mail() - double newline in headers, possible injection, mail dropped (attacker 'XXX.XXX.XXX.XXX', file '/var/www/drupal6/sites/all/modules/backup_migrate/includes/destinations.email.inc', line 138) I can see that in line 138 trim($this->to) is being used. So, that's obviously not fixing the problem.

Note: I get the error message in my syslog for the Drupal 6 cron job initiated mail send.

Additionally, 7.x-2.8 seems to be having trouble sending out the email. But, I can't find any error messages in any of my logs to give me a hint of what's happening there. I don't see the suhosin ALERT message.

I don't know exactly when the emailed backups stopped going out. They were working before. I know that I received one successfully as recently as January 19, 2014 (for a Drupal 6 site and a Drupal 7 site). It's possible that I received one even more recently than that and I had deleted that email message.

EDIT: It does appear that I'm seeing the same type of message when sending to the email destination manually in 7.x-2.8. I don't know why I don't get a message in the logs with the cron job.

EDIT 2: Interestingly, the IP address that is reported in the message when I trigger a manual send (either in Drupal 6 or Drupal 7) to the email destination appears to map to my ISP. I don't know why it doesn't map to the server address. Perhaps it's because I'm manually triggering the sending of the mail instead of the cron job triggering it. This is in contrast to the IP address which is shown from the cron job initiated mail (Drupal 6), which is the server address.

vegantriathlete’s picture

Title: Suhosin refuses sending mail because of to many new lines in mail header (possible attacker) » Suhosin refuses sending mail because of too many new lines in mail header (possible attacker)
vegantriathlete’s picture

Hmmm . . .

I have looked through the commit history and I can't find anything that changed since January 19, 2014.

One thing that did likely change, though, is that I switched my servers to a new host and set them up with suhosin. My servers probably were not set up with suhosin with the other host. Unfortunately, I know that I had deleted some of the emails that contained backups. I just can't remember which ones I deleted. It's possible that I deleted older emails and that the most recent successful ones were delivered in January 2014 prior to my switch to the new host.

So, my best guess is that the issue with suhosin was never properly resolved. Perhaps it's the $mime variable that's being passed to the mail() function that is causing a problem.

vegantriathlete’s picture

I've got suhosin.mail.protect set to 2.

vegantriathlete’s picture

I think I've found the culprit; I have not actually tested it, yet.

The $mime variable that is used in the send() method is concatenating the output of the build_multipart() method. Inside the build_multipart() method the $multipart variable is initialized to $multipart = "Content-Type: multipart/mixed; boundary = $boundary\n\nThis is a MIME encoded message.\n\n--$boundary"; (and then concatenated with other parts). You will notice that there are two double line breaks. Is it really necessary to have two line breaks? This is what suhosin is rejecting. It doesn't want to see the double line breaks in the additional header information.

I still don't know why the Drupal 7 version is not generating an error message in syslog.

vegantriathlete’s picture

I've started to test this and have removed the extra line break. The code now looks like $multipart = "Content-Type: multipart/mixed; boundary = $boundary\nThis is a MIME encoded message.\n--$boundary"; However, there is still an extra line break as seen in:

[snip]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary = bafeeb089bfb6b8fafd647ffb0a8b2524
Message-Id: <20140613150812.CABC0A13B1@xxxx.xxxx.xxx>
Date: Fri, 13 Jun 2014 11:08:12 -0400 (EDT)

This is a MIME encoded message.
--bafeeb089bfb6b8fafd647ffb0a8b2524
[snip]

It appears that the mail function is inserting the Message-Id: and Date: lines and that it puts the extra line break after Date:

If I remove the line break ($boundary\nThis) and put in a space so that it looks like $boundary This the message gets formatted incorrectly. It ends up looking like:

[snip]
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary = b56a84e0407284cc143fcfd130a2513c2 This is a MIME encoded message.
Message-Id: <20140613150625.65D0EA13B1@xxxx.xxxx.xxx>
Date: Fri, 13 Jun 2014 11:06:25 -0400 (EDT)

--b56a84e0407284cc143fcfd130a2513c2
[snip]

There still ends up being the double line break. EDIT: There isn't actually supposed to be a line break between the boundary and "This is a MIME encoded message." That is just an artifact of how the comment displays. In the actual email message they appear on the same line.

I can't look into this more at the moment.

Right now, I'm just going to leave suhosin.mail.protect set to 0. (I had to set it that way to even do the debugging to this point.)

I think that the way I've got iptables configured on my server protects me from any malicious email anyway. So, I don't think I really need suhosin to enforce this directive.

  • ronan committed d851e75 on 8.x-3.x
    #1503202 Suhosin refuses sending mail because of to many new lines in...
couturier’s picture

Status: Needs work » Closed (outdated)

Drupal 6 and Backup and Migrate 6 are no longer supported.