Fixed
Status Update
No update yet.
Comments
zh...@gmail.com
Hi,
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
We have passed this defect on to the development team and will update this issue with more information as it becomes available.
Thanks
en...@google.com
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.
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.
cc...@google.com
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."
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."
cc...@google.com
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).
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).
en...@google.com
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 inhttps://www.usenix.org/system/files/conference/usenixsecurity14/sec14-paper-chen.pdf (and also
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.
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.
alternatively, /proc access can be maliciously used to infer application state, as described in
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.
zh...@gmail.com
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.
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:
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.
Description
We find that in user mode, the adbd fork new process whose oom_adj is -1000.
Such as, we can see many omm panic in user log:
Line 82: <6>[17721.393968s][2016:02:03 16:05:54][pid:6467,cpu0,kworker/0:2]lowmem_dbg: [10425] 2000 10425 533125 478139 1045 53958 -1000 tewilovesyouyet
Line 175: <6>[17724.392442s][2016:02:03 16:05:57][pid:6467,cpu0,kworker/0:2]lowmem_dbg: [10425] 2000 10425 537221 479523 1048 53958 -1000 tewilovesyouyet
After analysis, in user mode, when the adbd start, it will have ADB_SHELL uid.
the code in shell_service.cpp:
void init_subproc_child()
{
setsid();
// Set OOM score adjustment to prevent killing
int fd = adb_open("/proc/self/oom_score_adj", O_WRONLY | O_CLOEXEC);
if (fd >= 0) {
adb_write(fd, "0", 1);
adb_close(fd);
} else {
D("adb: unable to update oom_score_adj");
}
}
Because the adbd don't have root permision, the code won't work here.
So we suggest if we can set adbd process oom_score_adj to 0 at default.