[Rubygems-developers] Need to release 0.9.1 due to security exploit

Eric Hodel drbrain at segment7.net
Wed Jan 17 21:16:59 EST 2007


On Jan 16, 2007, at 14:11, Paul Duncan wrote:
> Easy is certainly subjective, but there are a couple ways to "fix" the
> documentation hole:
>
> * RubyGems could pre-generate documentation and just copy it into
>   place (I don't like this solution; it makes gems significantly  
> larger).
> * RubyGems should create an initial documentation directory
>   elsewhere, then drop root permissions (maybe even chroot() as well)
>   and generate the documentation as a user with no privileges in the
>   safe location, then move the generated documentation into place.
>
> The second option is preferrable, and it's actually a lot easier to
> implement than it sounds.  I have a half-working patch that I can  
> clean
> up and submit if there's any interest.  Basically it just creates a  
> copy
> of the source in a temporary directory, then forks a child
> process which chroot() itself and drops it's permissions before
> generating any documentation.  The parent waits for the child to exit,
> then copies the generated documentation into place.

Can you post this one to the tracker?

> Unfortunately that doesn't really fix much of anything, because it  
> only
> closes off the huge security hole in documentation generation.  It
> doesn't prevent a malicious user from trojaning an existing gem and
> adding files or replacing legitimate code with pretty much
> whatever they want.
>
> The _really_ bad news is this type of attack became a whole lot easier
> once RubyGems started using mirrors.  Instead of worrying about a
> malicious user breaking into one machine (rubyforge.org), we now  
> have to
> worry about them breaking into N machines, where N is the number of
> Gem mirrors.
>
> The only way to completely eliminate this type of attack would be to
> force gem authors to sign their gems, create an author certificate
> distribution mechanism (or tie it to some sort of existing trust
> mechanism like X.509 or PGP keyservers [1]), remove all the unsigned
> gems from the Gem repositories, and (finally) enable signature  
> checking
> by default in RubyGems.
>
> Frankly, I don't see all of that (or any of it, really) happening any
> time soon.

Could we mitigate that by including a list of SHA1s of packages on  
the rubyforge gem server, and use it to validate packages from mirrors?

> The idea behind all the above steps is to assume the contents of
> packages can and eventually will be tinkered with, and to provide a  
> way
> for users to be reasonably certain that nothing fishy has happened to
> packages once they're out of the authors' hands and on the Gem
> repositories.

-- 
Eric Hodel - drbrain at segment7.net - http://blog.segment7.net

I LIT YOUR GEM ON FIRE!



More information about the Rubygems-developers mailing list