[Mailman-Users] Content Filtering Scrubs PDF Attachment

I am guessing you mean 'removing' as in throwing away, as opposed to
'scrubbing' as in storing on the server and replacing with a link to
the stored file. If by chance, you do mean 'scrubbing' in this sense,
you need to set Non-digest options->scrub_nondigest to No in the
list's admin interface.


These are the appropriate MIME types. The real question is why isn't
the poster's MUA putting the correct Content-Type: in the header? What
is the Content-Type of these attachments. If this is just one bogus
MUA, you could just accept the bogus Content-Type.


There are alternative ways to patch this. In fact, I'm not sure that
the current behavior couldn't be considered a bug.

Currently, if we have pass_filename_extensions defined, we don't accept
any parts with filenames that don't have a matching extension. I
suppose this is OK since the main inline parts we want probably don't
have filenames so aren't subject to this test. The issue is that
currently the mime types tests are applied first and the filename
extension tests are only applied to what's left. Perhaps the 'pass'
tests should be applied concurrently and a part accepted if it has a
matching mime type OR a matching extension.


Wrong question. The question should be "what's the best way to get list
members to use MUAs that properly identify the types of attachments?"
(not that I know the answer). Basically, you're dealing with
non-compliant MUAs, and given that the MUA is non-compliant, you can't
predict what it will do.

Thanks, Mark. The MUA is including "application/octet-stream" as the
mime type. I didn't include this as passable because I wanted to strip
".exe" files from messages. It looks like if I want to enable
subscribers to attach PDF files, it will at the same time enable them to
attach EXE files. From the security perspective, do most Mailman admins
let EXE files pass?

Thanks,

Ted


-----Original Message-----
From: Mark Sapiro [mailto:msapiro at value.net]
Sent: Friday, July 20, 2007 11:15 AM
To: Fitzpatrick, Ted; mailman-users at python.org
Subject: Re: [Mailman-Users] Content Filtering Scrubs PDF Attachment

Fitzpatrick, Ted wrote:

I am guessing you mean 'removing' as in throwing away, as opposed to
'scrubbing' as in storing on the server and replacing with a link to
the stored file. If by chance, you do mean 'scrubbing' in this sense,
you need to set Non-digest options->scrub_nondigest to No in the
list's admin interface.


These are the appropriate MIME types. The real question is why isn't
the poster's MUA putting the correct Content-Type: in the header? What
is the Content-Type of these attachments. If this is just one bogus
MUA, you could just accept the bogus Content-Type.


There are alternative ways to patch this. In fact, I'm not sure that
the current behavior couldn't be considered a bug.

Currently, if we have pass_filename_extensions defined, we don't accept
any parts with filenames that don't have a matching extension. I
suppose this is OK since the main inline parts we want probably don't
have filenames so aren't subject to this test. The issue is that
currently the mime types tests are applied first and the filename
extension tests are only applied to what's left. Perhaps the 'pass'
tests should be applied concurrently and a part accepted if it has a
matching mime type OR a matching extension.


Wrong question. The question should be "what's the best way to get list
members to use MUAs that properly identify the types of attachments?"
(not that I know the answer). Basically, you're dealing with
non-compliant MUAs, and given that the MUA is non-compliant, you can't
predict what it will do.

You'll want to test all this to be sure, but there's already a default
list of extensions in filter_filename_extensions which is 'exe',
'bat', 'cmd', 'com', 'pif', 'scr', 'vbs', 'cpl' which should block any
'named' attachments with those extensions.

However, if you add 'application/octet-stream' to pass_mime_types and
put 'pdf' and 'png' in pass_filename_extensions you should wind up
accepting named with extension attachments with only .png and .pdf
extensions. You will also accept an application/octet-stream
attachment without an extension, but this may not be particularly
risky, at least to those users with systems that identify a file type
by extension.

So no, it is not a good idea to allow .exe attachments on your list,
but you can allow some application/octet-stream files and still not
allow .exe files.

Not necessarily. You could allow application/octet-stream as an
allowed MIME type, while allowing only certain file extension types.
However, this does widen the hole for attackers to try to get through.
It depends greatly on the particular list and the site. Most of the
sites/lists I help administer (including python.org, where the
mailman-users list is hosted) will explicitly reject EXE and all the
other known major executable file extensions, as well as blocking
application/octet-stream, and only allow through certain MIME types
that are considered to be reasonably safe.

However, do keep in mind that spammers have recently latched onto the
fact that most people do seem to let *.PDF files through, although
I'm not sure what MIME type these messages are being tagged with. If
you allow application/octet-stream and *.PDF through your lists, this
may also open a much wider hole for spammers to go after.

Brad Knowles writes:
FWIW, in a sample of 10 recent .pdf spams, all had extension ".pdf"
and Content-Type "application/pdf", with disposition "inline".
(However, these may all be the same spammer for all I know, I don't
read them.)

Very standards-conforming spammers.