Well, if you’re logged in as an admin account all the time. Which is pretty silly.
If you’re not, windows won’t elevate you without you manually doing it yourself. It also won’t dump you to the secure desktop (as this is part of UAC) for password entry, which means that any password you DO enter using the run-as box is more vulnerable to snooping.
Is your UPlay installed in Program Files? If not, does it actually not work when you deny the UAC request? Mine seems to start just fine after telling it “No”, but my account does have Administrator privileges, so ymmv.
Might result in issues when it wants to update, or it’s just a case of “let’s just request these permissions, just in case”.
It’s installed in Program Files. Oddly, it seemed to work in my test VM, but I didn’t try running a game in it. Maybe Ubisoft fixed the thing?
Quite likely it may have been fixed in a more recent build of uplay that may not be apparent on upgrades of an old original install.
Its definitely a thing microsoft will be pushing major developers to fix, as this is the sort of stuff that makes running as non-admin a pain in the arse, and they really want to get people off running as admin for obvious reasons.
I have a personal anecdote involving UAC.
Back in 2016 (3–4 years ago), Audacity and Classic Shell were replaced by an MBR-overwriting trojan. They caught the Audacity malware in under 3 hours, and the CS malware after around 300 downloads.
I guess I should start buying lotto tickets (lol). I don’t remember why I was installing Audacity, but…it didn’t go so well, let’s say. The installer would just exit without opening any windows; when I rebooted to troubleshoot, I got a completely empty, black screen, except for an “ace” character printed by the command prompt. Cheeky.
I burned an install ISO and repaired my MBR the same night, so whatever. But this thread reminded me: UAC did come up before the installer ran. I had a chance to save myself the whole headache, and all I had to do was pick “no”! (Well, two headaches actually, since I ran the installer twice before I restarted.) But the thought never crossed my mind, of course, because a lifetime of using Windows had conditioned me to blindly click through those prompts as fast as possible. Additionally, Audacity installs system-wide to Program Files, so I expected a prompt. There was nothing out of the ordinary.
I think this is the biggest problem with UAC. Even though it might not be absolutely bulletproof, malicious hackers don’t even need to evade it. It’s just such a nuisance that I (and presumably many others) autopilot through it without thinking about exactly what I’m authorizing. Unless I was already suspicious of the software, I admit that I’m likely to elevate any process that asks. Granted, this might apply less to an enterprise setting (where the administrators are more cautious and know their software environment better), or to malware that executes without the user’s knowledge (although, in the heat of the moment, I would probably elevate a random background process if it had a reasonable name and asked nicely).
Yes, I completely agree with this, UAC is only useful if you have trained yourself to be suspicious of everything, and even then, it’s usefulness is very limited.
This is where Android has got it a bit better in that their version of UAC has to ask for permission to access specific things, like camera, location, photos, etc. People stop to think… hrmm, why does this “free” calculator program want my location/photos.
UAC is just a boolean yes or no to complete access & control of your system which is IMO it’s biggest issue. Why we still dont have a “Program X wants to register itself to start at login” prompt is beyond me.
Same reason we’re still running win32. Because microsoft are terrified of breaking anything that will significantly impact backwards compat, as that’s the only reason to run windows.
No backwards compat, no Windows sale.
Exhibit A: Surface RT, Windows Phone, etc.
Yes, this is exactly one of the core issues with UAC that caused so much controversy when it was initially presented. UAC was so fundamentally flawed from a security perspective that Microsoft could not call it a security feature. The fatal flaws are 1) the reason you presented above where the process the user elevates gets everything, (an elevated tetris game can install kernel drivers), and 2) lower IL processes can modify higher IL processes e.g. “hooking” by design.
This is false. Consider the following:
For instance, having your elevated AAM processes run in the same account as your other processes gives you the convenience of allowing your elevated processes access to your account’s code and data, but at the same time allows your non-elevated processes to modify that same code and data to potentially cause an elevated process to load arbitrary code.
Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs.
-src: Mark Russinovich on PsExec, User Account Control and Security Boundaries 12 Feb 2007 https://web.archive.org/web/20100610231407/http://blogs.technet.com/b/markrussinovich/archive/2007/02/12/638372.aspx
Instead of being presented as a security feature, it was presented as a convenient method to consider alternative system configurations.
The bottom line is that elevations were introduced as a convenience that encourages users who want to access administrative rights to run with standard user rights by default.
-Mark Russinovich on Inside Windows Vista User Account Control
Look, if you still think UAC was designed and implemented as a security feature after reading one Microsoft’s contemporary engineers literally say that it wasn’t designed/implemented to be a security feature, then I do not know what to say. UAC is convenience, not a mechanism that provides OS security. Those fatal to system security design decisions are not “bugs” in UAC, they are inherent to how it was meant to work.
So that “secure” desktop which has been mentioned is supposed to prevent processes from getting your password directly via sniffing and then using it to elevate themselves to bypass UAC? There is no need to, just hook an elevated process:
[A] process with a low IL could create a shared memory object (called a section or memory-mapped file) that it knows a higher IL process will open, and store data in the memory that causes the elevated process to execute arbitrary code if the elevated process doesn’t properly validate the data.
So if you aren’t guaranteed that your elevated processes aren’t susceptible to compromise by those running at a lower IL, why did Windows Vista go to the trouble of introducing elevations and ILs?
-Mark Russinovich on PsExec, User Account Control and Security Boundaries
To get us to a world where everyone runs as standard user by default and all software is written with that assumption.
Without the convenience of elevations most of us would continue to run the way we have on previous versions of Windows: with administrative rights all the time.
-Mark Russinovich on Inside Windows Vista User Account Control
The “whole point” of UAC is to get application developers to write their software in a way compatible with standard user rights if they do not need admin rights. Using elevations to cross security boundaries, is fundamentally the same as the “run as” feature present in Win XP, but more convenient than letting processes crash and restarting them with “run as”. That is all UAC can at most ever amount to: continence if enabled while in a standard user account in a context where a user adequately understands the OS security model, and the ramifications of elevating software. Want to guess how many Windows users fall into that category? Do you actually think UAC is useful for users outside of that narrow category?
Because lower integrity level processes can hook higher ones, running UAC inside an admin account (admin approval mode AAM), is pointless as well.
Microsoft designed UAC to get in your way as a user to send a message to application developers. It does not, nor has it ever been intended to help users, but limit them.
However what users care about is DATA integrity, not OS security, so even in the base case outlined above, UAC cannot protect what users really care about. It just gets in the way with no substantive benefit that can withstand critical scrutiny.
My recommendation is to disable it, and implement a real security boundary like Sandboxie or VMs if you care about OS security. Then you do not have to deal with the problems that UAC creates and you have real security boundaries between the stuff that matters (your data) and the stuff that does not (the OS).
Nope, Uplay is not really fixed unfortunately. It installs, but all within the Admin account. It starts from the installer if you check “Run Uplay” at the end though, but it disappears into the Admin account afterwards. I did try running a game though while doing that, it worked, but reinstalling Uplay over and over would be a real PITA. I guess Ubisoft doesn’t want my business. 
Most of what I have been saying is actually direct quotes from (at the time) the Microsoft employee “Mark Russinovich”. He is founder of sysinternals and became a MS engineer after sysinternals was acquired, and was there during the migration from XP->Vista. He did a lot of writing/publicity work explaining how MS implemented their UAC system on behalf of MS. Later on he moved on to Azure stuff.
Windows is closed source, so a lot of the technical and authoritative understanding of how UAC/ILs/AAM really work and their purpose comes from his posts.
Quotes from Microsoft’s spokesman for how and why their UAC was implemented so far have been dismissed as:
from people who do not know anything about Mark Russinovich. A MS engineer that actually knows how the software works takes precedence over a government body. Govs are not exactly known for their technically correct and up-to-date understanding of tech.
The only major thing I have added to Mark’s conclusions is that UAC was implemented to “annoy” people deliberately, which is not part of his writings (for obvious PR reasons). Why deliberately annoy people with a non-security feature?
To get us to a world where everyone runs as standard user by default and all software is written with that assumption.
Getting there would not happen if UAC was disabled by default, so they left it enabled in admin accounts, even if the “convenience” of using UAC for using elevations is inconvenient by
The parent company does not even try to seriously untangle the myth that UAC=security boundry. Those facts, along with Mark’s stated goal of UAC should paint a fairly obvious conclusion as to why the “[in-]convenience” of UAC to the user is deliberate.
Do they though? That’s not my experience…
What you are describing here is a flaw in the design of third party software that has been granted the ability to have/obtain elevated privs in the first place. Again, initial legitimate elevation is required, this changes nothing.
I am not at all debating the validity or reason for its implementation, but how it can and should be used even if it’s “not a security feature”.
You clearly have no idea what the secure desktop is or how it works.
if the elevated process doesn’t properly validate the data.
Again, you’re talking about a bug in a third-party privileged process, not a flaw in UAC’s design. Recall that iPhones for a time were jailbroken due to a failure to sanitize font data before making use of it by a privileged application. Does this mean that the iOS security model is also useless and Apple should just give up?
At the end of the day Microsoft MUST provide a method of elevation to perform privileged tasks, and as such must give some measure of trust to the elevated process. It’s then up to the process that has requested this level of access when granted it to act responsibly with said power. If it fails to do so, then it’s not a failure on the part of the OS to enforce security, but a failure on the part of the third-party software.
Microsoft are pretty explicit about how to properly and safely use such dangerous features.
Warning A driver that maps kernel memory into user address space must avoid exposing potentially sensitive kernel data to untrusted processes. Uninitialized buffers, such as buffers that are allocated from pool, must be explicitly filled with zeros before they are mapped. In addition, the size of a user-mode buffer that is allocated from pool must be a multiple of the virtual memory page size to prevent any part of the pages in the buffer from being used for other allocations. Finally, buffers must not be freed back to the pool while they are still mapped to user address space.
Note, that even a UAC elevated application can NOT load unsigned drivers/code in Windows Vista (x64 only) or later (all archs). Prior to the new security model (Yes, it IS a security model) driver signing enforcement was a joke and didn’t exist. There still is a tightly controlled boundary before applications are given the keys to the kingdom unless you’re dumb enough to turn on test signing mode… but hey, according to your logic we should just do that too.
So, no real-world experience then, you have read one article from one guy and decided that you know better. Yes the author may be respected and have the authority to make the points made but at the end of the day, you have made invalid assumptions without fully understanding the landscape.
I know who he is.
Doesn’t alter the fact that you were referencing a 13 year old blog post via web archive because it had been removed.
if we’re going to flash e-peen security creds, i’ve been responsible for enterprise security for my current employer for the past 12 years. I’m still employed in that capacity.
If no legitimate elevations are required on the system, then neither is UAC, a convenience feature designed to enable elevations. This implies that a system using UAC in a sane way will have at least one elevation, which any unelevated low-IL process can hijack.
The iphone example does not fit because that escalation was not intended by apple to be possible and is one which apple can fix. It is not a deliberate decision by apple to make their OS susceptible to attack in this way, but is for UAC. Thus, the comparison is illegitimate.
Because elevations and ILs don’t define a security boundary, potential avenues of attack , regardless of ease or scope, are not security bugs.
Scope here includes third party programs. So, this security flaw that allows for IL elevation is inherent in the system, irrespective of the specific third party use, that was deliberately engineered in and never changed. It is"not a bug". This is a textbook definition of a design flaw as to why UAC “doesn’t provide real security” which is the topic of this thread.
The point is to clear up the misconception that people are gaining real security simply by leaving it enabled, which they are not.
/agree Since we can at least agree that UAC is not a security feature, we can have a meaningful dialogue on the above topic, unlike uninformed users who mistakenly believe UAC = security feature because neither of us are confused on that fact.
The point I was making there is that it is not an effective security feature if it is trivial to bypass it. If the target is arbitrary code execution (ACX), there is no need to care about a user’s password if it is not needed for ACX.
This seems to make sense… up until you realize that a low IL process in AAM can hijack a high IL process and enable test signing mode on reboot, and patch .dll that displays the watermark so it doesn’t display. You do not need to break the front door if the back door is wide open.
I actually have not commented on what my credentials because I believe the facts should speak for themselves. Arguments are valid based upon the facts and reasoning presented, not letters in front of someone’s name. What “invalid assumptions” have I made that you can show is invalid?
You seem to only accept your own evidence on if UAC is a security feature. An article written back in the Vista days > current Microsoft docs to you. I don’t think there’s any current exploits to bypass UAC unless you have evidence of a current proof of concept. That again misses the point entirely that UAC by itself isn’t very good security, it takes many layers.
If current documentation about it isn’t enough and you want to rely on what one guy said about it back in the Vista days then fair enough, I won’t stop you.
You do know that SFP (System File Protection) would detect the signature breakage and either Blue Screen or refuse to load the module/driver depending on what it is? Even in test signing mode. Many applications/games and AV software also look for systems in Test Sign mode and alert to the mode either for anti-cheat or AV reasons.
Also you skipped over the fact that again, it would have to exploit another process to obtain a level of access where it could turn on test sign mode.
UAC is only 1/10th of the picture though, UAC is part of the entirely new security model that came with x64 Vista. Is it perfect, no… it’s flawed IMO also. Should you turn it off? No, turning it off also disabled features like Secure Desktop which is used for far more than just UAC prompts. Why do you think a program can’t just use the SendKeys API to click the Allow button programmatically?
The only way to interact with the Secure Desktop is to either be the process that invoked it via a custom secure dialog, etc. or be signed by Microsoft as a User Accessibility Application, which I know from first-hand experience is pretty much impossible to obtain without a ton of cash and a full code audit by Microsoft.
Also, you should be aware that there are several levels of elevation, UAC isn’t just total. The application can request for various security levels by means of access tokens. Your application needs to be granted these tokens in the first place to perform certain actions. Ever wondered why even the elevated regedit process can’t delete/edit/view some keys?
UAC is far more than just the confirmation prompt. The the false assumption you are making is that UAC is only the prompt and process of elevation of privs, and that it’s total and complete elevation.
Understood. I am not trying to change how you feel, let alone tell you how to feel. Just understand that siting old information can lead you astray. A lot has changed with the MS Windows product since that blog post was released. MS Got Smarter and also learned some expensive lessons.
This come from someone that Dumped MS Windows for GNU/Linux back in 2001. I have had to work with MS Windows products in my 15 years in IT, Development, Computer Forensics, and Cyber Security.
My hope is that you eventually get the time to do some hands on research for yourself. You can have faith, but the only way to truly know is for you to discover for yourself. Good luck on your journey.
@Adubs I actually read that MS doc you posted alink to a while back from top to bottom. Never did MS call UAC a security feature in it.
Can you site a document where MS’s documentation explicitly calls UAC a security boundary?
They tend to use deliberately confusing statements like “You can use security policies to configure how User Account Control works in your organization” which does not technically call UAC a security policy but forms the association in your mind that it could be, right? Because why would MS put a non-security feature in the secpol.msc settings? MS’s documentation is always like that: misleading to the point where people are confused on UAC itself being on security feature.
An alternative would be documentation where UAC is called a security benefit when used independently of standard user accounts. Calling UAC+standard user accounts is correct, but misleading because what provides the security benefit there is the security boundry (standard user account), not UAC.
SFP is usually enforced by SFC manually. The automatic stuff is only done for core services. The .dll that displays the watermark does not fall under core services. Again, why break the front door when the back door will suffice?
Which is my entire point! If this is possible, UAC is pointless as a security feature by itself. Unlike others, we are both fine calling it a non-security feature, so where is the disagreement exactly?
Maybe this is the disagreement? Secure Desktop is a deliberate context-switch which is not productive to a user’s workflow so it is an added benefit that such a “feature” is disabled when disabling UAC.
I am more interested in the user’s interaction with UAC and using that as the basis for which to criticize UAC than honoring MS’s attempts to annoy the user as a means of talking to application developers.
What user’s care about is the integrity of their data, so separating it completely from the OS is what “real security” means to a user, and is why UAC should be disabled. UAC cannot protect against ransomware, nor was it ever intended to. Since it cannot help them protect what they care about, what is the point of leaving a non-security feature enabled that breaks things and causes context-switches? There are plenty of ways to have real data security to a user, as I said before: VMs, Sandboxie. Half of the work I do day-to-day and all dev work is done in VMs. What is the point of running UAC in them?
Thanks for this info, but what key can I not view with UAC enabled? If we are agreeing that UAC is not a security feature, then are you saying now that it is?
The issue is that low level ILs can modify high level ILs so it will always be possible for malicious software to have admin rights when used in AAM mode, making UAC fundamentally, and by design pointless in that mode. If you really care about restricting application permissions, then you are running in a standard user mode, not in UAC mode + admin. Since the security boundary of the standard account is what is providing real OS security there, it can make sense to leave it enabled because UAC is not what is intending to provide OS security there. In other words, the “other” things that UAC does are just pointless, which is why I haven’t bothered to discuss Secure Desktop much.
Care to cite a source saying that UAC’s design has fundamentally changed since then? Claims without sources or that are not easily verifiable have no merit.
I don’t have a hard source to link because you would need access to developer docs and see the updates and changes made to those references over time. You can get when you sign up for MSDN. The only thing that I an say right now is anecdotal, so take it with a grain of salt.
Having maintained software that originally was designed for Win XP and then having had to support it for up to Win 10 and and Server 2014, I can tell you that UAC’s trigger mechanisms, invasive-ness, and breakage of software and code is proof to anyone has had to do such a task.
Honestly, my comment was just to let you know that technology changes and platforms change to fit need and focus. Maybe UAC was pointless when it was first introduced, but it does not mean that lessons were not learned and implementations of UAC have not changed.
What I am saying is that the computing landscape changes, rapidly, in a few years when you revisit this post, I am sure that you feel the same way. If you don’t, then for my sake, I hope that you do not work in this industry, at least not for long.