Re: [ECOS] Re: Firewall in ecos

[Ross Younger <wry at ecoscentric dot com>]

ratheesh k wrote:
> I have seen  Many cable modems and Gateways (Routers ) running on ecos
> . There should be some other mechanism ???

I can't speak for whatever security evaluation or enhancements which vendors
of such devices may or may not have carried out. However I would point out
that so much depends on what you mean by "security"; what situations you are
worried about. Yes, the IP stacks are a bit crusty and probably liable to
DoS attacks and so forth [0], but these are of limited import when compared
with the more serious attacks such as one sees against computers on the
internet - which in the eCos world I think extremely rare, perhaps
negligibly so.

eCos enjoys a fair degree of security through its obscurity: it's not
usually running on an x86, so the vast overwhelming majority of canned
exploits [1] out there [2] just don't work; there is no shell [3]; code
injection is extremely hard [4] [5] [6] [7] [8] [9] without insider
knowledge of the application image running on a target (or through a
significant reverse engineering effort starting with a disassembler).

I conclude that a successful and meaningful code injection attack is
therefore not impossible, but the bar is an awful lot higher than you might
at first imagine. Given the magnitude of the task it's clear to me that the
average random attacker will not even bother; the hypothetical case of an
insider with sufficient information and skill to carry out such an attack is
probably impossible to defend against. This is not to say that we
*shouldn't* think about security within eCos, but we need to keep in mind
what's practical and worthwhile and what's not our problem to solve.

Reviewing and potentially hardening the IP stacks against denials of service
 (etc) would probably be worthwhile, though of course simply synching with
upstream more often would let us benefit from their efforts in this regard.
The small number of packages in the repository which provide network servers
and clients might also be worth reviewing, but of course this is to little
avail if you write a dynamic content generation function for the httpd which
turns out to be susceptible to a trivial buffer overrun...

Tarmo Kuuse wrote:
>> Encryption is not supported, although there is some unofficial port
>> of OpenSSL - does that even work? Etc.

Gathering cryptographic-grade entropy on an embedded device is an extremely
difficult problem without some sort of hardware assistance (noisy diode
circuit, floating ADC input, etc). Many crypto protocols rely on having
access to a good supply of random numbers; violate their design assumptions
and all they provide is a dangerously insidious "security blanket" sort of
effect which you cannot rely on to meet its security goals.


[0] The eCos IP stacks are of different codebase to the various Microsoft IP
stacks with all their woes over the past 16 years, so will presumably
exhibit resistance to MS-targetted attacks such as the infamous win95
ping-of-death. I don't know how typical current DoS tools are targetted, but
given the vast population of MS IP stacks connected to the 'net it wouldn't
surprise me if they only contained attacks for the popular OSes. A modicum
of security is perhaps derived through being part of a tiny population
hidden in a haystack of IP stacks for which more vulnerabilities are widely
known?

[1] by "exploit", I mean something which does more than just crash the
target. Remote code execution which might let one install a rootkit to come
back later; packet sniffing; eggdrop and similar bots; traffic forwarding;
perversion of any network-based services legitimately running on the target.

[2] I'm thinking of remote shellcode and similar code injection types of
attacks.

[3] So what was your shellcode hoping to achieve anyway? (Unless the device
manufacturer has written one, but even so it may not be very functional.)

[4] So at this point you're not writing or reusing existing shellcode, you
have to write customised attack code for the processor. Well ...

[5] ... Every build of eCos is effectively customised so the in-memory
addresses of handy library functions which you might call could be quite
difficult to predict.

[6] As everything runs with the CPU in privileged (kernel) mode, there is no
real syscall interface, so that source of useful routines isn't available
either. While there are the fixed and virtual vector interfaces, they're
very tight (not to mention being architecture-specific?) and I don't think
you can achieve anything relevant with them.

[7] Also, as you're running in privileged mode, if you slip up with your
hypothetical carefully crafted attack code, you don't just crash (e.g.) a
web server process; the whole CPU traps and (typically) everything comes to
a crashing halt. Eventually the user will no doubt notice and power cycle.

[8] Unlike on a desktop OS, you won't find a raft of handy utilities
present. The link-time garbage collection process means that if an eCos
application doesn't use (e.g.) code which writes to the flash, such code is
simply not present in memory.

[9] So even if you do successfully inject code to remotely take over the
device, how do you make it persistent? I would suggest that most
eCos-powered devices have no hard drive nor flash filing system [10] so in
order to make a permanent change you'd have to figure out how the processor
was booting, what the flash format was and how to write to it without
bricking the device ... and you might not even be able to make changes if
the device requires a physical jumper to be set or switch to be flipped in
order to supply the correct programming voltage to the flash part!

[10] Compare and contrast with e.g. the jffs2-based root filesystem found on
OpenWRT (Linux-based) on various models of domestic router.

(Sorry for the footnote-fest...)


Ross

-- 
Embedded Software Engineer, eCosCentric Limited.
Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK.
Registered in England no. 4422071.                  www.ecoscentric.com

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss