Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.comp.os.windows-10 > #187028 > unrolled thread

Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection

Back to article view | Back to alt.comp.os.windows-10

Contents

  Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Symon <symon@notice.org> - 2025-08-27 09:14 +0200
    Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2025-08-27 23:25 +0800
      Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-27 23:22 +0000
        Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Hank Rogers <Hank@nospam.invalid> - 2025-08-27 19:21 -0500
          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 00:41 +0000
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-28 08:45 -0400
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 22:36 +0000
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-29 08:39 -0400
                  Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 00:16 +0000
                    Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Hank Rogers <Hank@nospam.invalid> - 2025-08-29 20:02 -0500
                      Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 03:35 +0000
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection pothead <pothead@snakebite.com> - 2025-08-28 15:45 +0000
          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-28 03:28 -0400
          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Daniel70 <daniel47@somewhere.someplaceelse> - 2025-08-28 20:19 +1000
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-28 07:54 -0400
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-28 14:57 +0200
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-28 09:02 -0400
                  Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-28 23:17 +0200
                  Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 22:35 +0000
                    Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-29 08:38 -0400
                      Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-29 10:35 -0400
                        Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-29 10:55 -0400
                      Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-08-31 02:35 +0200
                        Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 01:21 +0000
                          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Char Jackson <none@none.invalid> - 2025-08-31 12:58 -0500
                            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-31 22:46 +0000
                          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-09-01 02:44 +0200
                            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-09-01 07:56 -0400
                              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-09-01 14:21 +0200
                              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Char Jackson <none@none.invalid> - 2025-09-01 16:26 -0500
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 22:34 +0000
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 22:32 +0000
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-28 19:18 -0400
                  Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-29 00:50 +0000
                    Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-28 22:44 -0400
                      Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-29 04:02 +0000
                        Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-29 00:53 -0400
                          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-29 05:31 +0000
          Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-28 08:44 -0400
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection chrisv <chrisv@nospam.invalid> - 2025-08-28 16:30 -0500
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-29 08:35 -0400
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-28 22:29 +0000
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection CrudeSausage <crude@sausa.ge> - 2025-08-29 08:36 -0400
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-30 05:39 +0000
                Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-30 07:25 -0400
            Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Paul <nospam@needed.invalid> - 2025-08-28 19:40 -0400
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection Lawrence D’Oliveiro <ldo@nz.invalid> - 2025-08-29 00:51 +0000
              Re: Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection "Carlos E.R." <robin_listas@es.invalid> - 2025-09-02 12:45 +0200

Page 1 of 3  [1] 2 3  Next page →

#187028 — Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection

Cybersecurity researchers have shed light on a novel attack chain that
employs phishing emails to deliver an open-source backdoor called
VShell. 

The "Linux-specific malware infection chain that starts with a spam
email with a malicious RAR archive file," Trellix researcher Sagar Bade
said in a technical write-up. 

"The payload isn't hidden inside the file content or a macro, it's
encoded directly in the filename itself. Through clever use of shell
command injection and Base64-encoded Bash payloads, the attacker turns a
simple file listing operation into an automatic malware execution
trigger." 

The technique, the cybersecurity company added, takes advantage of a
simple yet dangerous pattern commonly observed in shell scripts that
arises when file names are evaluated with inadequate sanitization,
thereby causing a trivial command like eval or echo to facilitate the
execution of arbitrary code. 

What's more, the technique offers the added advantage of getting around
traditional defenses, as antivirus engines don't typically scan file
names. 

The starting point of the attack is an email message containing a RAR
archive, which includes a file with a maliciously crafted file name:
"ziliao2.pdf`{echo,<Base64-encoded command>}|{base64,-d}|bash`" 

Specifically, the file name incorporates Bash-compatible code that's
engineered to execute commands when it's interpreted by the shell. It's
worth noting that simply extracting the file from the archive does not
trigger execution. Rather, it occurs only when a shell script or command
attempts to parse the file name. 

Another important aspect to consider here is that it's not possible to
manually create a file name with this syntax, meaning it was likely
created using another language or dropped using an external tool or
script that bypasses shell input validation, Trellix said. 

This, in turn, leads to the execution of an embedded Base64-encoded
downloader, which then retrieves from an external server an ELF binary
for the appropriate system architecture (x86_64, i386, i686, armv7l, or
aarch64). The binary, for its part, initiates communication with a
command-and-control (C2) server to obtain the encrypted VShell payload,
decode, and execute it on the host. 

Trellix said the phishing emails are disguised as an invitation for a
beauty product survey, luring recipients with a monetary reward (10 RMB)
for completing it. 

"Crucially, the email includes a RAR archive attachment ('yy.rar'), even
though it doesn't explicitly instruct the user to open or extract it,"
Bade explained. "The social engineering angle is subtle: The user is
distracted by the survey content, and the presence of the attachment
might be mistaken for a survey-related document or data file." 

VShell is a Go-based remote access tool that has been widely put to use
by Chinese hacking groups in recent years, including UNC5174, supporting
reverse shell, file operations, process management, port forwarding, and
encrypted C2 communications. 

What makes this attack dangerous is that the malware operates entirely
in-memory, avoiding disk-based detection, not to mention it can target a
wide range of Linux devices. 

"This analysis highlights a dangerous evolution in Linux malware
delivery where a simple file name embedded in a RAR archive can be
weaponized to execute arbitrary commands," Trellix said. "The infection
chain exploits command injection in shell loops, abuses Linux's
permissive execution environment, and ultimately delivers a powerful
backdoor VShell malware capable of full remote control over the system." 

The development comes as Picus Security released a technical analysis of
a Linux-focused post-exploit tool dubbed RingReaper that leverages the
Linux kernel's io_uring framework to circumvent traditional monitoring
tools. It's currently not known who is behind the malware. 

"Instead of invoking standard functions such as read, write, recv, send,
or connect, RingReaper employs io_uringprimitives (e.g.,
io_uring_prep_*) to execute equivalent operations asynchronously,"
security researcher Sila Özeren Hacioglu said. "This method helps bypass
hook-based detection mechanisms and reduces the visibility of malicious
activity in telemetry commonly gathered by EDR platforms." 

RingReaper makes use of io_uring to enumerate system processes, active
pseudo-terminal (PTS) sessions, network connections, and logged-in
users, while reducing its footprint and avoiding detection. It's also
capable of collecting user information from the "/etc/passwd" file,
abusing SUID binaries for privilege escalation, and erasing traces of
itself after execution. 

"It exploits the Linux kernel's modern asynchronous I/O interface,
io_uring, to minimize reliance on conventional system calls that
security tools frequently monitor or hook," Picus said. 

https://thehackernews.com/2025/08/linux-malware-delivered-via-malicious.h
tml 

[toc] | [next] | [standalone]

#187032

On 27/8/2025 3:14 pm, Symon wrote:
> Cybersecurity researchers have shed light on a novel attack chain that
> employs phishing emails to deliver an open-source backdoor called
> VShell.
> 
> The "Linux-specific malware infection chain that starts with a spam
> email with a malicious RAR archive file," Trellix researcher Sagar Bade
> said in a technical write-up.


I think I have seen many bug reports about WinRAR ....

-- 
   @~@   Simplicity is Beauty! Remain silent! Drink, Blink, Stretch!
  / v \  May the Force and farces be with you! Live long and prosper!!
/( _ )\ https://sites.google.com/site/changmw/
   ^ ^   https://github.com/changmw/changmw

[toc] | [prev] | [next] | [standalone]

#187036

On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:

> I think I have seen many bug reports about WinRAR ....

This isn’t one of them, but I still don’t understand how the vulnerability 
is supposed to work. The proofs of concept on the Trellix page all seem to 
rely on wantonly dangerous use of the “eval” command, which would be a 
dumb thing to do indeed.

[toc] | [prev] | [next] | [standalone]

#187038

Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
> 
>> I think I have seen many bug reports about WinRAR ....
> 
> This isn’t one of them, but I still don’t understand how the vulnerability
> is supposed to work. The proofs of concept on the Trellix page all seem to
> rely on wantonly dangerous use of the “eval” command, which would be a
> dumb thing to do indeed.
> 

I thought Linux didn't have any bugs or malware.  Damn, things are 
getting bad.

[toc] | [prev] | [next] | [standalone]

#187039

On Wed, 27 Aug 2025 19:21:59 -0500, Hank Rogers wrote:

> I thought Linux didn't have any bugs or malware.

This certainly isn’t one of them.

> Damn, things are getting bad.

There used to be a lot more malware for Linux, back in the days when it 
was less popular. As its popularity has gone up, it actually seems to be 
getting more secure.

<https://en.wikipedia.org/wiki/Linux_malware#Threats>

[toc] | [prev] | [next] | [standalone]

#187055

On 2025-08-27 8:41 p.m., Lawrence D’Oliveiro wrote:
> On Wed, 27 Aug 2025 19:21:59 -0500, Hank Rogers wrote:
> 
>> I thought Linux didn't have any bugs or malware.
> 
> This certainly isn’t one of them.
> 
>> Damn, things are getting bad.
> 
> There used to be a lot more malware for Linux, back in the days when it
> was less popular. As its popularity has gone up, it actually seems to be
> getting more secure.
> 
> <https://en.wikipedia.org/wiki/Linux_malware#Threats>

Malware is not as much of a problem as the vulnerabilities are. People 
deny their existence, but they are there and it often takes a long time 
before they are fixed.

-- 
God be with you,

CrudeSausage
Islam is the enemy
John 14:6

[toc] | [prev] | [next] | [standalone]

#187069

On Thu, 28 Aug 2025 08:45:16 -0400, CrudeSausage wrote:

> Malware is not as much of a problem as the vulnerabilities are.

There was no “vulnerability” here. Read the Trellix report for yourself, 
and judge.

[toc] | [prev] | [next] | [standalone]

#187090

On 2025-08-28 6:36 p.m., Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 08:45:16 -0400, CrudeSausage wrote:
> 
>> Malware is not as much of a problem as the vulnerabilities are.
> 
> There was no “vulnerability” here. Read the Trellix report for yourself,
> and judge.

Yes, why would I call it a vulnerability just because it was reported as 
a vulnerability? Silly me!

-- 
God be with you,

CrudeSausage
Islam is the enemy
John 14:6

[toc] | [prev] | [next] | [standalone]

#187103

On Fri, 29 Aug 2025 08:39:24 -0400, CrudeSausage wrote:

> On 2025-08-28 6:36 p.m., Lawrence D’Oliveiro wrote:
>>
>> On Thu, 28 Aug 2025 08:45:16 -0400, CrudeSausage wrote:
>>
>>> Malware is not as much of a problem as the vulnerabilities are.
>>
>> There was no “vulnerability” here. Read the Trellix report for
>> yourself, and judge.
>
> Yes, why would I call it a vulnerability just because it was
> reported as a vulnerability? Silly me!

Silly you, indeed!

It was never “reported as a vulnerability”. If it had, it would have
been assigned a CVE number. There is no CVE number (at least that is
mentioned in the Trellix report) associated with this so-called
“vulnerability”. Doesn’t that make you think twice before jumping to
conclusions?

[toc] | [prev] | [next] | [standalone]

#187104

Lawrence D’Oliveiro wrote on 8/29/2025 7:16 PM:
> On Fri, 29 Aug 2025 08:39:24 -0400, CrudeSausage wrote:
> 
>> On 2025-08-28 6:36 p.m., Lawrence D’Oliveiro wrote:
>>>
>>> On Thu, 28 Aug 2025 08:45:16 -0400, CrudeSausage wrote:
>>>
>>>> Malware is not as much of a problem as the vulnerabilities are.
>>>
>>> There was no “vulnerability” here. Read the Trellix report for
>>> yourself, and judge.
>>
>> Yes, why would I call it a vulnerability just because it was
>> reported as a vulnerability? Silly me!
> 
> Silly you, indeed!
> 
> It was never “reported as a vulnerability”. If it had, it would have
> been assigned a CVE number. There is no CVE number (at least that is
> mentioned in the Trellix report) associated with this so-called
> “vulnerability”. Doesn’t that make you think twice before jumping to
> conclusions?
> 

Yes.  Every time a flaw has ever been reported with linux,  It has 
ALWAYS turned out to be a false alarm.  Linux is perfect, so why do 
people keep reporting problems?  I think it's a conspiracy.

[toc] | [prev] | [next] | [standalone]

#187105

On Fri, 29 Aug 2025 20:02:01 -0500, Hank Rogers wrote:

> Yes.  Every time a flaw has ever been reported with linux,  It has
> ALWAYS turned out to be a false alarm.

Do you have any evidence for that?

[toc] | [prev] | [next] | [standalone]

#187060

On 2025-08-28, Lawrence D’Oliveiro <ldo@nz.invalid> wrote:
> On Wed, 27 Aug 2025 19:21:59 -0500, Hank Rogers wrote:
>
>> I thought Linux didn't have any bugs or malware.
>
> This certainly isn’t one of them.
>
>> Damn, things are getting bad.
>
> There used to be a lot more malware for Linux, back in the days when it 
> was less popular. As its popularity has gone up, it actually seems to be 
> getting more secure.
>
><https://en.wikipedia.org/wiki/Linux_malware#Threats>

That's because major hardware companies like IBM are using Linux to power their mainframe
hardware management consoles and Linux is running under the covers in all types of
devices, adapters and so forth.
The same level of security does trickle down to use peon users.


-- 
pothead

"Our lives are fashioned by our choices. First we make our choices.
 Then our choices make us."
-- Anne Frank

[toc] | [prev] | [next] | [standalone]

#187045

On Wed, 8/27/2025 8:21 PM, Hank Rogers wrote:
> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
>>
>>> I think I have seen many bug reports about WinRAR ....
>>
>> This isnt one of them, but I still dont understand how the vulnerability
>> is supposed to work. The proofs of concept on the Trellix page all seem to
>> rely on wantonly dangerous use of the eval command, which would be a
>> dumb thing to do indeed.
>>
> 
> I thought Linux didn't have any bugs or malware.  Damn, things are getting bad.
> 

   The starting point of the attack is an email message containing a RAR
   archive, which includes a file with a maliciously crafted file name:
   "ziliao2.pdf`{echo,<Base64-encoded command>}|{base64,-d}|bash`"

Is that the Archive Manager, being called on to do something silly ?
Somewhere in that paragraph, is the guilty party. Why should an Archive
Manager evaluate a filename in an archive ? The file name should be
a static thing. Just like you would not evaluate a filename in a tar
file and attempt to expand it.

   Paul

[toc] | [prev] | [next] | [standalone]

#187048

On 28/08/2025 10:21 am, Hank Rogers wrote:
> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
>> 
>>> I think I have seen many bug reports about WinRAR ....
>> 
>> This isn’t one of them, but I still don’t understand how the 
>> vulnerability is supposed to work. The proofs of concept on the
>> Trellix page all seem to rely on wantonly dangerous use of the
>> “eval” command, which would be a dumb thing to do indeed.
> 
> I thought Linux didn't have any bugs or malware.  Damn, things are 
> getting bad.
> 
Does ANYTHING ever get to "didn't have any bugs or malware" state??

"didn't have any *UNDISCOVERED* bugs or malware" today, sure, but who 
know what will be the state tomorrow!!
-- 
Daniel70

[toc] | [prev] | [next] | [standalone]

#187051

On Thu, 8/28/2025 6:19 AM, Daniel70 wrote:
> On 28/08/2025 10:21 am, Hank Rogers wrote:
>> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
>>>
>>>> I think I have seen many bug reports about WinRAR ....
>>>
>>> This isn’t one of them, but I still don’t understand how the vulnerability is supposed to work. The proofs of concept on the
>>> Trellix page all seem to rely on wantonly dangerous use of the
>>> “eval” command, which would be a dumb thing to do indeed.
>>
>> I thought Linux didn't have any bugs or malware.  Damn, things are getting bad.
>>
> Does ANYTHING ever get to "didn't have any bugs or malware" state??
> 
> "didn't have any *UNDISCOVERED* bugs or malware" today, sure, but who know what will be the state tomorrow!!

A lot of mistakes, are implementation mistakes like not
using a hardened routine for this or that. And, we can estimate
how many unclassified mistakes there are in a work. Like some
version of Windows, the estimate was 50,000 just based on the KLOC count.
Microsoft would have automatic scans for the easy stuff -- even the
compiler can slap your fingers for some of those.

This is a different class of bug, in that it is an architecture bug.
It could be, that the private RAR module could be doing this, rather than
the Archive Manager applying this recipe to everything it does. There
is no mention of ZIP files having specially crafted filenames, for example.

The RAR decoder module is free. The only question I would have about
it, is whether it is Open Source and all the code for RAR in the
Archive Manager, can be read by anyone ("many eyes"). If Mr.Roshal
coded this up, and the activity is hidden in a binary blob, that would
make it easier to understand. It just doesn't seem like an activity you
would do at that level, and logically the place to be attempting
stuff like this, is the Archive Manager.

And once the Linux people find where in the code this is happening,
this will lead to an examination of the ecosystem, to make sure there
are no more of these (obviously bad) things out there. I doubt anyone
signed off on this as being "particularly clever". This might well be
code that was never reviewed.

The RAR encoder module costs money. That's how its author keeps himself fed.
That only gets on a computer if you bought a copy.

7ZIP comes with an SDK, and the Archive Manager version could be based
on the SDK materials. (Even Windows uses libarchive, a recent addition.)
Whereas the Windows 7Z executable version (from its web site) is closed
source as far as I know, but still free. The Windows version was recently
modified to include a higher threads-of-execution count, so that it could
be used on machines with "processor groups" (you can finally compress with
your 96 core computer and use all 96 cores). The article describing this,
was VERY strangely worded, and the reporter was obviously in a shit-disturbing
mood.

One of the acid tests for compressors, is getting two different versions
of code, to produce roughly the same file size. You can't expect an exact
match, due to time stamps, but if the byte counts are the same, that is
a positive sign. When I tried to get Linux and Windows to make the same
7Z, it didn't work out that well. Generally I do not hear comments about
"this version could not decode the output of that version", that
seems handled pretty well. The two ecosystems could still read each others output.

It may have started with an email, but only part of the attachment handling
would be done there, and handoff of any further layers of decoding needed,
could end up with the Archive Manager. As a software dev, when you
"use someone elses services", you don't know how stupid they are. And
it may not be apparently, that something as silly as the problem description,
is happening when you call that service. But some Black Hat figured it out.

   Paul

[toc] | [prev] | [next] | [standalone]

#187056

On 2025-08-28 13:54, Paul wrote:
> On Thu, 8/28/2025 6:19 AM, Daniel70 wrote:
>> On 28/08/2025 10:21 am, Hank Rogers wrote:
>>> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>>>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
>>>>
>>>>> I think I have seen many bug reports about WinRAR ....
>>>>
>>>> This isn’t one of them, but I still don’t understand how the vulnerability is supposed to work. The proofs of concept on the
>>>> Trellix page all seem to rely on wantonly dangerous use of the
>>>> “eval” command, which would be a dumb thing to do indeed.
>>>
>>> I thought Linux didn't have any bugs or malware.  Damn, things are getting bad.
>>>
>> Does ANYTHING ever get to "didn't have any bugs or malware" state??
>>
>> "didn't have any *UNDISCOVERED* bugs or malware" today, sure, but who know what will be the state tomorrow!!
> 
> A lot of mistakes, are implementation mistakes like not
> using a hardened routine for this or that. And, we can estimate
> how many unclassified mistakes there are in a work. Like some
> version of Windows, the estimate was 50,000 just based on the KLOC count.
> Microsoft would have automatic scans for the easy stuff -- even the
> compiler can slap your fingers for some of those.
> 
> This is a different class of bug, in that it is an architecture bug.
> It could be, that the private RAR module could be doing this, rather than
> the Archive Manager applying this recipe to everything it does. There
> is no mention of ZIP files having specially crafted filenames, for example.
> 
> The RAR decoder module is free. The only question I would have about
> it, is whether it is Open Source and all the code for RAR in the
> Archive Manager, can be read by anyone ("many eyes"). If Mr.Roshal
> coded this up, and the activity is hidden in a binary blob, that would
> make it easier to understand. It just doesn't seem like an activity you
> would do at that level, and logically the place to be attempting
> stuff like this, is the Archive Manager.

There are two decoders.

One is "unrar". The source is available, but AFAIK it doesn't classify 
as "open source". SUSE classifies it as "NonFree".

cer@Telcontar:~> rpm -qi unrar
Name        : unrar
Version     : 7.1.1
Release     : lp156.2.3.1
Architecture: x86_64
Install Date: 2025-02-13T21:45:22 CET
Group       : Unspecified
Size        : 404795
License     : NonFree
Signature   : RSA/SHA512, 2024-12-08T11:55:04 CET, Key ID 35a2f86e29b700a4
Source RPM  : unrar-7.1.1-lp156.2.3.1.src.rpm
Build Date  : 2024-12-08T11:54:57 CET
Build Host  : h02-ch1a
Relocations : (not relocatable)
Packager    : http://bugs.opensuse.org
Vendor      : openSUSE
URL         : https://www.rarlab.com
Summary     : A program to extract, test, and view RAR archives
Description :
The unRAR utility is a freeware program distributed with source code
and developed for extracting, testing, and viewing the contents of
archives created with the RAR archiver.
Distribution: SUSE Linux Enterprise 15
cer@Telcontar:~>


file "/usr/share/doc/packages/unrar/readme.txt" says:

    4. Legal stuff

    Unrar source may be used in any software to handle RAR archives
    without limitations free of charge, but cannot be used to re-create
    the RAR compression algorithm, which is proprietary. Distribution
    of modified Unrar source in separate form or as a part of other
    software is permitted, provided that it is clearly stated in
    the documentation and source comments that the code may not be used
    to develop a RAR (WinRAR) compatible archiver.

    More detailed license text is available in license.txt.


However, the file "license.txt" is not available, dunno why.


The other decoder is in the shareware "rar" package:

cer@Telcontar:~> rpm -qi rar
Name        : rar
Version     : 6.2.2
Release     : 150600.1.pm.2
Architecture: x86_64
Install Date: 2025-02-13T21:54:54 CET
Group       : Productivity/Archiving/Compression
Size        : 1001629
License     : NonFree
Signature   : RSA/SHA1, 2024-10-17T10:26:00 CEST, Key ID 45a1d0671abd1afb
Source RPM  : rar-6.2.2-150600.1.pm.2.src.rpm
Build Date  : 2024-10-17T03:58:06 CEST
Build Host  : buildwk3
Relocations : (not relocatable)
Packager    : packman@links2linux.de
Vendor      : http://packman.links2linux.de
URL         : https://www.rarsoft.com
Summary     : Compression and decompression program rar
Description :
Compression and decompression program.
Distribution: Extra / openSUSE_Leap_15.6
cer@Telcontar:~>


It is not clear what package presents the problem, but I guess it is 
both. readme file in unrar says:


    1. General

    Unrar source is subset of RAR and generated from RAR source 
automatically,
    by a small program removing blocks like '#ifndef UNRAR ... #endif'.
    Such method is not perfect and you may find some RAR related stuff
    unnecessary in Unrar, especially in header files.



> 
> And once the Linux people find where in the code this is happening,
> this will lead to an examination of the ecosystem, to make sure there
> are no more of these (obviously bad) things out there. I doubt anyone
> signed off on this as being "particularly clever". This might well be
> code that was never reviewed.
> 
> The RAR encoder module costs money. That's how its author keeps himself fed.
> That only gets on a computer if you bought a copy.
> 
> 7ZIP comes with an SDK, and the Archive Manager version could be based
> on the SDK materials. (Even Windows uses libarchive, a recent addition.)
> Whereas the Windows 7Z executable version (from its web site) is closed
> source as far as I know, but still free. The Windows version was recently
> modified to include a higher threads-of-execution count, so that it could
> be used on machines with "processor groups" (you can finally compress with
> your 96 core computer and use all 96 cores). The article describing this,
> was VERY strangely worded, and the reporter was obviously in a shit-disturbing
> mood.
> 
> One of the acid tests for compressors, is getting two different versions
> of code, to produce roughly the same file size. You can't expect an exact
> match, due to time stamps, but if the byte counts are the same, that is
> a positive sign. When I tried to get Linux and Windows to make the same
> 7Z, it didn't work out that well. Generally I do not hear comments about
> "this version could not decode the output of that version", that
> seems handled pretty well. The two ecosystems could still read each others output.
> 
> It may have started with an email, but only part of the attachment handling
> would be done there, and handoff of any further layers of decoding needed,
> could end up with the Archive Manager. As a software dev, when you
> "use someone elses services", you don't know how stupid they are. And
> it may not be apparently, that something as silly as the problem description,
> is happening when you call that service. But some Black Hat figured it out.

The rar compressor is not very useful in Linux. It has features I like, 
as error correction, but it can not save all the file attributes. I 
don't think it is popular.

However, it is possible to get emails with rar attachments. I have got a 
few. And there are tools that automatically examine the contents of emails.

-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#187057

On 2025-08-28 8:57 a.m., Carlos E.R. wrote:
> On 2025-08-28 13:54, Paul wrote:
>> On Thu, 8/28/2025 6:19 AM, Daniel70 wrote:
>>> On 28/08/2025 10:21 am, Hank Rogers wrote:
>>>> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>>>>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:
>>>>>
>>>>>> I think I have seen many bug reports about WinRAR ....
>>>>>
>>>>> This isn’t one of them, but I still don’t understand how the 
>>>>> vulnerability is supposed to work. The proofs of concept on the
>>>>> Trellix page all seem to rely on wantonly dangerous use of the
>>>>> “eval” command, which would be a dumb thing to do indeed.
>>>>
>>>> I thought Linux didn't have any bugs or malware.  Damn, things are 
>>>> getting bad.
>>>>
>>> Does ANYTHING ever get to "didn't have any bugs or malware" state??
>>>
>>> "didn't have any *UNDISCOVERED* bugs or malware" today, sure, but who 
>>> know what will be the state tomorrow!!
>>
>> A lot of mistakes, are implementation mistakes like not
>> using a hardened routine for this or that. And, we can estimate
>> how many unclassified mistakes there are in a work. Like some
>> version of Windows, the estimate was 50,000 just based on the KLOC count.
>> Microsoft would have automatic scans for the easy stuff -- even the
>> compiler can slap your fingers for some of those.
>>
>> This is a different class of bug, in that it is an architecture bug.
>> It could be, that the private RAR module could be doing this, rather than
>> the Archive Manager applying this recipe to everything it does. There
>> is no mention of ZIP files having specially crafted filenames, for 
>> example.
>>
>> The RAR decoder module is free. The only question I would have about
>> it, is whether it is Open Source and all the code for RAR in the
>> Archive Manager, can be read by anyone ("many eyes"). If Mr.Roshal
>> coded this up, and the activity is hidden in a binary blob, that would
>> make it easier to understand. It just doesn't seem like an activity you
>> would do at that level, and logically the place to be attempting
>> stuff like this, is the Archive Manager.
> 
> There are two decoders.
> 
> One is "unrar". The source is available, but AFAIK it doesn't classify 
> as "open source". SUSE classifies it as "NonFree".
> 
> cer@Telcontar:~> rpm -qi unrar
> Name        : unrar
> Version     : 7.1.1
> Release     : lp156.2.3.1
> Architecture: x86_64
> Install Date: 2025-02-13T21:45:22 CET
> Group       : Unspecified
> Size        : 404795
> License     : NonFree
> Signature   : RSA/SHA512, 2024-12-08T11:55:04 CET, Key ID 35a2f86e29b700a4
> Source RPM  : unrar-7.1.1-lp156.2.3.1.src.rpm
> Build Date  : 2024-12-08T11:54:57 CET
> Build Host  : h02-ch1a
> Relocations : (not relocatable)
> Packager    : http://bugs.opensuse.org
> Vendor      : openSUSE
> URL         : https://www.rarlab.com
> Summary     : A program to extract, test, and view RAR archives
> Description :
> The unRAR utility is a freeware program distributed with source code
> and developed for extracting, testing, and viewing the contents of
> archives created with the RAR archiver.
> Distribution: SUSE Linux Enterprise 15
> cer@Telcontar:~>
> 
> 
> file "/usr/share/doc/packages/unrar/readme.txt" says:
> 
>     4. Legal stuff
> 
>     Unrar source may be used in any software to handle RAR archives
>     without limitations free of charge, but cannot be used to re-create
>     the RAR compression algorithm, which is proprietary. Distribution
>     of modified Unrar source in separate form or as a part of other
>     software is permitted, provided that it is clearly stated in
>     the documentation and source comments that the code may not be used
>     to develop a RAR (WinRAR) compatible archiver.
> 
>     More detailed license text is available in license.txt.
> 
> 
> However, the file "license.txt" is not available, dunno why.
> 
> 
> The other decoder is in the shareware "rar" package:
> 
> cer@Telcontar:~> rpm -qi rar
> Name        : rar
> Version     : 6.2.2
> Release     : 150600.1.pm.2
> Architecture: x86_64
> Install Date: 2025-02-13T21:54:54 CET
> Group       : Productivity/Archiving/Compression
> Size        : 1001629
> License     : NonFree
> Signature   : RSA/SHA1, 2024-10-17T10:26:00 CEST, Key ID 45a1d0671abd1afb
> Source RPM  : rar-6.2.2-150600.1.pm.2.src.rpm
> Build Date  : 2024-10-17T03:58:06 CEST
> Build Host  : buildwk3
> Relocations : (not relocatable)
> Packager    : packman@links2linux.de
> Vendor      : http://packman.links2linux.de
> URL         : https://www.rarsoft.com
> Summary     : Compression and decompression program rar
> Description :
> Compression and decompression program.
> Distribution: Extra / openSUSE_Leap_15.6
> cer@Telcontar:~>
> 
> 
> It is not clear what package presents the problem, but I guess it is 
> both. readme file in unrar says:
> 
> 
>     1. General
> 
>     Unrar source is subset of RAR and generated from RAR source 
> automatically,
>     by a small program removing blocks like '#ifndef UNRAR ... #endif'.
>     Such method is not perfect and you may find some RAR related stuff
>     unnecessary in Unrar, especially in header files.
> 
> 
> 
>>
>> And once the Linux people find where in the code this is happening,
>> this will lead to an examination of the ecosystem, to make sure there
>> are no more of these (obviously bad) things out there. I doubt anyone
>> signed off on this as being "particularly clever". This might well be
>> code that was never reviewed.
>>
>> The RAR encoder module costs money. That's how its author keeps 
>> himself fed.
>> That only gets on a computer if you bought a copy.
>>
>> 7ZIP comes with an SDK, and the Archive Manager version could be based
>> on the SDK materials. (Even Windows uses libarchive, a recent addition.)
>> Whereas the Windows 7Z executable version (from its web site) is closed
>> source as far as I know, but still free. The Windows version was recently
>> modified to include a higher threads-of-execution count, so that it could
>> be used on machines with "processor groups" (you can finally compress 
>> with
>> your 96 core computer and use all 96 cores). The article describing this,
>> was VERY strangely worded, and the reporter was obviously in a shit- 
>> disturbing
>> mood.
>>
>> One of the acid tests for compressors, is getting two different versions
>> of code, to produce roughly the same file size. You can't expect an exact
>> match, due to time stamps, but if the byte counts are the same, that is
>> a positive sign. When I tried to get Linux and Windows to make the same
>> 7Z, it didn't work out that well. Generally I do not hear comments about
>> "this version could not decode the output of that version", that
>> seems handled pretty well. The two ecosystems could still read each 
>> others output.
>>
>> It may have started with an email, but only part of the attachment 
>> handling
>> would be done there, and handoff of any further layers of decoding 
>> needed,
>> could end up with the Archive Manager. As a software dev, when you
>> "use someone elses services", you don't know how stupid they are. And
>> it may not be apparently, that something as silly as the problem 
>> description,
>> is happening when you call that service. But some Black Hat figured it 
>> out.
> 
> The rar compressor is not very useful in Linux. It has features I like, 
> as error correction, but it can not save all the file attributes. I 
> don't think it is popular.
> 
> However, it is possible to get emails with rar attachments. I have got a 
> few. And there are tools that automatically examine the contents of emails.
RAR is usually the compression tool pirates use for their software. For 
my tastes, 7z is just fine, especially with its encryption capabilities. 
As far as I know, there are a few open-source programs capable of 
opening 7z and compressing to that format.
-- 
God be with you,

CrudeSausage
Islam is the enemy
John 14:6

[toc] | [prev] | [next] | [standalone]

#187062

On 2025-08-28 15:02, CrudeSausage wrote:
> On 2025-08-28 8:57 a.m., Carlos E.R. wrote:
>> On 2025-08-28 13:54, Paul wrote:
>>> On Thu, 8/28/2025 6:19 AM, Daniel70 wrote:
>>>> On 28/08/2025 10:21 am, Hank Rogers wrote:
>>>>> Lawrence D’Oliveiro wrote on 8/27/2025 6:22 PM:
>>>>>> On Wed, 27 Aug 2025 23:25:34 +0800, Mr. Man-wai Chang wrote:

...

>> The rar compressor is not very useful in Linux. It has features I 
>> like, as error correction, but it can not save all the file 
>> attributes. I don't think it is popular.
>>
>> However, it is possible to get emails with rar attachments. I have got 
>> a few. And there are tools that automatically examine the contents of 
>> emails.
> RAR is usually the compression tool pirates use for their software. For 
> my tastes, 7z is just fine, especially with its encryption capabilities. 
> As far as I know, there are a few open-source programs capable of 
> opening 7z and compressing to that format.

Sure.

But when we are receiving email, it is not our choice what compressor 
will be used.

I did notice, though, on a gmx account, that I got several posts with 
rar attachments with executables in them. Obviously malware of some 
sort. If some unknown sends me a .rar with an .exe inside, it will be 
malware. One plus one is two.

But gmx filters did not detect it, and reporting that got nowhere.


-- 
Cheers, Carlos.

[toc] | [prev] | [next] | [standalone]

#187068

On Thu, 28 Aug 2025 09:02:34 -0400, CrudeSausage wrote:

> RAR is usually the compression tool pirates use for their software. For
> my tastes, 7z is just fine ...

A few times now, after extracting a .rar archive, I have tried 
recompressing the result as .7z.

In every case, the .7z file ended up smaller than the .rar version.

[toc] | [prev] | [next] | [standalone]

#187089

On 2025-08-28 6:35 p.m., Lawrence D’Oliveiro wrote:
> On Thu, 28 Aug 2025 09:02:34 -0400, CrudeSausage wrote:
> 
>> RAR is usually the compression tool pirates use for their software. For
>> my tastes, 7z is just fine ...
> 
> A few times now, after extracting a .rar archive, I have tried
> recompressing the result as .7z.
> 
> In every case, the .7z file ended up smaller than the .rar version.

I might be wrong since I never really compress anything, but I believe 
that RAR is prioritized over 7z or ZIP not because it has a better 
compression rate, but because it makes it easy to create a number of 
similarly-sized files connected to the same piece of software. I'm sure 
that anyone who pirated software here, whether through Usenet, a BBS or 
the Internet, recalls the software coming in 16 equally-sized RAR, R01, 
R02 and so on files. Perhaps that was the advantage of the format.

-- 
God be with you,

CrudeSausage
Islam is the enemy
John 14:6

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | alt.comp.os.windows-10

csiph-web