This week on Pivots Talking Tuesday, I present to you Austin Vance speaking on using Ruby with Arduinos at Ruby Conf 2012. If you’re wondering what the thing is he’s standing next to, it’s a Ruby and Arduino powered tshirt cannon… and yes he fires it during his talk.

What’s the deal
Writing software is great, websites, applications, and scripts are things we interact with every day. What about writing software that we can interact with in the physical world? From automated sprinkler systems that turn off when you pull into your drive way, to scoreboards at the company foosball table physical computing opens a door for the innovator inside every software engineer.

It’s too hard
Not true, there are amazing libraries and compilers that let us write software for Arduinos in the best language, Ruby. Think about it no C, no headers, and no static types, just plain old ruby. That is a good deal.

In this talk I will go over a few of the most popular Ruby libraries for interacting with an Arduino, talk about some basics of each library and then spend time on how these libraries and Arduino can interact to create applications that respond in the physical world. There will be t-shirts shot from a robotic cannon.

A client recently expressed concern with a number of gems added to his project. A quick explanation and a little documentation cleared up what each gem was doing/why we needed it.

This satisfied the client, but it got me wondering: what’s the worst thing that could happen from a gem if it was malicious? The worst case I could imagine would be the client’s customer’s data getting stolen, the customers completely loosing faith in the site, and the client’s project failing because of it.

How likely is this to happen? I don’t really know.

How hard would it be for someone to do this?

I decided to see what it would take to harvest usernames and passwords from a typical Rails app using Devise for authentication. In less than 5 minutes, I had written an initializer which modified the behavior of the Devise controller to write out usernames and passwords to an HTML file in the public directory of the app.

The code wasn’t clever at all. I copied/pasted the create action, and added three extra lines to write out the data to the file.

So the answer to my question, how hard would it be for someone to write a malicious gem that would compromise customer data: dead easy.

I packaged up the code as a gem. Anyone can easily pwn their own Devise Rails app by adding the following line to their Gemfile:

gem 'devise_hack'

Of course, who would install a gem that would pwn their own app? No one, but what about a “long con” approach?

Say I wrote a useful gem, pushed updates occasionally, and got a decent level adoption. At this point I could push a new version of the gem which contained a little hack, and wait for the usernames and passwords to roll in. Maybe like this little guy…

gem 'awesome_rails_flash_messages'

This little gem takes all of your Rails flash messages and makes them more awesome. Simple as that. Ohh, it also logs and requests containing a password to a file AND posts it to an external web service, but that’s nothing to worry about.

So how do you avoid these malicious gems? For this dead simple hack, it is dead simple to identify. All you have to do is look at the source code. If you see code that is writing credentials to a file, maybe posting to an external web service, or sending emails when it really shouldn’t be… you might want to reconsider using that gem.