|
Message
From: claudevms at comcast.net<claudevms@c...>
Date: Sun Mar 27 21:32:22 CEST 2005
Subject: [oc] Hardware and OS integration and security
The papers I have read online about preventing code injection via instruction set encryption have taken the initial step of encryption of the image on load. This would leave a program image unencrypted on the filesystem. I was proposing
encryption of the OS and all applications so they execute encrypted where the LUT in the hardware would decrypt the instructions at the last possible moment and out of sight of users. The papers I read also presented information about encrypting interpreted languages (e.g. Perl) and found that encryption worked
in this environment too. This may extend to Java, etc...
As for return to libc I felt that the forced decryption of any buffer overflow
would result in garbage and forces the application to terminate without a return
to libc.
-------------- Original message --------------
> Le mercredi 23 Mars 2005 10:10, RT a écrit :
> > Charlton Heston wrote:
> > > in the cache prior to execution of the instruction? If a processor
> > > had this capability every buffer overflow
> > > would get translated into garbage and not execute.
> >
> > How does it protect against buffer overflows? The overflow must contain
> > valid instructions or it would be of no use to the attacker.
> >
> > > The system owner
> > > could translate software
> > > based on the lookup table in the install process using tools that
> > > come with the operating system
> > > that executes in this environement. Disk space is cheap so a user
> > > could even use several
> > > encrypted versions of their favorite OS. Since no one knows the
> > > translation lookup table no viruses
> > > could execute on the computer. This would end the code and patch
> > > cycle. By the way this idea was patented
> > > in the 1970s but not for virus protection. Obviously, the computer
> > > owner must not install any viruses
> > > to protect her/his computer but other computers will not let it in
> > > the door or allow it to propagate
> > > across the network by using this approach.
> >
> > I can't see that this gives you any protection. You have to get your
> > software from somebody else, unencrypted. You then encrypt it yourself
> > on your machine. The attacker simply sends you unencrypted software,
> > like everybody else, and you encrypt it for yourself. It doesn't even
> > address HTML and JVM-type attacks.
>
> You could have a different encryption scheme. The encryption could only be
> done by the loader. Code injection can't work anymore. You could imagine a
> software way of incription and a hardware way of decription.
>
> That could even protect from code injection inside the "env" variable. But
> return into libc still work.
>
>
> _______________________________________________
> attachment.htm
|
 |
Browse
