A notion

A notion

[Justin R. Smith]

It occurred to me that custom versions of software can be more secure
than standard versions because various exploits (like stack smashing,
etc.) require precise knowledge of certain sizes and distances in RAM
(for instance, the distance from the end of a buffer to the return
point...).

Isn't it possible to develop a "randomizing C compiler" that randomly
varies these distances every time it compiles a program? No two compiles
of the same source code would be exactly the same (but they would
execute the same way).

This might involve inserting small random-sized blocks of dead code, or
doing returns from subroutines through a level of indirection (i.e.,
putting the actual return at some random location in the object code
with a branch to it).

Done right, this might not degrade performance significantly.


-- 


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: A notion

[Jose Nazario]

On 2 Oct 2001, Justin R. Smith wrote:

> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No two
> compiles of the same source code would be exactly the same (but they
> would execute the same way).

to the best of my knowledge morphing code, in a variety of fashions (stuff
that changes every time it compiles, every time it runs, while it runs) is
a hot topic of DARPA research right now. as such, look around various
sites doing research for DARPA and see who is doing what, publicly. a lot
of the technology may be hidden behind various closed doors (ie commercial
interests).

____________________________
jose nazario						     jose@cwru.edu
	      	     PGP: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
				       PGP key ID 0xFD37F4E5 (pgp.mit.edu)


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: A notion

[Phillip H. Zakas]

polymorphic code usually follows one (or a combo) of three paths: 1)
randomly insert NOPs into the code; 2) break codes into pieces (sort of like
objects) and randomize placement and use JMP commands to keep the code in
proper order; 3) develop a 'translation' mechanism and use tokens to
represent code instructions...as code is executed, the translation code
interprets and translates each token.  not sure this is completely on-topic
for SELINUX, but it does have application.

cheers-
phillip

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]On
> Behalf Of Jose Nazario
> Sent: Monday, October 01, 2001 5:36 PM
> To: Justin R. Smith
> Cc: selinux@tycho.nsa.gov
> Subject: Re: A notion
>
>
> On 2 Oct 2001, Justin R. Smith wrote:
>
> > Isn't it possible to develop a "randomizing C compiler" that randomly
> > varies these distances every time it compiles a program? No two
> > compiles of the same source code would be exactly the same (but they
> > would execute the same way).
>
> to the best of my knowledge morphing code, in a variety of fashions (stuff
> that changes every time it compiles, every time it runs, while it runs) is
> a hot topic of DARPA research right now. as such, look around various
> sites doing research for DARPA and see who is doing what, publicly. a lot
> of the technology may be hidden behind various closed doors (ie commercial
> interests).
>
> ____________________________
> jose nazario						     jose@cwru.edu
> 	      	     PGP: 89 B0 81 DA 5B FD 7E 00  99 C3 B2 CD 48 A0 07 80
> 				       PGP key ID 0xFD37F4E5 (pgp.mit.edu)
>
>
> --
> You have received this message because you are subscribed to the
> selinux list.
> If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: A notion

[Phillip H. Zakas]

that's not a bad idea, though the solution addresses a limited number of
attacks. you can insert, for Intel and Athlon-based machines, NOPs
(assembler for No Operation) to pad the code.  To randomize the
number/position of NOPs inserted one could use a perl script to identify
begin and end-points in a c program and have it insert the NOPs randomly
before compilation.  In the case of optimizing compilers you may have to use
dummy instructions such as SHL then SHR on some variable, or conditional
jumps leading to a NOP, etc.
phillip

> -----Original Message-----
> From: owner-selinux@tycho.nsa.gov [mailto:owner-selinux@tycho.nsa.gov]On
> Behalf Of Justin R. Smith
> Sent: Tuesday, October 02, 2001 4:43 AM
> To: selinux@tycho.nsa.gov
> Subject: A notion
>
>
> It occurred to me that custom versions of software can be more secure
> than standard versions because various exploits (like stack smashing,
> etc.) require precise knowledge of certain sizes and distances in RAM
> (for instance, the distance from the end of a buffer to the return
> point...).
>
> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No two compiles
> of the same source code would be exactly the same (but they would
> execute the same way).
>
> This might involve inserting small random-sized blocks of dead code, or
> doing returns from subroutines through a level of indirection (i.e.,
> putting the actual return at some random location in the object code
> with a branch to it).
>
> Done right, this might not degrade performance significantly.
>
>
> --
>
>
> --
> You have received this message because you are subscribed to the
> selinux list.
> If you no longer wish to subscribe, send mail to
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: A notion

[Javier]

For exploit buffer overflow you needn't know the distances you say, it helps
but it's not essential. Once you know (or suspect) the program is weak you
can try with differet sizes till you get the good one. If you want keep
yourself safe from this kind of exploiting, make sure that you control
buffer sizes. It is a simple and efficient method.

PD: Excuse my english but it is not my parent tongue.

----- Original Message -----
From: "Justin R. Smith" <jsmith@mcs.drexel.edu>
To: <selinux@tycho.nsa.gov>
Sent: Tuesday, October 02, 2001 10:42 AM
Subject: A notion


> It occurred to me that custom versions of software can be more secure
> than standard versions because various exploits (like stack smashing,
> etc.) require precise knowledge of certain sizes and distances in RAM
> (for instance, the distance from the end of a buffer to the return
> point...).
>
> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No two compiles
> of the same source code would be exactly the same (but they would
> execute the same way).
>
> This might involve inserting small random-sized blocks of dead code, or
> doing returns from subroutines through a level of indirection (i.e.,
> putting the actual return at some random location in the object code
> with a branch to it).
>
> Done right, this might not degrade performance significantly.
>
>
> --
>
>
> --
> You have received this message because you are subscribed to the selinux
list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
with
> the words "unsubscribe selinux" without quotes as the message.


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: A notion

[Conan Callen]

On Tue, 2 Oct 2001, Javier wrote:

I was wondering about the possiblity of moving the return addresses out of
the stack completely (even hashed & check summed so that its not a simple
matter of just writing a new return address over the existing one).
Im not a complier or assembler writer, but it seems that this should
be possible. Of course, as soon as it was made public exploits could be
immediatly developed.

> For exploit buffer overflow you needn't know the distances you say, it helps
> but it's not essential. Once you know (or suspect) the program is weak you
> can try with differet sizes till you get the good one. If you want keep
> yourself safe from this kind of exploiting, make sure that you control
> buffer sizes. It is a simple and efficient method.
>
> PD: Excuse my english but it is not my parent tongue.
>
> ----- Original Message -----
> From: "Justin R. Smith" <jsmith@mcs.drexel.edu>
> To: <selinux@tycho.nsa.gov>
> Sent: Tuesday, October 02, 2001 10:42 AM
> Subject: A notion
>
>
> > It occurred to me that custom versions of software can be more secure
> > than standard versions because various exploits (like stack smashing,
> > etc.) require precise knowledge of certain sizes and distances in RAM
> > (for instance, the distance from the end of a buffer to the return
> > point...).
> >
> > Isn't it possible to develop a "randomizing C compiler" that randomly
> > varies these distances every time it compiles a program? No two compiles
> > of the same source code would be exactly the same (but they would
> > execute the same way).
> >
> > This might involve inserting small random-sized blocks of dead code, or
> > doing returns from subroutines through a level of indirection (i.e.,
> > putting the actual return at some random location in the object code
> > with a branch to it).
> >
> > Done right, this might not degrade performance significantly.
> >
> >
> > --
> >
> >
> > --
> > You have received this message because you are subscribed to the selinux
> list.
> > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov
> with
> > the words "unsubscribe selinux" without quotes as the message.
>
>
> --
> You have received this message because you are subscribed to the selinux list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: A notion

[Russell Coker]

On Tue, 2 Oct 2001 10:42, Justin R. Smith wrote:
> It occurred to me that custom versions of software can be more secure
> than standard versions because various exploits (like stack smashing,
> etc.) require precise knowledge of certain sizes and distances in RAM
> (for instance, the distance from the end of a buffer to the return
> point...).
>
> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No two compiles
> of the same source code would be exactly the same (but they would
> execute the same way).

I have a better idea.  Use such a compiler for testing your code.  If the 
program you are testing doesn't behave the same way in different compiles (a 
large proportion of programs won't because they are buggy) then you debug it!

Many times I have seen companies ship code compiled in debugging mode because 
optimising mode of the compiler resulting in SEGV's.  Naturally they assumed 
it was a bug in the compiler not a bug in their code.  :(

As someone else mentioned there are a number of options for trying to make it 
more difficult to smash stacks, including a kernel patch from Solar Designer.

-- 
http://www.coker.com.au/bonnie++/     Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/       Postal SMTP/POP benchmark
http://www.coker.com.au/projects.html Projects I am working on
http://www.coker.com.au/~russell/     My home page


--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: A notion

[Stephen Smalley]

On 2 Oct 2001, Justin R. Smith wrote:

> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No two compiles
> of the same source code would be exactly the same (but they would
> execute the same way).

This thread is not germane to SELinux.  Please take it elsewhere.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

RE: A notion

[Tim Hollebeek]

I don't know if Crispin Cowan watches the selinux list, but this is
exactly the sort of thinking that inspired stackguard.  To paraphrase
a recent comment of his, it seems that whenever you investigate a method
of enhancing security using randomization, similar thinking will provide a
protection mechanism which will perform even better than the randomization.

> -----Original Message-----
> From: Justin R. Smith [mailto:jsmith@mcs.drexel.edu]
> Sent: Tuesday, October 02, 2001 4:43 AM
> To: selinux@tycho.nsa.gov
> Subject: A notion
> 
> 
> It occurred to me that custom versions of software can be more secure
> than standard versions because various exploits (like stack smashing,
> etc.) require precise knowledge of certain sizes and distances in RAM
> (for instance, the distance from the end of a buffer to the return
> point...).
> 
> Isn't it possible to develop a "randomizing C compiler" that randomly
> varies these distances every time it compiles a program? No 
> two compiles
> of the same source code would be exactly the same (but they would
> execute the same way).
> 
> This might involve inserting small random-sized blocks of 
> dead code, or
> doing returns from subroutines through a level of indirection (i.e.,
> putting the actual return at some random location in the object code
> with a branch to it).
> 
> Done right, this might not degrade performance significantly.
> 
> 
> -- 
> 
> 
> --
> You have received this message because you are subscribed to 
> the selinux list.
> If you no longer wish to subscribe, send mail to 
> majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
> 

--
You have received this message because you are subscribed to the selinux list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.