Linked by Thom Holwerda on Wed 1st Jan 2014 19:11 UTC, submitted by jockm
Privacy, Security, Encryption

Remember when I wrote about how your mobile phone runs two operating systems, one of which is a black box we know and understand little about, ripe for vulnerabilities? As many rightfully pointed out in the comments - it's not just mobile phones that have tiny processors for specific tasks embedded in them. As it turns out, memory cards have microprocessors though - and yes, they can be cracked for remote code execution too.

Today at the Chaos Computer Congress (30C3), xobs and I disclosed a finding that some SD cards contain vulnerabilities that allow arbitrary code execution - on the memory card itself. On the dark side, code execution on the memory card enables a class of MITM (man-in-the-middle) attacks, where the card seems to be behaving one way, but in fact it does something else. On the light side, it also enables the possibility for hardware enthusiasts to gain access to a very cheap and ubiquitous source of microcontrollers.

There's so much computing power hidden in the dark.

Permalink for comment 579811
To read all comments associated with this story, please click here.
RE[3]: Interesting
by jockm on Fri 3rd Jan 2014 06:04 UTC in reply to "RE[2]: Interesting"
jockm
Member since:
2012-12-22

I just spend more time than I wanted reading datasheets so I could be sure about this.

The flash controller chips are not "translation layer[s] designed for FAT or NTFS". They are block level devices that support multiple page sizes based on the how the data is requested.

YAFFS Version 1 was based on a 512 byte block, because of assumptions of flash memory controllers at the time, but that 2002. YAFFS2 got rid of that assumption around 2003 or so.

Indeed if you look at the datasheet for the AX215 (http://www.appotech.com/dp/product/ax215) you will see it accomodates up to 8K blocks. This is true of the other flash memory controllers.

There is no reason to believe a posix file system is any more or less efficient on a flash memory controller. But I will add this: the reason error detection and correction is done at the controller level and not the driver level is so that the drivers do not have to know about every kind of flash memory, its structure, the number of banks, etc. Requiring drivers to be updated every time a SD card manufacturer wanted to tweak the internal design would only end in tears.

Reply Parent Score: 2