[AusNOG] (bad) cyber security and ideas coming out of thewoodwork?!

[phil colbourn]

It may seem magical, but it is very simple: From memory, native client 'safe
code' means the following:

1. a subset of instructions are legal.
2. all instructions are 32-byte aligned (yes, that is 32-byte aligned - lots
of nops in between)
3. all jumps must be to 32-byte aligned memory spaces
4. all indirect jumps must follow a pattern: something like load the address
into a certain register immediately followed by a 'and' opcode to mask the
low 5 bits to force the address to 32-byte alignment, immediately followed
by a indirect jump.
5. all calls must be implemented as a push 32-byte immediate return address
followed by a jump as above.
6. all systems calls must pass through an system API call which is well
defined.

(I should look it up first, but the above about covers it)

'safe code' complies with the rules. Code that tries to leave the sandbox
gets halted. Code that tries to use an invalid API call is halted. Code that
tries to jump to a non-32-byte aligned instruction gets halted.

For ARM it is much simpler since all instructions are 32 bit aligned (not
sure how thumb-mode is handled - my guess is that it isn't allowed).


On Fri, Jun 25, 2010 at 7:00 AM, Richard Pruss <ric at cisco.com> wrote:

> Yea, I have also been following this from the GoogleIO talk etc. I feel
> your key point 2 is seriously magical.
> Especially for any program of less than trivial size - think of something
> like AutoCad with a few million lines of code.
>
> Earlier on this thread someone pointed out the more people a platform gets
> the more it becomes a target, but also the
> more features there are on a platform or program on the target there is.
>
> That said I do not want to belittle the steps they are taking forward it is
> very interesting stuff.
>
> On 24/06/2010, at 7:47 PM, phil colbourn wrote:
>
> I have been following Google's Chrome OS. It seems to me that they have
> decided to tackle the problem in a different way: by eliminating the problem
> of malware, vulnerabilities and buggy code.
>
>
> The key points as I see it:
>
> 1. No app gets installed. The OS is a minimal image that has many ways to
> verify that it is sound. All other software is downloaded and cached. The OS
> itself is probably a native client app itself running on a small VM manager.
>
> 2. Strictly allow only native x86/ARM code that can be verified safe.
>
> 3. Run native code in a sandbox with limited access to system resources -
> basically none.
>
>
> These and other measures seem to solve the hardware/software security
> issues. To reduce the risk of social attacks they
>
> 5. Actively monitor sites for malware activity and highlight in searches.
>
> 6. Increasingly encourage SSL services.
>
>
> This does not solve the server issue, so they
>
> 7. Push Software as a Service and Platform as a Service to eliminate poorly
> secured servers and OSs.
>
>
> I think this sort of approach is the future of computers and servers. It is
> notable that their approach does not rely on trusted compiler tool chains,
> signed code (except for the boot loader I think) and malware scanners.
>
> --
> Phil
>
> http://philatwarrimoo.blogspot.com
> http://code.google.com/p/snmp2xml
>
> "Someone has solved it and uploaded it for free."
>
> "If I have nothing to hide, you have no reason to look."
>
> "Any sufficiently advanced technology is indistinguishable from magic."
> Arthur C. Clarke - Who does magic today?
>
>  _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>
>
>


-- 
Phil

http://philatwarrimoo.blogspot.com
http://code.google.com/p/snmp2xml

"Someone has solved it and uploaded it for free."

"If I have nothing to hide, you have no reason to look."

"Any sufficiently advanced technology is indistinguishable from magic."
Arthur C. Clarke - Who does magic today?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20100625/a0334bbb/attachment.html>