[LINK] Microsoft explains how the ANI bug got baked into Vista

[Chris Maltby]

>>On Mon, Apr 30, 2007, Bernard Robertson-Dunn wrote:
>>>When I used to do assembly programming on Univac mainframes in the mid 
>>>1970s, they had a concept of privileged Operating System mode. This 
>>>meant that the Operating System had its own set of registers and some OS 
>>>only instructions. The consequences of this were two fold:

> Adrian Chadd wrote:
>>Current Intel CPU architecture has that too. In fact, it has -four-
>>protection rings to seperate privileged and non-priviliged processes.
>>The whole point of having protected mode is being able to setup a process
>>in its own "virtual machine" with limited interfaces to the rest of
>>the system.
 
On Mon, Apr 30, 2007 at 11:00:08AM +1000, Bernard Robertson-Dunn wrote:
> I didn't think that the Intel architecture had a set of registers that 
> only the OS could use.  I thought that all registers were used by both 
> OS and application code, which is why buffer overflow hacks are possible.
> 
> In the Univac architecture, there was no such thing as a buffer overflow 
> hack in the sense of application data being executed as either 
> application code or OS code.

Bernard,

I wouldn't get too excited by a second set of registers. The OS context
is more than the contents of the register set... I'm sure there were
plenty of buffer overflow holes in the Univac OS too.

What Adrian is saying is that all modern systems have sufficient
hardware to implement secure OS environments - but developers often cut
corners on security to achieve other goals (typically performance). I
doubt if an animated cursor description is ever interpreted by the OS
kernel even in Windows, but it probably is interpreted by components of
the display manager and that is privileged because it needs to take
advantage of display performance enhancements which the OS provides only
to privileged tasks.

In fact, it's probably easier to launch your attacks against privileged
non-kernel tasks - when you gain control of one you have the full power
of the OS at your service. Inside the kernel it's often hard to perform
complex application level tasks, so injecting your own code there is less
attractive.

Chris