Live data from Hacker News

Microsoft: 0Day Exploit Targeting Word, Outlook

krebsonsecurity.com

21–30 of 43 posts

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#21

Earlier quoted context omitted.

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.

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

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#22

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

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

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#23
post #18

Earlier quoted context omitted.

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 tha…

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…

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

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#24

Earlier quoted context omitted.

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.

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 t…

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!)

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#25
post #6

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…

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.

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#26
post #17

Earlier quoted context omitted.

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).

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#27

"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.

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#28
post #27

"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...

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#29

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

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.

Re: Microsoft: 0Day Exploit Targeting Word, Outlook

#30
post #28
post #27

Earlier quoted context omitted.

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_1B81DC42240AEE4B96F487A2683E7EEB0…

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.
Post reply on HN