问题 以编程方式更改Manifest - Android自定义权限


目前 Android权限系统会导致以下问题

App A定义了以下的自定义权限:

com.package.permission.READ_APP_DATA

当安装了应用程序B声明自定义权限时,它将被授予。

但是,如果安装了应用程序A.  应用B,然后权限是  授予应用B.

虽然这可能不常见,但由于应用程序B经常是应用程序A的插件,它当然可以发生并适用于我的应用程序。

随着SuperUser应用程序同意引入全球自定义许可 android.permission.ACCESS_SUPERUSER 如果用户决定切换SuperUser应用程序,这可能是一个大问题。

为了解决这个问题,我打算在我的应用程序中使用以下代码来获取我即将开始声明的自定义权限:

checkPermissions(this, getCallingActivity().getPackageName()); // get the package name from the sender first

private boolean checkPermissions(Context context, String callingPackage) {

    final List<PackageInfo> apps = context.getPackageManager().getInstalledPackages(PackageManager.GET_PERMISSIONS);

    for (PackageInfo pi : apps) {

        if (pi.packageName.equals(callingPackage)) {

            String[] permissions = pi.requestedPermissions;

            if (permissions != null) {
                for (String permission : permissions) {
                    if (permission.equals("com.package.permission.READ_APP_DATA")) {
                        return true;
                    }
                }
            }
        }
    }
    return false;

根据这个问题的标题:这种方法“安全”吗?或者是否有一种方法/ root-hack,应用程序的清单在安装后可以更改,并且以编程方式“添加”到应用程序B的权限?


8710
2017-09-02 12:19


起源

“但是,如果在应用B之后安装应用A,则不会向应用B授予权限。” - 有相同的 <permission> 两个应用程序中的元素,特别是如果这是一个 signature级别的权限。 - CommonsWare
“我相信这已经是我正在做的事情” - 你的问题表明只有App A才有 <permission> 元素,而App B只有一个 <uses-permission> 元件。我是说要添加 <permission> 元素到App B也是如此,因此安装顺序不再重要。 - CommonsWare
“尽管要求第三方开发人员以这种方式声明我的自定义权限,但感觉有点令人不安” - 正如我所说,当你使用的时候最好 signature级别权限,因此所有受影响的应用程序都是您的。许可系统的一个不幸的限制是,无论谁先进入,都可以定义权限的样子 给用户 (标签和说明)。但是,你无能为力。 - CommonsWare
关于你的技术,我从未见过有人那样做过。事实上,我原来的反应是它不会起作用,直到我意识到这一点 requestedPermissions 确实包括未授予的。鉴于此,我没有看到任何漏洞,但我认为我有同样的惶恐,导致你发布这个问题。 :-)如果没有别的,请确保你一直测试到你的 minSdkVersion因为这感觉就像Android的行为多年来可能发生变化的领域之一。 - CommonsWare
在Android L上声明两个应用程序中的自定义权限不再有效(您收到安装错误:INSTALL_FAILED_DUPLICATE_PERMISSION)。他们似乎已经关闭了这个漏洞(另见 commonsware.com/blog/2014/02/12/...) - Emanuel Moecklin


答案:


我不确定我是否正确地提出了这个问题,因为我不知道安装后如何通过黑客攻击清单连接到您上面发布的代码。但要回答你的最后一段:

不是一个简单的方法。用户必须在他的设备上安装mod,可以在应用程序请求时动态授予任意权限。 IIRC清单文件本身只是在安装时解析。

所以我们在mod中使用的是改变方法 grantPermissionsLPw 在班上 com.android.server.pm.PackageManagerService

它用于授予启动器权限 android.permission.EXPAND_STATUS_BAR它没有在清单中声明。

我不确定,如果这将用于您的应用程序。但总结一下:如果用户想要授予应用程序仲裁权,则自定义权限:是的,这是可能的。

UPDATE

当然,我可以详细说明一下。我可以看到两种情况发生

1.静态mod

上述课程所在地 services.jar。我们知道,这样的文件可以被反编译,修改和重新编译。实际上,这个文件很容易编辑。我不知道直接在手机上这样做的方法,但我认为这是可能的。由于需要大量的处理能力,所以可以使用广泛的解决方案,这是不可行的。攻击者不能只提供通用文件。这些文件在设备之间以及固件版本之间发生变化。或者,攻击者需要提供大量修补文件,或者通过将其上传到服务器,对其进行修补,重新下载和安装来实时修补。如果你问我,这种情况不太可能发生。

动态模型

有多个框架可用,允许在运行时更改流程。其中最受欢迎的是 Xposed框架。基本上,它是一个补丁 app_process 以及利用的相应API Reflection改变运行过程。现在攻击者可以使用此框架发布他的应用程序,并具有root访问权限,然后以静默方式安装它。通过root访问,他甚至可以自己启用模块,这通常需要用户交互。一旦启用了类似的模块,攻击者就可以挂钩上述方法并更改请求的权限。他会通过获取拥有所请求权限的对象字段,添加他需要的那个,然后运行原始方法来添加最初定义的权限。

请注意,这两种方案都要求用户自己安装恶意应用程序。你没有提到你的应用程序是什么,所以我无法真正帮助你评估风险。我只能说,攻击者可以做那样的事情。


9
2017-10-23 13:22



谢谢你的回答 - 你能详细说明这个mod如何运作吗?这有助于我理解“风险”。 - brandall
请参阅上面的更新。修正了班级名称。如果您还有其他问题,请随时提出。 - langerhans
感谢您的更新,它真的很有帮助,还有一些很好的链接阅读。我会回来标记你的答案是正确的,并奖励你为你的努力的恩惠。 - brandall


我确实看到一个问题,如果App A安装在App B和之前 <permission> 在App A中未声明元素,用户将永远不会看到权限请求。如果你确实需要使用 <permission> 但是,在App A中,可以使用类似的方法来验证向用户显示的标签和描述是否准确。


0
2018-02-10 04:46