here is a link to artical warning of this malware Linux Malware Delivered via Malicious RAR Filenames Evades Antivirus Detection
Isnât that referring to a completely different topic, which is also possibly important on its own but is totally separate? Seems worthwhile to keep a separation there
2 Likes
I have some questions:
Why would linux malware be delivered via RAR?
Why havenât I ever heard of âThe Hacker Newsâ, canât find anything about it, and its name so close to âHacker Newsâ?
Why havenât any sites except content farms picked up on this?
1 Like
It may very well be bullshit, I have no idea. But to answer your question in general, even if this particular case is nonsense, it could happen that someone who wants to spread malware has found out about a vulnerability in the software that is most commonly used to unpack rar files. If the rar unpacking software has a bug that allows some special tricks through specially crafted rar files, then it would make sense for that person to try to distribute such rar files. The point would be to trigger the bug.
2 Likes
But that isnât what the linked article says. It says that the software that is unpacking RAR files works just fine - and creates the file with an unusual name just fine. The (alleged) problem comes only when a carelessly coded shell script processes the names of the files in the directory that contains that unusual name.
I can sort of reproduce this but only using an implausible shell script command. However I canât rule out that this has already been patched on my computer (in accordance with responsible disclosure).
As an aside, I didnât bother with an RAR file. I just created the file at the shell prompt (using a lot of backslash characters).
The article linked by the OP itself links to: https://www.trellix.com/blogs/research/the-silent-fileless-threat-of-vshell/ so it is not only the original article that discusses this (alleged) problem.
Edit: PS While this does include some novel features, at the end of the day this is basically the same as any other âblindly use input from an untrusted sourceâ.
Where it is different from those typical attacks is that a shell script may reasonably assume that, in traversing the userâs home directory (for example) in the security context of the user, all files are trusted.
Because of the disconnect between the time and event of extracting an RAR file and the time and event of processing the files in a directory, it is more difficult to manage that trust.
I would think that this attack is not specific to an RAR file. Perhaps it could work with any archive format that can be attached to an email and the user socially engineered into extracting the contents of the archive.
Of course thereâs a snowflakeâs chance in hell that any such email attachment could reach me from some rando internet source. It would get blocked, or stopped as spam and that by itself is most likely to trigger deletion without handling or, at the very least, an elevated level of suspicion. But security has always been a game of âdefence in depthâ.
2 Likes
Iâve refined this a bit. I have files with names starting with foo.txt as follows
i.e. ls -1 foo.txt* output.
foo.txt
'foo.txt`echo dG91Y2ggcHduZWQ7ZWNobyAtbgo=|base64 -d|bash`'
If you are silly enough to iterate through those files, f, doing
eval "ls -l $f"
then you will see that a shell does indeed execute for the second file and you get pwned but you will get no error message and it just harmlessly lists foo.txt twice.
Obviously, once the attacker can execute a shell running commands of his/her choice, it really doesnât matter what exactly the commands are. Youâve already lost. Iâve made it harmless in the above example but in the real example it downloads something and things go downhill from there.
So the moral of the story is ⌠never use eval if any part of the input can be controlled in any way by an attacker.
I searched my entire script tree and not a single script even uses eval but maybe more advanced scripting calls for its use.
2 Likes
I did find thisâŚ
2 Likes
Can we safely uninstall eval then?
2 Likes
My guess: Thatâs a double ânoâ. You canât safely do so and in any case there is no way to do so because it is a shell built-in command.
If there were some way to disable the eval command then that would only partly address the underlying issue anyway. Even without eval it is still possible for the combination of
- an attacker-controlled archive being extracted by the user, and
- a poorly-written shell script
to yield unexpected and potentially dangerous results.
So the bottom line for optimal security is ⌠donât write poorly-written shell scripts, to paraphrase a former Prime Minister. 
In case my post was confusing, by âI searched my entire script treeâ, I meant âscripts written by me personally and residing locally on my computerâ. I did not search all scripts that are provided by a standard typical Linux distro (which I guess would be somewhat possible but slow and difficult). Maybe someone else wants to do that.
If anything, this problem just reinforces the security risk posed by the very nature of how typical Linux shells work - too much complexity, too much functionality, a mass of special characters, and most importantly the very nature of âsubstitutionâ.
Where security is of the highest priority, programs should never fork off a shell process but if this is unavoidable then it is critical to sanitise all the inputs (e.g. simply reject any âfunnyâ characters).
Putting aside security for a moment, for correctness, when dealing with pathnames in a shell script, it is usually essential to substitute the filename enclosed within double quotes anyway i.e. if f is a pathname then "$f" rather than $f
3 Likes
this is why i have no email on my purism librem mini v2 . no way will i ever have email again on a computer its bad enough to have email on my iPhone.
2 Likes
That is the extreme example of blocking suspicious email but note that email is not the only vector by which a malicious archive could be delivered to you. There are three steps in this exploit:
- The malicious archive is delivered to you via some mechanism.
- The malicious archive is extracted either explicitly by you or automatically by poorly conceived software.
- A poorly written shell script processes the file or files that were extracted from the archive.
In the spirit of âdefence in depthâ, there should really be options added to any archive extraction program to warn about dodgy filenames (where the user gets to decide what categories of dodginess are appropriate for warning).
1 Like