On Tue, Dec 02, 2014 at 08:06:40PM -0800, travis+ml-lang...@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.
pgpRauaKhgnx6.pgp
Description: PGP signature
_______________________________________________ langsec-discuss mailing list langsec-discuss@mail.langsec.org https://mail.langsec.org/cgi-bin/mailman/listinfo/langsec-discuss
