Microsoft: 0Day Exploit Targeting Word, Outlook | Hacker News Reader

Microsoft: 0Day Exploit Targeting Word, Outlook

krebsonsecurity.com

82 pointsca98am7942 comments

I'm confused by the idea that there could be a vulnerability while reading RTFs, of all things. Annoying; I frequently send out documents in RTF format to make sure everyone can read them...

I stick with .pdf files

However, that might be bad practice.

With Adobe Reader it's probably even worse, to be honest.

For the past few years I've been using Chrome as a PDF reader (I don't use it as my primary browser, but have it nonetheless). I'm not saying Chrome can't be vulnerable... it's just good to get rid of such pointless software as PDF reader. Especially if the case is the bloated Acrobat Reader (though I think the UX was great with that one).

There have been countless (known) RTF vulnerabilities for over a decade.

Any data format that is read by an unsafe language (i.e. C/C++ here most likely) is prone to remote execution. They are pretty much like wandering around with a machine gun with the safety off. This is perfectly fine if you're trained for years to do this (Queens guard for example) but some drunk redneck (which is most of us, me included) will inevitably kill people.

Typical example of a buffer overflow that leads to execution specific to this case, although I'm sure this has been posted a million times here:

1. RTF parser allocates char[15] on the stack for storing the font family from {\fonttbl\...

2. Joe hacker shifts out a font definition of 15 chars plus a return address to some arbitrary code and the code itself.

3. The parser reads until the end of the fonttbl definition ;} which is longer than the buffer specified.

4. This blindly overwrites the return address by writing beyond the end of the buffer and pokes some arbitrary code on the end. If you're lucky this won't cause a bus error / MMU trap

5. The function returns and the malicious return address is jumped to executing Joe Hackers code.

Ultimately anyone can make this mistake when programming in C/C++ and they frequently do. It takes considerable skill to not blow your toes off like this.

There are certain mitigation method which prevent this but they aren't universally enabled or available or 100% effective.

I've pretty much given up on C these days but I spent a lot of time making sure stuff like this was impossible and most importantly avoided parsing anything myself when nice tools like lex/yaxx are around that have all this stuff safely wrapped up. I didn't win every time.

"One way to harden your email client is to render emails in plain text"

er yes.

This is one of the biggest false assumptions that I see smart people making. Unless you have verified the implementation under the hood, you have no knowledge that the parser and renderer are not being executed on a rich text part regardless of what is displayed on the screen.

Unless it's multi-part MIME which is usually the encapsulation mode for RTF based email. In that case, there's usually a plain text copy attached to the body as well which doesn't need to be read by the parser or any of the rich text stuff.

Confirmed:

   Content-Type: multipart/alternative;
	boundary="_000_1B81DC42240AEE4B96F487A2683E7EEB0A6AE7505BTHHS2E12BE2Xh_"
   MIME-Version: 1.0
   --_000_1B81DC42240AEE4B96F487A2683E7EEB0A6AE7505BTHHS2E12BE2Xh_
   Content-Type: text/plain; charset="Windows-1252"
   Content-Transfer-Encoding: quoted-printable

   RTF test

From outlook 2013 in RTF mode...

And I use mutt for my personal email...

It's unlikely that an attacker uses a well-behaved email-client to attack you. The parent points out that you don't know what your client does if it receives a rich-text (HTML,...)-only email and you set your client to render it as plain text. Your client will probably use some sort of parser to tell the formatting from the content and remove the formatting. If that is the "regular" parser, you're still vulnerable.

...and if the vulnerability is in the MIME parser itself?

It wouldn't be if the mitigation was to stop viewing RTF as it says on technet...

Well there goes half of .gov and .mil... (at least the agencies not forcing plain text email)

Fortunately, I think the current exploits rely on ActiveX controls which are disabled when reading Outlook RTF messages. In fact, I have seen no real world Word exploits using Outlook RTF messages, probably because spear phishing is effective enough.

The advisory says that Office for Mac 2011 is also affected, implying that it's not related to ActiveX controls.

The bug is not related to ActiveX controls, but current exploits for this bug rely on one of them.

Everyone in my office runs MS Office for inane reasons, I did try to make them move to openoffice/libreoffice w/ thunderbird, we run an open stack behind the scenes and things simply integrate better..

I feel like this is a massive 'told ya so' after spending thousands of pounds of company money on licenses, now I'll have to spend hours of my time fixing everyones machine one by one, just in case. >_<

hopefully a fix comes in soon and I don't have to worry too much, I assume it will but getting everyone to update (well, forcing it) is a bit hard too.

Serious question -- I don't intend to troll -- I've heard lots of people claim that as soon as OpenOffice et al. get more popular, more malware will target them. It's not as if Microsoft has a monopoly on bugs. Do you think there's ay truth to this line of thinking?

From a security situation, the worst situation is everyone running different mail clients, because then if any one of them has a vulnerability someone can send in a crafted mail to take over their box and gain access to your private company docs.

"Monoculture" isn't always bad.

I don't understand this theory that monoculture is safer in a corporate environment. Any interesting organization has more than one secret recipe. Virtually everyone has different access to different systems. If they are all vulnerable to the same bug, the attacker quickly gains control of everything. If they gain control of a single segment, then they can be detected.

The odds of the attack being identified once that segment is compromised is much higher, since everyone else has the opportunity to identify the bad behavior.

I think the theory is that once you have any beachhead onto a system, that existing local priv escalation exploits and network mapping techniques are almost always sufficient to complete the exploitation of your corporate network.

So if you have 5 people using 5 different email clients, all 5 of those must be kept secure from spear phishing or email-viewing vulnerabilities to avoid having a hacker get a beachhead on your network.

But if those 5 people are using 1 email client, you only have to keep that 1 safe (and you'd have to keep it safe anyways).

Monocultures are probably bad for drive-by automated hacking though, so I suppose it's a matter of deciding what threat model you're most at risk from.

> you only have to keep that 1 safe

This argument may appeal to the self-indulgent system administrator who believes he alone knows perfection. In reality, there is no perfection. One must know there are things one does not know. If China is stock-piling zero days against Outlook, how are you to know? In fact, if there is anything we have learned from biological systems, surely it is that when a monoculture falls, it falls harder and faster than any other variation.

I know it's appealing, but don't try too hard to apply biological analogies to computers.

If you are trying to mitigate against all your computers being taken down at once, diversify. If you are trying to keep intruders out of your network, reduce your surface area.

Well, let me reiterate: "(and you'd have to keep it safe anyways)".

You're right that no one is perfect, but that's no reason to expand the number of directions threats can come from.

This is the opposite of the commonly held belief in security.[1] As an attacker, I would invest all of my efforts into finding a 0day in one application, knowing it would work on any machine I choose.

If everyone uses different software, say for browsers, there are 3 or 4 major options and a fully reliable exploit (which is rare, but for the sake of argument) will still fail on 25% of targets. Now I need four 0days to know that I can compromise my target. If you're running multiple OSes, the same vulnerability requires a different exploit, so the number goes up even more. I also need a high quality rootkit that works on all of them.

It's not as though I only have to compromise a single box in an entire network to get what I need. Though I don't need to compromise every single box either, so in practice it's somewhere in the middle.

[1] http://en.wikipedia.org/wiki/Monoculture_%28computer_science...

Do you need 4 0days or 4 targets? I would assume the latter would be the easier thing to get. If that's true, the GPs point has some merit. You just need to find one person running some insecure software and choose him as your target. (I will fully admit I know little about how security works in practice, and would be glad to be proven wrong!)

> just need to find one person running some insecure software and choose him as your target.

The more options they use, the less likely it is the right person will be running the right exploitable client. You need all vulnerabilities aligned to succeed.

Right, if I want into your network, I just need in. I don't need to compromise every single person.

Now if you were discussing resistance to worms, everyone being different helps. It depends on your threat model.

I don't think they'll ever get that popular. Malware still isn't targeting Word and Outlook for Mac, despite them being vulnerable, so OpenOffice has a long way to go.

It looks like the temporary fix is just adding a registry key[1]. This can be automated via login scripts or pushed in a SCCM package.

1: https://technet.microsoft.com/en-us/security/advisory/295309...

A quick search reveals arbitrary code vulnerabilities in OpenOffice, too, so what's your point? Large surface area apps written in C++ will probably always have these issues.

As someone who used Word, and especially Excel (for data analysis) pretty intensively — if I couldn't use these tools for work, I'd probably think very hard about finding another job. Excel is miles ahead not only of any competing software, even it's OSX version is very subpar to the Windows one: I used parallels just to run it on my Mac. The usability difference is so big, it's like comparing working with and without version control in terms of productivity.

Most people don't use Word or Excel anywhere near as you do and only use them cause...cause...er...you're supposed to. Aren't you? Like cause everyone uses Photoshop cause...you're supposed to. Aren't you?

No, I used them because I tried nearly all of the alternatives and decided that they were the best for the task at hand.

Chances are you are the type of person I complain about every day. Using Excel for things it should not be used for....

There are true data analysis tools on the market, Excel is not one of them

I didn't say that it was the _only_ tool I used. I also regularly used R and SQL.

However, it is the best tool for fast mockups and visualization.

spend hours of my time fixing everyones machine one by one

probably you could instead spend those on writing an automated solution then run it against all machines?

You tried to make them move to openoffice/libreoffice w/ thunderbird but apparently you failed. Could you share what was the experience like?

I do wish they would tell us if EMET[1] is an effective mitigation for this vulnerability or not. Considering it involves memory corruption it's likely.. But finding out the hard way would be no fun.

[1] http://support.microsoft.com/kb/2458544

"First, our tests showed that EMET default configuration can block the exploits seen in the wild."

http://blogs.technet.com/b/srd/archive/2014/03/24/security-a...

It's usually the case that EMET blocks the "standard" exploit, but it can be bypassed with a little more work. It depends on the bug, but there are real world cases for which many have exploits that fully bypass EMET with all settings on.

Funny that the C&C's IP (185.12.44.51) reveals that the machine was used to confirm bitcoin transactions... Pretty sure it will try to rob you ;)

Reply on news.ycombinator.com