RubyGems 2.6.13 validates names and DNS destinations

A package name becomes part of a filesystem operation, while a DNS response can become a network destination. Package summaries become terminal output. RubyGems 2.6.13 repairs vulnerabilities at each of these boundaries, where externally supplied metadata acquires effects beyond being an ordinary string.

Ruby's August 29 security notice reports four vulnerabilities in the RubyGems versions bundled with Ruby. The RubyGems 2.6.13 announcement had published the fixes on August 27. The issues include arbitrary file overwrite by a malicious gem, DNS request hijacking, terminal escape sequences and denial of service in the query command.

I find Ruby's consistent treatment of objects useful, but package metadata cannot be trusted merely because it has been decoded into ordinary Ruby values. The relevant validation depends on what the installer or client will do with each value. These fixes make that relationship visible in the implementation.

Installation validates the package name

The 2.6.12 to 2.6.13 source changes add verify_spec_name to the installer. The pre-install checks call it after ensuring that the specification can be loaded. A name that fails the allowed pattern raises Gem::InstallError before installation proceeds.

The allowed pattern contains letters, digits, periods, hyphens and underscores. It is anchored to the whole value. The important property for the installer is that an arbitrary package-controlled string is no longer accepted as a valid name at that stage. The release announcement identifies arbitrary file overwrite as the vulnerability this security release fixes in gem installation.

Specification validation also becomes more specific. It requires a String, at least one letter and a value matching the valid-name pattern. Those checks operate at the specification level, while the installer independently checks the name it is about to use. A validly loadable specification is not automatically a safe installation input.

That distinction is useful because a package file can arrive from outside the normal publication path. Relying solely on checks performed when an author packages or uploads a gem would leave the consuming installer dependent on another system having applied them. The install-time check evaluates the actual specification being consumed.

The repair should not be described as a complete sandbox for malicious gems. Its stated purpose is to prevent the file-overwrite vulnerability, and the code adds a specific name constraint. Installing a dependency remains an operation that consumes executable software. Correcting one way metadata can redirect file operations does not establish that every possible installed package is trustworthy.

DNS targets need parsing before the host check

The remote-fetcher change concerns the target obtained during API endpoint discovery. Previously the code tested whether the target string ended with a suffix based on the original host. The new code parses a URI and asks whether its actual host ends with the required dotted suffix.

This distinction matters because a URI-like string contains more structure than a hostname. A suffix test on the complete text is not necessarily a statement about the destination a URI parser will extract from it. Validation must inspect the same component that the later networking operation uses.

The new check obtains the parsed host from URI("http://" + target) before testing it. After that check succeeds, the code constructs the selected endpoint using the requested scheme, target and path. The parsed-host test is therefore placed before accepting that target as the destination for the request.

The announcement calls this a DNS request hijacking fix and credits Jonathan Claudius with discovery and Samuel Giddins with the repair. The source supports a precise account of the validation change. It does not justify claiming that all DNS responses are authenticated or that every network request made by Ruby gains a new security guarantee.

The practical lesson in this particular implementation is that parsing and validation must agree. Checking the end of a string can look like a host constraint while permitting a different interpretation by the consumer. Reading the parsed host makes the constraint refer to the component whose identity matters for the request.

Terminal output treats control characters as input

RubyGems also adds clean_text for displayable metadata. The helper replaces a defined range of non-printable control characters with periods. The query command applies it to entries before adding them to output, and text formatting starts with cleaned input.

Terminal text is another interface where bytes have effects beyond their printed appearance. Escape sequences can direct terminal behavior instead of appearing as inert package description text. Sanitizing the output prevents the affected control bytes from reaching the terminal unchanged through these paths.

The helper's implementation is specific. It does not remove every kind of whitespace or turn metadata into a general-purpose escaped representation. Its pattern targets the control ranges shown in the source. Describing it as a complete solution for rendering untrusted text in every context would go beyond the change.

This repair is relevant even when the user is only inspecting package information. Querying a remote package does not necessarily imply an intention to install or execute it. The output path therefore needs to handle hostile metadata independently of the installer's package-name checks.

I value this separation because command-line inspection is often treated as passive. A terminal interprets control bytes, so displaying remote metadata is an operation with its own input requirements. The fix handles that requirement where the text becomes output instead of assuming that an earlier package validation made it safe.

Query summaries receive a length boundary

The query command now truncates summaries before formatting them. The new helper defaults to a maximum of 100,000 characters and includes a notice when truncation occurs. It also rejects a nonpositive maximum. The release announcement identifies a denial-of-service vulnerability in the query command among the fixed issues.

Limiting input before formatting matters because the cost of processing a description can exceed the cost of merely storing the original string. The source moves a bounded summary into the formatting operation. The user still receives an explanation that the displayed text has been truncated instead of silently assuming it is complete.

The limit belongs to this helper and this processing path. It is not a global maximum on every gem metadata field or every network response. Its concrete role is to keep the query's summary formatting from operating on an unbounded description through the affected route.

Taken with control-character cleaning, this gives the display operation both content handling and a size boundary. Neither replaces the other. A short string can still contain terminal control bytes, while printable text can still be too large for an operation to process safely. The implementation addresses those properties separately.

Updating RubyGems can repair a bundled copy

The Ruby notice lists Ruby 2.2.7 and earlier in the 2.2 series, 2.3.4 and earlier in 2.3, and 2.4.1 and earlier in 2.4 as affected through their bundled RubyGems. It recommends RubyGems 2.6.13 or later as the repair when updating Ruby itself is not possible. The documented command updates the package manager.

gem update --system

The notice also supplies patch paths when RubyGems cannot be upgraded. For the Ruby 2.4.1 bundle it specifies applying the 2.6.11-to-2.6.12 patch before the 2.6.12-to-2.6.13 patch. That ordering reflects the bundled version and the inputs expected by each patch. Applying only the last diff to an arbitrary older installation is not the procedure the notice describes.

At this date the actionable change is the fixed RubyGems implementation, including installer name validation, parsed-host checking and bounded, cleaned query output. These are distinct repairs to the operations that consume package metadata, so confirming the installed Ruby interpreter version alone is insufficient to identify which RubyGems code a command will execute.

The RubyGems announcement supplies SHA256 checksums for its distribution archives and update gem. Those values allow a downloaded update artifact to be compared with the published release. That comparison answers a delivery question. It does not replace installing the corrected implementation or identify whether an application has already encountered hostile metadata.

The repairs also affect commands used outside a running web application. A build environment, developer shell or package-inspection process can invoke RubyGems with its own permissions and network access. The relevant installation is the one used by that command. Updating an application's Ruby dependencies through a lockfile is a separate operation from updating the RubyGems implementation that downloads, installs and displays them.