Changing this to a learning question.
How did Samsung or other vendors fix this vulnerability?
It's not as simple as formating the SD card and running a specially formatted apk?
Thanks for any information.
http://blog.cassidiancybersecurity.com/post/2014/06/Android-4.4.3,-or-fixing-an-old-local-root
Quote from their site:
"The vulnerability here is rather obvious: there is no check on the "id" variable, which is the name given by the user to its ASEC container. It is therefore possible to perform a basic path traversal, to create the ASEC file and its mount point in a different directory than expected, as for example one the "attacker" can write into.
The following code is then responsible for the creation of the mount point:
This means that if the mount point already exists, no error is raised, and the container is correctly mounted in "mountPoint". Guess what? If "mountPoint" already exists AND is a symlink to an existing directory, the ASEC container will be mounted over this directory. And the user will have full access to it, allowing him to write new files inside.
There are many ways of exploiting this vulnerability to gain root privileges.
Last detail about this vulnerability: it requires permissions to create ASEC containers. The "shell" user, as used by adb, has the requiered privileges. For the vulnerability to be exploited from an application, it needs the ASEC_* permissions (such as ASEC_CREATE)."
How did Samsung or other vendors fix this vulnerability?
It's not as simple as formating the SD card and running a specially formatted apk?
Thanks for any information.
http://blog.cassidiancybersecurity.com/post/2014/06/Android-4.4.3,-or-fixing-an-old-local-root
Quote from their site:
"The vulnerability here is rather obvious: there is no check on the "id" variable, which is the name given by the user to its ASEC container. It is therefore possible to perform a basic path traversal, to create the ASEC file and its mount point in a different directory than expected, as for example one the "attacker" can write into.
The following code is then responsible for the creation of the mount point:
Code:
if (mkdir(mountPoint, 0000)) {
if (errno != EEXIST) {
SLOGE("Mountpoint creation failed (%s)", strerror(errno));
if (cleanupDm) {
Devmapper::destroy(idHash);
}
Loop::destroyByDevice(loopDevice);
unlink(asecFileName);
return -1;
}
}
[...]
mountStatus = xxx::doMount(dmDevice, mountPoint, false,
false, false, ownerUid, 0, 0000, false);This means that if the mount point already exists, no error is raised, and the container is correctly mounted in "mountPoint". Guess what? If "mountPoint" already exists AND is a symlink to an existing directory, the ASEC container will be mounted over this directory. And the user will have full access to it, allowing him to write new files inside.
There are many ways of exploiting this vulnerability to gain root privileges.
Last detail about this vulnerability: it requires permissions to create ASEC containers. The "shell" user, as used by adb, has the requiered privileges. For the vulnerability to be exploited from an application, it needs the ASEC_* permissions (such as ASEC_CREATE)."
Last edited:
