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.