[langsec-discuss] Isolating code for mechanical relay control ( request for ideas )

travis+ml-langsec at subspacefield.org travis+ml-langsec at subspacefield.org
Fri Dec 5 06:01:40 UTC 2014


On Tue, Dec 02, 2014 at 08:06:40PM -0800, travis+ml-langsec at subspacefield.org wrote:
> 3) The Harvard architecture does not allow for software updates
>    to program memory:
>    http://en.wikipedia.org/wiki/Harvard_architecture
> 
>    You might not be likely to find this in a MCU, but you might get a
>    close approximation by running out of ROM, or some kind of flash or
>    EEPROM that cannot be triggered from software.  Note that if it
>    caches ROM in RAM and it's a von Neumann architecture you've gained
>    nothing, but that was a 1980s/90s feature for slow ROMs, probably
>    not required with flash.
> 
>    Obviously the control over rewriting flash is something that has to
>    be audited.
> 
>    If you have any function pointers from RAM into ROM, such as an
>    interrupt table, that is an entry point that should be reviewed;
>    being able to "write void* anywhere" will allow one to overwrite
>    such a table, unless it is protected by MMU or like.

In retrospect, I was wrong.

Function pointer variables
Return into libc
Return-oriented programming

Ooops.

Still, as a defense in depth it might not be bad.

It just cannot be your only line of defense, you should fix the Web API bugs.

Anything that is legitimate use of Web API (logic flaws) will also not be
protected by anything technical - it's basically a design flaw.
-- 
http://www.subspacefield.org/~travis/
Split a packed field and I am there; parse a line of text and you will find me.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <https://mail.langsec.org/pipermail/langsec-discuss/attachments/20141204/dde180d2/attachment.sig>


More information about the langsec-discuss mailing list