A vulnerability leak in your mailbox all the secrets-vulnerability warning-the black bar safety net

ID MYHACK58:62201680257
Type myhack58
Reporter 佚名
Modified 2016-10-17T00:00:00


Google recently announced a 2 0 1 6 years 1 0 months of Nexus Security Bulletin, which includes a 3 6 0 mobile Guard Alpha team(Alpha Team)to submit e-mail information disclosure Vulnerability, CVE-2 0 1 6-3 9 1 8, The Google of this vulnerability is rated high risk level. The vulnerability can lead to a malicious application access to the e-mail within the data may be email content, email attachments and even the account password. Currently Google has patched the vulnerability and to the OEMS to push the patch, this article will for this vulnerability analysis. Herein, the test environment and code version are as follows: SDK Version: 2 3, Android 6.0.1 Build: MOB30Y Branch: android-6.0. 1_r60 Vulnerability causes In Android AOSP Email app source code, 我们可以看到在AndroidManifest.xml the file exists in the named AttachmentProvider the ContentProvider is. android:name=". provider. AttachmentProvider" android:authorities="com. android. email. attachmentprovider" android:grantUriPermissions="true" android:exported="true" android:readPermission="com. android. email. permission. READ_ATTACHMENT" /> Its main properties are as follows: exported true that is open to the public authorities com. android. email. attachmentprovider that the URI uniquely identifies the readPermission com. android. email. permission. READ_ATTACHMENT that read need this permission By query we can learn to com. android. email. permission. READ_ATTACHMENT permission of the protectionLevel is dangerous, you can be a third party app to get. android:name="com. android. email. permission. READ_ATTACHMENT"android:permissionGroup="android. permission-group. MESSAGES"android:protectionLevel="dangerous"android:label="@string/permission_read_attachment_label" android:description="@string/permission_read_attachment_desc"/> In determining this ContentProvider can be a third-party application contact to after we positioned AttachmentProvider the source code. The source path is as follows: /packages/apps/Email/provider_src/com/android/email/provider/AttachmentProvider.java By reading the source code we can find AttachmentProvider implements a public openFile interface, the interface will return a ParcelFileDescriptor object type for the caller to open the file. public ParcelFileDescriptor openFile(Uri uri, String mode) throws FileNotFoundException { Into the openFile interface will immediately determine the mode value is "w", if w returns a writable file descriptor. But before returning, the function of the implementation code for the permission check if the caller does not have com. android. email. permission. ACCESS_PROVIDER permission, it would throw an exception. And this permission statement are as follows: android:name="com. android. email. permission. ACCESS_PROVIDER" android:protectionLevel="signature" android:label="@string/permission_access_provider_label" android:description="@string/permission_access_provider_desc"/> You can see the permissions is not a third-party application access to, so can get write permissions is not feasible. Continue to analyze the code. List segments = uri. getPathSegments();String accountId = segments. get(0);String id = segments. get(1);String format = segments. get(2);if (AttachmentUtilities. FORMAT_THUMBNAIL. equals(format)) { int width = Integer. parseInt(segments. get(3)); int height = Integer. parseInt(segments. get(4)); ...}else { return ParcelFileDescriptor. open( new File(getContext(). getDatabasePath(accountId + ". db_att"), id), ParcelFileDescriptor. MODE_READ_ONLY);} The next series of code will be from the uri. getPathSegments (). split different fields, and read from the corresponding configuration parameters. When the format parameter is not equal to"THUMBNAIL", the code will directly return a getDatabasePath()this directory is named the id of the file's file descriptor. While the id parameter is above from the uri. getPathSegments(). get(1) Get, get after it without any processing. uri. getPathSegments()method is the role of the string to"/"for division, but since its not through the url encoded string is decoded, resulting in process, for/after encoding the%2f will not do the processing, bypassing the getPathSegments segmentation. Exploit According to the above for our code analysis, we can draw AttachmentProvider the uri as follows: content://accountId/id/format/width/height If we want to exploit this loophole to read data, so that the program flow can be run successfully to the target location, the need to construct the following uri content://com. android. email. attachmentprovider/1/file_position/1/1/1 Moreover, getDatabasePath()directory is/data/user/0/com. android. email/databases/, if we want to read Email data, you'll need to jump to the target directory/data/data/com. android. email/to read the Email application's sqlite database file, we need to construct the following uri: content://com. android. email. attachmentprovider/1/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fdata%2Fdata%2Fcom. android. email%2Fdatabases%2FEmailProvider. db/1/1/1 While the EmailProvider. stored in a db. we have a login account name and password, the corresponding structure to HostAuth table for the login and password fields. We constructed the PoC screenshot as follows: !

Summary Thus, the CVE-2 0 1 6-3 9 1 8 vulnerability analysis and utilization has been completed. After our test, currently more mainstream mobile phone models that comes with the e-mail client are the existence of the problem, such as the mi NOTE, Huawei P9, Samsung S5 and other models, in order to account security, please use the loopholes in the mobile phone of the user to suspend the use of the e-mail client and clear the account information, change to another mail client.