App vendors discover a new way to abuse Windows

[tranglos]

As many bad things, it began with Chrome. I'm sure it's only natural for Google to think they can do whatever the heck they please with your computer, but things go from bad to worse when others begin to follow.

What's wrong with this picture?



Yep. Just like Chrome, Swift To-Do List from Dextronet now installs under <user>\AppData\Local instead of under Program Files. This is touted as a "feature" - namely that the app can be installed without admin rights. Things won't be pretty when more vendors start doing that!

I don't think we should have dropped the "complaints" forum

[jpprater]

They're doing that to "make it easier" on customers who want to install their applications on computers where they don't have admin rights.  Which means the installation is per-user, not per machine.

[Stoic Joker]

This is touted as a "feature" - namely that the app can be installed without admin rights. Things won't be pretty when more vendors start doing that!
I don't think we should have dropped the "complaints" forum

-tranglos (October 07, 2011, 09:38 AM)

I'll 2nd that on both counts. Users get locked out of Program Files for a reason...And it's a damn good one too.

Trying to skip around that is bound to end badly for everyone.

[Renegade]

As many bad things, it began with Chrome. I'm sure it's only natural for Google to think they can do whatever the heck they please with your computer, but things go from bad to worse when others begin to follow.

What's wrong with this picture?
 (see attachment in previous post)
Yep. Just like Chrome, Swift To-Do List from Dextronet now installs under <user>\AppData\Local instead of under Program Files. This is touted as a "feature" - namely that the app can be installed without admin rights. Things won't be pretty when more vendors start doing that!

I don't think we should have dropped the "complaints" forum

-tranglos (October 07, 2011, 09:38 AM)

Hmmm... Dunno... I can see the point there.

I know Jiri, the fellow behind Dextronet, and I can't imagine any malicious intent there. He's a decent fellow.

[vlastimil]

I have to disagree, it really is a good feature. If the program you are installing does not require admin rights, you can be sure, it won't install any adware, a virus or add an invisible service or firewall exception. And if it does, it will only affect one account and not the whole computer. Not requiring admin rights is a step towards portability.

I actually do not like the opposite. Recently, I have chosen not to install some applications, because they required admin rights and I was not sure they won't do more than just "installing themselves". In today's world of adware, one can never be sure.

Though, I agree that installing into %APPDATA% should not be the default behavior. All my apps can be installed without admin rights, but the default target is the good old "Program Files" folder and users must manually override it, if they want to instal to Documents or whatever. I consider this optimal.

[Eóin]

The installer should offer the option to install "per-machine" or "per-user" and only look for elevation when the "per-machine" install is chosen. I've seen many applications doing this.

Certainly any application which defaults to a "per-user" install is going to cause no end of confusion for people on multi-user machines.

[f0dder]

I have to disagree, it really is a good feature. If the program you are installing does not require admin rights, you can be sure, it won't install any adware, a virus or add an invisible service or firewall exception.

-vlastimil (October 07, 2011, 12:36 PM)

All major OSes have local privilege escalation exploits. Installing to a place you shouldn't install to is plainly just stupid. I for one hope Microsoft will start enforcing "only execute from <sensible locations>" policies soon.

That, and what Eóin said.

[vlastimil]

Well, exploits are exploits. There will always be holes. That does not mean, applications should not behave correctly. Not requiring admin rights if they are not needed is correct in my book.

BTW If you read carefully, I said the same Eoin said using different words.

---

%APPDATA% is folder like any other, I see nothing insensible there. Granted, if Microsoft designed a "Personal Program Files" folder and named and placed it properly, it would be much better. Such a thing IS needed. We are basically arguing about names.

[rgdot]

I for one hope Microsoft will start enforcing "only execute from <sensible locations>" policies soon.

That, and what Eóin said.

-f0dder (October 07, 2011, 01:00 PM)

This +100. And prompt before dropping folders, especially generically named folders (eg. "Notes"), into My Docs

[Jibz]

It's a royal pain to install and use software if you are not always running as administrator and the only user on a system. Microsoft haven't fixed this in the past 10 years, and now developers are trying to work around it.

I agree that it would be ideal if programs were limited to run from specific sane places, and that installing software into a place that was meant for data is a bad choice, but after you have fought with installers that require admin rights and then only install the shortcuts to the administrators account, software that requires admin rights to enter a license key, and then only shows up as licensed on the admin account, endless changing accounts to update software, software that stores file in the program files folder, etc. etc. etc., quite frankly it was nice that Chrome just worked .

[tranglos]

Hmmm... Dunno... I can see the point there.

I know Jiri, the fellow behind Dextronet, and I can't imagine any malicious intent there. He's a decent fellow.

-Renegade (October 07, 2011, 12:31 PM)

Oh, I didn't want to imply it was malicious, as in doing evil on purpose. But it's an abuse of the AppData concept. I'll go out on a limb and say it's kind of like putting your heavy bags on a passenger seat on a crowded train. Not evil, not illegal, just an abuse of the existing framework, and if everyone did that, we'd all be worse off for it.

For one thing, a typical (automated, simple) backup regime may include AppData but not Program Files. This makes good sense, since usually you cannot restore software directly, you have to run the installer (registry, registration etc.). So now you're backing up useless executables, which raises space requirements for your backup, increases the time required to complete, and provides no positive trade-off at all.

AV software comes to mind as well. A user might not want to always run a full scan, since that takes awfully long on today's large drives. Instead, a user might reasonably assume that most if not all executables are located under c:\Windows and c:\Program files, and only scan those folders. The more apps install themselves under other system folders (especially ones that are hidden by default, such as AppData!), the more likely it is that your AV scan will never see them.

But first of all, it's a mess, and an attempt to work around the built-in protection mechanisms of the OS. And because Chrome did that first, a lot of developers will now think it's permissible.

[JavaJones]

Chrome did it not because of not wanting admin rights for *install*, but so it could support their silent auto-update feature, something which a lot of Chrome users actually appreciate (some even though they don't know it, hehe). It made me uncomfortable when I found that out, kind of like installing an app accidentally into My Documents or something (which I've done before long ago). Very messy. I do wish there was a better way to achieve what Google is trying to do with Chrome though. If they could sort out a way to establish "trust" for a given exe and then positively determine if a request to change that exe *originated from the exe itself* (or a process spawned by the exe), as in the case of an update, then it could auto-trust that perhaps. Yeah, probably an exploitable security risk. I don't know what the solution is but I think there will be a consistent push to have apps that keep themselves updated more easily and I'm more or less in favor of that.

- Oshyan

[Renegade]

I've contemplated using AppData in the past, but... I stick with Program Files.

It just seems cleaner to use AppData sometimes. There are significant advantages to it.

For example, in one piece of software that I write, I have a database and some files that the program needs. Those get installed to Program Files as normal. However, I still need to make certain that I have checked for the existence of them in the AppData folder. So, by installing to the Program File folder, I have extra steps to take:

* Check if folder exists
* Create it if it doesn't
* Copy files to target folder
* Make certain that all is well and happy and joy, sunshine, rainbows, & unicorns

That all incurs a small amount of additional overhead, both in terms of programming time and running time.

It's a trade-off. If I were to install to the AppData folder, I could avoid a lot of things like that and simply place a shortcut in the Program Files folder.

Another advantage to using the AppData folder is that if you are copying, you need to decide HOW to copy and WHAT to copy. Iterate over folders? Hard code file names? Use a manifest? Great. More points for problems to occur. Instead, by using the AppData folder, you can effectively simply add in folders and files without worrying about how/what to copy, making all of those other considerations moot. This lets you simply use some dynamic logic to deal with them normally instead of that logic plus logic to verify and copy files/folders.

It also leads to portability. i.e. You can simply XCOPY that folder to a USB drive or Dropbox or whatever. You don't have that option if you use the Program Files folder.

In short, AppData offers a simpler way to deal with things that is neat and clean.



In the past, you could use the Program Files folder (Windows 2000 and XP). Now, you can't realistically.

[Renegade]

Oh, I didn't want to imply it was malicious, as in doing evil on purpose. But it's an abuse of the AppData concept. I'll go out on a limb and say it's kind of like putting your heavy bags on a passenger seat on a crowded train. Not evil, not illegal, just an abuse of the existing framework, and if everyone did that, we'd all be worse off for it.

-tranglos (October 07, 2011, 01:50 PM)

Got it. I wasn't sure what you meant by abuse at first. I'm not always the sharpest lightbulb in the toolshed.

[Eóin]

Don't forget that when you install a program outside protected folders like Program Files it becomes fair game to any other malicious software. So that app you trusted to make an exception for in your firewall, oh oh, now it has been compromised or replaced by another non-elevated process.

[Stoic Joker]

Users aren't supposed to be installing software (it's dangerous). But if a program needs to be available to all users, and it wants to store writable files in its very own close by place ... That (IIRC) is what C:\ProgramData is for.

Binaries in Program Files
Writables in ProgramData
User X specific/only in AppData

[Renegade]

Don't forget that when you install a program outside protected folders like Program Files it becomes fair game to any other malicious software. So that app you trusted to make an exception for in your firewall, oh oh, now it has been compromised or replaced by another non-elevated process.

-Eóin (October 07, 2011, 10:41 PM)

True enough. But seriously... If the computer's going to get compromised there, anything goes, so whether or not your program is in AppData or wherever just doesn't matter anymore. Hosed is hosed.

Here's a fun way to look at it... If you're going to be eaten by zombies, do you care if you know the zombie or not?

...or maybe the zombie is just an impersonator zombie and not your mom zombie or...

I think it might be cool to be eaten by Elvis... Then again, maybe not.

Users aren't supposed to be installing software (it's dangerous). But if a program needs to be available to all users, and it wants to store writable files in its very own close by place ... That (IIRC) is what C:\ProgramData is for.

Binaries in Program Files
Writables in ProgramData
User X specific/only in AppData

-Stoic Joker (October 07, 2011, 10:47 PM)

Whether it's this or that folder, having all writable files & folders under the program's executable folder is a massive plus. (Worked on 2000/XP.)

Mind you, while I am freakish about some things, this isn't one of them. Or maybe it is. Either way -- whether I'm a freak or not -- I don't have a problem with programs outside of Program Files if it makes sense.

For example, I have "Magic the Gathering Online" on this machine. It's nutty. In the extreme. It drives me batty every time I want to play it... Here's how the insanity goes...

Start > Programs > MTGO > Run the program...

Oh... No. It doesn't start. Instead, I get the Admin prompt (orangish-yellow one at that... grrr...) to allow "Renamer.exe" to run. WTF? Oh... yeah... that's the "prelauncher"...

Mostly irrelevant, but I wanted to rant a bit

Click OK.

Updater runs... Wait half hour for game to update itself... (This annoyance isn't related to the discussion, but it's part of the insanity of getting the game to run.)

Once updated, have nice pretty screen to look at. Must click "Launch" to start game...Click "Launch". Game starts. Must remember password & login. Login name is case sensitive... Password rules are... Tired of farting around with it... Click X to close it... That's the nice part because it closes down quickly and gracefully. The exact opposite of the startup experience.

Ok. Most of that is just me complaining. But the first part where we get the lovely admin prompt... Like, c'mon... The reasons for requiring admin permissions or prompts or whatever are never good. They're always bad. No "user" level program needs to have admin rights. Ever. Why? There isn't a single scenario where a user would ever need admin elevation. User that is...

So, I take it that if you're installing drivers or doing system administration... well... that's administration.

It might be a better user experience to avoid that constant pestering and just put it in a folder that doesn't require prompts. That might make sense.

Getting off track there a bit...

As a user, I really don't care about "Program Files" and how it differs from AppData or any other folder. The *only* meaning that it has for me is that it is a central repository. Beyond that, I don't care. As a user...

Also, the whole "portable" application thing... I love it. But, with the whole Program Files model, it's tough. Copy files from folders X, Y and Z, then... oh Lord... My eyes are glazing over already...

For me, I don't want to have to think about those sorts of things. i.e. "Don't make me think." A nice little aphorism found in many writings on user experiences.

Let's See A Show Of Hands

Who here has ever setup a new machine, then copied all their programs from their old machine onto it by dragging and dropping them on?

Nobody. But that's what the user experience should be like.

I dread setting up new machines. It takes forever because I have to track down software, that I've already had to install, then install it, then configure it, then... the list goes on. It's extremely painful and time consuming.

Yeah... Licensing... a pain... piracy, yadda yadda yadda... As an honest user, do I really need to pay the price for other people's sins? Why? Why punish me?

(I have serious issues with people misdirecting their anger/whatever at me.)


How about this... Instead of:

> App vendors discover a new way to abuse Windows

How about:

> App vendors discover a way that illustrates how Windows program installations are basically overly complicated, fragmented, and difficult to work with

Is it a problem with abusing Windows, or is it a problem with how Windows sets things up?

I'm sure there are all sorts of technical reasons and lots of security mumbo-jumbo to go along with the way things are right now. But I really just don't care. It makes life more difficult for me. I think that the majority of people out there would agree that making life easier for them is good.

Am I just being a freak and oversimplifying?

BRAIN FART:

Instead of only looking for malware, why not have a security system that looks for "goodware", and only allows you to run pre-authorized programs? Kind of like a guest list at an exclusive party where you need to be invited.

[vlastimil]

> App vendors discover a way that illustrates how Windows program installations are basically overly complicated, fragmented, and difficult to work with

Is it a problem with abusing Windows, or is it a problem with how Windows sets things up?

-Renegade (October 08, 2011, 03:54 AM)

100% agree - it should be the OS responsibility to set up the file system on a computer in a sensible way. Today, every developer, who wants to improve installation experience on Windows (allow isolated, non-admin installs), ends in the %APPDATA% folder. It is the least of all evils (better than Desktop, better than Start menu folder, possibly better than Documents).

[Eóin]

True enough. But seriously... If the computer's going to get compromised there, anything goes, so whether or not your program is in AppData or wherever just doesn't matter anymore. Hosed is hosed.

-Renegade (October 08, 2011, 03:54 AM)

Not sure I agree, the whole point of UAC is that prior to you clicking yes and elevating a process your computer is not compromised. In reality UAC is not 100%, especially on the default Win7 settings. Nonetheless placing EXE's outside the protected folders is just plain careless to me, you are actively circumventing one level of a users protection and saying it's done for their convenience.

[Renegade]

True enough. But seriously... If the computer's going to get compromised there, anything goes, so whether or not your program is in AppData or wherever just doesn't matter anymore. Hosed is hosed.

-Renegade (October 08, 2011, 03:54 AM)

Not sure I agree, the whole point of UAC is that prior to you clicking yes and elevating a process your computer is not compromised. In reality UAC is not 100%, especially on the default Win7 settings. Nonetheless placing EXE's outside the protected folders is just plain careless to me, you are actively circumventing one level of a users protection and saying it's done for their convenience.

-Eóin (October 08, 2011, 08:05 AM)

I'm not following.

If your computer is already compromised with some malicious code running, I don't see what difference it makes whether some legitimate program is stored in Program Files or somewhere else. The damage is already done.

The same goes for all external storage. A portable application would also be "just plain careless".

Maybe I'm dense... Maybe we're talking about slightly different things?

[Eóin]

Well to stick with the firewall example -

Generally windows firewall needs admin privileges if you are to add exceptions for any program. Now say you install program T, a program you trust and it needs to open a port in the firewall. You allow it because you trust it. Later you accidently run some malicious app M which wants an open port for it's nefarious purposes. If T were installed in a writable location then M can modify or replace T to take advantage of the port you entrusted to it.

On the other hand if T is in Program Files then M can only get at an open port by requesting admin privileges.

[Carol Haynes]

The other issue is if you have lot of users in an organisation that use lots of different machines they need accounts on each machine. If software starts getting installed per user (rather than per machine) each machine will have multiple copies of the software which can't be a good thing.

The other point is that software should go through UAC to be installed - but it doesn't need UAC to run if the app doesn't need admin rights so from a users perspective it is one extra click if it installs in the correct place.

If it is being installed in an alternative location because a user can't get admin rights then they are circumventing a system specifically put in place to stop this behaviour and it provides a easy exploit route for any average user. Also system admins in organisations who set up systems to stop the addition of unauthorised software are not going to be totally happy!

Microsoft should treat this behaviour as potential security problem and issue and update to enforce correct installation procedures before it gets totally out of hand. One way round this would be to ensure that executables outside approved locations run with minimal priviledges, generating maximum UAC promtps for any and every change they make. As a result users would get really fed up with the software and force developers to use more standard approaches. You could relax thing by having a trust option (say for using portable apps) that allow you to elevate apps to normal user rights but only after admin permission is given.

There are a number of other things MS should enforce too when it comes to installation behaviour:

1) Don't allow temp folders to be used to store installers (that then get broken when you clear out temp folders).
2) Don't allow any programs to run from temp folders (most the viruses and malware I see tend to have stuff squirrelled away in global or user temp folders).
3) Provide optional UAC control during application installation to allow every potentially dangerous change to be monitored during installation. This could be off as standard but it would allow system admins (or people who want to know what is going on) to see what processes/services are being installed and registry changes that could open security issues. If you don't want to respond to lots of prompts this could be provided by producing comprehensive system logs when required. It would be great for troubleshooting too.

The final request is that MS start docuemting errors and issues. The system logs now show you errors but since MS changed their website I have not seen a single error that produces further information on their website - it almost invariably simply says 'no further information is available'. The only way to troubleshoot anything is to wade through pages of irrelevant search results from Google et al.

As for Google Chrome - silent updates are a VERY BAD THING! Not only do Eula's change all the time (and so users have to be proactive to see what they have tacitly agreed to) but you don't know what they are going to install at all. MS got into this shit with silent updates and thye world went mad and start shouting about rootkit installers etc. Google seem to get away with anything. All it needs is one line in their Eula to take over you computer completely and do as they want. No I am not paranoid - THEY ARE OUT TO GET YOU. This is corporate America we are talking about after all.

[Eóin]

Point 3) can be tackled by requiring application installation to use MSI i.e. Window Installer, it's by far the safest installer out there in terms it's transactional support. Plus there are plenty of official and unofficial tools to allow Administrators to inspect the msi files before running them as well as track what they do while installing.

[Renegade]

Well to stick with the firewall example -

Generally windows firewall needs admin privileges if you are to add exceptions for any program. Now say you install program T, a program you trust and it needs to open a port in the firewall. You allow it because you trust it. Later you accidently run some malicious app M which wants an open port for it's nefarious purposes. If T were installed in a writable location then M can modify or replace T to take advantage of the port you entrusted to it.

On the other hand if T is in Program Files then M can only get at an open port by requesting admin privileges.

-Eóin (October 08, 2011, 09:26 AM)

I suppose, but I still don't really see the point. Outbound connections are allowed by default. So if you're starting with the malware on the inside, it wouldn't matter at all -- any malware could just contact a remote server anyways.

If you have a very popular application then it might make sense, but for a smaller application, it's not likely to attract any attention from malware authors. So for something like Chrome, then maybe. But then again, you're not running browsers much on servers... Dunno.

I suppose that I'm somewhat lax in some areas when it comes to security. I don't install warez, or surf freaky stuff, or open email attachments (that never arrive as I filter them before), or do anything risky, so for myself, I wouldn't think twice about a program installing to AppData or wherever.

Mind you, when I write software, I'm not that lax. I still stick with Program Files, etc. etc.

I really just hate the atmosphere of fear created by the security industry. Some is ok, but enough is enough. Some basic stuff can prevent a lot of pain. It's really not hard.

Yeah... I could get hit by a bus, but I'm still going to cross the street.

I suppose it's all about risk levels, and I'm comfortable where you're not. Meh... I like vanilla ice cream too. Vanilla, chocolate, whatever.

I don't pass off my lackadaisical attitudes when I write software. At that point, I play paranoid a lot of the time. I suppose that's why I'm a bit of a lazy user -- it's like taking your work home with you.

[Renegade]

As for Google Chrome - silent updates are a VERY BAD THING! Not only do Eula's change all the time (and so users have to be proactive to see what they have tacitly agreed to) but you don't know what they are going to install at all. MS got into this shit with silent updates and thye world went mad and start shouting about rootkit installers etc. Google seem to get away with anything. All it needs is one line in their Eula to take over you computer completely and do as they want. No I am not paranoid - THEY ARE OUT TO GET YOU. This is corporate America we are talking about after all.

-Carol Haynes (October 08, 2011, 09:55 AM)

I've been battling between update checks, check & download, and check & install, but have never considered silent updates. "VERY BAD THING" is an understatement. To which, that last sentence is an understatement.

I'm having a very hard time going as far as check & download, and am thinking that a simple check is best. I can see forcing an update. It's little different from updating a web site to function differently (with the obvious exception of where the application is run, but other than that... not much).

MS & Google

For MS, they can do no right in the media mind. They could create world peace, and solve world hunger, and Bill Gates would still be the Anti-Christ.

For Google, almost no wrong. Google would have to crucify the Dali Lama upside down and then burn him alive for the media to cry, "That's not very nice."

The different standards that are applied to different companies absolutely drives me nuts.