It’s kind of an iffy assertion. That’s maybe the number of files it scans looking for misconfigurations it can exploit, but I’d bet there’s a lot of overlap in the potential contents of those files (either because of cascading configurations, or because they’re looking for the same file in slightly different places to mitigate distro differences). So the number of possible exploits is likely far fewer.
Separate remote code execution vulnerability in unupdated versions of RocketMQ, a Chinese-developed messaging/streaming server, in the case of the infection described in the article. It’s possible that there are a few other RCE vulns it can make use of, but 20000 of them seems unlikely.
Like it’s trying to convince people Linux is inherently vulnerable.
I’m typing this reply from a machine running KDE Plasma on top of Linux Mint 22.
I’m not sure what precisely what you mean by “inherently” but I’d like to point that “Linux” has security problems all over the place; the kernel has issues, the DEs have issues, the applications have issues. It’s more secure than Windows but that’s not a very high bar.
I’ve been using Linux since 2005, and I’ve heard all sorts of stories about Linux having “security problems”, and almost every time it turns out to be a problem that can’t be exploited on it’s own. but requires the use of other vulnerabilities.
The only exception I can recall is the zx util compression tool, which was detected before it was rolled out.
Zero day vulnerabilities have been non existent for 20 years to my knowledge.
Okay, so as a n00b you can be somewhat forgiven. As someone who started with Slack in 1997 I don’t have that excuse.
…and almost every time it turns out to be a problem that can’t be exploited on it’s own. but requires the use of other vulnerabilities.
Since when did chaining vulnerabilities make something not a problem? Are you claiming that the CUPS vulnerability announced in late September isn’t an issue simply because it takes multiple steps?
The only exception I can recall is the zx util compression tool…
The whole thing sounds fishy. Like it’s trying to convince people Linux is inherently vulnerable.
Like WTF?
It’s kind of an iffy assertion. That’s maybe the number of files it scans looking for misconfigurations it can exploit, but I’d bet there’s a lot of overlap in the potential contents of those files (either because of cascading configurations, or because they’re looking for the same file in slightly different places to mitigate distro differences). So the number of possible exploits is likely far fewer.
So how did it get into the system to be able to scan configuration files?
Separate remote code execution vulnerability in unupdated versions of RocketMQ, a Chinese-developed messaging/streaming server, in the case of the infection described in the article. It’s possible that there are a few other RCE vulns it can make use of, but 20000 of them seems unlikely.
I’m typing this reply from a machine running KDE Plasma on top of Linux Mint 22.
I’m not sure what precisely what you mean by “inherently” but I’d like to point that “Linux” has security problems all over the place; the kernel has issues, the DEs have issues, the applications have issues. It’s more secure than Windows but that’s not a very high bar.
I’ve been using Linux since 2005, and I’ve heard all sorts of stories about Linux having “security problems”, and almost every time it turns out to be a problem that can’t be exploited on it’s own. but requires the use of other vulnerabilities.
The only exception I can recall is the zx util compression tool, which was detected before it was rolled out.
Zero day vulnerabilities have been non existent for 20 years to my knowledge.
Okay, so as a n00b you can be somewhat forgiven. As someone who started with Slack in 1997 I don’t have that excuse.
Since when did chaining vulnerabilities make something not a problem? Are you claiming that the CUPS vulnerability announced in late September isn’t an issue simply because it takes multiple steps?
I don’t mean to be an ass but were you asleep December 2021 through January 2022? Log4Shell was a 10 of 10 critical vulnerability!
What about CVE-2022-47939 from December 2022?
I can keep going if needed but I think my point is made. The vulnerabilities, even true kernel level stuff, are out there.