131

I use Atlassian SourceTree on Windows, and one thing I like about it is that it doesn't require admin privileges to install or update. I happened to mention this to our ISSO (Information System Security Officer), and he was not a fan. He said that not requiring admin was dangerous because (to paraphrase) "If it's not asking you for approval, you never know what it's going and changing in the background!"

Now, this person has a tendency to be overly-cautious, so I am skeptical of his assessment. I had always thought that if a program doesn't ask for administrator permissions, it's because it doesn't make deep enough changes to need them. To add to that, our work computers are extremely locked down, so I find it hard to believe that all an installer has to do to get by our security features is to not ask for permission.

So what's the real situation? Can an installer that can run without administrator privileges really be that dangerous?

Improve this question
7
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – Rory Alsop ♦
    Feb 2, 2018 at 13:57
  • 19
    Chrome also has a non-admin install. What would your ISSO say about that?
    – Neil
    Feb 2, 2018 at 15:41
  • I'd answer, but am not allowed - sorry. But I think the issue of requiring admin privileges depends entirely on the functionality of the code, and therefore, can't truely be debated here. What is more important is whether or not a policy is in place that any code which is installed, is installed with a signed certificate. The UAC will pop up indicating certificate details, and a policy can be created to forbid unsigned, self-signed, or untrusted signers.
    – Andrew Jay
    Feb 5, 2018 at 12:44
  • TeamViewer installs without admin rights, and it is functionally a keylogger. Non-admin software can be very dangerous on Windows.
    – Aleksandr Dubinsky
    Feb 5, 2018 at 14:28
  • 5
    Relevant XKCD, "Authorization" (although the ISSO would probably advise you not to access Dropbox, Facebook, gmail, PayPal, and your bank from your work PC...)
    – david
    Feb 6, 2018 at 17:23

14 Answers 14

Reset to default
268

Installing something without needing admin privileges is no more dangerous than running a no-install program with standard user permissions. This is also less dangerous than installing something WITH admin privileges (or indeed, running anything with admin permissions).

Running a random program downloaded off the internet, of course, is potentially dangerous - even if it doesn't require admin.

If your ISSO's concern is "you're running random internet code, and the author of that code makes it easy for you to be lazy about asking me to vet it", then this is quite valid and factual. (you might debate the cost/benefit, but it is valid)

If the concern is "this installer is more dangerous than other installers or no-install programs because it doesn't escalate its access level", then no, this is factually incorrect.

Improve this answer
12
  • 70
    +1 for including a potential ISSO point of view. Sometimes there is a good reason under the hood, and it's just harder to communicate than they excuse reason.
    – Cort Ammon
    Jan 31, 2018 at 18:41
  • 6
    @CortAmmon Anyone who can't communicate this simple concern is incompetent and not to be trusted in my book. Even if they know what they're doing, what other wrong things are they telling people to do because they can't be even remotely clear?
    – jpmc26
    Jan 31, 2018 at 21:21
  • 8
    @jpmc26 What if it's not so easy? What if the reason for the issue is highly contextual and requires a deep understanding of their job? For example, what if the reason for why they need to vet the code is actually a nuanced discussion being held with upper managment that they aren't supposed to talk about yet?
    – Cort Ammon
    Jan 31, 2018 at 21:45
  • 60
    people, even intelligent people, miscommunicate simple ideas all the time. Look at the quote from OP: "If it's not asking you for approval, you never know what it's going and changing in the background!" Now, assume that this quote is not 100% the verbiage used by ISSO. What if he said: "Even if it's not asking you for approval, you still never know what it's going and changing in the background." Which is a much more salient point.
    – Segfault
    Jan 31, 2018 at 23:51
  • 10
    It's worth noting (as @Segfault alludes to) that the OP literally says "to paraphrase" just before quoting the ISSO's objection. Whether the ISSO's objection is reasonable or daft depends on exactly what the objection was, hence why I've included a response for the two interpretations that I find most likely (given the non-verbatim quote we have).
    – Soron
    Feb 1, 2018 at 12:11
80

Well, if it doesn't need admin rights, that means that it can only do what a regular user can. Of course, you won't really know what the installer is doing (but do you ever really know?) but you can be assured that it won't be able to do anything that an unprivileged user can't, so I don't see the problem if you trust the source.

Improve this answer
9
  • 7
    Even better, a program (or installer) that doesn't need admin rights should actually be more secure than one that does. Since a privileged program can change stuff that are a lot more dangerous to change than a non-privileged one can.
    – John Hamilton
    Feb 1, 2018 at 7:02
  • 2
    @JohnHamilton: but if it can modify stuff for the account you use all the time, it's hardly "a lot" more secure, unless it's truly a multi-user system. Taking over the primary account is only slightly / somewhat less bad than taking over the whole machine; e.g. it could still be ransomware.
    – Peter Cordes
    Feb 1, 2018 at 11:57
  • 7
    Or, to say it with the usual xkcd: xkcd.com/1200
    – Matteo Italia
    Feb 1, 2018 at 16:01
  • 3
    Unless there is an unpatched vulnerability in the Operating System/architecture. Then it can do more than a regular user can, and without first getting someone to look it over scrupulously because it didn't require admin privileges.
    – Nacht
    Feb 2, 2018 at 5:39
  • 2
    Well, just like an unprivileged user could exploit a vulnerability and gain admin access.
    – Tux
    Feb 2, 2018 at 15:51
26

On the windows platform, whether an app installer tiggers UAC (User Account Control) is not up to the app and the app cannot circumvent UAC. If the app install requires to do anything that would require admin, UAC will be triggered. This would include writing to system directories or registry settings that are system wide.

If an app install doesn't trigger UAC, that indicates the app is installing under the non-admin user's profile directory, and only setting registry under the user's own profile. It is certainly possible for a user to install malware, and the malware designed to only mess with that user's files/settings, the damage will not extend system wide.

In the context of ransomware threats, this means ransomware that targets only the user's own files would fly under the UAC radar.

To protect against that and satisfy your ISSO's concerns, your organization would need policy and protective tools to prevent running any app that is not provided by the company and certified. That is incredibly hard to do effectively, and to do that would require a very large investment in staff to certify apps as the business needs demand them.

Obviously, the above is only true if UAC has not been disabled or tampered with. It used to be fairly common for people to disable UAC because it was an annoyance, as apps that really shouldn't need admin would trigger it. For example, it used to be common (and still happens) where running a game requires elevation because the game does and auto-update at each run. These days, apps are better behaved and UAC really should not be disabled.

Updated for clarification following good comments:

It should be mentioned that when logged in as a user with local admin, there are ways of circumventing UAC. For best protection, one should not have admin rights for their everyday account, and create another with admin rights. UAC will prompt for that admin credentials when system wide settings are changed or software installed, but UAC can't be circumvented entirely if UAC is enabled.

Improve this answer
15
  • 16
    Triggering UAC prompt is of course in app's control. In fact, there are only two ways to do it: have a line in app manifest that indicates that app should always be run as admin, or explicitly (from the code perspective) run an app as admin. UAC prompt will not automagically pop up when privileged operation is attempted. Installer is no way a special kind of program and can't handle it differently. To create an illusion that UAC prompt is done in the middle of app execution it simply spawns another process that triggers UAC prompt.
    – n0rd
    Jan 31, 2018 at 19:51
  • 3
    There are UAC bypasses a plenty out there
    – McMatty
    Jan 31, 2018 at 20:42
  • 15
    This is incorrect. If an operation requires administrator privileges and the process doesn't launch with them, then the operation would simply fail (error). Some applications will launch new processes with the privileges to make the UX smoother (instead of making the user launch again manually), but nothing in the OS just automatically asks for the privileges when a process does something that needs them. @n0rd On the other hand, MSIs aren't applications. They're files that get executed by built in OS components. So those components might have some magic built in
    – jpmc26
    Jan 31, 2018 at 21:13
  • 3
    @n0rd: There are actually 3 options for the app manifest: require-Administrator (your always-admin), asInvoker (launch without elevation, even if admin) and highestAvailable (admin if possible for user). See msdn.microsoft.com/en-us/library/bb384608.aspx. There are 4 ways to run elevated executables, but the first (UAC disabled) will of course not show UAC dialogs.
    – MSalters
    Jan 31, 2018 at 22:37
  • 5
    I meant that an app cannot choose to not trigger UAC and still perform system-wide changes.
    – Thomas Carlisle
    Jan 31, 2018 at 22:37
16

One additional threat for program installations that do not require administrator rights is that the installation can be modified by user level code. This allows for silent (no admin access required) updates, which means that the program behavior can change without warning. This also allows an adversary to insert code and tamper with the program silently (no admin access required).

Improve this answer
4
  • 1
    This was the same issue I was thinking. You're going to type your git password into SourceTree; if another app wanted to get access to your account, it could capture your keystrokes (however, antivirus might quarantine the malicious app as a keylogger), try to get the auth cookie from git's memory (again, antivirus might detect this), or overwrite the SourceTree app with a tampered version.
    – Carl Walsh
    Jan 31, 2018 at 23:40
  • 5
    Yes, but if your installation is being modified by user level code then you already have some virus running on your computer. I'd say that the problem would be worse if the installation did require admin rights, because a virus could modify the installer binary before you run it and you would grant it admin rights, causing a privilege escalation of the virus.
    – user28763
    Feb 1, 2018 at 0:58
  • 2
    @CarlWalsh: Even if the installer did require admin the program itself doesn't, that would be a security risk in case there's a bug in the program.
    – user28763
    Feb 1, 2018 at 0:59
  • 3
    @Runemoro The thing is, there's a big difference between "running arbitrary code" and "saving a file to disk". And "saving a file to disk" is all it takes to execute arbitrary code (within the privileges of a given target application) if you can save in an app's exe directory. Are you sure there's no process anywhere on your machine that could be remotely exploited to save a file to the right place? Especially bad if there's an elevated app in an insecure place, but even for non-elevated apps, it can still gain access to anything the app can access - perhaps your passwords, logs, chat...
    – Luaan
    Feb 3, 2018 at 22:51
12

If it's not asking you for approval, you never know what it's going and changing in the background!

Wether the installer requires or not admin rights, you don't know what it is doing unless you're tracking/monitoring system changes.

What you know however, is that if it doesn't ask for admin rights, it can't make any change that requires admin right (alter system files, system registry, drivers, etc.).

Is an installer that doesn't require admin rights dangerous?

It could be, but no more that an installer that require admin rights, in fact it's theoretically less dangerous.

But either way, you shouldn't run any installer you can't trust on a sensible environment wether it requires admin rights or not.

Improve this answer
6

The application still has to ask for elevation if it needs more privileges, independend of its installer. On the other hand, if an application is maleware, it can run its harmful code in the installer already.

So actually it is the other way round, if neither the installer nor the application ask for elevation, it can do less harm, than if one of them ask for privileges.

When writing an installer, one tries to use as little privileges as necessary. Usually this determines, whether the program can only be installed on a per-user base, or if it can be installed for all users.

So if it is enough to write to the registry branch [HKEY_CURRENT_USER] there is often no need to ask for elevation, when the installer needs privileges to write to [HKEY_LOCAL_MACHINE] or to do other things only an admin should be allowed, it has to ask.

Improve this answer
3
  • 1
    I think this is an excellent answer. Atlassian could mollify OP's supervisor by adding code to request admin privileges (and then not use them) but that would make the code less not more secure. Perhaps in an obscure corner of the program there is rm -rf /. Without admin privs, the program would fail. With admin privs, the program would succeed in ruining the user's day.
    – emory
    Jan 31, 2018 at 16:55
  • 1
    @emory: That's actually not how Windows works. Users that have admin provs still need to invoke those privs on a process by process basis, using UAC.
    – MSalters
    Jan 31, 2018 at 22:41
  • @emory: Correction -- if you are using a system capable of running Windows, you have already given up on security. Even if you have replaced Windows with another OS, the vulnerabilities that plague Windows-capable platforms exist below ring 0 and thus are problems regardless of OS.
    – Ben Voigt
    Feb 1, 2018 at 16:57
4

What it means

If an installer doesn't require admin rights, then it is installing software for the current user only, rather than system-wide.

What are the security impacts?

The software you are installing can only run under your own user account, so it has no way of modifying or damaging the system at superuser/admin level and affecting other users or system services. In this regard it is more secure than running a software installer that requires admin rights.

However, that doesn't mean the software itself can't do bad things, like any software, such as spying on you, spamming unwanted network traffic, messing with your files in your account, etc. None of this, however, is specific to the method in which software is installed.

Why system admins may not like it

It gets around any policy they may have around users installing software such as an approval process.

Is their concern justified?

Yes and no. While it isn't any more of a security risk to the system itself than anything you can already do in your user account (such as write scripts, run your own binaries or compile your own software), there are still some reasons IT departments may like to be notified or consulted anyway.

Some IT departments like to keep a record of what software exists on users' computers for the purpose of auditing. If the user installs software without IT knowing about it, then that software can still do nefarious things such as attack computers over a network, send spam, use up lots of resources on the machine, leak confidential documents and so on. So even though it may not be able to risk the system integrity for other users on that system, it still may perform things that are unwanted.

Even well-meaning software may have vulnerabilities which can cause problems if not kept up to date. If an IT department knows about software installed on users' systems it can ensure they get kept up to date.

Summary

What this all boils down to is that there is no inherent security risk in an installer that installs for a single user and doesn't use admin rights. What an IT department may be concerned about is simply the act of installing software without notifying them.

Improve this answer
1

An installer that does not ask for admin rights is safer than one that does ask, …

Unless, you have admin rights and granted them to the installer.

As an example, I have an installer on my MacBook that is able to install applications in /use/local/bin without asking for my admin password (called ‘brew’ for the curious). The only way that is possible is for brew to have been given admin rights when it was installed. Now MacOS has something called SIP that prevents even admin from making some types of changes. As far as I know, Windows has no equivalent. (But I haven’t used Windows in almost four years.)

That said, even without admin privileges, a program you installed can possibly do nasty things to you. Another answer has mentioned some of those things. But any program can do some of those, not just an installer.

Improve this answer
1

A large number of installers can simply be extracted without administrator rights using third-party tools such as universal extractor and don't actually truly require administrator rights. By giving installers access to administrator mode you give them access to every part of your computer, an installer that runs without those rights only has access to the files that don't require administrator rights.

However, it is true that you never know what ANY third-party program does, unless you check for yourself. All you can do is make sure the program comes from a trusted source, doesn't have any known viruses (using an antivirus/virustotal) and lastly you could use something like universal extractor to see what the script does or even use it to extract the files from the installer directly. And obviously, make sure the boss is okay with the programs you're running/installing.

Do keep in mind that not every installer can be extracted in this fashion and that some installers do in fact require administrator rights to install things like drivers or enter things into the registry.

Improve this answer
0

To add to the existing answers, there is a flip side disadvantage to an installer which doesn't need admin rights if the software which is installed does need admin rights to run.

If the installer does not use admin rights, the software cannot possibly be installed in the (protected) Program Files folder. By installing locally rather than globally it is possible for a malicious actor to modify the program, or install custom add-ins, from a local rather than administrator account. This could potentially lead to an escalation of privilege if someone then runs that program as an administrator.

The conditions needed to achieve this practically however are very remote. It's more of a theoretical vulnerability rather than a real world one.

Improve this answer
0

Your ISSO is just plainly wrong.

First, if I managed to create an installer that doesn't need admin privileges but is actually malware (for example sends all your documents to me), then it is trivial for me to make it ask for admin privileges. I'd really be wondering how asking for admin privileges would make that installer safer.

Not asking for approval doesn't mean the installer can do anything it likes. It can only do things that don't require approval. It can't do these things without approval. The installer with admin rights can do anything on your computer and mess it up completely. The installer without admin rights can do anything in your user directory and mess it up completely - which is less than the installer with admin privileges can do.

Now damage isn't necessarily done by malice, but often by stupidity (aka bugs in the installer). With admin rights, an installer has the ability to mess up your whole computer unintentionally. Without admin rights, that risk is hugely reduced.

(As mentioned earlier, on recent MacOS systems "admin privileges" and "root privileges" are not the same at all, which is used to protect the operating system even from code with admin rights).

Improve this answer
0

It simply means that it cannot do what an Administrator can do. If some action requires Admin-rights, then the process execution will require Elevation. Since SourceTree isn't asking for elevation, it won't do anything that can harm the system.

For example, it cannot:

  • Install a Windows Service
  • Start or Stop any service
  • Stop any elevated process
  • Install Device Driver (signed or not, that's not the point).
  • Read/Write protected registry
  • Format a drive
  • Change disk partition
  • Change system time
  • Shut down the machine
  • Start a system-wide process profiler
  • Read protected directory.
  • Change boot configuration.
  • Change security policy
  • . . .

Therefore, it is better and safe that installer (or any program) is not asking for Admin-mode run.

Improve this answer
1
  • Note that you can start/stop some services as normal user. This is usually done for update checks, e.g. Mozilla installs a service that you can run as normal user which does the actual update.
    – Johannes Kuhn
    Feb 11, 2018 at 0:05
-1

For completeness: An installer which takes privileges it SHOULD NOT have silently (by one of the methods described in various comments) would indeed not only in bad taste but an added security risk - it could in some cases be instrumentalized by other malware that would otherwise not be capable of downloading an exploit tool like that to the local machine.

Example: Installer is whitelisted with an anti-malware solution by a user that knows the software is not malicious in itself. Actual malware (or a dedicated attacker), who would be stopped from directly using the same vulnerability, could conceivably turn that installer, if still laying around in eg the local downloads folder, into a confused deputy by modifying it or running it in a crafted environment.

Improve this answer
1
  • 1
    this seems more like a general comment to other answers than an answer to the question itself
    – schroeder ♦
    Feb 6, 2018 at 9:58
-1

Atlassian SourceTree can, in a sense, be viewed as a program capable of creating covert channels, that according to the ISO 27001 standard, require mitigation. The argument for this is that it is a Git client capable of pulling in a vast body of source code over https.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .