Skip to content

Authentication and extension bypass in Faye

High severity GitHub Reviewed Published Apr 28, 2020 in faye/faye • Updated May 16, 2023

Package

bundler faye (RubyGems)

Affected versions

>= 0.5.0, < 1.0.4
>= 1.1.0, < 1.1.3
>= 1.2.0, < 1.2.5

Patched versions

1.0.4
1.1.3
1.2.5

Description

On 20 April 2020 it was reported to me that the potential for authentication bypass exists in Faye's extension system. This vulnerability has existed in the Node.js and Ruby versions of the server since version 0.5.0, when extensions were first introduced, in July 2010. It is patched in versions 1.0.4, 1.1.3 and 1.2.5, which we are releasing today.

The vulnerability allows any client to bypass checks put in place by server-side extensions, by appending extra segments to the message channel. For example, the Faye extension docs suggest that users implement access control for subscriptions by checking incoming messages for the /meta/subscribe channel, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel === '/meta/subscribe') {
      if (message.ext.authToken !== 'my super secret password') {
        message.error = 'Invalid auth token';
      }
    }
    callback(message);
  }
});

A bug in the server's code for recognising the special /meta/* channels, which trigger connection and subscription events, means that a client can bypass this check by sending a message to /meta/subscribe/x rather than /meta/subscribe:

{
  "channel": "/meta/subscribe/x",
  "clientId": "3jrc6602npj4gyp6bn5ap2wqzjtb2q3",
  "subscription": "/foo"
}

This message will not be checked by the above extension, as it checks the message's channel is exactly equal to /meta/subscribe. But it will still be processed as a subscription request by the server, so the client becomes subscribed to the channel /foo without supplying the necessary credentials.

The vulnerability is caused by the way the Faye server recognises meta channels. It will treat a message to any channel that's a prefix-match for one of the special channels /meta/handshake, /meta/connect, /meta/subscribe, /meta/unsubscribe or /meta/disconnect, as though it were an exact match for that channel. So, a message to /meta/subscribe/x is still processed as a subscription request, for example.

An authentication bypass for subscription requests is the most serious effect of this but all other meta channels are susceptible to similar manipulation.

This parsing bug in the server is fixed in versions 1.0.4, 1.1.3 and 1.2.5. These should be drop-in replacements for prior versions and you should upgrade immediately if you are running any prior version.

If you are unable to install one of these versions, you can make your extensions catch all messages the server would process by checking the channel begins with the expected channel name, for example:

server.addExtension({
  incoming: function(message, callback) {
    if (message.channel.startsWith('/meta/subscribe')) {
      // authentication logic
    }
    callback(message);
  }
});

References

@jcoglan jcoglan published to faye/faye Apr 28, 2020
Reviewed Apr 29, 2020
Published to the GitHub Advisory Database Apr 29, 2020
Last updated May 16, 2023

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

EPSS score

0.388%
(74th percentile)

Weaknesses

CVE ID

CVE-2020-11020

GHSA ID

GHSA-qpg4-4w7w-2mq5

Source code

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.