Xprivacy is leaking complete storage - even when access denied

[T-vK]

I just found out that even if you restrict access to the whole Storage category, apps can still access/read/write/modify any files/folders they want.
That includes the folders that hold all of my Photos, Videos, WhatsApp messages/media, Music, .... basically just everything.

Please tell me this is a bug and not expected behavior.

Leaking my location is one thing... but leaking all my data that I have stored is 1000 times worse.

[M66B]

First of all please read the support section on GitHub.

Did you restart the applications?

[T-vK]

Yes, I read the whole readme at some point.
If you want details:

My default template restricts everything [X] [?].

Reproduce with "Simple Explorer":

• Install it, whitelist IPackage:getPackageInfo, deny everything else. It will be able to access the file system.

Reproduce with "QPython":

• I installed QPython.
• I manually enabled the inet restriction because Xprivacy doesn't create a prompt for that (another bug btw?)
  -When it asked for IPackage:getPackageInfo, I whitelisted that.
  -I denied every other permission.
  -I went into the Editor of QPython
  -I clicked the icon to save the script

I was able to save my script wherever I want and I was also able to delete any files... and everything happened within QPython.

Note: QPython does complain there is no SD Card, but you can ignore that message and access it anyway.

https://f-droid.org/repository/browse/?fdid=com.dnielfe.manager
https://github.com/qpython-android/qpython

[M66B]

Please read the support section again. In short: first ask on XDA before reporting a bug.

[M66B]

Did you also restrict the dangerous restrictions, especially 'sdcard' and restarted the applications?

[T-vK]

Yes. As I said my 'default template' automatically restricts everything including the ones with a red background (including sdcard). So the restrictions are applied before newly installed applications start for the first time. But yes I also restarted the applications. The result was always the same.

Btw I should mention that I don't have a physical sdcard in my phone. I have the /storage/emulated/0 directory which is the emulated sdcard from what I understand. That's also the directory that all apps can recursively access btw.

[M66B]

Which device? Which Android version? Which Xposed version?

[walrus543]

Nexus 5 - Android 6.0.1 - Xposed v86 - XPrivacy 3.6.19
All access from Storage are denied.
Tested with another file manager (MiXplorer).

[T-vK]

Device: OnePlus One
Android version: 6.0.1 (CyanogenMod 13.0-20160819)
Xposed version: 3.0 alpha4

@Primokorn

All access from Storage are denied.

Do you mean that the access is actually denied now or do you mean that you denied it with Xprivacy, but MiXplorer can access it anyways?

[walrus543]

The latter.
I recorded a video for another issue but you can see the Storage category.
MiXplorer can still create files and folders.

[M66B]

To diagnose this problem I need to see a logcat captured from your PC using ADB, started before you turn the device on.

[walrus543]

If @T-vK can't do it, I'll record a logcat tomorrow.

[T-vK]

I've never done this before, but I'll try in about 1-2 hours.

Is this how I would have to do it?

1. turn off my phone
2. connect my phone to the computer
3. run adb logcat -f /storage/emulated/0/logcat.log
4. start my phone
5. copy the log

[walrus543]

See FAQ: https://github.com/M66B/XPrivacy#FAQ14

[T-vK]

Okay, I think it worked. I'm currently going through the log manually to make sure that I'm not posting private information online. It will take a while until I went through all 20000 lines.. :/

[T-vK]

Here's the logcat:
https://github.com/T-vK/temp/blob/master/log.zip?raw=true

I removed some private information and a few ids and marked the lines in which i did so.

I started the log when the phone was off. Then I started the phone and opened simple explorer and opened a directory.

[M66B]

I am traveling the next four weeks, after that I will take a look. Remind me if I forget it.

[Toufukun]

I have this problem too on CM13 (Android 6.0.1) with Xposed v87 and XPrivacy 3.6.19 (481). I've been a XPrivacy user and I found storage restrictions won't work on Marshmallow. When an app accesses the internal storage (sdcard), XPrivacy won't prompt open function like before. In XPrivacy app, the timer near the function name (like 'open (x minutes ago)') won't show or refresh. There's even no orange '!' near the function name.

[kaizokan]

For me it does work. I'm on:
KitKat 4.4.2 - Stock Samsung (cleaned)
Xposed 2.6.1
XPrivacy 3.6.19 (481)
Simple Explorer 2.3.1 (xda apk version, used only to test, since I do not use Simple Explorer myself)

[T-vK]

@kaizokan Can you confirm that it is actually Xprivacy blocking the access? For instance by disabling the restriction temporarily.

[Toufukun]

@kaizokan @T-vK I think it's a Marshmallow-only problem. (Nougat may have this too if Xposed get compatible with Nougat.)

[kaizokan]

@T-vK I already did that.
@Toufukun Yeah maybe. I just wanted to let know that on my software it works, to narrow down the cause of the problem. but if its already sure that its only marshmallow and above then nvm ; )

[M66B]

@T-vK please provided another logcat with XPrivacy debugging enabled.

[M66B]

My best guess is that is that these three gids needs to be revoked as well too:

https://android.googlesource.com/platform/system/core/+/master/include/private/android_filesystem_config.h#126

If somebody want to try this, here is the relevant code:

https://github.com/M66B/XPrivacy/blob/master/src/biz/bokhorst/xprivacy/XProcess.java#L91

[Magissia]

Was able to reproduce leak with Fx on ASUS ZenFone 2 Laser running 6.0.1 in compatibility mode.

Used Fx to explore user's root media directory and deleted successfully an APK file.
XPrivacy doesn't report any usage of open for Fx.

[Toufukun]

I know nothing about lower levels of Android, but I have to say it doesn't only involve media files. In Lollipop, I can restrict apps open their data and log files in the internal storage. And when office app reads my doc documents, XPrivacy will show too. That's nearly all types of file. (I just can't stand those messy folders created by ad SDKs. I know XPrivacy is only for privacy, but these restrictions does work.)

I think it's not about compatibility mode. XPrivacy runs in compatibility mode on my Lollipop system and it works well.

[ghost]

This problem do exist in Android 6.0, as I confirmed it just now.

Device: Asus Zenfone 2

OS: CyanogenMod 13 latest nightly (20161219)

Xposed: Latest (v87, API 23)

Procedure:
1.Turn on all debug/logging settings in XPrivacy
2.In XPrivacy, set the storage permission of an app (I used Plus Messenger as an example) to 'ask' (show as question marks in checkboxes).
3.Open the Plus Messenger app and try to send a file.
4. XPrivacy will ask for the 'getExternalStorageState' permission but will NEVER ask the 'open' permission.
5.As a result, browsing files in the in-app file explorer is fully unrestricted.

Screenshots:
https://goo.gl/photos/bCkoNstktikfXgZU8

Logcat file:
https://drive.google.com/file/d/0B2eNTCyy3IPQVFRoM1hHYzFvUlE/view?usp=drivesdk

Thanks!

[c33s]

@M66B any chance of fixing this? i thought about crowdfounding a bounty, would that be something where you can invest more time in your awesome app? how high should it be? any good sites for that?

[M66B]

@c33s this has already been discussed on XDA, so please check the XDA XPrivacy thread.

[c33s]

do you mind posting the answer here or link it here? the thread has over 1789 pages.

[M66B]

XDA has a search function. Search for crowd funding. It are recent discussions, so reading back some pages is an option as well.

[Fury22]

I think a major confirmed year-old bug such as this really needs to be fixed and given priority. It's the whole point of XPrivacy. Lack of confidence in one app may lead to loss of confidence in another.

[M66B]

@Fury22 you are welcome to fix this problem, else please read what I have written already several times about updates in the XDA forum.

[8alucard8]

True, unfortunately :(

…

________________________________ Von: Fury22 <[email protected]> Gesendet: Freitag, 18. August 2017 01:56 An: M66B/XPrivacy Cc: Subscribed Betreff: Re: [M66B/XPrivacy] Xprivacy is leaking complete storage - even when access denied (#2388) I think a major confirmed year-old bug such as this really needs to be fixed and given priority. It's the whole point of XPrivacy. Lack of confidence in one app may lead to loss of confidence in another. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#2388 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AWP-GYPMT5nY_ziwycFITclQ67UjR_8Kks5sZO80gaJpZM4K6guw>.

[Fury22]

Unless you're speaking to another developer, telling anyone who wants a bug fix to go fix it themselves is just being saucy. If no more updates are forthcoming then you should close this issue again "because... reasons".

As for others who'll end up here in the future, searching for a ROM with a built-in permission manager is now the better and more reliable and the only option - unless you're fine with a false sense of privacy.

[M66B]

XPrivacy is a community project and therefore my comment is not saucy in any way.

This issue stays open for this reason too, because maybe someday somebody is going to work on it. It won't be me though.

[8alucard8]

Btw I am a dev myself and I can say with an absolute certainty, that I would be proud to one day update it to absolute compatibility and efficiency. (assuming I have enough time :P) This program is too powerful to die. At least find a motivated open source team to pass it to. Please. And also tausend Dank again for everything you have done so far :) 🥇

[M66B]

@8alucard8 if "This program is too powerful to die", then do an effort to find a "motivated open source team to pass it to" yourself and don't leave this to others.

I have done more than my share, but it seems that nobody else is willing to do anything.

[8alucard8]

Ok