Samsung S20 - Access External Storage Files
-
Ken Gannon
- Published: 26 Mar 2021
CVE-2021-25367
Share
Type
Severity
Affected products
Remediation
Credits
2021-11-03 | Notified Aruba Networks about the identified vulnerability |
2021-12-01 | Vendor acknowledged issue |
2022-03-02 | Vendor release fixed version |
2022-05-04 | Vendor publish advisory https://www.arubanetworks. com/assets/alert/ARUBA-PSA-2022-007.txt |
2022-05-23 | WithSecure publishes advisoryt |
F-Secure looked into exploiting the Samsung S20 device for Tokyo Pwn2Own 2020. An issue was discovered that would have allowed a rogue application to access any file on the external storage partition without the “External Storage” Android permissions.
Samsung Notes (com.samsung.android.app.notes) has an exported content provider called “clipdatacontentprovider” that can be used by other applications to download files from the external storage. The issue is due to the class “com.samsung.android.support.senl.nt.base.framework.provider.ClipDataContentProvider” having two methods “onCreate” and “addRoot”:
public boolean onCreate() { Context context = getContext(); addRoot(“external_files”, new File(Environment.getExternalStorageDirectory(), ”.”)); File[] externalFilesDirs = ContextCompat.getExternalFilesDirs(context, null); if (externalFilesDirs.length <= 0) { return true; } addRoot(“external-files-path”, new File(externalFilesDirs[0], ShareCacheHelper.CACHE_PATH)); return true; }
private void addRoot(String str, File file) { if (!TextUtils.isEmpty(str)) { try { mRoots.put(str, file.getCanonicalFile()); } catch (IOException e) { throw new IllegalArgumentException(“Failed to resolve canonical path for ” + file, e); } } else { throw new IllegalArgumentException(“Name must not be empty”); } }
The class relies on the hashMap “mRoots” to keep track of what the content provider’s root directories are. In the “onCreate” method, the external storage folder is added as an authorized root directory.
A rouge application installed on the same device can call this content provider to browse and download files from the External Storage area, bypassing the need to add “EXTERNAL_STORAGE_READ” or “EXTERNAL_STORAGE_WRITE” to the rouge application’s manifest. As an example, F-Secure utilized its Android testing application, Drozer, to exploit this issue. The screenshot below shows that Drozer did not have any additional Android permisions (right) and it could not read the file “/storage/emulated/0/yay.jpg” (top left). Meanwhile, the ADB user could read the file “/storage/emulated/0/yay.jpg” (bottom left):
Drozer’s “app.provider.download” module can be used to dynamically craft a proper content provider call and communicate with the vulnerable content provider. The below output shows Drozer downloading the file “/storage/emulated/0/yay.jpg” from the external storage using the vulnerable content provider:
dz> run app.provider.download content://com.samsung.android.app.notes.clipdatacontentprovider/external_files/yay.jpg /tmp/yay.jpg Written 1932151 bytes
dz> exit root@324bda543ccd:/# sha1sum /tmp/yay.jpg 1e29865dc1b592b06f87cd7d569f93170daa74ed /tmp/yay.jpg