I think you're incorrect, the article isn't written as FUD. Some media outlets don't understand, and so they throw around titles like "Major Android Vulnerability" and similar garbage. The purpose and tone of the article is to document and inform. Yes, I agree, none of this is news to someone with intimate knowledge of the Android API, like the folks on this list.
The fact that 2-way communication with the Internet is possible without INTERNET permission, and that it's been publicly discussed for 2 years, is exactly the type of thing that should have attention brought to it. Maybe the android.intent.category.BROWSABLE Intent should be restricted? Or maybe there should be a OPEN_BROWSER permission? However it's done in the future, I think the current situation is rather serious. Those who've read the Android documentation know that SD/External storage shouldn't be used for anything sensitive and that any app can read it. Great. But what about the millions of non-developer Android users? Do they know that a random app can access their backups, upload their pictures somewhere, etc.? FYI, stealAppData() actually looks in /data/data/<packagename> for readable data. The purpose of this was to find apps that use world-readable permission on their files, such as the Skype vulnerability linked in the article or the Lookout vulnerability from last year: http://blog.mylookout.com/look-11-001/ -- these are not Android OS vulnerabilities, they are vulnerabilities in apps that specifically go against the suggestions in the documentation. I don't think it's stated any differently in the article. Paul Brodeur On Friday, April 13, 2012 8:45:02 AM UTC-6, Will Enck wrote: > > Jeffrey, > > Please correct me if I'm wrong, but this article is a bunch of FUD. > > The article includes a link to the source code: > http://leviathansecurity.com/blog/uploads/NoPermissions.zip > > The readIdentifiers() method in NoPermissionsActivity.java is calling: > > - TelephonyManager.getNetworkOperator(): "Returns the numeric name > (MCC+MNC) of current registered operator." This is the Mobile Country Code > (MCC) and Mobile Network Code (MNC), which is only going to say what > country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not > very specific to a handset, and therefore a very low privacy risk. > > - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country > code + mobile network code) of the provider of the SIM." > > - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, > this is readable without a permission *by design*. Note that the ANDROID_ID > is different than IMEI/IMSI, because you can change it without purchasing a > new handset. > > The readVersion() method is getting the value of /proc/version, which is > the kernel version (not sensitive). > > The stealAppData() method gets the list of installed packages from > /data/system/packages.list (also available from > PackageManager.getInstalledPackages() without a permission). It then looks > for app home directories that are readable (i.e., on the SDCard). The > SDCard is well known to be insecure for storing information, and apps have > to specify if they can be loaded to the SDCard, *and* the user has to move > them there. As for access to the SDCard without a permission, see the next > point. > > The stealSD() method goes through all the files in /sdcard and just sends > a list of files. Android has no limitations on applications reading the > contents of the SDCard. While this is a well known fact, there was another > story recently about the concern over apps stealing photos that caused a > lot of hype, and IIRC, Google responded that they are working on it. This > fix is going to take some time due to legacy compatibility, but hopefully > now that Android 3.0 and later connect to PCs using MTP and not a USB mass > storage device, there's an opportunity to use file permissions on the > SDCard. So yes, this is something that really needs to be fixed, but it's > not a new finding (it's been the elephant in the room since day one of > Android). > > The sendGzByBrowser() and sendByBrowser() just take the acquired > information and include it in a URL passed to the Web Browser. This method > of exfiltrating data is well known (Tim includes a link on implementing a > root shell using this method). > > Thanks, > -Will > > On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote: > > A new twist just arrived (or it looks new to me). An app with no > > permissions gets pseudo-READ_PHONE_STATE for free. > > > > ""No permissions" Android app allows secret data harvesting," > > > http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709 > > > > Paul Brodeur, security researcher with Leviathan Security Group, has > > created a proof-of-concept app that shows how an Android application > > which doesn’t ask for any security permissions is still able to get > > access to data stored on SD cards, data stored on the handset by other > > apps, and information about the handset and handset’s Android ID. > > ... > > -- > William Enck > Assistant Professor > Department of Computer Science > North Carolina State University > Email: e...@cs.ncsu.edu > Web: http://www.enck.org > > On Friday, April 13, 2012 8:45:02 AM UTC-6, Will Enck wrote: > > Jeffrey, > > Please correct me if I'm wrong, but this article is a bunch of FUD. > > The article includes a link to the source code: > http://leviathansecurity.com/blog/uploads/NoPermissions.zip > > The readIdentifiers() method in NoPermissionsActivity.java is calling: > > - TelephonyManager.getNetworkOperator(): "Returns the numeric name > (MCC+MNC) of current registered operator." This is the Mobile Country Code > (MCC) and Mobile Network Code (MNC), which is only going to say what > country and cellular provider you are on (e.g., AT&T, T-Mobile). It's not > very specific to a handset, and therefore a very low privacy risk. > > - TelephonyManager.getSimOperator(): "Returns the MCC+MNC (mobile country > code + mobile network code) of the provider of the SIM." > > - Settings.Secure.ANDROID_ID: As Tim Strazzere indicated in his reply, > this is readable without a permission *by design*. Note that the ANDROID_ID > is different than IMEI/IMSI, because you can change it without purchasing a > new handset. > > The readVersion() method is getting the value of /proc/version, which is > the kernel version (not sensitive). > > The stealAppData() method gets the list of installed packages from > /data/system/packages.list (also available from > PackageManager.getInstalledPackages() without a permission). It then looks > for app home directories that are readable (i.e., on the SDCard). The > SDCard is well known to be insecure for storing information, and apps have > to specify if they can be loaded to the SDCard, *and* the user has to move > them there. As for access to the SDCard without a permission, see the next > point. > > The stealSD() method goes through all the files in /sdcard and just sends > a list of files. Android has no limitations on applications reading the > contents of the SDCard. While this is a well known fact, there was another > story recently about the concern over apps stealing photos that caused a > lot of hype, and IIRC, Google responded that they are working on it. This > fix is going to take some time due to legacy compatibility, but hopefully > now that Android 3.0 and later connect to PCs using MTP and not a USB mass > storage device, there's an opportunity to use file permissions on the > SDCard. So yes, this is something that really needs to be fixed, but it's > not a new finding (it's been the elephant in the room since day one of > Android). > > The sendGzByBrowser() and sendByBrowser() just take the acquired > information and include it in a URL passed to the Web Browser. This method > of exfiltrating data is well known (Tim includes a link on implementing a > root shell using this method). > > Thanks, > -Will > > On Apr 12, 2012, at 5:25 PM, Jeffrey Walton wrote: > > A new twist just arrived (or it looks new to me). An app with no > > permissions gets pseudo-READ_PHONE_STATE for free. > > > > ""No permissions" Android app allows secret data harvesting," > > > http://www.zdnet.com/blog/hardware/no-permissions-android-app-allows-secret-data-harvesting/19709 > > > > Paul Brodeur, security researcher with Leviathan Security Group, has > > created a proof-of-concept app that shows how an Android application > > which doesn’t ask for any security permissions is still able to get > > access to data stored on SD cards, data stored on the handset by other > > apps, and information about the handset and handset’s Android ID. > > ... > > -- > William Enck > Assistant Professor > Department of Computer Science > North Carolina State University > Email: e...@cs.ncsu.edu > Web: http://www.enck.org > > -- You received this message because you are subscribed to the Google Groups "Android Security Discussions" group. To view this discussion on the web visit https://groups.google.com/d/msg/android-security-discuss/-/TEjG-vIH_KcJ. To post to this group, send email to android-security-discuss@googlegroups.com. To unsubscribe from this group, send email to android-security-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/android-security-discuss?hl=en.
