Re: Email and smtp.sendmail security vulnerabilities?

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