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

Alex Kropivny alex.kropivny at gmail.com
Wed Dec 3 15:34:24 UTC 2014

Hash: SHA512

As a rule, sandboxing code within a low cost microprocessor is hard/"interesting". There are fun avenues to experiment in (minimal VM/Forth/interpreter with guarded memory access primitives, or an nacl equivalent, or something with OTP ROM) but they are all standalone projects, not week long hacks you can embed into another project.

To get an idea of the effort these techniques require, see:

1. the prevalence of feature creep in sandbox VMs, leading to easy escapes via peek/poke primitives being provided or low quality exploitable code attached.

2. the work that was put into testing nacl for unforeseen instruction edge cases, in addition to and outside of the analysis that the initial proof of safety covered.

3. Various public bypasses of manufacturer IP-protection sandboxes, like trustzone or the AVR BootJacker hack (which involves ROP with a clock-cycle granular return via a hardware timer interrupt.) BootJacker is an example that breaks most low end IP protection schemes that block memory reads from outside the region but allow jumps.

In short, in-processor sandboxing is a fun topic. *However, for getting work done, you are better off drawing a security boundary outside the processor.*

A low cost processor implementing a simple protocol (that does not include remote code exec/firmware upgrade functionality!) can be a *very* hard target remotely.

Local access to the chip will always result in code exec. However, if you're trying to protect a condensor from damage, local access with a crowbar would result in worse. Против лома нет приема!

On December 2, 2014 8:06:40 PM PST, travis+ml-langsec at subspacefield.org wrote:
>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,
>> risks can grow rather greatly in the case of something like a
>> condensor.  In the event someone were to compromise the refrigerators
>> programming or otherwise induce a scenario of the relay closing the
>> indefinitely, on many refrigeration units this could potentially
>> irreparable harm to the condensor, and even potentially ( however
>> ) start a fire.  There are hardware work arounds, which are a good
>> necessary safeguard, such as directly cutting power to the condensor
>> off of a thermal sensor and/or timer hardwired into the circuit and
>> isolated from the programatic logic of the appliance.
>> However, this raised a point.  Is there a way to isolate an area of
>> 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
>> 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:
>   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.
>   IIRC, MIPS = no MMU.  ARM = MMU.  Anything else, probably none.
>   But if you're running Unix there's probably no hope of this
>   working.
>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
>setups that aren't feasible developemnt environments for you but would
>solve it.
Version: APG v1.1.1


More information about the langsec-discuss mailing list