Right. I'm aware of that. I get spam post-dated all the time (so it will go the end of the list when sorted by date). I was more thinking that the mail drive program would get the system time from the OS before processing new unsigned mail. Matthew Flaschen Darkz wrote: > Matthew Flaschen wrote: >> Just set it to only accept signed messages starting from a certain date. >> >> Matthew Flaschen >> >> Darkz wrote: >> >>> Matthew Flaschen wrote: >>> >>>> 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/ >>>>> >>>>> >>>>> >>>> >>>> >>> I am not really familiar with message signing but i guess you can not sign >>> already received emails in your inbox. So how you manage the older >>> files(emails)? If you chose to support signed and unsigned emails then you >>> are >>> vulnerable, if you not then you have to delete all files(emails) and >>> rewrite >>> them, which method is no more compatible with the old file-system. Please >>> correct me if I am wrong. >>> >>> Attila Gerendi >>> >> >> >> > Then the remote attacker will have to override the email date. After a fast > test > I found out it can be done by changing the settings on the SMTP server, and > that is possible if you have access to server setting or you own one. I send > this email with altered SMTP server date, you should check in the email > headers > to see how will arrive to you. > > Attila Gerendi
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/