NSEC2021 - Jeff Dileo and Addison Amiri - dRuby Security Internals
Channel: NorthSec
Date: 13/12/2021

dRuby is a "distributed object system" built into Ruby that is generally known to be insecure, but which has never been properly audited... until now. In this talk, we will discuss how dRuby works, where its insecurities lie, and how it is much more insecure than previously understood to be — which is a feat, considering that dRuby already provides code execution as a service. This talk will focus on a discussion of the dRuby API, its internals, and its underlying wire protocol, covering the security issues inherent in each along the way. As part of the this, we will also demonstrate several novel exploitation techniques that can be used against both dRuby servers and clients, the latter of which have not been known to be vulnerable until now. Following this, we will discuss some of our work to harden dRuby against each of the issues we identified. We will then close our talk by covering our work to exploit the exploits used to compromise dRuby-based services for some very ironic honeypotting.
dRuby is a "distributed object system" for Ruby (think CORBA or Java's RMI). Included in the Ruby standard library and implemented in vanilla Ruby without native extensions, it provides a simple-to-use interface to interact with Ruby objects from other Ruby processes, locally or over a network. While dRuby makes it fairly easy to expose objects and their interfaces to other processes, including those running on separate systems, it leaves a lot to be desired in terms of its security. While its own API documentation warns coyly of its insecurity with a simple-to-understand example exploit written in Ruby, the actual implementation and protocol of dRuby are not documented at all, nor are the actual risks dRuby exposes. While dRuby is well known to be a readily exploitable service enabling remote code execution, the underlying protocol exposes a number of additional risks that enable not only alternate methods of compromising dRuby services, but also the means to compromise dRuby clients.

In this talk, we will open with the background of how we found dRuby being used by a popular remote debugging dependency. We will then shift to an overview and technical discussion of dRuby and its protocol as defined by its implementation, starting with some basic examples of how to use dRuby. Following this, we will walk through an analysis of the network protocol guided by the traffic generated from our examples, and discuss how the data is processed, including a high-level discussion of the dual client-server peer-to-peer model used in dRuby. As part of this, we will also discuss the implementation of dRuby's remote method call scheme, data serialization, and proxy objects, including the default object reference scheme and ID mapper.

Throughout our discussion of dRuby's API, internals, and wire protocol, we will bring attention to and discuss relevant risks and vulnerabilities — and how they make dRuby fundamentally unsafe — and demonstrate several novel proof-of-concept exploits targeting dRuby services and clients. We will also discuss some of the existing advice and documentation for "securing" dRuby and how it fails to guard against dRuby's inherent issues.

Following this, we will briefly discuss our efforts to harden dRuby; the kinds of protocol, logic, and API changes needed to negate its issues; and additional considerations that should be taken into account not to expose further security issues.

-
Jeff is a security consultant by day, and sometimes by night. A Technical Director at NCC Group, he specializes in application security, and regularly assesses mobile device firmware applications, embedded platforms, web applications, and "privileged" code of all kinds. He has spoken publicly at conferences such as DEF CON, ToorCon, RECON, and CCC, covering a wide range of topics including Android and Java bytecode instrumentation, scriptable debugging, and, more recently, eBPF and unikernel security. A connoisseur of exotic candies and snacks, he enjoys starting arguments about text editors and window managers that he doesn't actually use. Jeff holds an MS in Computer Science from NYU Poly (Tandon).

Addison Amiri got his start in security in the mid-2000’s when he read about how easy it was to break WEP. From there, he’s meandered the world of security, through academia and industry, eventually entering the world of professional security consulting. Along the way, he’s had the opportunity to be simultaneously amazed at how well computers work and terrified that our lives now rely on them. These days he’s traveling the world and making the most of the cyberpunk dystopia.