Hacker News Reader

Comment by cmurf | Hacker News Reader

Seems to me in 2018 you shouldn't be receiving Word Docs as email attachments from unknown/unauthenticated senders.

In ancient times .exe were banned outright, and I have customers who also ban .zip. And a Word Doc with embedded macro is in effect an executable.

View on HN

Lots of supposedly known senders that are actually hostile actors, some account takeovers, and there are many external facing people who expect to receive word docs from unknown people.

Accounts payable, for example, gets lots of these things as an expected part of the workflow, as does legal, and various parts of management.

PDFs have had problems of their own.

Many of the people that you most want to secure are the same people who need to be exposed to the outside world. CEO and CFO HAVE to deal with random people, as it's the job, but they are the most dangerous. If someone needs a 5 step verification process that takes days to communicate with your CEO, then you are not going to get may new clients or investors.

Yep. And what about the most obvious? HR. Resumes, cover letters, reference material, etc. Many places don't subscribe to the evil ATS or taleo parser tools and casually open whatever is sent to them with a familiar icon or extension as attachment.

These people need to be receiving Word Docs with macros and need to open those docs executing macros by default, from unknown/unauthenticated people? That doesn't make much sense to me. I see automated tasks as being internal. Receiving automated tasks from random people and executed by default seems like asking for trouble.

You dont understand. Everyone has all Macros enabled by default because Bob down the hall wrote an Excel macro that lets us plug numbers in our spreadsheet from the mainframe in 5 seconds instead of typing them for 20 minutes.

Everyone knows that to get the Macro to work, step one is to enable all macros.

We could reduce our risk a lot using a combo of technology that isolates executions to certain deprivileged memory ranges with tech that blocks code injections in general. Think a separation kernel running a desktop OS in one partition and in another a PDF viewer written in Rust. The general tech for stuff like that was being sold commercially far back as 2005, minus Rust of course. They did have Ada runtimes, though. The NSA and military ended up retiring the concept because there was too much complexity in PC hardware they thought would lead to attacks bypassing the VM boundaries. They did.

The old approach, which I used, was to use a mix of desktop and embedded boards physically separated with a KVM switch plus controlled, sharing mechanism. Just keep the untrustworthy stuff on their own machines. It's klunky but a greater chance of working securely.

Would it be possible to simply serve employees a hardened email VM on demand which included editing and composition utilities (office, Adobe)? I envision something that could be destroyed after each use to prevent persistence and could be put on a VLAN which included only the email server and specific internal services if need be to make pivoting difficult.

There is something similar on the market called Bromium. It spawns micro VMs for some filetypes so that possible code execution is contained within the micro VM. Still haven't tested it.

https://www.bromium.com/

That's what I was talking about with VM risk, though. You're right back to it. Even the most secure VM will have the hardware and firmware in its attack surface. Those are getting tons of attention right now. It will reduce the number of times you get breached with associated damage. It's not as secure as physical separation, though.

Reply on news.ycombinator.com