Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
What's the worst that could happen if your app has a dependency on a malicious gem? How easy would it be to write a gem that could compromise a box? Much of the Ruby community blindly trusts our gems. This talk will make you second--guess that trust, and show you how to vet gems that you do choose to use.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the talk titled "Hacking with Gems," presented by Ben Smith at the Ancient City Ruby 2013, the speaker explores the risks associated with trusting third-party gems in Ruby applications. The central theme revolves around the potentially malicious behavior that could be embedded in Ruby gems, and Ben Smith aims to raise awareness about the importance of scrutinizing code dependencies in software development. Key points discussed include: - **Introduction to the Topic**: Ben differentiates between ‘hacking on gems’ and ‘hacking with gems,’ the latter focusing on how malicious code could be introduced into applications through trusted dependencies. - **Confession of Non-Expertise**: Ben acknowledges his lack of formal security training while explaining concepts in a manner accessible to a general developer audience. - **Concept Demonstration**: The talk features several hypothetical gem examples that appear innocent but include harmful functionalities, demonstrating how easy it is to disguise malicious code: - **Awesome Rails Flash Messages**: A gem that seems to enhance Rails flash messages but secretly harvests user credentials by logging sensitive data to a web service. - **Net HTTP Detector**: A gem that detects HTTP requests made by other gems, potentially logging sensitive data transmissions. - **Better Date to US**: A gem that claims to modify date formats but could actually compromise application source code. - **Be Truthy**: An empty gem that pretends to offer functionality but executes harmful code upon installation, allowing remote access to compromised systems. - **Viral Malicious Gems**: Ben explains the potential for maliciously coded gems to spread throughout the Ruby community via trusted dependencies. He prescribes measures to prevent such occurrences: - **Caution in Dependencies**: Developers should thoroughly vet gems before installation using tools to track network activities and filesystem changes. - **Sign and Trust your Gems**: Leveraging signing mechanisms using public/private keys to ensure the integrity of the code being used. - **Monitoring and Sandboxing**: Encouraging the use of isolated environments to test gems before full integration. - **Conclusions and Advice**: The talk finishes with a warning about the risks of installing untrusted gems. Ben strongly advises developers to: - Favor writing custom code over relying on external gems. - Monitor the behavior of gems during and after installation to detect any malicious activity. - Use tools like Coal Mine Canary to identify and respond to security risks efficiently. Ultimately, Ben hopes to empower developers to critically evaluate the dependencies they incorporate into their projects, fostering a more secure programming environment within the Ruby community.
Suggest modifications
Cancel
