Email and smtp.sendmail security vulnerabilities?

[John W. Long]

Hi,

I've created a small class and supporting methods for sending email from a
web page. I use it like this:

msg = Web::Email::Message.new(
:from => from,
:to => to,
:subject => subject,
:body => body.untaint # security vulnerability?
)
Web::Email.send(msg)

All of the email strings (:from, :to, etc...) could potentially come from
the the outside world. I'm doing some munging on the :from, :to, and
:subject strings replacing \n \r \f \e and \b with something
non-threatening. Right now I'm just untainting the :body string, but I have
the distinct feeling that I may be exposing myself to a security
vulnerability because I don't really understand what the Net::SMTP class is
doing in the background.

Could someone who understands how Net::SMTP works check over my code (see
below) and comment on security vulnerabilities? Also I looked for details on
specification for email, but a brief search on google didn't turn up
anything. Can someone point me in the right direction?

Thanks,

John Long
[url]http://wiseheartdesign.com[/url]

<code>
# you will probably want to paste this into
# a syntax highlighting editor like Scite
require 'net/smtp'
module Web
module Email
class Message
attr_accessor :from, :to, :subject, :body

def initialize(hash = {})
@from = hash[:from]
@to = hash[:to]
@subject = hash[:subject]
@body = hash[:body]
end

def message
time = current_time
<<-SMTP_MSG
Subject: #{@subject}
Message-Id: <#{"%.8f" % time.to_f}@iblp.org>
Date: #{time.strftime("%a, %d %b %Y %H:%M:%S %z %Z")}
From: #{@from}
To: #{@to}

#{@body}
SMTP_MSG
end

def current_time
Time.now
end
end
def self.send(msg)
msg.subject = safe_subject(msg.subject) # munges and untaints string
msg.from = safe_address(msg.from)
msg.to = safe_address(msg.to)
raise ArgumentError, 'msg.body tainted' if msg.body.tainted?
raise ArgumentError, 'msg tainted' if msg.tainted?
Net::SMTP.start('localhost', 25) {|smtp|
smtp.sendmail(msg.message, msg.from, msg.to)
}
end
def self.safe_subject(subject)
subject.gsub(/[\n\r\f\e\b]/, ' ').untaint
end
def self.safe_address(address)
address.gsub(/[\n\r\f\e\b]/, '').untaint
end
end
end
</code>

[Hugh Sasse Staff Elec Eng]

On Tue, 26 Aug 2003, John W. Long wrote:

> Hi,
>
> I've created a small class and supporting methods for sending email from a
> web page. I use it like this:
>
> msg = Web::Email::Message.new(
> :from => from,
> :to => to,
> :subject => subject,
> :body => body.untaint # security vulnerability?
> )
> Web::Email.send(msg)
>
> All of the email strings (:from, :to, etc...) could potentially come from
> the the outside world. I'm doing some munging on the :from, :to, and

That is your security problem in itself. Far better would be to
permit certain addresses only, and let the user choose them by
passing a hash (such as MD5) of the desired address into the form.
Thus different addresses cannot easily be created, because only
those selected addresses will be reverse mapped (md5->address).
This selection would obviously have to be done from a radio button
or similar selector.

Why go to all this trouble? See
[url]http://spamcop.net/fom-serve/cache/270.html[/url]
for links to details about formmail which used to be open.
Basically, anyone could use your script for relaying mail via your
machine...

Hugh

[John W. Long]

Hi,

> > All of the email strings (:from, :to, etc...) could potentially come

from

> > the the outside world. I'm doing some munging on the :from, :to, and

>
> That is your security problem in itself. Far better would be to
> permit certain addresses only, and let the user choose them by
> passing a hash (such as MD5) of the desired address into the form.
> Thus different addresses cannot easily be created, because only
> those selected addresses will be reverse mapped (md5->address).
> This selection would obviously have to be done from a radio button
> or similar selector.

Well, at any one time I do not intend to allow the user to enter all of the
information. Right now we have an "email this page" form on our web site.
Which allows the user to send a link from our web site to a friend. They
enter their name and email, their friends name and email, and a brief
message. The code then wraps their message with some standard text and the
link. You can see our old form here:

[url]http://iblp.org/email.asp[/url]

This emails something like this to their friend:

<email>
Hi John,

Your friend Bill wants you to visit:

#{link}

Message:

#{usermessage}

--------------------
The Institute in Basic Life Principles
[url]http://iblp.org[/url]
</email>

> Why go to all this trouble? See
> [url]http://spamcop.net/fom-serve/cache/270.html[/url]
> for links to details about formmail which used to be open.
> Basically, anyone could use your script for relaying mail via your
> machine...

While I realize that anyone with enough know how could send mail from the
form, he would have to be willing to send the message with our header and
footer (something I hope would discourage spammers from using our form).

The main thing I want to know is if someone could enter a message that would
add headers to the email or cause the footer not to be displayed, or exploit
some other security vulnerability. Right now I'm preventing the email fields
from having more than one address, and am forcing the name fields to only
have certian characters. The field that I am primarily worried about is the
message field.

--
John Long
[url]http://wiseheartdesign.com[/url]

[Hugh Sasse Staff Elec Eng]

On Tue, 26 Aug 2003, John W. Long wrote:

> Hi,
>
>
> Well, at any one time I do not intend to allow the user to enter all of the
> information. Right now we have an "email this page" form on our web site.

[...]

> [url]http://iblp.org/email.asp[/url]

[...]

This is open to the same kind of abuse.

>
>
> While I realize that anyone with enough know how could send mail from the

But it isn't much know how: it is only constructing a URL. Then the
"spam" comes via your domain, and you get blacklisted.

> form, he would have to be willing to send the message with our header and
> footer (something I hope would discourage spammers from using our form).

Spammers don't seem to care much how their message is delivered.
This statement is anecdotal, of course. Add a tablespoon or 4 of
salt, to taste.

>
> The main thing I want to know is if someone could enter a message that would
> add headers to the email or cause the footer not to be displayed, or exploit
> some other security vulnerability. Right now I'm preventing the email fields

I've not looked in that much depth. I think this is a serious
enough flaw to make that much less significant.

Another quick look throws up: You have not trapped ';' although you
don't pass this directly to a shell, so you should be OK.
When you expand the string with #{} they can find out things like
$RUBY_PLATFORM and such, which may reveal more about your system
than you wish to reveal.

The Body cannot become part of the headers, even with vertical tabs,
I think.

The Message id may not be unique, since you only use time.current.
You may need $$ and possibly Thread.current as well to guarantee 2
concurrent submissions having unique ids.

I don't seem to have enough low cunning to think of all the holes
that others are able to point out.

You also may wish to limit submissions from/to an address in a given
period to prevent automated mail bombing.

> from having more than one address, and am forcing the name fields to only
> have certian characters. The field that I am primarily worried about is the
> message field.
>
> --
> John Long
> [url]http://wiseheartdesign.com[/url]
>

Hugh

[John Long]

Hi,

> > While I realize that anyone with enough know how could send

> mail from the
>
> But it isn't much know how: it is only constructing a URL. Then the
> "spam" comes via your domain, and you get blacklisted.

> Spammers don't seem to care much how their message is delivered.
> This statement is anecdotal, of course. Add a tablespoon or 4 of
> salt, to taste.

How would you suggest we implement this feature on our web site?

Technically someone could send a link from the iblp web site to a million
people and get us black listed, but the chances of this happening are
relatively slim. Talking with our IT department head here he said that the
way most blacklists work is by checking to see if you are running open
relay. If you are then they blacklist you. We wouldn't be running open relay
so that wouldn't be a problem. Also if that occured the hits to that page
would suddenly sky rocket.

> > The main thing I want to know is if someone could enter a

> message that would

> > add headers to the email or cause the footer not to be

> displayed, or exploit

> > some other security vulnerability. Right now I'm preventing

> the email fields
>
> I've not looked in that much depth. I think this is a serious
> enough flaw to make that much less significant.

Again the main field I am concerned about is the message field.

> Another quick look throws up: You have not trapped ';' although you
> don't pass this directly to a shell, so you should be OK.
> When you expand the string with #{} they can find out things like
> $RUBY_PLATFORM and such, which may reveal more about your system
> than you wish to reveal.

I'm not quite sure what you mean here. Can you give an example of someone
getting the Ruby Platform that way?

irb(main):001:0> a = "RUBY_PLATFORM"
=> "RUBY_PLATFORM"
irb(main):002:0> j = "#{a}"
=> "RUBY_PLATFORM"
irb(main):003:0>

When I use this class on my page I actually do some checking to insure that
only one email address is entered and a few other things.

> The Body cannot become part of the headers, even with vertical tabs,
> I think.

This would be my guess too. But I would like to know for sure.

> The Message id may not be unique, since you only use time.current.
> You may need $$ and possibly Thread.current as well to guarantee 2
> concurrent submissions having unique ids.

Interesting point. What does $$ stand for?

> I don't seem to have enough low cunning to think of all the holes
> that others are able to point out.
>
> You also may wish to limit submissions from/to an address in a given
> period to prevent automated mail bombing.
>

Something to consider I guess. But probably not worth the extra effort on
this front. For now we will just continue checking our site statistics on a
regular basis.

How does what we are doing differ from what major news sites are doing (eg.
msnbc.com, cnn.com)? What would prevent me from using their sites to send
spam?

--
John Long
[email]jlong@iblp.org[/email]

[Sean O'Dell]

John Long wrote:

> Hi,
>
>

>>>While I realize that anyone with enough know how could send

>>
>>mail from the
>>
>>But it isn't much know how: it is only constructing a URL. Then the
>>"spam" comes via your domain, and you get blacklisted.

>
>

>>Spammers don't seem to care much how their message is delivered.
>>This statement is anecdotal, of course. Add a tablespoon or 4 of
>>salt, to taste.

>
>
> How would you suggest we implement this feature on our web site?
>
> Technically someone could send a link from the iblp web site to a million
> people and get us black listed, but the chances of this happening are
> relatively slim. Talking with our IT department head here he said that the
> way most blacklists work is by checking to see if you are running open
> relay. If you are then they blacklist you. We wouldn't be running open relay
> so that wouldn't be a problem. Also if that occured the hits to that page
> would suddenly sky rocket.
>
>

>>>The main thing I want to know is if someone could enter a

>>
>>message that would
>>

>>>add headers to the email or cause the footer not to be

>>
>>displayed, or exploit
>>

>>>some other security vulnerability. Right now I'm preventing

>>
>>the email fields
>>
>>I've not looked in that much depth. I think this is a serious
>>enough flaw to make that much less significant.

>
>
> Again the main field I am concerned about is the message field.

The only way for a someone to do something evil with your body message
is if they wrote a single line with nothing but a period. This signals
the SMTP server that the body of the message is done, and the server
will then wait for more commands. If after that, there are more lines
in the message body, they would be sent to the server and those could
contain SMTP commands that initiate more mailings or what-not.

However, most SMTP library writers know the specification and
deliberately prepend any lines beginning with a period with a second
period, which results in an "escape" sequence that the server recognizes
as "periods are coming, but they're just body text."

You should have nothing to worry about, unless the library author didn't
take that precaution.

One way to test that is to send yourself an email through the library
containing lines that you will easily recognize, and make one of the
lines just a period by itself, and nothing else. Then add some more
lines you will recognize after that line. If you get the email with the
period showing, the library is safe. If the period and the rest of the
message body is missing, the library is not safe.

>>Another quick look throws up: You have not trapped ';' although you
>>don't pass this directly to a shell, so you should be OK.
>>When you expand the string with #{} they can find out things like
>>$RUBY_PLATFORM and such, which may reveal more about your system
>>than you wish to reveal.

>
> I'm not quite sure what you mean here. Can you give an example of someone
> getting the Ruby Platform that way?

You don't need to trap anything but the period.

> irb(main):001:0> a = "RUBY_PLATFORM"
> => "RUBY_PLATFORM"
> irb(main):002:0> j = "#{a}"
> => "RUBY_PLATFORM"
> irb(main):003:0>
>
> When I use this class on my page I actually do some checking to insure that
> only one email address is entered and a few other things.

This is a good idea. Also, stripping off anything from a
newline-onwards will prevent people from adding their own headers, such
as CC and BCC (blind CC).

>>The Body cannot become part of the headers, even with vertical tabs,
>>I think.

>
>
> This would be my guess too. But I would like to know for sure.

Like I mention above, the body can actually cause you problems, although
the SMTP library author should be checking for any lines beginning with
a period. Can't hurt to look at the code and see for yourself though.

>>The Message id may not be unique, since you only use time.current.
>>You may need $$ and possibly Thread.current as well to guarantee 2
>>concurrent submissions having unique ids.

>
> Interesting point. What does $$ stand for?

Probably the process and thread IDs, respectively. The thread ID should
also be a process ID, and that should be good enough, but in case you're
using some unusual threading library, you might want to combine the
process and thread IDs to create a truly unique ID (append it to a time
value).

> How does what we are doing differ from what major news sites are doing (eg.
> msnbc.com, cnn.com)? What would prevent me from using their sites to send
> spam?

Major sites might be taking more sophisticated steps to address specific
problems they encounter, but the only two real vulnerabilities I would
worry about are: newlines in the "to" address and periods at the
beginning of lines in the body. If you check for those two things
before sending to an SMTP server, you should be free of problems.

Sean O'Dell

[ts]

>>>>> "J" == John Long <JLong@iblp.org> writes:

J> How would you suggest we implement this feature on our web site?

The good question is, perhaps, why do you want to add such feature when
many browsers give the possibility to send a link (or a page) in an
e-mail (option "Send page", "Send link" in mozilla).

J> Technically someone could send a link from the iblp web site to a million
J> people and get us black listed, but the chances of this happening are
J> relatively slim.

Do you know Murphy's laws ?


Guy Decoux

[Nathaniel Talbott]

ts [mailto:decoux@moulon.inra.fr] wrote:

> >>>>> "J" == John Long <JLong@iblp.org> writes:

>
> J> How would you suggest we implement this feature on our web site?
>
> The good question is, perhaps, why do you want to add such
> feature when many browsers give the possibility to send a
> link (or a page) in an e-mail (option "Send page", "Send
> link" in mozilla).

You could also do something like this:

<html>
<body>
<a href="mailto:somebody@somewhere?subject=Subject&bo dy=Body">Email
this site to a friend</a>
</body>
</html>

Which has the distinct advantage of sending everything through the user's
email system, whatever that may be. I'm not sure how well the construct
works across platforms, though.


Nathaniel

<:((><

[John W. Long]

Hi Nathaniel,

> You could also do something like this:
>
> <html>
> <body>
> <a
> href="mailto:somebody@somewhere?subject=Subject&bo dy=Body">Email
> this site to a friend</a>
> </body>
> </html>
>
> Which has the distinct advantage of sending everything
> through the user's
> email system, whatever that may be. I'm not sure how well the
> construct
> works across platforms, though.

We've considered this, but it has the disadvantage of not being able to work
in a public access situation (a library).

--
John Long
[url]http://wiseheartdesign.com[/url]