continuum-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent N Atkinson (JIRA)" <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (CONTINUUM-1200) Password Characters Not Supported in SCM Checkout
Date Thu, 24 Jul 2008 16:17:26 GMT

    [ http://jira.codehaus.org/browse/CONTINUUM-1200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143034#action_143034
] 

batkinson edited comment on CONTINUUM-1200 at 7/24/08 11:16 AM:
-----------------------------------------------------------------------

This is also true when specifying SCM username/pass in the release plugin functionality. The
general problem is that commands are run using a command shell. Username and password are
concatenated into these commands without protecting the command interpreter from special characters,
if present. This is a security vulnerability as well. Because my password is inserted directly
into a shell command, I can use a specially crafted username or password to do some really
nasty things.

Unfortunately, because continuum uses the shell, any solution will raise portability concerns.
For instance, if we assume bash we can use the special $'' quoting feature:

 svn --username $'it\'s cool' --password $'but don\'t try this in tcsh or in window\'s' 

However, this is not portable across all target platforms.

Perhaps it would be possible to detect the shell that the continuum is running in by executing
carefully crafted commands on startup. Once the shell is detected, the proper procedure could
be chosen for escaping. For instance, if there is support for bash's quoting style, use it
in combination with escaping single quotes in passwords with a backslash. If using windows,
use an appropriate scheme, tcsh another, etc. 

Another alternative is to allow continuum administrators to configure the shell as part of
setup. Yet another would be don't bake in the commands at all, allow the administrators to
edit configuration files with the commands.

At the very least, I think securing it is a wise choice. The easiest short term fix would
probably be to use double quotes and escape double quotes present in the values with a backslash.
This would clear up  the security issue, and would support most special characters which would
be significantly better than the current solution. The only big problem would be parameter
expansion in values that contained $ (or double-% on windows). You could approach this with
one of the techniques above, or you could simply detect problem values and give the user feedback
that their password is not supported.

      was (Author: batkinson):
    This is also true when specifying SCM username/pass in the release plugin functionality.
The general problem is that commands are run using a command shell. Username and password
are concatenated into these commands without protecting the command interpreter from special
characters, if present. This is a security vulnerability as well. Because my password is inserted
directly into a shell command, I can use a specially crafted username or password to do some
really nasty things.

Unfortunately, because continuum uses the shell, any solution will be raise portability concerns.
For instance, if we assume bash we can use the special $'' quoting feature:

 svn --username $'it\'s cool' --password $'but don\'t try this in tcsh or in window\'s' 

However, this is not portable across all target platforms.

Perhaps it would be possible to detect the shell that the continuum is running in by executing
carefully crafted commands on startup. Once the shell is detected, the proper procedure could
be chosen for escaping. For instance, if there is support for bash's quoting style, use it
in combination with escaping single quotes in passwords with a backslash. If using windows,
use an appropriate scheme, tcsh another, etc. 

Another alternative is to allow continuum administrators to configure the shell as part of
setup. Yet another would be don't bake in the commands at all, allow the administrators to
edit configuration files with the commands.

At the very least, I think securing it is a wise choice. The easiest short term fix would
probably be to use double quotes and escape double quotes present in the values with a backslash.
This would clear up  the security issue, and would support most special characters which would
be significantly better than the current solution. The only big problem would be parameter
expansion in values that contained $ (or double-% on windows). You could approach this with
one of the techniques above, or you could simply detect problem values and give the user feedback
that their password is not supported.
  
> Password Characters Not Supported in SCM Checkout
> -------------------------------------------------
>
>                 Key: CONTINUUM-1200
>                 URL: http://jira.codehaus.org/browse/CONTINUUM-1200
>             Project: Continuum
>          Issue Type: Bug
>          Components: SCM
>    Affects Versions: 1.1-alpha-1
>            Reporter: Stephen Duncan Jr
>             Fix For: 1.x
>
>
> Certain characters are not supported for the password for an SCM checkout.  For instance
if a ')' is the first character, then the command fails.  This is because the password is
provided as a CLI parameter, and is not surrounded by quotes.  Obviously, adding quotes might
break other passwords, so it would be best to pass the password along some other way.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message