Message-ID: <454F2D7E.6080000@gatech.edu>
Date: Mon, 06 Nov 2006 07:41:34 -0500
From: Matthew Flaschen <matthew.flaschen@...ech.edu>
To: Darkz <darkz.gsa@...il.com>
Cc: full-disclosure@...ts.grok.org.uk
Subject: Re: Mail Drives Security Considerations

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



Download attachment "signature.asc" of type "application/pgp-signature" (251 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists