full-disclosure - Re: Mail Drives Security Considerations

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <454B6E2B.80109@gatech.edu>
Date: Fri, 03 Nov 2006 11:28:27 -0500
From: Matthew Flaschen <matthew.flaschen@...ech.edu>
To: Darkz <darkz.gsa@...il.com>,
	full-disclosure <full-disclosure@...ts.grok.org.uk>
Subject: Re: Mail Drives Security Considerations

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/
> 



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/