RE: How about digital signed binaries?

["Andreas Haug" <andreas.haug () this net>]

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.