Why can't message signing offer backwards compatibility (assuming you use multipart/signed)? Matthew Flaschen Darkz wrote: > Mail Drives Security Considerations > =================================== > > Author: Attila Gerendi (Darkz) > Date: November 03, 2006 > > > There are more "mail drive" solutions available like "GMail Drive", > "GSpace", "Gmail FS", etc.. These systems are built to store ordinary > files in email accounts (usually gmail because it's free 2Gb++ space). > > In some of these solutions the files and folders usually are stored as > attachments in a special email. The file system does not have FAT (File > Allocation Table) and the informations regarding the name and path of > the files/folders are stored in the email SUBJECT field. Additionally > there is no mechanism to filter these emails. > > So the problem is the remote attacker can shout blindly emails which > describe a file or folder in this file systems and manipulate or inject > files into that file system. This may be used for a new spam type or to > inject undesirable/malicious files into someone's file collection. At > the first sight this can not be worse then plain email spamming, however > because this concept is extending the email use if no sanitation will be > included then it will extend the spam use as well, some malicious people > will find out new malicious solutions for particular or generic situations. > > A few examples are described below, other may exist. > > 1. viksoe's GMail Drive shell extension > --------------------------------------- > > - file injection. You can inject files into the "GMail Drive file > system" by sending email with Subject: "GMAILFS: /new_filename.txt > [13;a;1]" and "new_filename.txt" as attachment. However if the sender is > not "self" then the filename will be displayed with red color. The > sender email address can be spoofed. > > - folder creation. You can create new folder by sending email with > Subject: "GMAILFS: /new_folder/. [14;a;1]" > > - rewrite file contains. You can overwrite file displayed content > sending email with Subject: "GMAILFS: > /existing_path/existing_filename.txt [13;a;1]" and "filename.txt" as > attachment. However if the sender is not "self" then the extension will > display 2 files with the same name but both will have the same new content. > > > > 2. Gmail File Space(GSpace) by Rahul Jonna > ------------------------------------------ > > - file injection. You can inject files into the "GSpace file system" > by sending email with Subject: "GSPACE|new_filename.txt|2174|1|1|1|gs:/ > d$" and putting "new_filename.txt" and "metadata.txt" as attachment. > However the interface will fill the "from" information with the sender > email address. The sender email address can be spoofed. > > - folder creation. You can create new folder by sending email with > Subject: "GSPACE|test/|-135|1|1|0|gs:/ d$" and "blank.txt" and > "metadata.txt" as attachment. However the interface will fill the "from" > information with the sender email address. The sender email address can > be spoofed. > > > Solution: > --------- > there are more possible solutions to filter unwanted content, such as > inserting unpredictable id-s in the emails, message signing, but none > (in my opinion) which can offer backward compatibility. > > _______________________________________________ > Full-Disclosure - We believe in it. > Charter: http://lists.grok.org.uk/full-disclosure-charter.html > Hosted and sponsored by Secunia - http://secunia.com/ >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/