lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <1078787584.23556.56.camel@adesk> From: full-disclosure at illuminated.nl (Aschwin Wesselius) Subject: Re: E-Mail viruses Jorge Daza wrote: > Other problem that comes to my mind, weak shared secrets might solve the > problem in some way for spreading massive viruses but not for directed > attacks. In those cases probably the attacker is already reading the > email of some or all of the employees, thus she surely knows the secret > extension. Even if the attacker can't read the email, lets consider the > strength of a secret that is sent plaintext on every message. Not good. > > Of course this solution can be too complex for home users, that can > still rely on crypto, but not to receive attachments from people they > don't even know. > > But I guess it could be implemented in bussiness environments. > I don't know if it is far fetched, but we all know the "Reply-To" header part........ What about the implementation of something like a "Attachments-To" header??? An mail client can extract Reply-To headers, so why couldn't they extract such headers as well? People can fill in this variable just as they do with the Reply-To thing If people do have another e-mail address strictly devoted to attachments, very much under inspection of virus-killers etc., they can put that into this field when they fill in their account details at the time they configure their client. If they don't have any extra's they can leave it blank of fill it in with the same as usual. Just like a Reply-To field is handled. The receiving mail-client can keep track of this field, just as they do with the Reply-To field. As soon as they attach an extra file, the client should be aware of this and use the Attachment-To header as the destination mail-address by default. The key is the usage of these email-addresses separately. Plain text can be handled as plain text. Any attachments wich appearantly will be unwanted, can be stripped of with no mercy by any mail processing service. Mail addresses with attachments can be inspected by virus-killers, but anyhow how could a virus-maker depent on an extra email-address or not? Since it would come in handy when "instructions" about how to treat the attachment are stripped off at the attachment-address processing. So, two separate e-mail addresses (wich doesn't have to be that different anyhow, up to the admin or user like attach.joe@...mon.com or joe@...ach.common.com) could make a lot of difference. Only, how could we get (if approved) these changes into the SMTP protocol??? Another solution, is having people make clear that something in the header should mention an attachment already (e.g "ATT Subjectline". But this is, like Jorge already implied not good policy in large businesses where training and changes could become daily tasks. Just being creative..... Aschwin Wesselius BTW: this is my very first post on the list, so any hints on misbehavior of the netiquette are welcome. I'm not a security expert, but do have security in mind. ;-)
Powered by blists - more mailing lists