Linux email server that strips down attachments?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Linux email server that strips down attachments?

Samba - linux mailing list
For a change of topic from the impending doom of CLUG…

Is there, or could there be, a Linux email server that strips all the
code and interactivity from incoming attachments while leaving the
content readable?

I'm now in my second job working with mostly non-technical folk, and
I'm seeing a lot of attachments being emailed around, mostly DOCX
(Microsoft Word) and PDFs. Now the first reaction of anyone who
follows the regular stories about phishing and malware spread through
email is "Nooo! Don't do that!" and trying to convince people to
change their ways.

Which I've come to recognise won't work. A lot of people write emails
in Word format because Word is their usual writing tool, just a a lot
of hackers read and write email within Emacs. And PDFs are usually the
best way to send around reports, design proposals, anything where the
appearance needs to be evaluated. Banning attachments is not
realistic.

However, these documents are not being emailed around for editing.
Office 365, Google Docs, Dropbox, whatever, are well established for
collaborative work. At least 95% of the time the recipient just needs
to read them, nothing else.

So, I imagine that these organisations would be considerably more
secure with an email server that examined and stripped down all
incoming attachments. Use the Libre Office code to take apart the
DOCXs and PDFs. Strip out every macro and embedded font, every
fragment of Javascript or Visual Basic, even hyperlinks. Re-assemble
as a pure read-only document and send it on.

Doable?


--

        cheers,
        Hugh Fisher

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linux email server that strips down attachments?

Samba - linux mailing list
antiword might be a start here, but it wont do all the things you
need. I used it many years ago, not sure if its still up to date.

a


On 2 July 2017 at 21:06, Hugh Fisher via linux <[hidden email]> wrote:

> For a change of topic from the impending doom of CLUG…
>
> Is there, or could there be, a Linux email server that strips all the
> code and interactivity from incoming attachments while leaving the
> content readable?
>
> I'm now in my second job working with mostly non-technical folk, and
> I'm seeing a lot of attachments being emailed around, mostly DOCX
> (Microsoft Word) and PDFs. Now the first reaction of anyone who
> follows the regular stories about phishing and malware spread through
> email is "Nooo! Don't do that!" and trying to convince people to
> change their ways.
>
> Which I've come to recognise won't work. A lot of people write emails
> in Word format because Word is their usual writing tool, just a a lot
> of hackers read and write email within Emacs. And PDFs are usually the
> best way to send around reports, design proposals, anything where the
> appearance needs to be evaluated. Banning attachments is not
> realistic.
>
> However, these documents are not being emailed around for editing.
> Office 365, Google Docs, Dropbox, whatever, are well established for
> collaborative work. At least 95% of the time the recipient just needs
> to read them, nothing else.
>
> So, I imagine that these organisations would be considerably more
> secure with an email server that examined and stripped down all
> incoming attachments. Use the Libre Office code to take apart the
> DOCXs and PDFs. Strip out every macro and embedded font, every
> fragment of Javascript or Visual Basic, even hyperlinks. Re-assemble
> as a pure read-only document and send it on.
>
> Doable?
>
>
> --
>
>         cheers,
>         Hugh Fisher
>
> --
> linux mailing list
> [hidden email]
> https://lists.samba.org/mailman/listinfo/linux

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linux email server that strips down attachments?

Samba - linux mailing list
In reply to this post by Samba - linux mailing list
Interesting problem.

On 02/07/17 21:06, Hugh Fisher via linux wrote:
> For a change of topic from the impending doom of CLUG…
>
> Is there, or could there be, a Linux email server that strips all the
> code and interactivity from incoming attachments while leaving the
> content readable?

Yes.

Exim.

For those that fear the subset of HTML used in email you can use
acl_smtp_mime (formerly demime)

To process attachments - you can use antiword and pdf2text.

In both cases adjust your ACL rules to implement the conversions....
however I'd strongly suggest *not* doing these things because: the
results are inconsistent; it presupposes that every email recipient does
not have visual handicaps; it overlooks the positive features of marked
up documents (images, links, character formatting; accessibility tags;
versioning controls; inline MIME digital signatures; and because proper
implementation of malware scanning *and* secured client systems make the
processes redundant.

You *will* need considerably more resources for your email system if you
decide to go the path you propose.

IMO the source of the problem is where the malware has an effect - on
the client systems. If people do, um, bad things as the result what the
postie delivers I'd rather the problem is solved by educating the
recipients and limiting their ability to shoot foot, than *trust* and
task Australia Post with scanning and modifying the mail.

>
> I'm now in my second job working with mostly non-technical folk, and
> I'm seeing a lot of attachments being emailed around, mostly DOCX
> (Microsoft Word) and PDFs. Now the first reaction of anyone who
> follows the regular stories about phishing and malware spread through
> email is "Nooo! Don't do that!" and trying to convince people to
> change their ways.

A major problem - and the most common cause of software projects failing
is failure to consult with end-users. The best intentions will not
result in a system policy/software project being used if the end-users
don't want or understand it...

I feel your pain (seriously) - but my experience is that it's very
difficult (even in high security environments) to trample on employees
rights to treat their employers systems and equipment as their own
personal playground - even when nothing in their job description or
qualifications gives them the ability to assess the risks of their
actions (no need to explain the problem where a user with
non-administrative rights can trigger malware with elevated system rights).

Apropos of nothing - it takes about 20 minutes of poking around to gain
remote access as a system admin on the "locked down" M$ Surface devices
designed/marketed as being "the defence" against that problem.

>
> Which I've come to recognise won't work. A lot of people write emails
> in Word format because Word is their usual writing tool, just a a lot
> of hackers read and write email within Emacs.

*cough* Vi
:p

> And PDFs are usually the
> best way to send around reports, design proposals, anything where the
> appearance needs to be evaluated. Banning attachments is not
> realistic.
>
> However, these documents are not being emailed around for editing.
> Office 365, Google Docs, Dropbox, whatever, are well established for
> collaborative work.

Each have their failings e.g. security, privacy, integration with local
tools/applications.

> At least 95% of the time the recipient just needs
> to read them, nothing else.

That varies considerably from one organisation to another, and within
organisations.

>
> So, I imagine that these organisations would be considerably more
> secure with an email server that examined and stripped down all
> incoming attachments.

That might be true if it were only text that was important (and we
ignore proof of the author e.g. PGP, as opposed to the oft-neglected
proof of the sender e.g. DKIM etc).

> Use the Libre Office code to take apart the
> DOCXs and PDFs. Strip out every macro and embedded font, every
> fragment of Javascript or Visual Basic, even hyperlinks. Re-assemble
> as a pure read-only document and send it on.

A (properly?) implemented client system 'should' prevent any of those
things from being a concern - instead of transferring responsibility for
security from the unrestricted ability of the end recipient to shoot
foot to solely being the responsibility of the email server (like
passing laws against sharp corners on furniture to protect the clumsy)
(??) As you undoubtedly discovered - that's an issue that's rarely
addressed, and failure to do so just exacerbates the existing problem.

>
> Doable?
>
>

Yes but - to be effective you would need to implement and enforce
organisation wide publishing policy, and spend considerable time and
resources doing system analysis to try and prevent unforeseen problems.
There are also legislative issues with removing accessibility aids -
aids that are not possible to add to plain text without reducing the
content itself to "dumb text".

Consider that only a small percentage of people that "use" email - use
it effectively (most use it like postcards instead of conversation), and
fewer still can "write" (communicate effectively). Very, very few
understand or use proven identification systems - which makes much
content redundant/dangerous regardless of the format it's delivered in. :(


Kind regards


--
    A: Because we read from top to bottom, left to right.
    Q: Why should I start my reply below the quoted text?

    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?

    A: The lost context.
    Q: What makes top-posted replies harder to read than bottom-posted?

    A: Yes.
    Q: Should I trim down the quoted part of an email to which I'm reply

http://www.idallen.com/topposting.html

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linux email server that strips down attachments?

Samba - linux mailing list
On Thu, Jul 6, 2017 at 5:52 PM, Scott Ferguson via linux
<[hidden email]> wrote:
> however I'd strongly suggest *not* doing these things because: the
> results are inconsistent; it presupposes that every email recipient does
> not have visual handicaps; it overlooks the positive features of marked
> up documents (images, links, character formatting; accessibility tags;
> versioning controls; inline MIME digital signatures;

I'm well aware of these, which is why I very carefully wrote that I
wanted to *preserve* formatting and markup, reassembling the content
as valid DOCX/PDF, not convert everything to plain text. While I am at
times nostalgic for USENET, I'm not trying to impose plain ASCII or
UTF-8 on everyone.

> and because proper
> implementation of malware scanning *and* secured client systems make the
> processes redundant.

Which is what we, the IT industry, have been trying to do for at least
the past decade. Malware scanners aren't new or rare, they just don't
work. If malware scanners were going to prevent phishing and malware
attacks, they would have by now.

(I know that scanners can pick up attacks IF we already know about
them. Surprise surprise, evil minded individuals keep coming up with
new attacks.)

> IMO the source of the problem is where the malware has an effect - on
> the client systems. If people do, um, bad things as the result what the
> postie delivers I'd rather the problem is solved by educating the
> recipients and limiting their ability to shoot foot, than *trust* and
> task Australia Post with scanning and modifying the mail.

Again, educating users is what we've been trying and failing to do for
over a decade. If education worked, phishing attacks would have died
out long ago.

People, myself included, will click on the wrong link or whatever
because the majority of humanity are neither James Bond nor Dungeons &
Dragons adventurers. We don't assume that everyone we come in contact
with might be an enemy agent, and we don't constantly check for traps.
Even skilled people get tired or distracted.

The people on this list are presumably more technical minded than
most. Hands up if you check PDF documents for embedded JavaScript
before you open them?

As for responsibility of the mail delivery system rather than
individuals, a thought experiment. Put 500 grams of some radioactive
substance in a box, address it to the workplace office/cubicle of
someone you know at the Australian Taxation Office or Northrop
Grumman, and drop it in a postbox. Do you think it's going to arrive
on their desk? (Or if it does, that there won't be some serious
conversations with the security and mailroom staff?)

Organisations impose all kinds of security practices on their
employees. Stripping toxic crap out of email attachments is something
malware scanners already do. I just want to extend it to whitelisting
rather than blacklisting.

> I feel your pain (seriously) - but my experience is that it's very
> difficult (even in high security environments) to trample on employees
> rights to treat their employers systems and equipment as their own
> personal playground - even when nothing in their job description or
> qualifications gives them the ability to assess the risks of their
> actions (no need to explain the problem where a user with
> non-administrative rights can trigger malware with elevated system rights).

Nothing I'm suggesting takes away capabilities from end user desktops.
If Jane in Auditing wants to write a Visual Basic macro or whatever
that extracts email addresses from the organisation directory and
sends out a form letter, I don't want to stop her. But there's
absolutely no reason why that kind of program can be emailed to
everyone from anywhere in the world. Even internally Jane should not
be able to do so: she can drop it on the shared file server and email
everyone where to look instead.

>> At least 95% of the time the recipient just needs
>> to read them, nothing else.
>
> That varies considerably from one organisation to another, and within
> organisations.

And I said this was for organisations, not everyone. If your company
or whatever really needs people to receive and execute random bits of
code in email, I imagine you won't be interested.

> Consider that only a small percentage of people that "use" email - use
> it effectively (most use it like postcards instead of conversation), and
> fewer still can "write" (communicate effectively). Very, very few
> understand or use proven identification systems - which makes much
> content redundant/dangerous regardless of the format it's delivered in. :(

Which is why I think this would be easier to get implemented and used
than you think. The number of people who actually want to send macros
and JavaScript and whatnot is microscopic. Nobody else will notice.

Oh, and and I didn't make it clear first time around that this would
of course be a Linux system. "Your email has been checked by Linux
Steam Cleaner" would make a nice tag at the end of incoming emails,
and might even get a few people thinking what else Linux might be good
for.

--

        cheers,
        Hugh Fisher

--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Linux email server that strips down attachments?

Samba - linux mailing list
Perhaps it might be better to assume that some things are going to get
through your defences.

How about putting the email client (and enough stuff to read and answer
the emails) in a sandbox that was isolated from the users' other files
and programs. Any time a file needed to be moved to or from the email
sandbox it would be subject to stringent examination.
(This might also make it a bit more difficult for users to email
sensitive information out of the organisation.)

Brenton

On Fri, 2017-07-07 at 12:57 +1000, Hugh Fisher via linux wrote:

> On Thu, Jul 6, 2017 at 5:52 PM, Scott Ferguson via linux
> <[hidden email]> wrote:
> > however I'd strongly suggest *not* doing these things because: the
> > results are inconsistent; it presupposes that every email recipient does
> > not have visual handicaps; it overlooks the positive features of marked
> > up documents (images, links, character formatting; accessibility tags;
> > versioning controls; inline MIME digital signatures;
>
> I'm well aware of these, which is why I very carefully wrote that I
> wanted to *preserve* formatting and markup, reassembling the content
> as valid DOCX/PDF, not convert everything to plain text. While I am at
> times nostalgic for USENET, I'm not trying to impose plain ASCII or
> UTF-8 on everyone.
>
> > and because proper
> > implementation of malware scanning *and* secured client systems make the
> > processes redundant.
>
> Which is what we, the IT industry, have been trying to do for at least
> the past decade. Malware scanners aren't new or rare, they just don't
> work. If malware scanners were going to prevent phishing and malware
> attacks, they would have by now.
>
> (I know that scanners can pick up attacks IF we already know about
> them. Surprise surprise, evil minded individuals keep coming up with
> new attacks.)
>
> > IMO the source of the problem is where the malware has an effect - on
> > the client systems. If people do, um, bad things as the result what the
> > postie delivers I'd rather the problem is solved by educating the
> > recipients and limiting their ability to shoot foot, than *trust* and
> > task Australia Post with scanning and modifying the mail.
>
> Again, educating users is what we've been trying and failing to do for
> over a decade. If education worked, phishing attacks would have died
> out long ago.
>
> People, myself included, will click on the wrong link or whatever
> because the majority of humanity are neither James Bond nor Dungeons &
> Dragons adventurers. We don't assume that everyone we come in contact
> with might be an enemy agent, and we don't constantly check for traps.
> Even skilled people get tired or distracted.
>
> The people on this list are presumably more technical minded than
> most. Hands up if you check PDF documents for embedded JavaScript
> before you open them?
>
> As for responsibility of the mail delivery system rather than
> individuals, a thought experiment. Put 500 grams of some radioactive
> substance in a box, address it to the workplace office/cubicle of
> someone you know at the Australian Taxation Office or Northrop
> Grumman, and drop it in a postbox. Do you think it's going to arrive
> on their desk? (Or if it does, that there won't be some serious
> conversations with the security and mailroom staff?)
>
> Organisations impose all kinds of security practices on their
> employees. Stripping toxic crap out of email attachments is something
> malware scanners already do. I just want to extend it to whitelisting
> rather than blacklisting.
>
> > I feel your pain (seriously) - but my experience is that it's very
> > difficult (even in high security environments) to trample on employees
> > rights to treat their employers systems and equipment as their own
> > personal playground - even when nothing in their job description or
> > qualifications gives them the ability to assess the risks of their
> > actions (no need to explain the problem where a user with
> > non-administrative rights can trigger malware with elevated system rights).
>
> Nothing I'm suggesting takes away capabilities from end user desktops.
> If Jane in Auditing wants to write a Visual Basic macro or whatever
> that extracts email addresses from the organisation directory and
> sends out a form letter, I don't want to stop her. But there's
> absolutely no reason why that kind of program can be emailed to
> everyone from anywhere in the world. Even internally Jane should not
> be able to do so: she can drop it on the shared file server and email
> everyone where to look instead.
>
> >> At least 95% of the time the recipient just needs
> >> to read them, nothing else.
> >
> > That varies considerably from one organisation to another, and within
> > organisations.
>
> And I said this was for organisations, not everyone. If your company
> or whatever really needs people to receive and execute random bits of
> code in email, I imagine you won't be interested.
>
> > Consider that only a small percentage of people that "use" email - use
> > it effectively (most use it like postcards instead of conversation), and
> > fewer still can "write" (communicate effectively). Very, very few
> > understand or use proven identification systems - which makes much
> > content redundant/dangerous regardless of the format it's delivered in. :(
>
> Which is why I think this would be easier to get implemented and used
> than you think. The number of people who actually want to send macros
> and JavaScript and whatnot is microscopic. Nobody else will notice.
>
> Oh, and and I didn't make it clear first time around that this would
> of course be a Linux system. "Your email has been checked by Linux
> Steam Cleaner" would make a nice tag at the end of incoming emails,
> and might even get a few people thinking what else Linux might be good
> for.
>
> --
>
>         cheers,
>         Hugh Fisher
>


--
linux mailing list
[hidden email]
https://lists.samba.org/mailman/listinfo/linux
Loading...