Two of this month’s Update Tuesday vulnerabilities relate to Microsoft’s Group Policy system.
Those two bugs, MS15-011 and MS15-014, have stolen the spotlight.
They’ve acquired a high profile for a number of reasons:
- They both allow Remote Code Execution (RCE) in the most general way possible: by feeding imposter files from a server to a client. (I ask for a trusted program; you send me malware instead.)
- They both involve Group Policies and Group Policy Objects (GPOs), features of Windows Active Directory that are ironically supposed to simplify administration, improve consistency and boost security.
- One of the two bugs has been given a catchy, media-friendly name (JASBUG) and a big PR shove by one of the companies that helped to uncover it.
Curiously, or perhaps amusingly, the company that came up with the name JASBUG named the bug after itself, JAS Global Advisors.
(Hats off to JAS Global Advisors for not going public with details of the flaw before Microsoft had a fix ready, even though this took more than a year.)
However, as you will see, JASBUG is less of a bug, and more of a design flaw left over from the old days.
In the past, network security was designed around “keeping the inside safe from the outside,” rather than the more general “protect each computer from all the others.”
These days, network defence that assumes a rigidly-defined perimeter isn’t good enough, because imposters and crooks may very well be on the inside looking out, not the old way around.
Very greatly simplified, here’s what needed fixing.
MS15-014 – Vulnerability in SMB
When you log on to an Active Directory network, the server will send you any updates to what’s called your Group Policy, so that your sysadmin has an opportunity to set up a standardised, secure configuration on every PC that is allowed to join the network.
But in MS15-014, a Group Policy update that fails (or, presumably, that is cunningly made to fail by network interference from an attacker) may cause your computer to fall back to an insecure state.
In particular, the security setting related to SMB Signing may be relaxed, which effectively turns off any cryptographic verification between your computer and file shares on the network.
Think of it as connecting to a website over HTTPS (secure HTTP), logging in to what you are sure is the right site, and then invisibly being redirected to the content of the site over plain old unauthenticated HTTP.
In short, if a Group Policy update breaks, a crook could redirect your network file traffic to an imposter server, and your computer simply wouldn’t notice.
That CALC.EXE program that you try to run from \\TRUSTEDAPPS could be replaced with a copy of MALWARE.EXE from \\203.0.113.66 instead.
The MS15-014 patch sorts this out by making Group Policy updates fail closed, not fail open, so that a broken Group Policy update won’t leave you with a broken SMB Signing setting.
MS15-011 – Vulnerability in Group Policy
MS15-011 is similar, but was much trickier to fix.
Here, a crook who can redirect your network traffic to an imposter server may be able to subvert your Group Policy update itself, without needing to get SMB Signing to fail first.
This bug is a sort of Catch-22: to find out if SMB Signing should be turned on, a client has to fetch a Group Policy from the Active Directory server, during which time SMB Signing is irrelevant.
The server validates the client via the logon process, but the client doesn’t validate the server. (This, in a nutshell, is the flaw.)
And a client’s Group Policy is applied is by fetching various policy files and scripts from the server and running them, e.g. \\DOMAINSRV\NETLOGON\logon.cmd.
So a crook who can redirect traffic to an imposter logon.cmd file on an imposter server pretty much has script-kiddie-level Remote Code Execution.
He can put any commands he likes in his bogus logon.cmd script, and your computer will run them.
What to do?
Fixing this problem was much harder than MS15-014, because Microsoft had to:
- Add a feature to implement what is effectively SMB Signing during the Group Policy process, so that your client can validate the server before trusting its Group Policy data.
- Turn on the above new feature (known as Mutual Authentication) on every client.
Ironically, the easiest way to implement step (2) turned out to be…
…using a Group Policy Object.
In other words, to fix this hole, you have to run the gauntlet against it one last time.
You install the patch, reboot your PC, log in one last time with Mutual Authentication off, and rely on a Group Policy update to enable the new feature.
Don’t forget
Don’t forget to install all the other updates from this month’s batch, too.
JASBUG may have stolen the spotlight, but there are numerous other RCE flaws patched in Internet Explorer, Office (including the Word Viewer) and the Windows kernel itself.
Any of these could expose your users to attack, whether they have a logon and are part of a Group Policy or not.
→ For a full list of this month’s fixes, please see the SophosLabs Vulnerabilities page.
Patchwork letters and background of denim cloth courtesy of Shutterstock.
