'Thousands' of businesses at mercy of miscreants thanks to unpatched Ray AI flaw Thousands of companies remain vulnerable to a remote-code-execution bug in Ray, an open-source AI framework used by Amazon, OpenAI, and others, that is being abused by miscreants in the wild to steal sensitive data and illicitly mine for cryptocurrency. This is according to Oligo Security, which dubbed the unpatched …
Neither am I, but it's important to note that this issue is only tangentially related to so-called "AI". Mostly it's just "crap developers create crap web API and other crap developers install and use it without any sort of due diligence".
I mean, this is an OWASP Top 10 failure right here. There are many points in the development cycle where someone at the various firms using this garbage should have said "wait, this is rubbish, stop using it".
So it's the usual basic failure in security engineering, and the basic failure of using a third-party component blindly.
I think that AI is designed to be very efficient and always generate accurate data results and processing for the people using AI to make sure that whatever they want to do is helped to work.
I've never seen anything in the AI world that sees "security" as far more significant then "accurate results" - I'm not saying that hacking is a feature in the AI design, it looks like it's just "processing" for hackers so AI may just be doing a "good job" working to meet the hackers questions?
The only way AI is involved in this is that Ray happens to usually be asked to execute jobs that run AI workloads.
As the linked to "best practices" points out "Ray faithfully executes code that is passed to it – Ray doesn’t differentiate between a tuning experiment, a rootkit install, or an S3 bucket inspection.".
Don't fall into the trap (that TFA does appear to push) that any if these vulnerabilities have anything to do with AI: that is just there to make these CVEs super sexy and relevant to how you live today.
I just see AI as "working" to make the users think that AI is working ... so I don't use it because I always feel I need to verify that things are working, not just be told they are working. I'm not assuming that AI doesn't work, I just feel that it's safer to verify that the answers are good.
I'm never confident that my views are accurate either, I just prefer to verify everything - I see detecting any mistakes as helping me learn about stuff.
Best practices
Security and isolation must be enforced outside of the Ray Cluster. Ray expects to run in a safe network environment and to act upon trusted code. Developers and platform providers must maintain the following invariants to ensure the safe operation of Ray Clusters.
1. Deploy Ray Clusters in a controlled network environment
Network traffic between core Ray components and additional Ray components should always be in a controlled, isolated network. Access to additional services should be gated with strict network controls and/or external authentication/authorization proxies. gRPC communication can be encrypted with TLS, but it is not a replacement for network isolation. Platform providers are responsible for ensuring that Ray runs in sufficiently controlled network environments and that developers can access features like Ray Dashboard in a secure manner.
2. Only execute trusted code within Ray
Ray faithfully executes code that is passed to it – Ray doesn’t differentiate between a tuning experiment, a rootkit install, or an S3 bucket inspection. Ray developers are responsible for building their applications with this understanding in mind.
> ...we designed it with piss poor security
No.
As the Ray site says, they don't claim it has *any* security, certainly none that could be described as "piss poor".
So they point out, at length (and as quoted elsewhere in the comments) that there is no security provided by Ray therefore you must apply security yourself.
Like, don't expose it to an untrusted network (e.g. the Internet).
Don't we often hear the mantra "do one thing and do it well"? Ray very explicitly doesn't claim to do security, that isn't its job, so if you *want* to expose its remote job execution API, it is up to you to select a way to do that which meets your security needs.
There are plenty of programs that provide an unsecured route to control them, such as a simple web server that provides an API and/or a friendly UI. You'd never dream of running them on a machine with port 80 open to the Internet, but you might well choose to run a secured web server that, after checking who it is talking to (and not on port 80!), will forward the request.
Yebbut...
The types of businesses likely to be running this are the same types of businesses who'd least be interested in securing their networks.
Cast your mind back to the yuppies of the '80s and you'll know precisely what the executives look like at these companies.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
