That's not as common with other platforms. Even the common GUI platforms on Linux would require the user to manually save the file and explicitly marking the file as executable. Nobody would conflate user friendliness with the ease of running untrusted code.
Defaults does make a difference. Even as these users are "left behind" in email filtering, we're seeing limited effects of malware with the more popular Linux platforms such as Android and the various desktops.
If someone can find a way to drop a text file in my "~/.config/autostart" dir, next time I log in my Gnome desktop will happily execute the command present in the "Exec" line and it doesn't require the execute bit.
I think something similar could be done using "~/.local/share/applications", overriding an installed application next time that application is launched, but it probably would show two icons; the autostart at the moment is more stealth.
While once it is out side the control of the email client -- as the quote suggest, it's up to the user -- not the email client to do the dirty work.
The notion is that on windows, even a all knowing user who knew the email contained a virus after viewing it would be helpless as the email client already did the steps required to make the virus active. Where as on Linux, the user would still need to be the facilitator -- not the email client blindly destroying your system.
As a example. You can email me virus all day long, and it is not likely I will get infected because of how my email client handles files and attachments. If I were to switch to a windows based system using a windows client then all bets are off.
tl;dr your exception would mean the bad thing we are talking about already happened. If they could get your email client to write to that file they probably already had enough control to do whatever you are suggesting they put in autostart.
OK, I see your point, normal usage against exploits, and usually security goes against convenience.
I don't know if I'm overly paranoid, but in this specific case I've started long time ago to keep my autostart dir read only. At the same time I've dirs in my command path that are writable by my user (but those need the execute bit tho)...
After that, a ZIP symlink traversal could still drop a script in your command path directories that are writable by your user. The execute bit is not a hurdle, unzip utilities will typically preserve the execute bit on Unix systems.
ZIP directory traversals are as old as the hills, yet they are still a thing: https://snyk.io/research/zip-slip-vulnerability.
ZIP symlink traversals are even more powerful, yet they are hardly spoken of.
Ideally, you want your email provider to be blocking ZIP attachments with symlink traversals or execute bits (but I am not aware of any which do).
ZIP attachments preserve executable flags.
Also, symlink traversal attacks only require a ZIP attachment to be clicked. Apple patched macOS for this a little while ago, but it's probably still a thing on many systems - since most email providers know to detect ZIP directory traversals, but not ZIP symlink traversals.
There's also a range of other containers for macOS and Linux which will preserve executable flags if you ask them to.
And we have also seen simple character encoding attacks which can crash Apple Mail just on viewing the email.
Citation please? This is not my experience.
Which email client is that?
Also, for many years already, Windows won't let you run an executable that you just downloaded from the internet just by double clicking, without first clicking through a warning dialog.
For example, recent versions of Word won't run VBA macros by default without the user clicking through a warning dialog, and yet people fall for it all the time.
Malware authors don't mind either way.
- PDFs with JS code. It's not a joke, someone actually titled a paper on PDF exploits alone, "PDF, Let Me Count the Ways".
- Hostile RTFs (with or without OLEs) disguised as Word documents (which Office will gladly open).
- Hostile HTML disguised as Excel spreadsheets (likewise).
- New unknown variants of the old Windows metafile exploit (just by viewing, as xorcist suggested).
- Image "stegosploits" (likewise).
The list goes on...
The app is usually in an installer package or ZIP which adds a couple more execute barriers.
The real threat is malware hidden in document formats like docx or pdf, which usually have fewer clicks before open + get exploited.
While developing our antivirus system, I was surprised to find that most email providers do not block ZIP attachments containing SH shell script files, nor ZIP attachments containing extension-less files with the executable bit set, nor ZIP attachments containing symlink traversal paths, nor any attachments which start with the shebang "#!" shell script signature, nor any which start with ELF or MACH O signatures.
In addition, for a recent sample of 15,000 attachments, we found 700 viruses, of which less than 50% were detected by the top 30 engines on VirusTotal. In particular, ClamAV, which is used by most Linux systems, had a less than 1% success rate. Ironically, most email providers know to block EXE attachments, even in ZIP attachments, but now its Linux and Mac users that are being left behind.