Microsoft drops rush Internet Explorer fix for remote code exec hole Microsoft has released an out-of-band patch for Internet Explorer versions 7 through 11, to close a dangerous remote code execution flaw allowing attackers to commandeer machines. The attack will be a highly useful tool in hacker arsenals likely allowing them to build powerful phishing, watering hole, and malvertising …
"Redmond's new Edge browser is not impacted."
I wonder why?
http://m.theregister.co.uk/2015/08/17/microsoft_replaces_windows_10_patch_update_wont_say_why/
Not that I actually believe that, but it does hint that there might be a "Vulnerability? What vulnerability?", as the updates silently churn in the background, type scenario coming.
What the good people of the register failed to understand is the meaning of the term cumulative according to Microsoft's dictionary. The update wasn't replaced, new bug fixes were added to it and it was pushed to users again. Those who had the earlier fixes just downloaded the new ones while the rest downloaded every fix that Microsoft has pushed out for windows 10 since its launch.
This is how Microsoft intends to keep everyone updated. Apart for zero day vulnerabilities all other updates will be grouped together meaning if you want a new security update you will have to take every security and feature update that has been released till then since it is all now part of the same cumulative update.
"I wonder why"
Microsoft's KB article says "A remote code execution vulnerability exists when Internet Explorer improperly accesses objects in memory." so it is probably something like a use-after-free.
If this was in the back-compat cruft then it would be removed when that cruft was deleted from the IE codebase to make the first version of Edge. At the time, they needn't have been aware that the bug existed, or that they'd just removed it.
An attacker who successfully exploited this vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited this vulnerability could take complete control of an affected system.
"A simple fix for this is to not allow browsers to run under admin accounts by default. Disabling other common attack vectors in a similar manner (e.g. email clients) will result in increased security on systems. In general, it is a good idea to not do non-administrative tasks using an admin account."
- Captain Obvious (attrib.)
> A simple fix for this is to not allow browsers to run under admin accounts by default.
If you do not turn off UAC - you are never running with admin capability by default on Windows. On Windows - unlike Unix - your identity is separated from your privileges.
When you log in using an administrator account, you retain the identity, but all administrative privileges are stripped from the *token* that is created. Security tokens on Windows are infinitely more capable than the naive Unix "effective user" thingy.
As a committed UNIX and Linux proponant, I've frequently said that the security model of UNIX-like operating systems is one of it's weakest features. but the flip side of this is that the role based access control systems, where you acquire additional privilege through further authentication is complex, and very rarely used properly or correctly.
This can be seen in the slow take-up of RBAC in the proprietary UNIXes that implemented it nearly 20 years ago, and SELinux, as well as the number of times that it is not used, or not used appropriately in other OSs.
Bearing in mind how many people even working in the industry as a whole don't understand what RBAC is, or how it works, the well understood UNIX-like SUID, uid and euid mechanism, which is basically less complex, and deployed properly by a greater number of people may be preferable.
Of course, the large number of senior application developers who cut their teeth on Windows ME and earlier, who just disable all the security or insist on it running with privilege on whatever platform they're on to get their applications to work properly are a serious problem with many applications. Fortunately, the security message is finally getting through, and the influence of these people is waning, and their legacy applications are disappearing into history.
Traditional Unix used to have some partitioning of function by username. For instance a user logged in as the printer administrator could administer the printing sub-system to stop & start queues etc without having root access. This approach seems to have died out for one reason or another probably because a lot of Unix installations didn't have more than one admin. A lot of the old user IDs are still sitting there in Linux but without any apparent use. What, for example, does bin (userID 2) do on Debian?*
We now have sudo attempting to do much the same thing but all too often set up to simply use the user's own password rather than root's and to be as omnipotent as root in terms of privilege. OK, we have logging thrown in as a bit of security theatre but it's a weakening of the original concept for the sake of convenience.
*I ran a find on my Debian laptop looking for files owned by uid 2. The only hits were in /opt and were in an IBM package.
> We now have sudo attempting to do much the same thing but all too often set up to simply use the user's own password rather than root's and to be as omnipotent as root in terms of privilege.
On a desktop machine owned and used by just one user, at home for example, then admin being done using sudo is appropriate - there is no administrator other than that user.
On other machines where there is a separate administrator then the sudo is easily controlled as to what each user can actually do (see /etc/sudoers file, if you are allowed to). They can also be given permission to do stuff or access stuff by making them members of a particular group and giving permission to the group.
> For instance a user logged in as the printer administrator could administer the printing sub-system to stop & start queues etc without having root access.
They don't have to login as a specific user (though it could be done that way), Access can be given to a specific group and particular users can be added to that group. (A user can be a member of several groups).
>On Windows - unlike Unix - your identity is separated from your privileges.
Modern UNIX systems have RBAC implementations that allow granular access to files and resourced and role shifting without changing identity,
Unfortunately they are rarely used for anything outside of the UNIX vendor provided tools (and not much even there) , as there is far too much historical cruft that doesn't know about this stuff.
Of course, while there may still be occasions when you need to gain additional privilege to carry out some functions, for most applications it is not necessary if the application is written correctly in the first place.
Historically, this appears to have been a difficult lesson for Windows developers to learn.
Sorry for the direct attack on Windows, but security-illiterate Windows programmers have blighted application development on all platforms for years, and often pass their bad-practice on to newer generations of coders.
>"A simple fix for this is to not allow browsers to run under admin accounts by default.
True but not the whole story.
You need to block, "run on login" (e.g. skype) from being set by a "normal" user and you need to get people to log off rather than sleep. Then you need to make sure common executables such as Office documents/templates aren't infected. That's before you get into the "is there a buffer overflow in the display system such that using a particular font will get me root access."
The problem is non-trivial, mostly because OS vendors (and I hold those charging for their OS particularly responsible here) haven't really progressed beyond securing a resource beyond the file system and even then its mostly, rwx rather than the ability to filter the data. What we need is the ability to prevent raw sockets being opened and forcing traffic through an OS call. Then you can deny raw sockets but allow access via the OS-provided http request mechanism which does logging, white/blacklist, geo-restriction checking, real-time user confirmation etc. That would put a major crimp in botnet trojan abilities as vendors would have an incentive to provide help to prevent their software being hijacked and there is a easy tie between naughty http connections and the process which made them. If you're worried about privacy, you could have a flag to delete the urls when the application closes, and log the fact that the log has been deleted - the usual auditing stuff.
My pro tip, for what its worth, is to browse within a vm that has its hard drive set to refresh on reboot. I have IE11 (I do a lot of web testing with various browsers) within VM workstation set up that way, and with Unity switched on can access IE as if its part of my desktop. If I get hit by a virus, a reboot will kill it. It has no permissions to my real desktop at all, (runs in a seperate virtual network, seperate user account.) Brought this method of working across from my VM Fusion days on my mac, and am happy with the extra layer of security it provides.
I've always understood that the main security issue with XP/2000 is that Internet Explorer's default settings leave it wide open. XP is fairly safe if you can use Firefox or other browser, because you just lock down IE to be safe. Go into Internet Options under Control Panel. Select Security tab, then Custom Level and set the options to "don't". And update your hosts file with something like Peter Lowe's list at http://pgl.yoyo.org/adservers/serverlist.php?hostformat=hosts&showintro=1.
Most other security issues are escaped by not opening attachments that you are not expecting. People don't analyse these things with any common sense. A friend got an email purportedly from UPS saying they had a delivery for her (sender not named), and she had to fill in the attached form before they could deliver. Luckily I had beaten the friend up to call me FIRST before succumbing to temptation. Are you expecting a delivery? No. When has a delivery agent ever had an email address as opposed to a phone number? When ever has a recipient had to fill in paperwork conditional on delivery for domestic mail? People see something official looking and don't analyse before twitching that mouse finger to have a look... and won't do a gOogle search first with a clip of text from the email to check whether it comes up as a known nasty.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
