|
Message
From: Nicolas Boulay<nico@s...>
Date: Sun Mar 27 14:18:10 CEST 2005
Subject: [oc] Hardware and OS integration and security
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.
|
 |
Browse
