Feel free to add/edit/delete.
On Thu, Nov 7, 2013 at 12:27 PM, John Chilton <chilton(a)msi.umn.edu> wrote:
The project has had a lot of contributors over the years, it is
probably not safe to assume they have all been "experts" and
frequently "experts" know of little tricks or shortcuts that can
result in a lot of trouble (this case in point) - a less sophisticated
developer probably would not have even known about the Python
functionality that resulted in this trouble.
I suspect the mere fact that you are concerned about writing secure
tools means you would do a better job than many professional software
developers whom you may term as "experts". Furthermore, you are
absolutely right there should be some documentation or something
somewhere to aid in writing secure tools - the rest of this e-mail
contains a couple quick notes hopefully it can be translated to the
wiki at some point and grown over time.
If your tool is not taking in text inputs - its all numbers and
select parameters, etc.... it is very likely secure. These sorts of
vulnerabilities would usually come into play when users are allowed to
pass free text and the tool or wrapper use this text in such a way
that it can be broken out of the intended context (these are broadly
characterized as code injection attacks). 95% of how these text
parameters are going to be used is likely passing them as a
command-line argument to another program. For this reason Galaxy
preprocesses the text and sanitizes it so it cannot contain characters
that would result in the text easily result in code injections.
So for this reason - you are still probably fine unless you are
"circumventing" this text preprocessing. For instance, Galaxy will
translate quotations marks to '__dq__', this tool explicitly
retranslates those back to quotations marks
There is a reason to do this in this case but you will not need for
most bioinformatics applications. If your tools are doing this it is
time to start getting extra careful.
If you are really interested in this topic or when it is time to get
extra careful, I would recommend picking up the book "The Web
Application Hacker's Handbook" - it is pretty good. Most of it would
not be relevant for tool developers, but chapter 1, chapter 2, and all
of chapter 9 could be very relevant and would probably leave one with
a solid grasp of what to look for in many different contexts - not
just the ones the book discusses explicitly.
Hopefully over time the IUC will provide guidance about this sort of
thing (informing you if there are potential security vulnerabilities
in your tools). Also feel free to post example tool configurations to
this list you might be concerned about and I am sure someone would be
happy to look it over and tell you if there are any red flags.
On Tue, Nov 5, 2013 at 12:30 PM, Ido Tamir <tamir(a)imp.ac.at> wrote:
> On Nov 5, 2013, at 6:28 PM, Nate Coraor <nate(a)bx.psu.edu> wrote:
>> Hi Ido,
>> Thanks for the feedback. Replies below.
>> On Nov 5, 2013, at 9:54 AM, Ido Tamir wrote:
>>> This seems to happen often e.g.
>> I'm not sure I'd agree that it's often - we've had 4 or 5
vulnerabilities over the life of the project. 2 allowed arbitrary code
execution, the others were less severe.
> But these were written by experts, not by people like me, that don't
know what the galaxy framework really does/does not do with the input, so I
guess I make many more mistakes.
>>> a) are there general guidelines in the wiki on how to avoid these
problems when creating tools?
>> The guidelines for writing a Galaxy tool are no different from best
practices for writing secure code. In specific for this vulnerability,
execution of user input should be handled with extreme care, and this tool
had some gaps in its input validation and sanitization. For what it's
worth, the filter tool (on which the other vulnerable tools were based) is
one of the few tools surviving from the very early days of Galaxy, and
would not be implemented the same way if written today.
> I think it would be nice to have a small outline on the wiki of what
galaxy does with the input data and how it could affect a tool.
> What sanitisation is there by default so I don't have to worry about it,
but what could happen I if I don't care to check/remove sanitise ' | or "
..., maybe with examples.
>>> b) is there a way to check automatically if all input fields are
correctly escaped in a tool?
>> I am not sure how Galaxy could do this. Galaxy sanitizes the command
line so that input fields passed to a tool as command line arguments cannot
be crafted to exploit the shell's parsing rules.
> Thats good
>> What the tool itself does with its inputs are out of Galaxy's control.
>>> A search for security in the wiki brings up:
>>> • Admin/Data Libraries/Library Security
>>> 0.0k - rev: 1 (current) last modified: 2013-01-02 23:54:33
>>> • Admin/DataLibraries/LibrarySecurity
>>> 19.2k - rev: 4 (current) last modified: 2013-01-03 00:12:36
>>> • HelpOnConfiguration/SecurityPolicy
>>> 1.9k - rev: 1 (current) last modified: 0
>>> • Learn/Security Features
>>> 7.0k - rev: 3 (current) last modified: 2011-09-13 16:52:08
>>> • News/2013_04_08_Galaxy_Security_Release
>>> 1.3k - rev: 3 (current) last modified: 2013-04-08 16:56:41
>>> "escape" does not bring up anything.
>>> thank you very much,
>>> On Nov 5, 2013, at 12:45 AM, Nate Coraor <nate(a)bx.psu.edu> wrote:
>>>> A security vulnerability was recently discovered by John Chilton with
Galaxy's "Filter data on any column using simple expressions" and
on ambiguities in polymorphism datasets" tools that can allow for arbitrary
execution of code on the command line.
>>>> The fix for these tools has been committed to the Galaxy source. The
timing of this commit coincides with the next Galaxy stable release (which
has also been pushed out today).
>>>> To apply the fix and simultaneously update to the new Galaxy stable
release, ensure you are on the stable branch and upgrade to the latest
>>>> % hg branch
>>>> % hg pull -u
>>>> For Galaxy installations that administrators are not yet ready to
upgrade to the latest release, there are three workarounds.
>>>> First, for Galaxy installations running on a relatively new version
of the stable release (e.g. release_2013.08.12), Galaxy can be updated to
the specific changeset that that contains the fix. This will include all
of the stable (non-feature) commits that have been accumulated since the
8/12 release plus any new features included with (and prior to) the 8/12
release, but without all of the new features included in the 11/4 release.
Ensure you are on the stable branch and then upgrade to the specific
>>>> % hg pull -u -r e094c73fed4d
>>>> Second, the patch can be downloaded and applied manually:
>>>> % wget -o security.patch
>>>> and then:
>>>> % hg patch security.patch
>>>> % patch -p1 < security.patch
>>>> Third, the tools can be completely disabled by removing them from the
tool configuration file (by default, tool_conf.xml) and restarting all
Galaxy server processes. The relevant lines in tool_conf.xml are:
>>>> <tool file="stats/dna_filtering.xml" />
>>>> <tool file="stats/filtering.xml" />
>>>> The full 11/4 Galaxy Distribution News Brief will be available later
today and will contain details of changes since the last release.
>>>> Galaxy Team
>>>> Please keep all replies on the list by using "reply all"
>>>> in your mail client. To manage your subscriptions to this
>>>> and other Galaxy lists, please use the interface at:
>>>> To search Galaxy mailing lists use the unified search at:
> Please keep all replies on the list by using "reply all"
> in your mail client. To manage your subscriptions to this
> and other Galaxy lists, please use the interface at:
> To search Galaxy mailing lists use the unified search at:
Please keep all replies on the list by using "reply all"
in your mail client. To manage your subscriptions to this
and other Galaxy lists, please use the interface at:
To search Galaxy mailing lists use the unified search at: