Update on Ray CVEs CVE-2023-6019, CVE-2023-6020, CVE-2023-6021, CVE-2023-48022, CVE-2023-48023

TLDR: 

• 4 of the 5 reported CVEs (CVE-2023-6019, CVE-2023-6020, CVE-2023-6021, CVE-2023-48023) are fixed in master and will be released as part of Ray 2.8.1.

• The remaining CVE (CVE-2023-48022) - that Ray does not have authentication built in - is a long-standing design decision based on how Ray’s security boundaries are drawn and consistent with Ray deployment best practices, though we intend to offer authentication in a future version as part of a defense-in-depth strategy.

In recent days, security researchers have published reported vulnerabilities (known as CVEs) on the national vulnerability database (NVD) regarding the Ray open source project.

We’d like to provide some context and an update. As of the date of this post, 4 of the 5 reported bugs have already been fixed; 2 of the 4 were merged to Ray 2.8 prior to the publication of the CVEs. If you are running Ray on Anyscale, we have deployed a server-side fix to mitigate these bugs.

Note that we are referring to these reported vulnerabilities as bugs rather than vulnerabilities.  This is because Ray, as its core value proposition, is designed to provide arbitrary remote code execution (RCE) as-a-service. So, for instance, while it was clearly a bug (now fixed) that permits malformed URL queries to the Ray Dashboard to execute arbitrary code, if a user has the ability to send the Ray Dashboard an HTTP request, that same user, by design, also has the ability to directly request it to execute the same arbitrary code, because the Ray dashboard is within the security boundary of the Ray cluster, and so there is no additional privilege that user is getting as a result of the bug.

Due to Ray’s nature as a distributed execution framework, Ray’s security boundary is outside of the Ray cluster. That is why we emphasize that you must prevent access to your Ray cluster from untrusted machines (e.g., the public internet).

This is why the 5th CVE (the lack of authentication built into Ray) has not been addressed, and why it is not in our opinion a vulnerability, or even a bug.

We have considered very seriously whether or not something like that would be a good idea, and to date have not implemented it for fear that our users would put too much trust into a mechanism that might end up providing the facade of security without properly securing their clusters in the way they imagined.

That said, we recognize that reasonable minds can differ on this issue, and consequently have decided that, while we still do not believe that an organization should rely on isolation controls within Ray like authentication, there can be value in certain contexts in furtherance of a defense-in-depth strategy, and so we will implement this as a new feature in a future release.

If you’re interested, like we are, in making Ray as secure as it can be, you might be a great person to work at Anyscale. Please reach out to recruiting@anyscale.com if you’re interested.

If you have any questions, please contact us at security@anyscale.com .