GHSA-p6pm-ch9v-44vx: 
Ruby vulnerability analysis and mitigation

Summary

Dalli's pipelined reply parser treated any reply line without a value body (for example CLIENT_ERROR or SERVER_ERROR) as the MN that ends the batch. It stopped reading that server's replies and left the rest on the connection, where later commands read them as their own replies. A later get could then return a different key's value.

Trigger

memcached answers CLIENT_ERROR for a key that is over 250 bytes on the wire. Dalli checked key length in characters, before base64-encoding keys that need it (non-ASCII or whitespace), so a key of under 250 characters could still be too long on the wire. If any part of a cache key comes from user input, a user can trigger this.

Impact

After such a batch, later reads on the same connection return values belonging to other keys, until the connection is reset. In an application that caches per-user data, one user can see another user's data. Affects multi-server get_multi (including Rails read_multi), get_multi with a block, and get_multi_cas. This is the same bug class as #1170, whose fix only exempted VA replies. With the binary protocol (the default before 5.0), the same over-long key made memcached drop the connection, and get or get_multi with it retried forever (see GHSA-4qp6-2jcr-596v), so a user-supplied key could hang requests.

Affected versions

• Wrong values: the meta protocol since 3.2.0 (the default since 5.0.0).
• Hang on an over-long key: the binary protocol in all versions before 5.0.

Fix

Only MN ends the pipeline; other bodyless replies are skipped. Keys are measured in bytes as sent (after base64 encoding for the meta protocol), and keys over the limit are truncated as other long keys always were. Keys that worked before are unchanged. Fixed in 5.2.1, 5.1.3, 5.0.9, 4.3.6 and 3.2.12.