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

travis+ml-langsec at subspacefield.org travis+ml-langsec at subspacefield.org
Wed Dec 3 04:06:40 UTC 2014

On Tue, Dec 02, 2014 at 02:09:25PM -0500, matt wrote:
> As with many things that involve mechanical relays, there are safety
> concerns.  For one, rapidly toggling a relay can break it.  However, the
> risks can grow rather greatly in the case of something like a refrigeration
> condensor.  In the event someone were to compromise the refrigerators
> programming or otherwise induce a scenario of the relay closing the loop
> indefinitely, on many refrigeration units this could potentially cause
> irreparable harm to the condensor, and even potentially ( however unlikely
> ) start a fire.  There are hardware work arounds, which are a good and
> necessary safeguard, such as directly cutting power to the condensor based
> off of a thermal sensor and/or timer hardwired into the circuit and kept
> isolated from the programatic logic of the appliance.
> However, this raised a point.  Is there a way to isolate an area of code
> and ensure that it cannot be replaced, impeded, or otherwise changed in the
> carrying out of it's duties.  In short, in software is there a way to
> isolate the logic controlling the mechanical relays from any potential
> intruder?  I immediately thought of tpm as a potential vector to a
> solution, however no tpm on your average low power supporting MCU.

First thoughts are:

Python is a pretty good language to write that in, and you're probably
okay if the Web API cannot be abused (the OWASP Top 10).  However,
since Python loads the program into (RAM) memory and executes it, that
area is mutable and can bypass read-only program security (mentioned

Your biggest risk is going to be outdated platform.  In my experience,
embedded Linux is a PITA and you should really consider something very
popular like ARM-kirkwood (e.g. OpenRD) with a well-supported Linux
distribution (debian, arch, emdebian, gento, ubuntu), because your
trivially exploitable vulnerabilities will be in (for example) an
outdated OpenSSL library on the distro.  IOW, how long will it take
you to update OpenSSL if it has a major POODLE-style bug?  As a side
benfit, you're less likely to run into kernel bugs or boot loader bugs
that prevent your system from working entirely.

BTW, learn uBoot.  GRUB doesn't exist in embedded.

1) Your problem is the same problem the iphones have.  They don't want
   unauthorized manipualation of the radio unit, SMS, etc.  They use
   some complicated protection systems, including DEP, ASLR, and
   signed code updates.  It has undergone several revolutions; the
   first iPhone hacks had to do with a flaw in how the code update was
   handled in microcode.  Not all may be possible in a MCU, since it
   may not have a MMU.

2) Your problem is completely identical to the industrial control
   (SCADA) security problem, only significantly smaller.  You can
   probably read up on what they recommend; every recent DEFCON and
   BlackHat has at least one talk on this hot topic, and you can
   probably search SCADA security and visually grep for IOActive,
   iSecPartners, Cigital, Symantec, Neohapsis, and other security
   consulting firm names.

3) The Harvard architecture does not allow for software updates
   to program memory:

   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.

   IIRC, MIPS = no MMU.  ARM = MMU.  Anything else, probably none.

   But if you're running Unix there's probably no hope of this

4) You could use something like SELinux or RSBAC to limit what
   legitimate processes can do.  Totally bypassed by kernel bugs.

Basically, your defense for a von Neumann system is:

0) Hardware protection
1) Web Sec (OWASP Top 10 Defenses)
2) Updated platform
3) Process privilege limitation (e.g. SELinux) which 
   is totally bypassable with sufficient creativity,
   or an unpatched kernel bug.

Alternately, you could try a non-mutable program (OS?), but it seems
unlikely to be comptable with Unix.  There may be other kinds of unusual
setups that aren't feasible developemnt environments for you but would
solve it.
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/20141202/9d7d4982/attachment.sig>

More information about the langsec-discuss mailing list