Help with kernel.exec

Hey there,
Im trying to figure out something. If I had Postfix execute a ruby
script that says

Kernel.exec “/usr/sbin/sendmail -i -f #{@sender} – #{@recipient}”

would this be a huge security risk? to me it seems so because if you had
a specially crafted email address you could execute a different command.
How to protect against it?

Cheers,
Petr

On 24.01.2007 16:09, Petr J. wrote:

Im trying to figure out something. If I had Postfix execute a ruby
script that says

Kernel.exec “/usr/sbin/sendmail -i -f #{@sender} – #{@recipient}”

would this be a huge security risk? to me it seems so because if you had
a specially crafted email address you could execute a different command.
How to protect against it?

As always with input parameters: verify them. Make sure those variables
contain what you expect / want to allow them to.

Kind regards

robert

On Thu, 25 Jan 2007, Petr J. wrote:

Cheers,
Petr

harp:~ > cat a.rb
require ‘tmail’

def valid_addr addr
TMail::Address::parse addr
addr
end

p(valid_addr(‘[email protected]’))
p(valid_addr(’rm -rf /@fortytwo.org’))

harp:~ > ruby a.rb
[email protected]
parser.y:370:in on_error': parse error on token "@" (TMail::SyntaxError) from a.rb:1:in_racc_yyparse_c’
from parser.y:366:in parse_in' from /home/aamine/lib/ruby/racc/parser.rb:154:inyyparse’
from parser.y:357:in parse' from parser.y:335:inparse’
from
/home/ahoward//lib/ruby/site_ruby/1.8/tmail/address.rb:21:in parse' from a.rb:4:invalid_addr’
from a.rb:9

or you can write your own from rfc2822

regards.

-a

Petr J. wrote:

Hey there,
Im trying to figure out something. If I had Postfix execute a ruby
script that says

Kernel.exec “/usr/sbin/sendmail -i -f #{@sender} – #{@recipient}”

would this be a huge security risk? to me it seems so because if you had
a specially crafted email address you could execute a different command.
How to protect against it?

One thing you can do is to use 2 or more args with exec.

$ ri exec | cat
------------------------------------------------------------ Kernel#exec
exec(command [, arg, …])

  Replaces the current process by running the given external
  command. If exec is given a single argument, that argument is
  taken as a line that is subject to shell expansion before being
  executed. If multiple arguments are given, the second and
  subsequent arguments are passed as parameters to command with no
  shell expansion.

On 1/24/07, Robert K. [email protected] wrote:

As always with input parameters: verify them. Make sure those variables
contain what you expect / want to allow them to.

Kind regards

    robert

Robert is correct - you would be surprised how much stuff is legal in
an RFC2822-compliant e-mail address. I just successfully sent mail to
these 100% valid addresses:

|/dev/[email protected]
(rm -rf )[email protected]
"; rm -rf /tmp/path/
;"@example.com

(replacing example.com with a domain that I own). No quotes are
required on that first example: pipe and forward slash aren’t even
specials in RFC2822. Nor is ampersand. Nor backtick. And parens are
used for comments in addresses. And quoted bits are allowed in local
parts, so you can shoehorn in semicolons.

If you’re going to use exec, you need to process those address bits
separately to find the SUBSET of RFC2822 addresses that your process
is willing to accept. Because with enough quoting and escaping, I can
send almost anything as the sender of an e-mail message.

Unless you have a strong use case otherwise, I suggest allowing only
[-_.a-zA-Z0-9]

-Alex
…former e-mail server admin

On Jan 24, 2007, at 2:22 PM, Alex LeDonne wrote:

If you’re going to use exec, you need to process those address bits
separately to find the SUBSET of RFC2822 addresses that your process
is willing to accept. Because with enough quoting and escaping, I can
send almost anything as the sender of an e-mail message.

Unless you have a strong use case otherwise, I suggest allowing only
[-_.a-zA-Z0-9]

I generally agree with Alex, but I would suggest allowing a ‘+’ also.
The reason being is that

[email protected]

is often interpreted to cause the message to be delivered to

[email protected]

It is an easy way for a single ‘user’ with one mailbox to actually have
an infinite number of email addresses. I’m not sure if this
interpretation
is mandated by the standard or is just common practice.

Gmail is an example of an email service that supports this concept.

Gary W.

On 1/24/07, [email protected] [email protected] wrote:

I generally agree with Alex, but I would suggest allowing a ‘+’ also.
interpretation
is mandated by the standard or is just common practice.

Gmail is an example of an email service that supports this concept.

Gary W.

Good call, Gary, thanks for the reminder. Some MDAs (Courier
maildrop’s in default config, for example) use + as a delivery folder
designator.

-Alex

“Speaking of GMail” trivia: Gmail not only allows the +, but ignores
dots in the local-part in delivering mail.
http://mail.google.com/support/bin/answer.py?ctx=gmail&hl=en&answer=10313

Joel VanderWerf wrote:

Petr J. wrote:

Hey there,
Im trying to figure out something. If I had Postfix execute a ruby
script that says

Kernel.exec “/usr/sbin/sendmail -i -f #{@sender} – #{@recipient}”

would this be a huge security risk? to me it seems so because if you had
a specially crafted email address you could execute a different command.
How to protect against it?

One thing you can do is to use 2 or more args with exec.

$ ri exec | cat
------------------------------------------------------------ Kernel#exec
exec(command [, arg, …])

  Replaces the current process by running the given external
  command. If exec is given a single argument, that argument is
  taken as a line that is subject to shell expansion before being
  executed. If multiple arguments are given, the second and
  subsequent arguments are passed as parameters to command with no
  shell expansion.

I did use it, but for some reason it kept being a pain in the arse.

Anyway, thanks to all! I installed tmail and ive modified the script and
testing it now.

Petr

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs