From Newsgroup: comp.unix.shell

So, there is this new *nix-specific rCLvulnerabilityrCY that cleverly
encodes the malicious commands in the file name, not the file contents <https://www.trellix.com/blogs/research/the-silent-fileless-threat-of-vshell/>.

Except I donrCOt understand how you could fall for it. All the examples
they give for the exploit involve the use of the rCLevalrCY command on
that filename string ... well, duh.

This part is equal parts mystifying and amusing:

[missing pronoun?] cannot manually create a file with this name in
the shell due to its special characters being interpreted as
command syntax

DonrCOt they know anything about *nix command shells?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 27.08.2025 09:48, Lawrence DrCOOliveiro wrote:

So, there is this new *nix-specific rCLvulnerabilityrCY that cleverly
encodes the malicious commands in the file name, not the file contents
[ snip commercial link ]

Except I donrCOt understand how you could fall for it. All the examples
they give for the exploit involve the use of the rCLevalrCY command on
that filename string ... well, duh.

Yes. But what do you expect from a company that *sells* "security"?
There's tons of trash like that on the Internet!

(For the informed folks here it's first of all just a waste of time
reading; I'd suggest to abstain from spreading links with such ads/ FUD/misleading information. Its dissemination doesn't help anyone.)

Janis

[...]

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-27 at 04:48 ADT, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

So, there is this new *nix-specific rCLvulnerabilityrCY that cleverly
encodes the malicious commands in the file name, not the file contents
<https://www.trellix.com/blogs/research/the-silent-fileless-threat-of-vshell/>.

Except I donrCOt understand how you could fall for it. All the examples
they give for the exploit involve the use of the rCLevalrCY command on
that filename string ... well, duh.

This part is equal parts mystifying and amusing:

[missing pronoun?] cannot manually create a file with this name in
the shell due to its special characters being interpreted as
command syntax

DonrCOt they know anything about *nix command shells?

Apparently not. Which makes me wonder about the validity of anything else
they have to say.


I think Janis' reply to your (Lawrence's) comment is a bit harsh. As
bizarre as it might be to trigger a bug like this, it is (IMHO) an
interesting reminder of how using eval is so often a risky move.


Jim
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 27.08.2025 22:19, Jim Diamond wrote:

On 2025-08-27 at 04:48 ADT, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

["security" related sort of adds of a commercial company]

[...] it is (IMHO) an
interesting reminder of how using eval is so often a risky move.

The inherent shell programming security problem [that Lawrence
already identified] (and that is well known since decades!) is
in that ads hidden in a bunch of distractions from the problem.
Of course with a simple and to the point elaboration on 'eval'
they wouldn't sell anything, neither tools nor expertise.

If you want to be reminded on the problem of 'eval' get texts
(or write texts) about that, and spread the word for the good
of all. (I've had a paragraph on 'eval' explicitly put in our
company coding standards back in the early/mid 1990's.)

But meanwhile that should be anyway already commonly known.[*]

Janis

[*] Of course you shouldn't let amateurs [without expertise
or supervision] do shell programming for critical Real World
systems. IMHO.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-08-28 at 01:23 ADT, Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 27.08.2025 22:19, Jim Diamond wrote:

On 2025-08-27 at 04:48 ADT, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote: >>> ["security" related sort of adds of a commercial company]

[...] it is (IMHO) an
interesting reminder of how using eval is so often a risky move.

The inherent shell programming security problem [that Lawrence
already identified] (and that is well known since decades!) is
in that ads hidden in a bunch of distractions from the problem.
Of course with a simple and to the point elaboration on 'eval'
they wouldn't sell anything, neither tools nor expertise.

If you want to be reminded on the problem of 'eval' get texts
(or write texts) about that, and spread the word for the good
of all. (I've had a paragraph on 'eval' explicitly put in our
company coding standards back in the early/mid 1990's.)

But meanwhile that should be anyway already commonly known.[*]

Yes, to people who have done shell programming for a while (or very
diligent beginners). But there are always new, aspiring shell programmers coming along.

In any case, I found this particular example a bit more subtle than the
usual "obvious" dangers of using eval.

[*] Of course you shouldn't let amateurs [without expertise
or supervision] do shell programming for critical Real World
systems. IMHO.

Not just shell programming... amateurs can much up any other kind of programming too.

Jim

--- Synchronet 3.21a-Linux NewsLink 1.2