IDS: RE: How about digital signed binaries?

[Andreas Haug <andreas.haug@this.net>]

    [ The following text is in the "iso-8859-1" character set. ]
    [ Your display is set for the "US-ASCII" character set.  ]
    [ Some characters may be displayed incorrectly. ]

Archive: http://msgs.securepoint.com/ids
FAQ: http://www.ticm.com/kb/faq/idsfaq.html
IDS: http://www-rnks.informatik.tu-cottbus.de/~sobirey/ids.html
HELP: Having problems... email questions to ids-owner@uow.edu.au
NOTE: Remove this section from reply msgs otherwise the msg will bounce.
SPAM: DO NOT send unsolicted mail to this list.
UNSUBSCRIBE: email "unsubscribe ids" to majordomo@uow.edu.au
-----------------------------------------------------------------------------

> From: Vinmcius da Silveira Serafim
[...]
> So I've been
> thinking on a server that just executes signed binaries, and I want hear
> you about that...

Not really a new idea. Check for example http://www.securebsd.org/

> When we root any server, in most cases, we compile some toolz and
> execute them, deploy some trojan binaries, etc... How about if you got
> in a server and you cannot execute any of your tools or change the
> binaries?

Someone might break a box with just using what is on the box. However, 
wouldn't it be a good idea to have sh/csh only run signed scripts and/or 
signed command lines?

This would be fun. Imagine someone uses a buffer overflow to root a box. He 
succeeds and gets back a shiny '#' prompt. Now he types something, but 
instead of executing, the shell says "No signature found on given command. 
Administrator has been notified. Your session will be terminated. Thanks for 
trying". 

Instead of signing scripts, you could write a preprocessor which would turn 
any script into a script in which the lines are signed.

Bonus points:

- Implement a 'run this program bug don't check the args' mode (dangerous, 
but perhaps needed)

- Implement it in the kernel (exec call, see footnote).

- Build a working system which is tied down using this approach

But perhaps this idea is flawed, too (I am still suffering a headache caused 
by a jetlag of 9 hours. The downside of attending BlackHat/Defcon...). 

Thinking about it: An attacker could code everything in the payload and not 
use exec at all... So this solution wouldn't be very effective. On the other 
hand, it would stop those who can't write their own 'shellcode'...

Ultimate Idea:

Signed syscall programming. Require every syscall to include 

        (1) a bitmask showing which of the parameters 
            are fixed and which are variable
        (2) a signature authorizing the use of the
            syscall with the given (code, mask, fixed) parameters

Thinking more: Wouldn't it be nice to have 'blessed' non-root binaries?

        mybox# bless httpd
        bless> allow bind
         Enter domain [PF_INET]: PF_INET
         Enter type [SOCK_STREAM]: SOCK_STREAM
         Enter IP address, use ANY for allowing bind to any [ANY]: 1.2.3.4
         Enter port: 80
        bless> sign
         The current blessings are:
                Bind a tcp stream at address 1.2.3.4 port 80
         md5 for blessings is d8e8fca2dc0f896fd7cb4cb0031ba249
         Enter signature for the above md5: 88354053212d6f123f8313f6d3baa266
         Verifying signature: ok.
         Thank you. Signature has been noted.
        bless> save /usr/local/bin/httpd-blessed
         Saving to /usr/local/bin/httpd-blessed. Done.
         md5 for new file is: 01adc9c2bc3ea6c6300b93cef9e17e0c
        bless> quit

Now you could run httpd as nobody.

But wait: Doesn't this look an awful lot like a trusted-os? ;-)

andreas.

Footnote: The signature should include the name (really? Perhaps the md5 of 
the executing image would be better) of the calling process. Imagine: Named 
could only exec named-xfer because it lacks the signature to exec anything 
other.