[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
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
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
Size: 834 bytes
Desc: not available
More information about the langsec-discuss