Handbrake Developers Issue Mac Security Warning After Mirror Download Server Hack

[manu chao]

One example is the /Applications directory. When you're running under an admin account, everything that you execute can e.g. replace or modify your installed application executables without any password prompt. This can be used e.g. to make malware persistent. You can try it yourself: open a terminal while logged in to an admin account and type "touch /Applications/xxxx". You will not see any prompt an the file will be created. If you try the same under a standard user account, you'll get "permission denied".

Ok, though I sometimes get a password prompt when trying to change something in the /Applications folder (while using an admin account). If I had to guess, maybe when I am trying to change apps in there that are part of the OS.

I just tried to delete Garageband and I am getting a password prompt (I've also tried to delete Gamecenter and I get a this-is-part-of-the-system-and-cannot-be-deleted warning, but that is not necessarily a security feature, more one against self-harm).

I am trying to think what harm can be done by writing to and/or modifying (third-party) items in the applications folder beyond what launching a trojan application in the first place can do.

 

[Rigby]

Ok, though I sometimes get a password prompt when trying to change something in the /Applications folder (while using an admin account). If I had to guess, maybe when I am trying to change apps in there that are part of the OS.

It depends on the app. The permissions aren't always set consistently by the installers. Check the permissions using "ls -l /Applications" or similar. If a bundle is writable for group "wheel", it's writable for all administrator accounts. There are a number of other system directories besides /Applications as well.

BTW, just because Finder throws up a prompt in certain situations doesn't necessarily mean that other apps (such as Terminal or a malware app) are also restricted from accessing the underlying resource.

Bottomline is that it is still advisable to follow the "least privileges" principle on MacOS. There is really no good reason for regular users to run under an admin account all the time, especially since the OS makes it easy to temporarily gain admin rights when necessary.

 

[manu chao]

It depends on the app. The permissions aren't always set consistently by the installers. Check the permissions using "ls -l /Applications" or similar. If a bundle is writable for group "wheel", it's writable for all administrator accounts.

Another question: Is there any real difference between using an admin user and installing all applications into /Applications and using a non-admin user and installing all applications into ~/Applications, if we are dealing with a computer only used by a single person? Phrased differently, if a non-admin user is tricked into running a trojan, that trojan can do to ~/Applications about the same thing as a trojan run by an admin user can do to /Applications.

There are a number of other system directories besides /Applications as well.

BTW, just because Finder throws up a prompt in certain situations doesn't necessarily mean that other apps (such as Terminal or a malware app) are also restricted from accessing the underlying resource.

Ok, I've tried touch /[folder name]/xxxx in the Terminal on all visible root level folders (plus a smattering of the hidden ones) from an admin account and all except for /Applications came back with a permission denied.

Bottomline is that it is still advisable to follow the "least privileges" principle on MacOS. There is really no good reason for regular users to run under an admin account all the time, especially since the OS makes it easy to temporarily gain admin rights when necessary.

I get the impression that Apple has over time required the admin password in a lot of situations such that the difference between running an admin account and a non-admin account (both in terms of user experience as well as security implications) has been narrowed significantly.

I don't argue against the recommendation that using a non-admin account is safer. I am just trying to ascertain in what specific ways it is actually safer in a single-user (as in single human) usage scenario.

 

[Rigby]

Another question: Is there any real difference between using an admin user and installing all applications into /Applications and using a non-admin user and installing all applications into ~/Applications, if we are dealing with a computer only used by a single person? Phrased differently, if a non-admin user is tricked into running a trojan, that trojan can do to ~/Applications about the same thing as a trojan run by an admin user can do to /Applications.

Yes. That's why it's best to install executables where the regular user does not have write privileges (i.e. /Applications is usually preferable from a security perspective).

Ok, I've tried touch /[folder name]/xxxx in the Terminal on all visible root level folders (plus a smattering of the hidden ones) from an admin account and all except for /Applications came back with a permission denied.

Try something like this (as an administrator): "find /Library -perm -g=w". There are wheel-writable files and directories all over the place.

 

[CPx]

Eek, I downloaded it the night before their stated infection window. Dodged a bullet there...

 

[bmac89]

I just happened to download Handbrake for the first time during this period. I can't see any activity_agent in the Activity Monitor, so I guess my mac is not infected.

I assume if you are infected it shows activity_agent regardless of whether handbrake app is open?

I opened the app directly from the .dmg volume - not that it makes any difference as far as I know. Either way I will be deleting the app.

 

[UL2RA]

I just happened to download Handbrake for the first time during this period. I can't see any activity_agent in the Activity Monitor, so I guess my mac is not infected.

I assume if you are infected it shows activity_agent regardless of whether handbrake app is open?

I opened the app directly from the .dmg volume - not that it makes any difference as far as I know. Either way I will be deleting the app.

Scan with Malwarebytes to be sure: https://www.malwarebytes.com/mac/

 

[huperniketes]

Great job, Handbrake. Uninstalling now and not supporting your software again.

This isn't a commercial product you paid for. I'm sure it was the work of hobbyists who had a passion for the public to be able to view the media they'd purchased legally. So development of the product, providing technical support, and operating a website for it is a labor of love. Just how did you support their software? Did you donate any funds to the team? If not, I wouldn't consider your "support" to be worth the bits it was printed on.
[doublepost=1494314409][/doublepost]

It's also another reminder that it's better for your day-to-day account to not be an admin account. OS X / MacOS make it trivially easy and painless to run as a non-admin user.

Unfortunately, many developer or pro-grade apps aren't as security conscious as that. Project Builder/Xcode for example required one to run as an admin to work correctly. I don't know if that's still the case, but it's true for enough apps that even fast switching accounts just to work was a nuisance.

If GateKeeper helps move the Mac ecosystem to resolve that security hole, I'd appreciate it.

 

[loby]

The app is one of the best out there. I use it almost daily.

This is a great app and I too use it quite often.

It amazes me how people quickly complain and comment negatively on an open source "free" software that they don't have to pay anything for. Give them a break. This is not apple with unlimited resources and employees with high paying salaries who are expected to have everything protected and secure and perfect. They don't get paid. They were quick to reveal the issue and not hide anything.

Complainers either don't write code, or if you do, you are doing it for money. They are not. Those who use their software appreciate their hard work and appreciate their honesty to reveal the issue quickly and not hide anything so we can fix the issue on our side. This stuff happens occasionally. If you paid for the software, then "yeah"..complain. They have limited resources, so give them a break as they work hard to resolve the issue. I am sure someone had no sleep trying to quickly fix the problem and then have to go to their day job after, just to fix a free program that they offer to the world to use.

Appreciate the open source community that gives us a great program. Thanks for informing us right away so we can protect our systems and continue to use handbrake.

 

[rhett7660]

You can do that as a malware developer, but Apple will have information about you. If my app had problems, Apple could send someone to my home if they felt that was the right thing to do. They have the name of my company, companyhouse in the UK who holds information about all UK companies has my company's address and my name and home address, they have delivered mail there so they know where I am. It's not just $99 to register, Apple checks and keeps information about the developer.

I don't think this would prevent a developer from using a false name and or false name of a company. If I am out only 99$ but my app brings in much more than that, I could see them using

 

[Rigby]

Unfortunately, many developer or pro-grade apps aren't as security conscious as that. Project Builder/Xcode for example required one to run as an admin to work correctly. I don't know if that's still the case, but it's true for enough apps that even fast switching accounts just to work was a nuisance.

Xcode works fine with a standard user account. Some of the debug tools require elevated privileges to be able to manipulate running processes, but it's enough to add the user to the _developers group.

 

[zooby]

.

 

[KALLT]

It depends on the app. The permissions aren't always set consistently by the installers. Check the permissions using "ls -l /Applications" or similar. If a bundle is writable for group "wheel", it's writable for all administrator accounts. There are a number of other system directories besides /Applications as well..

‘wheel’ is used exclusively by root. Unlike Linux and BSD-based systems, Apple uses the ‘admin’ group for sudo. The /Applications directory has group permissions for the admin group, all other system directories are restricted to wheel.

Another question: Is there any real difference between using an admin user and installing all applications into /Applications and using a non-admin user and installing all applications into ~/Applications, if we are dealing with a computer only used by a single person? Phrased differently, if a non-admin user is tricked into running a trojan, that trojan can do to ~/Applications about the same thing as a trojan run by an admin user can do to /Applications.

It depends upon what the application is after. Programs are always run with the permissions of the executing user, unless configured otherwise or additional privileges are needed. This is true for both types of accounts, with the difference that a program executed by an admin may also write where the ‘admin’ group has additional permissions, such as the /Applications directory. However, if an application is after user data or intends to monitor the user, then there is no need to require elevated privileges in many cases.

I think it is still beneficial to operate within the user space as much as possible. It makes you aware of the space in which you are working and shows you what the limits of your permissions are. You almost never have to divulge your user password, because you cannot elevate permissions anyway. With admin accounts, this is not always clear, given that your password gives not only access to elevated privileges but also confidential data in your keychain.

I also think that it is better for software such as Time Machine which operates at a system level and cannot be controlled by a standard user. There seem to be at least some incidents where admin accounts are able to tamper with the Time Machine volume, but I have not been able to confirm this with a standard user.

Moreover, there were vulnerabilities in Apple’s Security framework in the past and sudo itself was not configured with IMO sensible security settings (until Sierra that is).

The bottom line is that running as a standard user bears a negligible hassle and has at least some security benefits. But it is by no means a panacea.

 

[manu chao]

I think it is still beneficial to operate within the user space as much as possible. It makes you aware of the space in which you are working and shows you what the limits of your permissions are.

When I switched from Classic MacOS (OS 9) to OS X, it took me a darn long time to accept to put all my files into my user folder. Why should I complicate matters and bury things two-level deep from the root of the hard drive?

You almost never have to divulge your user password, because you cannot elevate permissions anyway.

But you will be asked the admin password at least as often as you do when running an admin account. If a certain task requires an admin password in an admin account, it most definitely also needs an admin password in a non-admin account.

With admin accounts, this is not always clear, given that your password gives not only access to elevated privileges but also confidential data in your keychain.

That is not an admin vs non-admin issue, you can set the keychain password independently from the user password.

I also think that it is better for software such as Time Machine which operates at a system level and cannot be controlled by a standard user. There seem to be at least some incidents where admin accounts are able to tamper with the Time Machine volume, but I have not been able to confirm this with a standard user.

Unfortunately, this has been tightened a lot. Doing anything but read files from a TM backup has become quite difficult. For example, I recently wanted to delete all but one snapshot from an older, no-longer current TM backup to keep it as an archive. I had to give up after a while.

 

[Tinmania]

Guess it's an indication that using the tool won't make any sense either... fair game.

Overlooking the ignorance of that comment, if you needed the functionality this app provides you would already know all about it. Did you think malware authors would target a crappy piece of software that no one downloads?



Mike

 

[bmac89]

Malware can trick users with fake password dialogues for installation which raises the issue in my mind that it seems only sensible to better protect the keychain and saved passwords with a second layer of security.

1. Two step authentication or different pin/password to view Safari saved passwords.
Currently this is not possible - all you need is the account password to view all saved passwords which could be compromised by phishing. Fingerprint reader plus password could be another option in the future.

2. A different password for keychain then the user account password?
Can someone clarify this and explain if this is a good practise?


I understand the security concerns of installing apps that requires password for extra privellidges but not all users will have the same awareness. I also realise a lack of understanding or awareness is a problem in itself but I think this could potentially be better protected from a software point of view with the above points.

I must point out that I don't know a lot about this and maybe I'm missing something. Can someone clarify this for me. I tried changing the keychain password and this caused many issues. I had repeated dialogue pop ups and the only password that it would accept was my user password and not the new keychain password. This also messed up my iCloud and I had to reset the entire keychain and return to default password.



Thanks

 

[huperniketes]

Xcode works fine with a standard user account. Some of the debug tools require elevated privileges to be able to manipulate running processes, but it's enough to add the user to the _developers group.

Yep, that's the problem: running developer tools and some other non-development housekeeping functionality, if I remember correctly. It would seem to be more secure, especially in a corporate environment, to require Xcode to run in a group with elevated privileges, but which isn't an admin.

 

[groovyd]

Overlooking the ignorance of that comment, if you needed the functionality this app provides you would already know all about it. Did you think malware authors would target a crappy piece of software that no one downloads?

Mike

I used to contribute to it... just stating the obvious regarding naming and icon. I agree though most geeks don't care if the name has anything to do with what it does and generally think that makes it even cooler. Most non-geeks would never use it even if they needed it because they would never be able to find it and make sense of how to use it. The interface isn't entirely obvious at all.

 

[KALLT]

But you will be asked the admin password at least as often as you do when running an admin account. If a certain task requires an admin password in an admin account, it most definitely also needs an admin password in a non-admin account.

It is not about reducing password prompts, but about separating privileges. You reduce the impact one compromised password can have. You absolve your main account from this responsibility and separate access.

That is not an admin vs non-admin issue, you can set the keychain password independently from the user password.

You can, but it is not practical. Nowadays the login keychain is used by many applications for encryption keys and authentication tokens. You can certainly do it, but you will end up having to enter two passwords every time you log in. Alternatively, you can keep separate keychains too.

However, the benefit of having two accounts is that it is almost never necessary to enter your standard-user password. You do not need it for authorisation other than for logging in. This malware here is a perfect example of why that is not a bad idea: the malware showed a fake authorisation prompt, saying that it needs admin privileges. However, it is actually after the (keychain) password. If you were to enter the password of your separate admin account, then this would not have been possible.

Unfortunately, this has been tightened a lot. Doing anything but read files from a TM backup has become quite difficult. For example, I recently wanted to delete all but one snapshot from an older, no-longer current TM backup to keep it as an archive. I had to give up after a while.

You can also use tmutil, it can be less of a hassle. Time Machine has so much potential, but Apple just does not use it. They should have baked this into apps without having to use this clunky timeline screen. I have high hopes for APFS’ snapshotting feature as a replacement.

 

[manu chao]

You can, but it is not practical. Nowadays the login keychain is used by many applications for encryption keys and authentication tokens. You can certainly do it, but you will end up having to enter two passwords every time you log in.

Which is hardly a huge burden.

However, the benefit of having two accounts is that it is almost never necessary to enter your standard-user password. You do not need it for authorisation other than for logging in. This malware here is a perfect example of why that is not a bad idea: the malware showed a fake authorisation prompt, saying that it needs admin privileges. However, it is actually after the (keychain) password. If you were to enter the password of your separate admin account, then this would not have been possible.

If something can fool you into entering your admin password, it can equally fool you into entering your current non-admin user account password. And if you have given the malware your admin password, it can extract passwords from your keychain via virtual keylogging as well.