Re: Pentium Computers Vulnerable to Attack?

[Matthew Murphy <mattmurphy () kc rr com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Dude VanWinkle wrote:
> Crap, not part of the OS, but the code... well here let me make sure I
> got this right.

SMM code handles hardware-related events.  I'm not sure if the OS has a
role in establishing *what* code runs in SMM at all.

> When your macine gets a signal to enter system management mode, it
> takes a bit of code (written to memory during boot?) that enables it
> to run at 16bit

Not necessarily 16-bit, AFAIK.

> till it gets the OK signal. When it gets the OK
> signal, the processor grabs its previous 32 bit environment (dumped to
> memory when SMM was triggered?) and runs that.

You're right about all except one part here.  SMM is ENTERED by an
interrupt.  That is, some external event.  It's exited by the code
itself.  That is, the SMM code controls when it stops running internally.

> This part of Xserver enables you to overwrite the part of memory that
> holds the SMM "image",and the true danger is that from there it could
> overwrite the part of memory that holds the
> "what-I-was-doing-before-smm" image?

Essentially.

> if I got that right (a longshot), then this seems pretty hard to
> actually be afraid of (even more of a longshot).

Indeed, what you have is a rough idea. :-)

The only environment where this is a problem is environments that
attempt to limit 'root'.  That is, these systems fundamentally violate
(or attempt to violate) these assumptions:

   root = superuser
   root access = game over

1) 'root' owns /dev/xf86.

2) 'root' needs write access to /dev/xf86 because 'root' is what X runs as.

3) Nobody else needs write access to that device and nobody else has it.

4) On this particular system, even 'root' is restricted from performing
some actions.  Immutable files are one example.

5) X (and possibly anything else running root) can use /dev/xf86 to
modify SMM, eventually executing arbitrary code at a layer able to
modify the running system image.

6) This malicious code removes one or more of the accounting checks from
the running kernel that prevent root from gaining total control.

7) Root is now in total control of the box.

The danger in this is that the underlying architecture of X makes this a
problem with no solution for the developers of root-limiting software.

- --
"Social Darwinism: Try to make something idiot-proof,
nature will provide you with a better idiot."

                                -- Michael Holstein

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB5444D38

iD8DBQFEPLBmfp4vUrVETTgRA0i5AJ4vxvQan8rUr3WGgvPO6zMekxaMegCfetY+
INvS/dBl5w/2A3e/mtiwlwY=
=w1bV
-----END PGP SIGNATURE-----

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.