
Hello, I have a web application which needs to send mail using sendmail. However, the way the system is configured, sendmail is not in the web server's $PATH. There are two fixes for this -- change the init script so that sendmail is in the $PATH -- or modify the web server so that the admin can set the path to sendmail via the control panel. At first the second option sounds good. But I wonder about the security implications. If someone manages to get the password for the admin control panel -- they could change the path to sendmail to something else -- like `vim` or `gcc` and then somehow craft a message that would place a backdoor on the system. Now, given that the input to the message is going to be a mime message that sounds pretty difficult. But, then again, in December tons of Joomla sites were open to an exploit where a malformed user-agent header allowed hackers to execute arbitrary code. Although in this case I care about sendmail, this is clearly an issue for any web application that depends on external binaries like pandoc, etc. In my use case, I am dealing with a CMS and I assume the poor user doesn't know anything about Haskell, init scripts, ssh, etc. So, allowing the location to be changed via the admin panel makes things easier because it can be adapted to any distribution. (Clearly, I would start by checking the most common locations, but provide an escape hatch for oddballs). But I don't like the idea of providing a potential attack vector. Any thoughts ? - jeremy

Two thoughts come to mind:
* Hard-code into the application a list of common sendmail locations and
search them
* Allow some kind of configuration (via file, env var, etc) to specify
sendmail location at launch
The first may sound slightly dangerous, but if you're already searching the
PATH for `sendmail`-named binaries, I don't think it's any worse. I'd
definitely include a configuration override to set the location of the
sendmail executable and override any searching (via list of paths or the
PATH var).
On Tue, Feb 9, 2016 at 7:46 PM, Jeremy Shaw
Hello,
I have a web application which needs to send mail using sendmail.
However, the way the system is configured, sendmail is not in the web server's $PATH.
There are two fixes for this -- change the init script so that sendmail is in the $PATH -- or modify the web server so that the admin can set the path to sendmail via the control panel.
At first the second option sounds good. But I wonder about the security implications. If someone manages to get the password for the admin control panel -- they could change the path to sendmail to something else -- like `vim` or `gcc` and then somehow craft a message that would place a backdoor on the system.
Now, given that the input to the message is going to be a mime message that sounds pretty difficult. But, then again, in December tons of Joomla sites were open to an exploit where a malformed user-agent header allowed hackers to execute arbitrary code.
Although in this case I care about sendmail, this is clearly an issue for any web application that depends on external binaries like pandoc, etc.
In my use case, I am dealing with a CMS and I assume the poor user doesn't know anything about Haskell, init scripts, ssh, etc. So, allowing the location to be changed via the admin panel makes things easier because it can be adapted to any distribution. (Clearly, I would start by checking the most common locations, but provide an escape hatch for oddballs).
But I don't like the idea of providing a potential attack vector.
Any thoughts ?
- jeremy
_______________________________________________ web-devel mailing list web-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/web-devel

Hi, You could put the ability to change the setting on "the other side of the airtight hatchway" as Raymond Chen might say: put the setting in a file and don't provide any ability to change it remotely. Then if someone does manage to change the setting to something nefarious, they already had write access to your filesystem so they've not gained anything. You can of course show the current value of the setting in the UI, along with instructions on how to change it. Presumably your user at least has SCP or FTP access, or else how did they install your software? That, plus autodetection when first set up (looking in a bunch of common places) sounds reasonably usable to me. It might also be worth taking heart in the fact that if you're dealing with someone running on a system that has sendmail in an unexpected place then they're going to be having a Bad Time in all sorts of other ways, no matter whose software they're using! Cheers, David

On 02/09/2016 01:26 PM, David Turner wrote:
Hi,
You could put the ability to change the setting on "the other side of the airtight hatchway" as Raymond Chen might say:
It's worth providing a link to this since it's hard to find the original in Google: https://blogs.msdn.microsoft.com/oldnewthing/20060508-22/?p=31283/ There's really not much you can do about this except perhaps simply require that sendmail be in the path, and even that is subject to concerns about whether the path is set up securely. It isn't really your program's problem to make sure the system it's running on is set up securely; it is neither capable of correctly and safely determining the answer to that question, nor fixing it if it could. Disclaimer: I actually work in computer security. This isn't an uninformed dismissal; this is an informed dismissal. :) In particular the last line of the previous paragraph is a core part of my point. If that wasn't true I might have a different opinion, but at the point where we're discussing a system that can't trust that sendmail is actually sendmail, you've already lost. The only thing you can do is ensure that changing the path really and truly requires the proper authorization and there's no way to trick that system.
participants (4)
-
David Turner
-
Jeremy Bowers
-
Jeremy Shaw
-
Michael Snoyman