3 ms·
I became aware of this problem this morning when it was discussed on a public github issue. I think the problem has been known for a couple of weeks. I checked
by benmmurphy 14y ago
I became aware of this problem this morning when it was discussed on a public github issue. I think the problem has been known for a couple of weeks. I checked latest rack and active_support gem (would seem to be good targets...) to see if they had been backdoored but they were clean. Not sure if these gems are still clean or if any others have been compromised.
- vinhboy 14y agoconsider me a fan of your work!
- timdorr 14y agoNow would be a good time to build up a quick script to compare the last modification time of the files on S3 against the updated_at of any gem record in the system. If the delta is too long, that would be a candidate for deeper investigation.
- nirvdrum 14y agoHopefully they use S3 bucket versioning. Rolling back would be pretty easy then.
- daveungerer 14y agoI'd be interested in seeing this github issue. Link please?
- benmmurphy 14y agohttps://github.com/tenderlove/psych/issues/119#issuecomment-12875715 https://github.com/tenderlove/psych/issues/119#issuecomment-...
- daveungerer 14y agoAh, so were were supposed to look at the .yml files included in your exploit gem? Which contained some injected code that would then run on the rubygems server?
- benmmurphy 14y agonot my exploit gem. the code was in the metadata part and I believe someone else has posted it in this thread.
- deleted 14y ago[deleted]
- rmc 14y agoto see if they had been backdoored but they were clean You can never be too sure. There's a whole contest (http://underhanded.xcott.com/ http://underhanded.xcott.com/) whose goal is "make something that looks legit, but actually does something evil / has an exploit). Nuke from orbit.
- benmmurphy 14y agoi diffed the rack gem and active_resource gem from the versions built from git. i'm fairly sure the versions i downloaded were not compromised.