Still no DejaBlue exploits generally available

Topic

New Reply

And, in spite of what you’ve read, there are no DejaBlue attacks in the offing. https://twitter.com/GossiTheDog/status/1163713950258728960
[See the full post at: Still no DejaBlue exploits generally available]

2 users thanked author for this post.

SueW, geekdom

Reply | Quote

Replies

[ek]

I guess I’m interpreting the blog post you cite very differently.  Specifically, the MalwareTech blog post: https://www.malwaretech.com/2019/08/dejablue-analyzing-a-rdp-heap-overflow.html

In the blog post, the author appears to have deliberately crafted test exploits that would just crash the RDP service.  It appeared to me that he did so because it was a very quick and simple proof-of-concept that a BlueKeep style exploit could work.  He did not go further and craft a RCE exploit.  I can imagine why he made that choice.

His sentence in the end of the article is the most important: “This bug is powerful because object instances are stored on the same heap, making it possible to overwrite them.”.  The ability to overwrite heap objects is a powerful vector for remote code execution.

I just don’t get the “no need to take this vulnerability seriously because it’s not being seen in the wild yet” mentality.  That’s because it communicates what many folks want to hear: “no need to take proactive steps now, just wait until a bunch of poor folks get harmed first.”.  That’s all well and good – as long as you are not one of those users initially affected by the security hole.

• This reply was modified 5 years, 9 months ago by ek.

2 users thanked author for this post.

Anton Karlan, jabeattyauditor

Reply | Quote

If MS were supplying a “clean” patch just for the BlueWho family of vulnerabilities, then I would agree with you: Waiting to patch would be foolhardy. However, that is NOT the case; the BlueWho patch is bundled with all manner of unrelated stuff. Consequently, the risk calculation is NOT as simple as you make it out to be. A prudent sysadmin needs to balance the risk of leaving BlueWho unpatched with the risk of patching quickly and then taking one on the chin because of some other so-called “fix” that is buried in the same patch file. And I do mean BURIED, since MS seems loath to tell us EXACTLY what change(s) are present in any given patch. That makes testing VERY difficult, and impossible to do with any degree of confidence, since it becomes a complete guessing game as to what must be tested to feel some assurance that the patch won’t adversely affect production systems. And don’t tell me that unexpected interactions are highly unlikely. What about the recent “Visual Basic” fiasco? Or the early Spectre/Meltdown patches, which actually made the systems on which they were installed LESS secure than if those systems hadn’t been patched at all? If “side-effects” like that were predictable, then why didn’t MS catch (and FIX) them during design, implementation or testing? If not, then my point is proven: Fools rush in whereas prudent sysadmins tread slowly and lightly. QED

1 user thanked author for this post.

Anton Karlan

Reply | Quote

[ek]

Well… wow!

I re-read my initial comment and I could find no mention of patching.  And… that’s because I was careful in the words I chose.  The words I did choose (paraphrased here) were: “…take proactive steps…”.

Heck, as of last month I decided to stop installing updates on my Win 7 systems permanently.    And, I actually disable the performance sucking side channel (eg: Spectre/Meltdown/etc) patches on my systems – but I mitigate the risk through other steps (browser & browser security/privacy add-on choices, browsing habits, firewall rules, etc).

There are indeed steps users can take to mitigate the RDP risk without actually installing update(s).  Those steps have been mentioned by others in this forum (& me too):

• Disable the RDP service
• Block the RDP protocol at the home router/firewall (both inbound & outbound)

One or both of the above have been mentioned in other related threads here and I’ve taken the steps myself… and not patched.

Yes, for some users RDP is essential, so the above is perhaps impractical (OK, you could fine tune the router/firewall blocking rules to allow RDP to/from specific trusted hosts).

But there are also many users that don’t use RDP at all, so disabling and/or blocking RDP seem reasonable mitigations.

I deliberately did not mention the above steps in my original post, nor did I recommend updating.  I left the course of action up to the readers to research & decide for themselves.

But, yes, I did express an opinion about not agreeing with the “no need to take this vulnerability seriously because it’s not being seen in the wild yet” mentality.  I worried it would trigger some rebuttals.  Regardless, I stand by my opinion on the matter.

I’d also like to point out that I’ve been quite vocal (in this forum and elsewhere) about how utterly awful MS updates have become, as they now often seem like a new category of malware.

Thank goodness for Linux.

• This reply was modified 5 years, 9 months ago by ek.
• This reply was modified 5 years, 9 months ago by ek.

1 user thanked author for this post.

Anton Karlan

Reply | Quote