Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[security] Config.read: Use YAML.safe_load to avoid arbitrary Ruby class instantiation #334

Merged
merged 4 commits into from
Jun 1, 2018

Conversation

cben
Copy link
Collaborator

@cben cben commented May 31, 2018

Previously used YAML.load designed for deserialization from trusted sources only, allowing !ruby/object:AnyClass ... and other risky constructs.
The risk depends on ruby classes available in the application; sometimes a class may have side effects - up to arbitrary code execution - when instantiated and/or built up with x[key] = value during YAML parsing.

[See https://www.sitepoint.com/anatomy-of-an-exploit-an-in-depth-look-at-the-rails-yaml-vulnerability/ for one detailed example how YAML.load made Rails vulnerable, and ruby/psych#119 for more links]

Documented Config.read and Config.new better.

  • Documented when config may read other files from file system.
    Added tests for Config.new(data, nil) preventing this (this happens via TypeError, might improve to nicer exception but out of scope here). UPDATE: no it didn't prevent this ☹️, fixed in Really enforce Config.new(data, nil) prevents external file lookups #372.

  • Added warning that despite this fix, using untrusted config remains a questionable idea!

@moolitayer @grosser @pkliczewski @masayag please review.

@moolitayer, I want to release this quickly, possibly by myself. (Hence CHANGELOG and version bump all in one PR.)

cben added 3 commits May 31, 2018 20:33
…ass instantiation

Previously used YAML.load designed for deserialization from trusted sources
only, allowing `!ruby/object:AnyClass ...` and other risky constructs.
The risk depends on ruby classes available in the application; sometimes
a class may have side effects - up to arbitrary code execution - when
instantiated and/or built up with `x[key] = value` during YAML parsing.

Despite this fix, using untrusted config is still a questionable idea!
@@ -1,4 +1,4 @@
# Kubernetes REST-API Client
module Kubeclient
VERSION = '3.1.0'.freeze
VERSION = '3.1.1'.freeze
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bump should happen on master

CHANGELOG.md Outdated
@@ -4,6 +4,15 @@ Notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](http://keepachangelog.com/en/1.0.0/).
Kubeclient release versioning follows [SemVer](https://semver.org/).

## 3.1.1 - 2018-05-31
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should say ## Next

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, took out bump, changed this to "Unreleased"

@grosser
Copy link
Contributor

grosser commented May 31, 2018

👍 ... I guess version bumping is fine if this get's merged and released as it is ... but in general prefer not bumping in a PR

cben added a commit to cben/kubernetes-deploy that referenced this pull request May 31, 2018
dturn pushed a commit to Shopify/krane that referenced this pull request Jun 1, 2018
@cben cben merged commit 7e0d5d3 into ManageIQ:master Jun 1, 2018
@cben cben mentioned this pull request Jun 1, 2018
@cben cben added the bug label Jun 1, 2018
cben added a commit to cben/kubeclient that referenced this pull request Dec 2, 2018
Promised in README since 040d6ea (ManageIQ#334).
Didn't work - absolute path lookups were allowed!
Test passed because some of the paths were still relative.
cben added a commit to cben/kubeclient that referenced this pull request Dec 2, 2018
Promised in README since 040d6ea (ManageIQ#334).
Didn't work - absolute path lookups were allowed!
Test passed because some of the paths were still relative.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants