Summary

On 2019-08-02 we at bitcrowd discovered a security vulnerability in simple_form. simple_form is one of the go-to ways to easily handle HTML forms in Ruby on Rails. The security issue allows arbitrary code execution in the worst case, but at least has potential for data corruption or DOS attacks. This security issue was responsibly disclosed by bitcrowd. Find details about the timeline of the events and a more detailed description below.

Links

• simple_form announcement
• the commit that fixed the issue

Description

On August 2nd 2019 developers at bitcrowd started a bug-fix ticket for one of its clients. The app in question is a CMS which offers its admins to configure custom key-value pair settings in the admin backend. The key of a setting was later used as the HTML <label> for a form implemented in simple_form. Thus, admins could control the input for the simple_form label method as shown in the following ERB template:

# Simplified version of the ERB template resulting in discovery of the security issue

<%= simple_form_for @important_record do |f| %>
  <%= f.label @user_supplied_string %>
  ...
  <% end %>
<% end %>

One of the admins added a setting with the key tap which resulted the later <label>-generation to throw a 500 server error. It seemed like the tap method was called with insufficient arguments.

During the inspection of that error, it turned out that calling f.label causes simple_form to executed a method with the given label name — tap in this case — on the forms object. This means that calling f.label 'delete' would result in deleting the @important_record in case it is an ActiveRecord object. In general, almost any method could be called on the forms object leading to a potential arbitrary code execution vulnerability. The exception are methods containing password, time_zone, country, email, phone, and url since these methods are handled differently as shown later in the code examples.

We did fix the issue with a work around for our client and deployed that to production. In addition we planned to responsibly report this issue to plataformatec, the author of simple_form.

For the report to be constructive, we attempted to find the cause of this bug. Since the cause is hidden behind only three methods, we outline our journey here. Please follow the # 👉 comments, they will provide further context to the simple_form source code:

module SimpleForm
  class FormBuilder < ActionView::Helpers::FormBuilder

    # 👉 The form builder is what we call in our ERB template within `simple_form_for`.
    # 👉 In our vulnerable code above, we called `f.label @user_supplied_string`.
    # 👉 This is the `label` method we called 👇

    def label(attribute_name, *args)
      return super if args.first.is_a?(String) || block_given?

      options = args.extract_options!.dup
      options[:label_html] = options.except(:label, :label_text, :required, :as)

      column      = find_attribute_column(attribute_name)

      # 👉 to generate the label HTML, simple_form creates the whole `<input>` object
      # 👉 to just return the <label> part of it. To create a valid `<input>`, however,
      # 👉 it must know which type the input should have. Since we didn't specify it
      # 👉 e.g. with `f.label 'delete', as: :string` simple_form needs to guess.
      input_type  = default_input_type(attribute_name, column, options)
      SimpleForm::Inputs::Base.new(self, attribute_name, column, input_type, options).label
    end

    # ...

    def default_input_type(attribute_name, column, options)
      # 👉 If you provide the `as:` option, it returns what was given with that option.
      # 👉 This way the vulnerable code is never executed.
      # 👉 However, in our case we didn't provide that option.
      return options[:as].to_sym if options[:as]
      custom_type = find_custom_type(attribute_name.to_s) and return custom_type
      return :select             if options[:collection]

      # 👉 in the following case statement simple_form attempts to guess which type
      # 👉 of <input> you want. This is done by checking some common name patterns.
      input_type = column.try(:type)
      case input_type
      when :timestamp
        :datetime
      when :string, :citext, nil
        case attribute_name.to_s
        when /(?:\b|\W|_)password(?:\b|\W|_)/  then :password
        when /(?:\b|\W|_)time_zone(?:\b|\W|_)/ then :time_zone
        when /(?:\b|\W|_)country(?:\b|\W|_)/   then :country
        when /(?:\b|\W|_)email(?:\b|\W|_)/     then :email
        when /(?:\b|\W|_)phone(?:\b|\W|_)/     then :tel
        when /(?:\b|\W|_)url(?:\b|\W|_)/       then :url
        else
          # 👉 some names, like `delete` are not matched by the regular expressions above
          # 👉 so it tries to guess if the given name is a method returning some kind of file
          file_method?(attribute_name) ? :file : (input_type || :string)
        end
      else
        input_type
      end
    end

    # ...

    def file_method?(attribute_name)
      # 👉 the "is it a file?" check is done by calling the method and inspecting the result.
      # 👉 This is where our given label-name is called as a method on the forms object 🔥
      # 👉 `@object.send(attribute_name)`
      file = @object.send(attribute_name) if @object.respond_to?(attribute_name)
      file && SimpleForm.file_methods.any? { |m| file.respond_to?(m) }
    end
  end
  end

Now that we had the cause of the bug, we could contact plataformatec about the issue at opensource@plataformatec.com.br. When reporting security vulnerabilities take care of how to report them. A good first source of how to behave can be found in the OWASP Vulnerability Disclosure Cheat Sheet. There is some danger in reporting security vulnerabilities the wrong way, or them being taken wrong by the author. So consider your options and consult a lawyer in case there are any uncertainties.

We decided to report the vulnerability responsibly to give plataformatec the needed time to release a fix for the issue. Plataformatec was very responsive on our first mail and provided us ongoing feedback about the state of the fix (without any lawyers involved ;)).

We can only thank them for open sourcing simple_form in the first place, and for handling security issues responsibly.

Timeline

• 2019-08-02: Discovered the issue and reported it to opensource@plataformatec.com.br
• 2019-08-02: Answer from plataformatec, that they received the issue
• 2019-08-09: Confirming the issue, they are working on a fix “for next week”
• 2019-09-19: Update from plataformatec including a source code diff with a potential fix. They said to request a CVE and prepare an announcement, and release the fix “next week”
• 2019-09-21: Bitcrowd proposed potential improvements on the fix
• 2019-09-24: We found that a suggested code change would be too hard to maintain and that the security contact should be listed more prominently. Also both parties are preparing announcements on the issue.
• 2019-09-27: Simple Form version 5.0 released, including the fix