Help with kernel.exec

[Petr Janda]

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

 

[Robert Klemme]

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

 

[Joel VanderWerf]

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.
...

 

[Alex LeDonne]

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

 

[gwtmp01]

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

(e-mail address removed)

is often interpreted to cause the message to be delivered to

(e-mail address removed)

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 Wright

 

[Alex LeDonne]

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

(e-mail address removed)

is often interpreted to cause the message to be delivered to

(e-mail address removed)

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 Wright

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

 

[Petr Janda]

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