On Tue, Apr 5, 2011 at 6:04 PM, Andrei Warkentin <[email protected]> wrote:
> On Tue, Apr 5, 2011 at 4:59 PM, John Calixto
> <[email protected]> wrote:
>> Some ACMDs might actually damage the card. This check ensures the
>> caller has CAP_SYS_ADMIN before allowing such an activity.
>>
>> Signed-off-by: John Calixto <[email protected]>
>> ---
>> drivers/mmc/card/block.c | 29 +++++++++++++++++++++++++++++
>> 1 files changed, 29 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index c2e107c..2ed8c57 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -31,6 +31,7 @@
>> #include <linux/mutex.h>
>> #include <linux/scatterlist.h>
>> #include <linux/string_helpers.h>
>> +#include <linux/capability.h>
>> #include <linux/compat.h>
>> #include <linux/delay.h>
>>
>> @@ -205,6 +206,34 @@ static int mmc_blk_ioctl_acmd(struct block_device *bdev,
>> goto acmd_done;
>> }
>>
>> + /*
>> + * The following ACMDs are known to be nondestructive. They are used
>> + * by SD security applications (ref: SD Specifications, Part 1,
>> + * Physical Layer Simplified Specification, Version 3.01, Table
>> 4-27).
>> + * Any other commands require CAP_SYS_ADMIN because they may destroy
>> + * the card.
>> + */
>> + switch (sdic.opcode) {
>> + case SD_APP_SD_STATUS:
>> + case 18:
>> + case 25:
>> + case 26:
>> + case 38:
>> + case 43:
>> + case 44:
>> + case 45:
>> + case 46:
>> + case 47:
>> + case 48:
>> + case 49:
>> + break;
>> + default:
>> + if (!capable(CAP_SYS_ADMIN)) {
>> + err = -EPERM;
>> + goto acmd_done;
>> + }
>> + }
>> +
>> cmd.opcode = sdic.opcode;
>> cmd.arg = sdic.arg;
>> cmd.flags = sdic.flags;
>> --
>> 1.7.4.1
>
> Hi John,
>
> Just to clarify, were the commands supposed to exclude commands that do
> writes?
>
> In MMC-land:
> CMD18 is PROGRAM_CID (which is a once-in-a-lifetime operation).
> CMD38 is erase
> CMD25 is write_multiple_block - this can give a non-root user full
> control over a disk, bypassing security.
>
> You should definitely check if the the target device is MMC or SD.
> Because the MMC and SD have slightly differing command sets.
>
> A
>
Let me clarify, this is what the MMC spec says:
The only effect of the APP_CMD is that if the command index of
the, immediately, following command
has an ACMD overloading, the non standard version will used. If,
as an example, a card has a definition
for ACMD13 but not for ACMD7 then, if received immediately after
APP_CMD command, Command 13
will be interpreted as the non standard ACMD13 but, command 7 as
the standard CMD7.
In order to use one of the manufacturer specific ACMD’s the host will:
* Send APP_CMD. The response will have the APP_CMD bit (new
status bit) set signaling
...
...
...
If a non valid command is sent (neither ACMD nor CMD) then it
will be handled as a standard
MultiMediaCard illegal command error.
This means, since an MMC card doesn't support ACMD25 or ACMD38, these
will be executed as CMD25 or CMD38. I.e. - it's an attack vector.
A
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
