Re: [Full-disclosure] Cisco IOS Shellcode Presentation

From: Tim (tim-security_at_sentinelchicken.org)
Date: 07/29/05

  • Next message: Geo.: "RE: [Full-disclosure] Cisco IOS Shellcode Presentation" 
    Date: Fri, 29 Jul 2005 15:53:56 -0400
To: Jason Coombs <jasonc@science.org>

    > How about adopting an architecture that incorporates special-purpose
    > security safeguards into the CPU? Routers and switches don't need to
    > execute arbitrary code, Cisco knows ahead of time, before they deploy a
    > product, what code that product should be allowed to execute.
    >
    > Do you think there is no way in hardware to limit the code that gets
    > executed? Maybe you should join the FBI.

    Hardware has bugs too.

    Arbitrary code execution isn't too hard on the XBox, for instance, even
    with complex crypto checks.

    Intel screwed up their design of hyperthreading with caches, and as a
    result, local users can steal data from one another.

    I think your broad suggestion is flawed. Perhaps the only reason we
    *don't* see as many hardware-based bugs, is that when you are getting
    ready to put something in hardware, you are generally more interested in
    getting it right the first time, given the production costs. The
    problem is, the mode of failure is astronmically worse, as you can't
    easily patch any problems that do crop up.

    On another note:
    The unfortunately common misconception that 'appliances' are safe
    because they are "hardware devices" really needs to go. Everything is a
    combination of hardware and software, and that's how it should be, from
    an engineering perspective.

    >From a security perspective, software should be viewed as a living thing
    that constantly needs feeding, whether it is on a funny-looking
    rackmount proprietary computer, in your mobile phone, or on your
    desktop.

    tim
    _______________________________________________
    Full-Disclosure - We believe in it.
    Charter: http://lists.grok.org.uk/full-disclosure-charter.html
    Hosted and sponsored by Secunia - http://secunia.com/

  • Next message: Geo.: "RE: [Full-disclosure] Cisco IOS Shellcode Presentation"

    Relevant Pages

    • Re: Relocating application architecture and compiler support
      ... to which the hardware adds all program addresses. ... >> the base register. ... user program code temporarily. ... > an option to execute a program when it was done, ...
      (comp.arch.embedded)
    • Re: Insufficient guarantees for null pointers?
      ... guaranteed to be portable and execute "as expected", ... performance on a wider variety of platforms. ... implementing it on existing hardware. ... defines a virtual machine, just two stacks. ...
      (comp.std.c)
    • Re: /lib/ld-2.2.4.so
      ... > user doesn't have the permission to execute, it is enough to have read ... security of your system on the inability of users to run arbitrary code ... arbitrary code (from various features of ld.so, to programs like gdb, to ... I mean programs whose vulnerabilities (and features) are "mostly ...
      (Vuln-Dev)
    • Re: Program protection - can not be copied
      ... User can not read the program, but how does the system can read and execute ... It seems that there is no any direct method to protect the program from ... If you need to "lock" the image on a specific hardware you'll have to ... (l'indirizzo di reply di questo messaggio non ?valido) ...
      (microsoft.public.windowsce.platbuilder)
    • Re: Insufficient guarantees for null pointers?
      ... guaranteed to be portable and execute "as expected", ... architectures the standard *could* impose more stringent ... Tribble said, "flat memory spaces, single pointer representations, and ... implementing it on existing hardware. ...
      (comp.std.c)