Message-ID: <4550E8A2.4080205@gatech.edu>
Date: Tue, 07 Nov 2006 15:12:18 -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

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



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