Microsoft to lock out Windows RDP clients if they are not patched against hijack bug

Microsoft will prevent Windows Server from authenticating RDP clients that have not been patched to address a security flaw that can be exploited by miscreants to hijack systems and laterally move across a network. The bug, CVE-2018-0886, was fixed in March's Patch Tuesday software update, and involves Microsoft's …

[Anonymous Coward]

"It's also worth looking for updates from vendors of third-party RDP clients, as they can also fall foul of this vulnerability."

https://github.com/FreeRDP/FreeRDP/issues/4449

https://github.com/FreeRDP/FreeRDP/issues/4503

https://github.com/FreeRDP/FreeRDP/issues/4498

etc.

It took nearly three whole days from patch Tuesday for a fix to arrive via pacman on my PC.

[hplasm]

It took nearly three whole days from patch Tuesday for a fix to arrive via pacman on my PC.

waccka-waccka-waccka

[DCdave]

Such a shame the patch kills 2008R2 servers running with static IP addresses on VMware. On the other hand, it does make them more secure, by virtue of being unreachable unless there happens to be DHCP available too.

I know, I know, we should all move to Azure...

[Anonymous Coward]

"Such a shame the patch kills 2008R2 servers" and Windows 7 and possibly not just on VMware either. We also have several instances of wifi being disabled on Windows 7 on our helpdesk ...

[arctic_haze]

Enough is enough

It's good to have a safe operating system. However the recent Microsoft patches introduce so many side effects that actually it is better to have an operating system. I know I'm safer with no Internet connection but I still need to comment on The Register from time to time. So I decided not to patch at all.

[knelmes]

Re: Enough is enough

Ugh, I hate anti-vaxxers.

[knelmes]

OK, am I being stupid? The change to mitigated will still allow unpatched clients to access RD services. From the table in the documentation, in the row for 'Mitigated':

"Client applications that use CredSSP will not be able to fall back to insecure versions."

"Services that use CredSSP will accept unpatched clients."

So clients won't be able to connect to unpatched servers, right? But servers will still allow unpatched clients unless the server is set to 'Force updated clients'. Which MS aren't planning on doing. Which makes the opening line complete round objects.

[knelmes]

Instead of the thumb down could you explain why I'm wrong?

[TheVogon]

"So clients won't be able to connect to unpatched servers, right? "

Patched servers will have the capability to reject connections from unpatched clients. That's the objective here. As per the article title. The risk being mitigated is the interception of administrative credentials being used to logon to a server.

[knelmes]

But only if the setting is set to 'Force Updated Clients' right? Which Microsoft aren't setting by default? Which would make the headline and first line incorrect?

Honestly trying to work this out.

[Joey Deacon]

But only if the setting is set

According to: https://bit.ly/2DR3HQz

Microsoft are looking to enforce 'Mitigated' mode in May so it could bite us in the arse then...

[knelmes]

Re: But only if the setting is set

But as I said above:

"The change to mitigated will still allow unpatched clients to access RD services. From the table in the documentation, in the row for 'Mitigated':

"Client applications that use CredSSP will not be able to fall back to insecure versions."

"Services that use CredSSP will accept unpatched clients."

So clients won't be able to connect to unpatched servers, right? But servers will still allow unpatched clients unless the server is set to 'Force updated clients'. Which MS aren't planning on doing."

[TheVogon]

Re: But only if the setting is set

"But servers will still allow unpatched clients unless the server is set to 'Force updated clients'. Which MS aren't planning on doing."

Yes but why would that be a problem seeing as you only need to enable mitigated mode on your servers to fix the issue as it stops MITM downgrade attacks.

[knelmes]

Re: But only if the setting is set

Exactly, it's not a problem - the article makes it sound like a huge problem. Came here for confirmation of how I was reading the documentation.

[Roland6]

Re: But only if the setting is set

>Exactly, it's not a problem

I can see user calls to support desks increasing as this update gets rolled out and user start to see the new error message...

[Roland6]

Re: But only if the setting is set

Actually, I think this is going to cause problems, specifically with legacy systems.

I assume the RDP client/server for versions of Windows prior to 7/2008, won't get updated. So if I'm running an XP/2003 VM, will the updated RDP client connect to it? my reading of the CVE implies not.

However, if I'm running a pre- 7/2008 client system (eg. XP) then I can set a flag on the 7/2008+ updated server to permit these legacy clients to connect.

Aside: I'm not interested in the pro's and con's of running legacy systems, just that for various reasons people do. I also fully understand why MS no longer publicly support EoL products. However, those of us working in the everyday world have to work with and around these constraints.

[Andrew 99]

Remmina fixes

I read that changing the security level to TLS fixes the issue for the Remmina client, which works for most cases. For stubborn servers on 2008R2, also changing the server RDP security level to TLS as well, helps.

[Anonymous Coward]

Just practicing

Getting ready to lockout plenty others, mmm

[solv]

So I wasn't aware of this flaw until today where it seems the group policy mitigation was enforced by MS without our permission...and now we are scrambling to get business clients back onto their servers. So what about thin clients that don't/can't get updates...too bad for them? Seriously MS?? What the hell - they have no right to just change a group policy without asking...what a bunch of turds

[sfbp]

XP needs a patch too

I'm a bit surprised that Microsoft did not make a patch for XP available (well, they did - it was there under EmbeddedPOS 2009) given how easy it would be and how many people probably need it. Interestingly there is no error message whatsoever (for at least a couple of minutes) when one tries to connect to a patched server with an unpatched XP client, it spins its wheels trying "securing connection".

Installing the two .dll files from there has XP rdp-ing nicely again. Installing the patch was a real pain as they seem to have all but turned off the SFCDisable feature now. Safe mode followed by protecting the files did the job.

Maybe someone decided the bottom line would be impacted by people failing to purchase W10?

Stephen