12

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

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

com.package.permission.READ_APP_DATA

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

但是,如果应用 A 是在应用 B 之后安装,则权限不会授予应用 B。

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

如果超级用户应用程序同意引入全局自定义权限,android.permission.ACCESS_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 后对其进行更改?

4

2 回答 2

10

我不确定我的问题是否正确,因为我不知道安装后如何将权限侵入清单连接到您在上面发布的代码。但要回答你的最后一段:

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

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

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

不过,我不确定这是否会用于您的应用程序。但总结一下:如果用户想授予应用程序任意权限,自定义权限:是的,这是可能的。

更新

当然,我可以再详细一点。我可以看到两种情况发生

1.静态模组

上面提到的类位于services.jar. 众所周知,像这样的文件可以被反编译、更改和重新编译。实际上,对这个文件进行相当简单的编辑。我不知道直接在电话上执行此操作的方法,但我认为这是可能的。只是不那么可行,因为它需要大量的处理能力,所以可以使用广泛的解决方案。攻击者不能只提供通用文件。这些文件因设备而异,也因固件版本而异。要么,攻击者需要提供大量已修补的文件,要么通过将其上传到服务器、修补、重新下载和安装来实时进行修补。如果你问我,这种情况不太可能发生。

2.动态模组

有不止一个框架可用,它们允许在它们运行时改变进程。其中最受欢迎的是Xposed 框架。基本上,它是一个修补app_process的和相应的 API,Reflection可以用来改变正在运行的进程。现在攻击者可以使用这个框架发布他的应用程序,并拥有 root 访问权限,静默安装它。有了root权限,他甚至可以自己启用模块,这通常需要用户交互。一旦启用了这样的模块,攻击者就可以挂钩上述方法并更改请求的权限。他将通过获取包含请求的权限的对象字段来执行此操作,添加他需要的那个,然后运行原始方法,该方法添加了最初定义的权限。

请注意,这两种情况都需要用户自己安装恶意应用程序。您没有提及您的应用程序的用途,因此我无法真正帮助您评估风险。我只能说,攻击者可以做这样的事情。

于 2013-10-23T13:22:57.617 回答
0

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

于 2014-02-10T04:46:30.047 回答