From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1457 invoked by alias); 4 Dec 2009 11:49:22 -0000 Received: (qmail 1446 invoked by uid 22791); 4 Dec 2009 11:49:21 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_20,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 04 Dec 2009 11:49:05 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 24CD12F78006 for ; Fri, 4 Dec 2009 11:49:03 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FScd+mQoMM6y; Fri, 4 Dec 2009 11:49:01 +0000 (GMT) Message-ID: <4B18F72B.3030204@ecoscentric.com> Date: Fri, 04 Dec 2009 11:49:00 -0000 From: Ross Younger User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: ecos-discuss@sources.redhat.com References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: Firewall in ecos X-SW-Source: 2009-12/txt/msg00012.txt.bz2 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