I've made a few changes to mod-auth-pgsql2 v2.0.3 for a project I'm working on.

The goal was to allow Subversion to authenticate user credentials against an ActiveRBAC users table.

I needed to use a Ruby on Rails ActiveRBAC users table with salted md5 passwords, where the salt is stored in a separate column. Unfortunately, there was really nothing out there in the public domain to do this.

With this patch, there are two new auth modes: SALTMD5 and SALTEDMD5.

The SALTMD5 mode was my attempt to use md5hash to authenticate an MD5'ed hash.

                Auth_PG_hash_type SALTMD5
                Auth_PG_salt_table users
                Auth_PG_salt_field password_salt

Unfortunately, the output of apr's md5hash() function didn't seem compatible with the RFC-1321 style postgres md5() function output.

Rather than fight with it, I decided to quickly add a new function, get_pg_saltedpw, that would do a select with an embedded postgres md5() function to do the actual salted compare.

                Auth_PG_hash_type SALTEDMD5
                Auth_PG_salt_table users
                Auth_PG_salt_field password_salt
                Auth_PG_salt_selectclause select %s from %s where %s='%s' and %s=md5( '%s' || %s )

Anyway, the patch is below, should you wish to do with it however you choose. It's not much, and far from perfect, but someone may benefit from it in the future.

Download: mod-auth-pgsql-2.0.3+salt.diff

Ciao!

I've been listening on #rails-security on IRC for a while now, and there doesn't appear to be much headway describing what bugs were fixed by what patches.

There are at least two "bugs" going on here:

• HTTP_LOAD_PATH can be set to upload ruby content to a server, and then have it executed in the context of the running rails instance. This is what the majority of the hubub was all about.
• There's an unspecified routing bug that will, at a minimum, let people run your schema.rb and blow away your database. There is also mention of this being the cause of some DoS cases.

Security Focus has listed the "vulnerability" in as much as they have some basic patch information as regurgitated from the Rails core blog posts, and no real full disclosure.

The 1.1.5 release didn't fix all of the exploitable conditions. Which conditions? I don't know, I haven't had the time to reverse engineer the diff to 1.1.6 and figure it out. Hooray for full disclosure.

We started "upgrading" all of our 0.13 and 1.0.x rails projects to 1.1.5 as there was no point release patch option at the time. Neither did we know that anything prior to 1.1.x wasn't exploitable.

By the time 1.1.6 came out to fix 1.1.5, I had already upgraded all of our projects. At that point, an upgrade to 1.1.6 was really quite minor.

This post to the django-developers list pretty well sums up our feelings about this fiasco.

Evan Weaver's posts follow this folly better than anything else out there.

Why haven't the "bugs" been individually listed, fully explained, with mention of the specific updates that fixed it (1.1.5 vs 1.1.6, etc). Are we still avoiding full disclosure? The 1.1.6 blog post claims to be full disclosure, but doesn't do a particularly good job of accomplishing that goal.

It's sad that the core rails team isn't addressing this better. Reading the 1.1.6 blog post comments, I'm sure they're learning the hard way with this one.

To their credit: they did eventually come out with patches against given point releases with the 1.1.6 blog post.

At least one person on IRC has confided in me that the patches didn't work from them. I didn't get a chance to test those patches, so caveat emptor.

Twice in two days. I get to upgrade to rails 1.1.6, which is likely to break Engines if I'm reading this correctly.

Mark my words, I doubt this patch fest is over yet.

Look for 1.1.7 tomorrow to fix the broken Engines.

Rather than fess up with full disclosure to the new rails hole, we're told to update to rails 1.1.5 to fix an unspecified security problem

How difficult is it to diff two source trees and find patched code? Seriously.

Looking at the diff between 1.1.4 and 1.1.5, a few changes are apparent:

• Changes to path handling code in ActionMailer
• Addition of attachment handling/multipart code
• Changes to path handling code in ActionViewer

and this nice little test function:

  def test_sql_injection_via_find
    assert_raises(ActiveRecord::RecordNotFound) do
      Topic.find("123456 OR id > 0")
    end

    assert_raises(ActiveRecord::RecordNotFound) do
      Topic.find(";;; this should raise an RecordNotFound error")
    end
  end

I get nothing out of the IRC channels except tpope suggesting that the find() test might be a red herring to throw people off the path.

What the heck?

So I'm madly patching boxes now with some unknown fix to a problem I haven't a clue about.

Thanks guys.