SecurityFocus Article

SecurityFocus Article

[Ed White]

A researcher of the french NSA discovered a scary vulnerability in modern x86 cpus and chipsets that expose the kernel to direct tampering.

http://www.securityfocus.com/print/columnists/402

The problem is that a feature called System Management Mode could be used to bypass the kernel and execute code at the highest level possible: ring zero.

The big problem is that the attack is possible thanks to the way X Windows is designed, and so the only way to eradicate it is to redesign it, moving video card driver into the kernel, but it seems that this cannot be done also for missing drivers and documentation!

I would like to hear developers opinion about it...


------------------------------------------------------------------------

The quest for ring 0

by Federico Biancuzzi
2006-05-10

Federico Biancuzzi interviews French researcher Loïc Duflot to learn about the System Management Mode attack, how to mitigate it, what hardware is vulnerable, and why we should be concerned with recent X Server bugs.
http://www.securityfocus.com/columnists/402

Re: SecurityFocus Article

[Andi Kleen]

"Ed White" <ed.white@libero.it> writes:

> A researcher of the french NSA discovered a scary vulnerability in modern x86 cpus and chipsets that expose the kernel to direct tampering.
> 

It's nothing new really. Similar attacks have been known and discussed
in theory for years.

>From a security perspective X server and anything else with direct
hardware access is essentially part of the kernel.

-Andi

Re: SecurityFocus Article

[Alan Cox]

On Iau, 2006-05-11 at 14:34 +0000, Ed White wrote:
> The big problem is that the attack is possible thanks to the way X
> Windows is designed

Where did you get that idea.

What it essentially says is "if you can hack the machine enough to get
the ability to issue raw i/o accesses you can get any other power you
want". Thats always been true. Using SMM to do this seems awfully hard
work.

Alan

Re: SecurityFocus Article

[linux-os (Dick Johnson)]

On Thu, 11 May 2006, Ed White wrote:

> A researcher of the french NSA discovered a scary vulnerability in modern x86 cpus and chipsets that expose the kernel to direct tampering.
>
> http://www.securityfocus.com/print/columnists/402
>
> The problem is that a feature called System Management Mode could be used to bypass the kernel and execute code at the highest level possible: ring zero.
>
> The big problem is that the attack is possible thanks to the way X Windows is designed, and so the only way to eradicate it is to redesign it, moving video card driver into the kernel, but it seems that this cannot be done also for missing drivers and documentation!
>
> I would like to hear developers opinion about it...
>
>
> ------------------------------------------------------------------------
>
> The quest for ring 0
>
> by Federico Biancuzzi
> 2006-05-10
>
> Federico Biancuzzi interviews French researcher Loïc Duflot to learn about the System Management Mode attack, how to mitigate it, what hardware is vulnerable, and why we should be concerned with recent X Server bugs.
> http://www.securityfocus.com/columnists/402
>

If the SMRAM control register exists, the D_LCK bit can be set
in 16-bit mode during the boot sequence. This makes the SMRAM
register read/only so the long potential compromise sequence
that Mr. Duflot describes would not be possible. If the control
register doesn't exist, then the vulnerably doesn't exist.

The writer doesn't like the fact that a root process can execute
iopl(3) and then be able to read/write ports. He doesn't like
the fact that the X-server can read/write ports from user-mode.

Sorry, the X-server is too large to go into the kernel. It's
a lot easier to modify the boot-loader to set the D_LCK bit
if the security compromise turns out to be real.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.16.4 on an i686 machine (5592.89 BogoMips).
New book: http://www.lymanschool.com
_
\x1a\x04

****************************************************************
The information transmitted in this message is confidential and may be privileged.  Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited.  If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to DeliveryErrors@analogic.com - and destroy all copies of this information, including any attachments, without reading or disclosing them.

Thank you.

Re: SecurityFocus Article

[Ingo Oeser]

Hi,

On Thursday, 11. May 2006 17:47, linux-os (Dick Johnson) wrote:
> If the SMRAM control register exists, the D_LCK bit can be set
> in 16-bit mode during the boot sequence. This makes the SMRAM
> register read/only so the long potential compromise sequence
> that Mr. Duflot describes would not be possible. If the control
> register doesn't exist, then the vulnerably doesn't exist.
> 
> The writer doesn't like the fact that a root process can execute
> iopl(3) and then be able to read/write ports. He doesn't like
> the fact that the X-server can read/write ports from user-mode.
> 
> Sorry, the X-server is too large to go into the kernel. It's
> a lot easier to modify the boot-loader to set the D_LCK bit
> if the security compromise turns out to be real.

That sounds like a good move.

Any patches?

I would love to review them!


Regards

Ingo Oeser

Re: SecurityFocus Article

[Segher Boessenkool]

> If the SMRAM control register exists, the D_LCK bit can be set
> in 16-bit mode during the boot sequence. This makes the SMRAM
> register read/only so the long potential compromise sequence
> that Mr. Duflot describes would not be possible. If the control
> register doesn't exist, then the vulnerably doesn't exist.

No, if there is no mechanism to lock down SMmode (re)configuration,
the vulnerability of course _does_ exist.

> The writer doesn't like the fact that a root process can execute

Rest of this email happily ignored...


Segher

Re: SecurityFocus Article

[Jon Smirl]

On 5/11/06, linux-os (Dick Johnson) <linux-os@analogic.com> wrote:
> Sorry, the X-server is too large to go into the kernel. It's
> a lot easier to modify the boot-loader to set the D_LCK bit
> if the security compromise turns out to be real.

The X server doesn't need to go into the kernel, only a very tiny
portion of it needs to go in. But X blindly pursues the idea of total
platform independence which means it ignores many of the services
offer by the Linux kernel and reimplements them in user space. This is
because the BSDs are missing many things that Linux supports.

I just love the idea of 2.4M lines of X code that opens network
sockets needlessly running as root. Top it off with 1,300 unfixed
Coverity hits, http://scan.coverity.com/. But what fun is life if you
don't live a little dangerously. If you want ideas on how to fix X to
not run as root read,
http://people.freedesktop.org/~jonsmirl/graphics.html

Of course DaveA will chime in and say that they are working on fixing
things to use the Linux kernel. This is good and I am glad it is being
done, I just worry that it will get finished sometime around 2014.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: SecurityFocus Article

[Dave Airlie]

>
> The X server doesn't need to go into the kernel, only a very tiny
> portion of it needs to go in. But X blindly pursues the idea of total
> platform independence which means it ignores many of the services
> offer by the Linux kernel and reimplements them in user space. This is
> because the BSDs are missing many things that Linux supports.
>
> I just love the idea of 2.4M lines of X code that opens network
> sockets needlessly running as root. Top it off with 1,300 unfixed
> Coverity hits, http://scan.coverity.com/. But what fun is life if you
> don't live a little dangerously. If you want ideas on how to fix X to
> not run as root read,
> http://people.freedesktop.org/~jonsmirl/graphics.html
>
> Of course DaveA will chime in and say that they are working on fixing
> things to use the Linux kernel. This is good and I am glad it is being
> done, I just worry that it will get finished sometime around 2014.

I'll also suggest you stop talking out of your arse, there are no
aliens in Area 51 either Jon and man did walk on the moon, refuting
the crap you post takes more time than fixing X...

Coverity scan is all of X (clients, libraries, server, apps) not just
the X server, it is also against the old 6.9 tree not the modular
tree, so it never gets anything fixed as that tree is dead. We are
working with coverity to scan modular instead.

My current X server hasn't any network sockets open by default.

Your ideas to fix X didn't result in patches to fix X, ideas are great
we all have ideas, patches are better, for some reason we don't all
have patches.

We are fixing X, you are not.

Dave.

Re: SecurityFocus Article

[Jon Smirl]

On 5/12/06, Dave Airlie <airlied@gmail.com> wrote:
> Your ideas to fix X didn't result in patches to fix X, ideas are great
> we all have ideas, patches are better, for some reason we don't all
> have patches. We are fixing X, you are not.

In the past I wasted way too much time writing patches for X. I
understand now that there is little consensus on where X is going in
the future. X has few resources and many of these resources work at
cross purposes. You are doing a fine job, please keep up the good
work. For my part I have chosen to stop working in such a chaotic
environment.

But, no matter how you slice it, X is still a multi-megabyte process
needlessly running as root which makes it a scary security issue. I
know you are already aware of the philosophical and architectural
changes needed to switch X to a model where it runs as a normal
process and relies on the kernel for privileged operations. You and
Ian are taking the first steps, I hope that X will reach the consensus
necessary to implement the full change.

Question my sanity if you want, but I'm sticking with the old fashion
idea that privileged code that mucks with hardware belongs in a device
driver. I'm also stuck on the radical idea that only one device driver
at a time should be in control of a piece of hardware. X violates both
of these.

-- 
Jon Smirl
jonsmirl@gmail.com