Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: The "Biggest Target" paradigm and its consequence

  • Subject: Re: The "Biggest Target" paradigm and its consequence
  • From: Richard Rasker <spamtrap@xxxxxxxxxx>
  • Date: Sun, 01 Oct 2006 10:37:04 +0200
  • Newsgroups: comp.os.linux.advocacy
  • Organization: Linetec
  • References: <pan.2006.09.30.17.30.20.356006@linetec.nl> <4o7obnFcp3f1U1@individual.net> <1679689.nfbT7gsTrn@schestowitz.com> <pan.2006.09.30.18.58.41.38209@linetec.nl> <q853v3-df5.ln1@sky.matrix>
  • User-agent: Pan/0.14.2.91 (As She Crawled Across the Table)
  • Xref: news.mcc.ac.uk comp.os.linux.advocacy:1162951
Op Sat, 30 Sep 2006 22:47:37 +0100, schreef [H]omer:

> Richard Rasker wrote:
> 
>> It's just that I realized that the "Biggest Target" paradigm is actually
>> the absolutely stupidest defence possible to explain the malware crisis,
>> as it implies that *any* OS with MS' market share would suffer the exact
>> same problems; therefore, the only possible remedy is a reduced market
>> share, so that there wouldn't be one Biggest Target any more, but a number
>> of smaller targets of roughly equal size.
> 
> "Creating more targets" is a process called diversity; it's a solution
> that has already been implemented in Linux since 2003, and is set to be
> a feature of Vista called ASLR (Address Space Layout Randomization).
> 
> http://www.eweek.com/article2/0,1895,1969505,00.asp

I've heard about it before; the idea is to make exploiting leaks more
difficult. But if we can believe Erik "Complexity is no Deterrent" F.,
this is a completely futile excercise.

> Note that the technology upon which ASLR is founded, was created by
> Professor Stephanie Forrest at the University of New Mexico, using Linux.

Could you've imagined her doing this with Windows? "Hello Microsoft,
please give me your source code, because I'd like to play around with
address space randomization in your kernel." Microsoft would've laughed in
her face, told her no way, bugger off, and six months later present their
own memory randomization "innovation", patent pending and all. And of
course in a crappy, crash-prone implementation.

> .----
> | To test her concept, Forrest experimented with a version of the
> | open-source operating system Linux. She altered the system to force
> | programs to assign data to memory locations at random. Then she
> | subjected the computer to several well-known attacks that used the
> | buffer-overflow technique. None could get through.

It's a smart idea, but I wonder if there's a noticable performance penalty.

> |
> | ...
> |
> | Linux computer-security experts quickly picked up on Forrest's idea.
> | In 2003 Red Hat, the maker of a popular version of Linux, began
> | including memory-space randomisation in its products.
> |
> | ...
> |
> | ####################
> | # Also of interest #
> | ####################
> |
> | Memory scrambling isn't the only way to add diversity to operating
> | systems. Even more sophisticated techniques are in the works. Forrest
> | has tried altering "instruction sets", commands that programs use to
> | communicate with a computer's hardware, such as its processor chip or
> | memory.
> |
> | Her trick was to replace the "translator" program that interprets
> | these instruction sets with a specially modified one. Every time the
> | computer boots up, Forrest's software loads into memory and encrypts
> | the instruction sets in the hardware using a randomised encoding key.
> | When a program wants to send a command to the computer, Forrest's
> | translator decrypts the command on the fly so the computer can
> | understand it.
> | "The program turns malicious code into digital gibberish and it
> | vanishes on reboot"
> |
> | This produces an elegant form of protection. If an attacker manages
> | to insert malicious code into a running program, that code will also
> | be decrypted by the translator when it is passed to the hardware.
> | However, since the attacker's code is not encrypted in the first
> | place, the decryption process turns it into digital gibberish so the
> | computer hardware cannot understand it. Since it exists only in the
> | computer's memory and has not been written to the computer's hard
> | disc, it will vanish upon reboot.
> `----
> 
>  - http://tinyurl.com/jrnbv (publicenemy.com) [New Scientist Article]

Interesting as these solutions may be, they're creating new problems as
well, e.g. in debugging. Of course, they shouldn't be necessary in the
first place, but then again, there's no such thing as fault-free software,
and this may considerably harden systems against yet undiscovered
vulnerabilities.

Richard Rasker

-- 
Linetec Translation and Technology Services

http://www.linetec.nl/


[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index