The Oppo Find 5 was teased several months ago, but recent news from Beijing has made the device official, and revealed some truly impressive specs.
A 5-inch, 1080p display is probably the most noticeable feature of the phone, but this is backed with a quad-core 1.5GHz Snapdragon S4 chip.
The primary camera is 13MP with a host of intriguing software features, including super-slo-mo recording at 120fps. The front camera is 1.9MP and there’s the usual array of near-field communication (NFC), Wi-Fi direct and more, all running on Jelly Bean, specifically Android 4.1.2.
It’s 8.8mm thick, but this also allows the Find 5 to accommodate a 2500mAh battery, along with Dolby 3D sound, for some reason.
In fact, probably only the big downer is the lack of a microSD slot, meaning that you’re stuck with the default 16GB of memory.
The Find 5 is definitely getting a US release, although Oppo phones haven’t made it to some countries in Asia before. The specs for the spectrum tech used in the phone are GSM 850, 900, 1800, 1900MHz and UMTS 850, 1700/2100, 1900, 2100MHz, so parallel importing may be an option for some users.
Before you download an Android app, a developer has to present you with a list of system-level resources the app needs to access in order to run. These are simply referred to as Permissions; the purpose of Android Permissions is to let you know exactly what information an app maker is harvesting from your device, so you can make an informed decision over whether or not you want to download it. And an app needs your permission to do even trivial tasks like connecting to the Internet or preventing your phone from going to sleep.
But according to Leviathan Security researcher Paul Brodeur, even an Android app with zero permissions can still extract plenty of data from your device. Leviathan created a proof-of-concept app (called “No Permissions”) and found three types of personal data the app was still able to see:
1. Files on an SD card
2. A list of all apps already installed on the device, and files associated with those apps (the /data/system/packages.list file)
3. Basic device information: the GSM and SIM vendor ID, the Android ID which associates an app with a device, and kernel version.
An obvious question you might ask is what No Permissions could do with this data, if it couldn’t even connect to the Internet (which would require the ubiquitous “Internet” permission)? Brodeur claims Zero Permissions could still make one network call without explicit permission, one that would allow the app to launch the browser. Theoretically, from there the developer would be able to create additional browser calls and transmit the data.
Over-blown Claims? Before you do something dramatic like making a leap to iOS, another security researcher says Leviathan’s findings don’t pose much of a threat at all.
“None of these are flaws with the Android operating system, but with some specific applications that aren’t named,” researcher Daniel McCarney from the Carleton Computer Security Lab told me. ”Most of the findings are entirely supported behaviour. None of this is new research [or] a serious security risk for end users.”
Here’s what’s really going on:
Older versions of Android use an outdated partitioning system (FAT32) also used by many other operating systems, including Windows and MacOS. FAT32 is popular as it allows users to insert an SD card without formatting it into another operating system.
Furthermore in February, Google said it was exploring a Read permission for the SD card in a future release:
“As phones and tablets have evolved to rely more on built-in, non-removable memory, we’re taking another look at this and considering adding a permission for apps to access images. We’ve always had policies in place to remove any apps on Android Market that improperly access your data,” Google said in a statement.
2. App list: Yes, the permission-less app was able to pull a list file showing all the apps on your device. But McCarney said Google is not only aware, it has given developers an even easier way to get a list of installed apps (the PackageManager API).
“The use of this obscure file (packages.list) strikes me as a way to make the issue seem like a serious oversight or a vulnerability,” he said.
Jerry Hillebrand over at Android Central noted this list file doesn’t really pose a risk.
“Knowing what applications a user has installed is a great way to know what exploits may be useful to compromise their phone or tablet,” Hillebrand writes. “Knowing that an exploit exists it’s there means an attacker could try to target it. It’s worth mentioning that targeting a known insecure app would probably require some permissions to do so, though.”
3. Basic device information: Lastly, it remains to be seen whether a hacker with your GSM, SIM, kernel version, and Android IDs can actually identify who you are.
“This claim is entirely overblown,” McCarney says. “All their application is able to gain is the Mobile country code (MCC) and the Mobile Network code (MNC) of the phone. This information would tell you something akin to the fact that I have a Rogers mobile phone in Canada.”
Still Paranoid? There are a few precautions you can take, if this information still leaves you feeling uneasy.
1. Don’t store any personal information on your SD card.
The security of the Android mobile platform has always been a topic of debate. Due to Google’s open ecosystem and less invasive app policing policies, researchers argue that the Google Play marketplace is home to numerous malicious apps. Reports have surfaced over the past few years that claimed even applications from legitimate companies — such as Facebook, Skype and Path — were exploiting Android permissions and secretly accessing data. Paul Brodeur of Leviathan Security had a simple question: what data can an app access when it has no permissions? What he found may be shocking.
Brodeur created a special Android application that explores what data can be harvested from a device when the app has no permissions. The researcher found that his application was able to access the SD card, various system information and unique handset identification data. Access to the SD card provided Brodeur with information to all files that were not hidden, including photos, backups and any external configuration files. He states, however, that “while it’s possible to fetch the contents of all those files, I’ll leave it to someone else to decide what files should be grabbed and which are going to be boring.”
The second slew of information the application was able to access was located in the /data/system/packages.list file, which allowed the software to determine what apps are currently installed on a device. Brodeur was also able to scan each installed application’s directory to determine whether sensitive data could be read and accessed. This feature could be used by malware in an attempt to find apps with weak-permission vulnerabilities.
The last piece of information Brodeur’s application was able to gather regards a handset’s identifiable information. Without the “PHONE_STATE” permission, an application is not able to read the International Mobile Equipment Identity (IMEI) or International Mobile Subscriber Identity (IMSI). With no permissions, however, Brodeur’s app was still able to access the GSM and SIM vendor IDs. The researcher was also able to access the /proc/version pseudofile, which reveals the kernel version, Android ID and name of the custom ROM installed, if there is one.
Brodeur cautions Android users about suspicious applications, claiming any installed app can execute these actions without any user interaction or permissions. The researcher goes on to note that even without an Internet permission, he was able to use something called the URI ACTION_VIEW Intent to open a browser and export any collected data.
The researcher’s application was tested on Android 4.0.3 Ice Cream Sandwich and Android 2.3.5 Gingerbread.