OT: security of make as authorized_keys command

[Dave Burns]

I should probably ask this on an ssh oriented list, but I thought I'd
try my luck here first.

I want to do some remote commands securely. I put a key in my
.ssh/authorized_keys file like so:

command="/usr/bin/make $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC1[etc.etc.]

so I can invoke make targets like so:

ssh username@host target

Assuming the bad guys never get my key, I am fine, even though it is
passwordless.

What if a bad guy does get my key? Then I see three possible problems:

1) somehow use make's -F switch in ssh command to change Makefiles?
2) stack overflow of make or ssh?
3) Somehow put extra command after make target using ';' or something?

And obviously the bad guy can invoke any of the targets in my
makefile, but I've made them pretty innocuous.

So, should I seriously worry about any of these potential problems?
Any other holes I haven't thought of?

The motivation for all this is some cron jobs I want to run, obviously
calls for a passwordless ssh key, but I want to put some limits on it.

Thanks,
Dave

[Dave Burns]

On Dec 31, 2007 8:20 AM, Mikkel L. Ellertson <mikkel(a)infinity-ltd.com&gt; wrote:
>  Dave Burns wrote:
> >[snip]I put a key in my
>  > .ssh/authorized_keys file like so:
>  >
>  > command="/usr/bin/make $SSH_ORIGINAL_COMMAND" ssh-rsa
> AAAAB3NzaC1[etc.etc.]
>  >
>  > so I can invoke make targets like so:
>  >
>  > ssh username@host target
>  >
>  > Assuming the bad guys never get my key, I am fine, even though it is
>  > passwordless.
>  >
>  > What if a bad guy does get my key? Then I see three possible problems:
>  >
>  > 1) somehow use make's -F switch in ssh command to change Makefiles?
>  > 2) stack overflow of make or ssh?
>  > 3) Somehow put extra command after make target using ';' or something?
>  >
>  > And obviously the bad guy can invoke any of the targets in my
>  > makefile, but I've made them pretty innocuous.
>  >
>  > So, should I seriously worry about any of these potential problems?
>  > Any other holes I haven't thought of?
>  >
>  > The motivation for all this is some cron jobs I want to run, obviously
>  > calls for a passwordless ssh key, but I want to put some limits on it.
>  >
>  > Thanks,
>  > Dave
>  >
>  Instead of running make directly, run a script that does some
>  checking on what is supplied. You could limit the directories that
>  make could be run in, strip out any extra command, etc. (Search the
>  line for a ; , then log and discard the command if it is found.) You
>  could even disable the key if you get an invalid command. 
Well, yeah, but this was what I was trying to avoid, having to predict
all sorts of attacks and do lots of parsing. If I agree that just
slapping $SSH_ORIGINAL_COMMAND into make without any parsing is too
risky, wouldn't it be better to just parse out the first alphanumeric
target name from $SSH_ORIGINAL_COMMAND and slap that into make? That
is, the target name starts at the beginning of $SSH_ORIGINAL_COMMAND
and is terminated by the first non-alphanumeric char. This restricts
it to one target at a time, but I don't mind. Then make does the rest
of the parsing for me, generating an error if the requested target
isn't defined. There's still a possibility of stack overflow, so I
still need to know if there are any particular risks to worry about
when make is given a humongous undefined target or ssh is given a
humongous command. Though you'd think that if sshd was going to blow
up due to excessive input, it would blow up on the sending side,
right?

>  As added security, you can limit the IP address that the key is
>  valid from, so the key would only be useful from a specific network. 
I've done so, but I doubt it helps much  - I'd say by far the most
likely way for a bad guy to get his hands on my key would be to hack
the box where it lives, in which case this gives little extra
protection. that is, he can only attack from my machine, but we're
assuming he has the capability to do so.It becomes more likely that
I'll notice the activity, but I can't assume I'm safe.

Thanks for the reply,
Dave

[John Summerfield]

Dave Burns wrote:
>  
>  
>  What if a bad guy does get my key? Then I see three possible problems:
>  
>  1) somehow use make's -F switch in ssh command to change Makefiles?
>  2) stack overflow of make or ssh?
>  3) Somehow put extra command after make target using ';' or something?
>  
>  And obviously the bad guy can invoke any of the targets in my
>  makefile, but I've made them pretty innocuous.
>  
>  So, should I seriously worry about any of these potential problems?
>  Any other holes I haven't thought of?
>  
>  The motivation for all this is some cron jobs I want to run, obviously
>  calls for a passwordless ssh key, but I want to put some limits on it. 

I'm completely confused as to the whys and wherefores of what you're 
trying to do, but for the ungodly to do bad they'd
1. Need your credentials
2. Need to know your system's address
3. Need to be able to connect to it - iptables is really good for this
4. Need to know your account name
5. Need to know what it does and how to do it
6. Need a means to profit. The value (in their eyes) comes into this.

The last is a little difficult to estimate, conceivably someone might 
have an idea of how to profit that you can't imagine, maybe just for 
bragging rights in some peer group.

Finally, you need to be able to estimate the harm they could do if they 
did gain access. On my systems, they could send email, but IRC bots 
would not work, and they could not port-scan others (though testing ssh 
would work).





-- 

Cheers
John

-- spambait
1aaaaaaa(a)coco.merseine.nu  Z1aaaaaaa(a)coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375

You cannot reply off-list:-)

[Mikkel]

Dave Burns wrote:
>  I should probably ask this on an ssh oriented list, but I thought
> I'd
>  try my luck here first.
>  
>  I want to do some remote commands securely. I put a key in my
>  .ssh/authorized_keys file like so:
>  
>  command="/usr/bin/make $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC1[etc.etc.]
>  
>  so I can invoke make targets like so:
>  
>  ssh username@host target
>  
>  Assuming the bad guys never get my key, I am fine, even though it is
>  passwordless.
>  
>  What if a bad guy does get my key? Then I see three possible problems:
>  
>  1) somehow use make's -F switch in ssh command to change Makefiles?
>  2) stack overflow of make or ssh?
>  3) Somehow put extra command after make target using ';' or something?
>  
>  And obviously the bad guy can invoke any of the targets in my
>  makefile, but I've made them pretty innocuous.
>  
>  So, should I seriously worry about any of these potential problems?
>  Any other holes I haven't thought of?
>  
>  The motivation for all this is some cron jobs I want to run, obviously
>  calls for a passwordless ssh key, but I want to put some limits on it.
>  
>  Thanks,
>  Dave
>   
Instead of running make directly, run a script that does some
checking on what is supplied. You could limit the directories that
make could be run in, strip out any extra command, etc. (Search the
line for a ; , then log and discard the command if it is found.) You
could even disable the key if you get an invalid command.

As added security, you can limit the IP address that the key is
valid from, so the key would only be useful from a specific network.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Mikkel]

Manuel Arostegui Ramirez wrote:
>  
>  Morning Dave,
>  
>  This is such a dangerous thing, I have to say.
>  First off, and regarding to the fact of what a bad guy could do...
>  If he had acces to $command it means it would be able to know the key,
>  so he can log in without a problem in the remote machine (not just
>  executing remote commands which would involve a wee bit of experience
>  in Linux enviroments to know the remote paths and all that, if he got
>  access to the machine it would be easier. I hope I´m explaining myself
>  quite clear).
>   
I don't believe this is true. From the sshd man page:

command="command"
     Specifies that the command is executed whenever this key is
     used for authentication. The command supplied by the user (if
     any) is ignored. The command is run on a pty if the client
     requests a pty; otherwise it is run without a tty. If an 8-bit
     clean channel is required, one must not request a pty or should
     specify no-pty. A quote may be included in the command by
     quoting it with a backslash. This option might be useful to
    restrict certain public keys to perform just a specific
    operation. An example might be a key that permits remote backups
    but nothing else. Note that the client may specify TCP and/or
    X11 forwarding unless they are explicitly prohibited.  Note that
    this option applies to shell, command or subsystem execution.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

[Manuel Aróstegui]

2007/12/31, Dave Burns <tburns(a)hawaii.edu&gt;:
>  I should probably ask this on an ssh oriented list, but I thought
> I'd
>  try my luck here first.
>
>  I want to do some remote commands securely. I put a key in my
>  .ssh/authorized_keys file like so:
>
>  command="/usr/bin/make $SSH_ORIGINAL_COMMAND" ssh-rsa AAAAB3NzaC1[etc.etc.]
>
>  so I can invoke make targets like so:
>
>  ssh username@host target
>
>  Assuming the bad guys never get my key, I am fine, even though it is
>  passwordless.
>
>  What if a bad guy does get my key? Then I see three possible problems:
>
>  1) somehow use make's -F switch in ssh command to change Makefiles?
>  2) stack overflow of make or ssh?
>  3) Somehow put extra command after make target using ';' or something?
>
>  And obviously the bad guy can invoke any of the targets in my
>  makefile, but I've made them pretty innocuous.
>
>  So, should I seriously worry about any of these potential problems?
>  Any other holes I haven't thought of?
>
>  The motivation for all this is some cron jobs I want to run, obviously
>  calls for a passwordless ssh key, but I want to put some limits on it.
>  
Morning Dave,

This is such a dangerous thing, I have to say.
First off, and regarding to the fact of what a bad guy could do...
If he had acces to $command it means it would be able to know the key,
so he can log in without a problem in the remote machine (not just
executing remote commands which would involve a wee bit of experience
in Linux enviroments to know the remote paths and all that, if he got
access to the machine it would be easier. I hope I´m explaining myself
quite clear).

Secondly, keeping in mind he would log into as a user, he could change
makefiles owned by the user, and compile them, most likely, which lead
us to the fack being able to do really nasty things in your system.

I don´t see the point actually in doing what you´re doing to run cron
jobs in the remote machine, why don´t you just use the cron, It was
designed for that, what´s the point of running remote commands and
letting the key visible?

You asked if you should worry about all that. I´d do it.
We don´t know, yet, in which scenario all this is running into, if
you´re doing this between two system in your home, without being
exposed to the internet or with some kinda iptables rules to allow ssh
connections from one IP and all that..you know, we could let it go.
But from my point of view, and even being a small scenario (I really
want to hope you´re not using this in a production enviroment or
proffesional ones..), people should be concerned as much as possible
that someone can compromise your system, whether it is a small network
at home or a company huge network, it is much better to do not play
with fire. It is not too much effort to do things in a good way,
you´ll feel safer and you´d not let your network to be on risk,
techinically it will be, either if you do it good or bad (everybody
knows any machine on the internet is on risk), but it will be less
risky if you do things well.

Hope this helps.
Manuel.