IssueTracker

Hi,
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks

It is generally privacy wise to limit unnecessary data disclosures across apps.

Previously, device MACs(Wi-Fi, Bluetooth)can be fetched from the /proc file system, even though the corresponding APIs are downgraded to return a fake and static value.

Re: https://code.google.com/p/android/issues/detail?id=205565#c3

Protecting privacy between applications is important, but bear in mind that the effect of this issue is that the information is being made private from the device owner.  Any time you restrict information from the device owner, it gives malware a place to hide.  Restricting the user from being able to determine what is running on his/her device is a net negative for privacy.

If protection of running process information is truly required, a third-party application-accessible permission should be provided to allow access.  Make it scary sounding and put it in a special group, e.g., a user-readable description of "Analyze device behavior and monitor running applications."

I agree with your opinion that a third-party application-accessible permission could be made, or combining it with something like the UsageStatsManager.

However entries made for protection can be abused for infiltration.
For example the new Android permission model since marshmallow:

1, We know certain sensitive device serial code is protected by the PHONE permission group:
Device's IMEI/MEID
sim(uim) card's ICCID

2, Apps can detect whether a runtime permission is revoked by the user.
3, An app can then force user to grant PHONE permission in order to permanently track the device. If user refuses, the app deliberately shuts itself down.
4, Similar tricks also apply to other permissions(location, contacts, modify settings..etc). Modify settings is for writing some persistent tracking cookies available to other apps that may be using the same user tracking SDKs.
5, A very important mitigation for #4 can be established if Google Play effectively pull down these malicious apps, however this is not case.


Such behavior is very popular among China's app developer(especially among large firms).

Thank you for taking the time to file this bug. We appreciate your feedback in the N preview release.

The behavior you're describing is working as intended. Android provides strict sandboxes that applications must run in. These sandboxes protect application data from other applications, including application metadata such as process state.

/sys and /proc are well known for leaking side channel information about processes, information which can be used to infer state about the processes. For instance, it's been documented for years that /proc access can be used to monitor for app launching, enabling phishing attacks.

  http://www.cnet.com/news/android-could-allow-mobile-ad-or-phishing-pop-ups/
  https://www.usenix.org/system/files/conference/woot12/woot12-final7.pdf

alternatively, /proc access can be maliciously used to infer application state, as described in https://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-chen.pdf (and also bug 36949180)

The availability of an API to "legitimately" access these capabilities would defeat the intended purpose of this security fix. Malicious applications could merely request the permission and gain access.

If there are specific files in /sys you believe should be available to applications, but are not, please file a new bug where the request can be evaluated. For instance, /sys/devices/system/cpu is available to all processes, so it's inaccurate to say all of /sys is restricted.

Thank you for your interest in the Android N preview release.

I'm quite frankly stunned by this.

I'm an app developer, not a security researcher.  What you've cited is certainly a real problem, but I believe you are solving it in the wrong way.

And when I say I'm stunned, I mean I'm so stunned I made a demonstration video of the type of malware attack that you are describing here, and I'm running it on an Android N device:

https://www.youtube.com/watch?v=SkvHA1jBpn8

The changes that have been made to Android N which cripple SystemPanel (and other system utilities, security, and antivirus apps) will do little to stop this kind of attack.  Again, the only real beneficiaries will be the malware authors who are better able to hide.

In the video above, the fake malware app--which took about 30 minutes to write, by someone who has never written even "fake" malware before--successfully does exactly what you're talking about on an Android N device.  You're eliminating *one* way an app can monitor the operations of others, but there are myriad more.  The demo above is triggered by network activity to the target app's network.  An identical attack is possible my monitoring that app's public directory structure on the filesystem.

The real problem here is that applications are permitted to launch themselves arbitrarily.  The fake malware demo above launches from a *service*.  This behavior should ABSOLUTELY NOT BE ALLOWED.  I had no idea this was possible until I tried it (given that arbitrarily launching an app to the foreground has never come up...perhaps because the only reasons I can think for doing so are malicious).

And regarding the permissions...I really don't understand your statement here.  Malware can request the permissions?  Why do we bother asking for permissions at all then?  The point of asking for permissions is so a user can determine whether they trust a given app to do something.  Your same argument can be made regarding allowing an app to access your contacts or camera.  The same justification can be used to say that apps simply shouldn't be allowed to access either of those features, period.

One more question...why is the root directory protected?

FWIW, this brings Android in line with iOS 9, Windows Phone, ChromeOS and similar platforms. It goes a long way towards making the Android app sandbox on par with those. Applications should be completely isolated from each other unless they explicitly expose APIs to other apps. A permission granting exceptions from hidepid=2 would be easy to implement, but it isn't a great use case for a permission. Users don't have an understanding of the kind of data that's being leaked (timing information, memory address leaks, command-line parameters which may contain personal information, etc.). It would make a bit more sense as a dangerous permission but it's not possible to grant it without restarting the application, so it wouldn't really work in the existing model.

The only way I can see an exception for apps making sense is if it was included into the umbrella of device management. I think improving the built-in system management tools is the way to go though... even prior to this change, the ability to do this from untrusted apps from VERY limited. In terms of AV/IDS apps, those never made sense as untrusted apps. Those are an example of something that really does need to be built into the base system. They could never do a great job without more privileges and they need to be protected from other apps which this change is actually moving towards.

These changes really hurt indie app developers. Apps, like Tod Liebeck's SystemPanel, have millions of active users. Now, when the user updates to N, they will no longer work. At least provide a better alternative before killing our apps. As a user, I appreciate that you are attempting to make the system more secure, but this won't stop malicious apps.

This is a business killer development, and Google should take responsibility for it. To protect the OS against malicious SW is something everybody should agree. But the way this is tried to be achieved simply shows an incompetency. You could very easily update an API of yours by opening app usage to third parties and attach it to a user permission, and then restrict the use of /proc/ and /sys/.  Somebody should explain to me why Google itself, can collect such information with a system permission without making users to go on Settings and allow it!!! Which businesses are you targeting? This is against the antitrust laws. Expect some legal challenges...

There's no permission tied to it so Google apps don't have a way to access this either. It's only for some components of the base system, including system_server which is how the Settings app obtains information (indirectly). The security implications of this include the ability to spy on things like keyboard input in other apps via timing side channels. The SELinux /proc restrictions combined with hidepid=2 prevent issues like https://www.lightbluetouchpaper.org/2016/07/29/yet-another-android-side-channel/. The implications of a permission for viewing process information wouldn't be something users would understand, unlike the existing user-facing permissions which are all tied to personal information access.

Check your facts Daniel, Google Play Services has App Usage permission as well as Google Play Store. Google Play can easily use such info for commercial purposes, for advertisement etc. This is a very clear case of antitrust laws violation. If third parties do not collect app usage, so shall not Google. Period. But it does.
Do not give any decision on behalf of the users. They know more than you do, do not underestimate people's intelligence. This is called freedom. They might give permission to access data
Security issues can be solved in many other ways.  You want to prevent spying, you can. App usage has nothing to do with keyboard input. Fix the one you need to fix.

I agree procfs access should be protected to prevent side channel attacks.  However, the idea that this protection requires the user be entirely prevented from determining what is running on his/her device is absurd.  Absolute denial of procfs access plugs a difficult-to-exploit security hole at the cost of giving malware a perfect means to hide.  This is a net negative.

Yes, you can explain this to the user.  You can give it a short name, like "monitor and analyze other applications".  It could even be implemented as a device administrator permission (as is the ability to lock the screen).  Or though I would not recommend it, it could even be set up like the android.permission.PACKAGE_USAGE_STATS permission, where the user must directly grant it from the system settings activity.

And if none of that is acceptable, just provide an Android API to obtain the data.

But alas, I think this is all paranoia over the any-app-can-launch-itself-at-any-time-to-impersonate-anything-else-problem.  That is a problem that security researchers pointed out FIVE YEARS AGO.  And it isn't fixed in Android Nougat.  And yes, preventing procfs access will prevent *one* of the *uncountably many* ways that an app might make use of that giant security hole.  

STOP FOCUSING ON THINGS THAT MINORLY HELP MALWARE AUTHORS TO EXPLOIT THE GIANT SECURITY HOLE, AND START FOCUSING ON FIXING THE GIANT SECURITY HOLE.

https://www.youtube.com/watch?v=SkvHA1jBpn8    <= another link to my video, a demo of that security hole being exploited on Android N to steal money from your bank account.  

[Comment deleted]

It was a huge security hole permitting keylogging and other information leaks, and it really doesn't matter if there are still other security holes to be fixed. These issues aren't going to be fixed by refusing to do anything until there's a giant patch set solving everything at once. There are plenty of changes that should happen like having a permission required to access the clipboard from the background. They are entirely orthogonal. It has nothing to with /proc access. Neither does access to things like app usage information.

This change came from CopperheadOS, which doesn't have Play Services. A Google security engineer agreed with the value in having it and they ported it to AOSP master and fixed some additional compatibility issues. There's no grand conspiracy behind it. It's not anti-competitive to remove clear security holes and to harden the system. It's unfortunate that there are legitimate use cases that are no longer being served as well, and that's something to improve. It makes a lot of sense for Settings to expose more information, and for it to be less hidden. Settings itself doesn't have access to /proc though, it gets the information from system_server indirectly and it's mostly not real-time information.

Solving UX design issues is going to require UX design. It's not something that security engineers working primarily on low-level code are going to be able to do alone, so you're really complaining to the wrong people about security issues at that layer.

If the malware has system/root access, it can easily hide itself whether or not apps have access to these APIs. If it doesn't have system/root, then exposing the information from Settings works fine. It's irrelevant to 99.9% of users either way. They're not going to be watching low-level process information, especially to the point that they would be able to spot something suspicious between all of the noise. It would be nice to have the information for other reasons, but there isn't much of a security argument for it.

The SELinux /proc restrictions and hidepid=2 also have nothing to do with higher level things like app usage statistics. There is no permission granting hidepid exceptions for apps. The information isn't available to Google apps. It's available to SafetyNet (snet) because it's part of the base system.