back to article 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 …

  1. Anonymous Coward
    Linux

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

    1. hplasm
      Happy

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

      waccka-waccka-waccka

  2. DCdave
    Flame

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

    1. Anonymous Coward
      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 ...

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

    1. knelmes
      WTF?

      Re: Enough is enough

      Ugh, I hate anti-vaxxers.

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

    1. knelmes

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

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

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

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

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

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

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

                1. Roland6 Silver badge

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

                  1. Roland6 Silver badge

                    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.

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

  6. Anonymous Coward
    Devil

    Just practicing

    Getting ready to lockout plenty others, mmm

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

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

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like