3 ms·

I think the point is -- do to that you would have to have the email client do it. While once it is out side the control of the email client -- as the quote sug

I think the point is -- do to that you would have to have the email client do it. 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.

IronBacon 7y ago
> 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. 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)...
- jorangreef 7y ago
  Keeping your autostart directory read-only is a great idea. 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 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).

IronBacon 7y ago

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

jorangreef 7y ago
Keeping your autostart directory read-only is a great idea. 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 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).