From: "marcandre (Marc-Andre Lafortune)" <ruby-core@...>
Date: 2013-03-14T02:24:14+09:00
Subject: [ruby-core:53378] [ruby-trunk - Feature #7292] Enumerable#to_h


Issue #7292 has been updated by marcandre (Marc-Andre Lafortune).


drbrain (Eric Hodel) wrote:
> There is a potential for a security exploit with Enumerable#to_h:
> 
>   user_input = %w[rm -rf /]
>   system ['ls', '-l'], *user_input
> 
>  With system, the first argument is used as the environment if it can be converted to a Hash. With user input to system this may lead to arbitrary code execution.

I think you are confusing `to_h` (explicit conversion) with `to_hash` (implicit conversion). `system` calls rb_check_hash_type which will attempt to call `to_hash` but will *not* send `to_h` on its argument.

So no, there is no such potential security risk here.
----------------------------------------
Feature #7292: Enumerable#to_h
https://bugs.ruby-lang.org/issues/7292#change-37577

Author: marcandre (Marc-Andre Lafortune)
Status: Assigned
Priority: Low
Assignee: matz (Yukihiro Matsumoto)
Category: core
Target version: next minor


Now that #to_h is the official method for explicit conversion to Hash, we should also add

	Enumerable#to_h: Returns a hash for the yielded key-value pairs.

	  [[:name, 'Joe Smith'], [:age, 42]].to_h # => {name: 'Joe Smith', age: 42}


With the Ruby tradition of succint documentation I suggest the documentation talk about key-value pairs and there is no need to be explicit about the uninteresting cases like:

    (1..3).to_h           # => {1 => nil, 2 => nil, 3 => nil}
    [[1, 2], [1, 3]].to_h # => {1 => 3}
    [[1, 2], []].to_h     # => {1 => 2, nil => nil}

I see some reactions of people reading about the upcoming 2.0 release like this one:
http://globaldev.co.uk/2012/11/ruby-2-0-0-preview-features/#dsq-comment-body-700242476



-- 
http://bugs.ruby-lang.org/