direct H/W physical memory access and dangers thereof

[Czernobyl]

Since you do not disclose what you claim, there's no way for us to verify whether what you claim is true, and therefore we must assume it isn't.

No problemo.

[Czernobyl]

Hi,

There is an undocumented way that certain popular X86-32 processors are able to access (read/write) *physical* addresses in main memory directly, bypassing protections, paging and segmentation altogether.

One way??

One of its kind. Your interesting list of exploits above (none of which can be considered "undocumented", and scrubbed here for brevity) does not come near : the method I claim provides direct read/write access from CPU to any given 32-bit wide absolute physical address in system RAM, as if the CPU were in (big) real mode or in SMM, no chipset help needed, memory controllers, DMA (and how would legacy DMA give access over the 16 Megabyte limit, we're left to wonder), no cache, TLB, SMM, VMX,whatever.
It's something built into the naked CPU.

From the answers I have received so far, I gathered this ability (from ring zero) is not considered a threat per se.

[*]There's probably more ways for specific CPUs if you care to exaime the MSRs and/or errata

This guess is better. Well of course this must be what I've claimed. Not an erratum either, a secret feature lurking on millions of CPUs.

I'm not going to disclose details; what I'm asking from your precious lots of experience is does the existence of such a feature - which can't be turned off - constitute a new security menace for a securely conceived OS ? Or do you consider it "no problem" as the feature is available from ring zero only ?

CPL=0 was always meant to have complete access to everything with no protection/security at all. Regardless of how many different ways there are to bypass the imaginary protection that doesn't exist at CPL=0, it doesn't make any difference because that protection never existed anyway.

It's like saying "OMG I found a way to get access to the glove box" in a car that happens to have all doors unlocked and open (including bonnet and boot) and the alarm system turned off, with a large sign on its roof that says "Free stuff in glove box, please help yourself". Of course if this car happens to be inside a fortified underground bunker then the real achievement would be saying "OMG I found a way to get inside the fortified underground bunker (where anyone can easily access the stuff in the car's glove box)". In the same way, for a secure OS the real achievement would be finding a way to get to CPL=0 in the first place (where you can easily do whatever you like).

Alright. I've made my mind anyway for not disclosing the mechanism - if it is non interesting as deemed by you and several other people then I'm not depriving anyone of a useful tool, OTOH if it could be used to mount new attacks I don't want to be the one responsible.

Thank you - and all others (the ones that know better than just insult). This has been instructive (including the insults).

Cheers

--
Czerno

[Owen]

I don't think any of us said it was non-interesting. What we did say was that it was not a security risk (because if you are in CPL=0, then you've already broken the OS' protection system anyway).

[Czernobyl]

I don't think any of us said it was non-interesting. What we did say was that it was not a security risk (because if you are in CPL=0, then you've already broken the OS' protection system anyway).

Yes, it is what you/they said, and I contend it is only so if the "OS protection system" is made deliberately weak(for reasons of efficiency or worse, for programmers' convenience) - such as using the "flat" addressing model, returning phys-to-linear mappings on demand, providing services by means other than call gates, and so on - just browse the list of Win 9x VMM services or NT system services for a catalog of horrors.

In addition to the "OS protection sytem" (or lack thereof), you could've mentionned incorrect protection at the platform and BIOS level, such as failure to lock out access to the SMRAM, and more chipset issues.

I stay persuaded though there is no general, architectural, means for random CPL zero code to retrieve the full page directory and tables contents and/or bypass the whole lot.

Concerning the non-architectural mechanism which I found, from the start it has not been my intention to explain it here, I came to collect seasoned opinions about the perceived additional security risk. Should I decide to get along with my reticence, it will appear as an entry to my blog (http://blogs.mail.ru/mail/czernobyl/) and also at the collaborative RCE knowledge library http://www.woodmann.com/collaborative/k ... _Knowledge

Happy celebrations !

[Czernobyl]

You can not prevent CPL0 code from accessing full page directory and tables contents ever (other than by paging them out and marking non-present - but you can do that only to a limit, and then CPL0 can just switch paging off anyway, so it won't help).

I think it is you who are misunderstanding the X32 abstract model. There is generally no reason for paging tables to be mapped into your task's or driver's virtual memory, be it running at CPL 0, (even 'doze doesn't do that as far as I know unless you've loaded the debugging components), nor is there reason for them tables to be retrievable at will (don't forget the CR3 holds a physical address of course, which is like a chicken and egg problem if you would attempt to follow the chain).

Looks like a crafted attempt to advertise your own resource. Happy celebrations to you, too.

They're not my own places either, just convenient white boards of sort. See you... next year

[Owen]

If I'm CPL0 code, running in a task other than the kernel, and with the page directories unmapped and want to root your system, then all I have to do is:

1. SGDT to find where the GDT is in virtual space
2. Find the TSS selector for the kernel. If in doubt, this is probably the one pointed to by one of the exception handlers (This can be established by looking in the IDT)
3. Engineer a way of injecting my code into the kernel

The latter entry is relatively simple: Construct a far call into the kernel which moves from CPLx to CPL0 (where x > 0). The CPU will therefore copy however many parameters I say I'm providing onto the kernel's stack. I've read the kernel's TSS. I know its value of SS:rSP0.

After that I just need to reverse engineer the running kernel in order to find out what mechanism it uses for updating the page tables. Any protection owned.

The "x86 abstract model" assumes that CPL0 code is absolutely trusted. None of the major OSes - Windows, Linux, Mac OS X, FreeBSD, OpenBSD, NetBSD, etc, use more than one "CPL0 process"; all run the kernel (including drivers) in CPL0 and apps in CPL3. That there is no convenient method for arbitrary CPL0 code to access arbitrary physical memory is just an accident of design, not an intention - something which can be further seen in all the configuration registers exposed to CPL0 code that can be used to, yes, damage arbitrary data in physical memory.

[Czernobyl]

Happy new year!

If I'm CPL0 code, running in a task other than the kernel, and with the page directories unmapped and want to root your system, then all I have to do is:

1. SGDT to find where the GDT is in virtual space
2. Find the TSS selector for the kernel. If in doubt, this is probably the one pointed to by one of the exception handlers (This can be established by looking in the IDT)
3. Engineer a way of injecting my code into the kernel

The latter entry is relatively simple: Construct a far call into the kernel which moves from CPLx to CPL0 (where x > 0). The CPU will therefore copy however many parameters I say I'm providing onto the kernel's stack. I've read the kernel's TSS. I know its value of SS:rSP0.

After that I just need to reverse engineer the running kernel in order to find out what mechanism it uses for updating the page tables. Any protection owned.

Yes, looks like a good plan towards subverting an OS, I agree ;=)

The "x86 abstract model" assumes that CPL0 code is absolutely trusted. None of the major OSes - Windows, Linux, Mac OS X, FreeBSD, OpenBSD, NetBSD, etc, use more than one "CPL0 process"; all run the kernel (including drivers) in CPL0 and apps in CPL3.

None of those so-called "major OSes" is a satisfactory X86 OS unfortunately - each one of them was designed to be portable between several CPU types, and their X86 variants make only minimal use of X86 specific protection. This is why my OP was careful in talking about an ideal OS... which does not exist (OS2 could have been a better contender).

That there is no convenient method for arbitrary CPL0 code to access arbitrary physical memory is just an accident of design, not an intention....

Possibly so. Looking at the question from another perspective, convenient access to physical memory may not be of immense value to an evil doer. Maybe more so for access to memory mapped devices (which 'my' method doesn't grant, giving access to only system memory).

Thank you

[Brynet-Inc]

This is probably less of an issue for systems that don't allow "binary-blob" closed source drivers from running in kernel space (ring0/cpl0).

Once a system loads a 3rd party binary kernel module it should be considered tainted, one should assume that they'll probably trash kernel structures accidentally or maliciously.

OpenBSD for example, doesn't accept bug reports with any 3rd party kernel modules loaded, and I believe Linux has a similar policy regarding them.

A system with portability in mind makes a clear distinction between kernel/supervisor and user spaces, and code running at that higher privileged level should be trusted.

Also, please don't use colours, especially black, unreadable on a few themes here.

[Czernobyl]

I have also devised a method to access arbitrary physical memory in CPL0, regardless of page mappings, segmentation and so on:

Code: Select all

disable paging
....

wdyt?

Always same answer : you can't (in general) just disable paging like that, for it to work you have to make yourself run from an identity-mapped page. Which (again, in general) is not possible.

[NickJohnson]

It's trivial to have identity-mapped kernel code if you don't have a higher-half kernel. Even if you do have a higher-half kernel, you can still achieve the same results with position independent code or other trickery.

So, really, the only thing I can see whatever magically redundant technique you've found doing is helping when copying data between address spaces. If whatever it is could be used with SIMD extensions and does not incur overhead from the MMU (unlike turning off paging or mapping frames), it could be used to speed up implementations of things like fork() at least a bit. That's about as constructive (or destructive, if you wish) as it gets.

[gerryg400]

It's trivial to have identity-mapped kernel code if you don't have a higher-half kernel. Even if you do have a higher-half kernel, you can still achieve the same results with position independent code or other trickery.

So, really, the only thing I can see whatever magically redundant technique you've found doing is helping when copying data between address spaces. If whatever it is could be used with SIMD extensions and does not incur overhead from the MMU (unlike turning off paging or mapping frames), it could be used to speed up implementations of things like fork() at least a bit. That's about as constructive (or destructive, if you wish) as it gets.

It's only trivial to disable paging if 'you' are the kernel. If you are a rogue ring0 driver, it's not at all easy.

[Czernobyl]

So, really, the only thing I can see whatever magically redundant technique you've found doing is helping when copying data between address spaces. If whatever it is could be used with SIMD extensions and does not incur overhead from the MMU (unlike turning off paging or mapping frames), it could be used to speed up implementations of things like fork() at least a bit.

I'm afraid the technique in question, won't be too efficient in copying (streaming) large contiguous data; while there is no overhead for the setting-up, the throughput will be relatively low, requiring one access to some MSR per quadword transferred ; SIMD not applicable. The technique might still be advantageous for smallish streams, and without doubt for random access to physical locations.

All in all it will have to be carefully benchmarked in the appropriate situation.

[xenos]

Just in case anyone is interested in this "magic" unlock key for AMD CPUs:

http://www.google.com/search?q=9C5A203A ... 0x9C5A203A

It's not really a secret.

[Czernobyl]

Just in case anyone is interested in this "magic" unlock key for AMD CPUs:

http://www.google.com/search?q=9C5A203A ... 0x9C5A203A

It's not really a secret.

Zero connection, not even remotely : the MSR(s) used in this magic (your word) aren't even password protected in fact :=) All the "magic" required was curiosity and (some amount of) intelligence and flair to find what it does and how it works ;=)

Really I don't want to be rude, but WTF can't people like you pause a minute before posting nonsense thus uselessly misleading people ? A problem with the generation I assume. Can't hold your tongues/pens/mice/selves. Didn't your mum raise you ?

Anyway I will post details shortly, not that don't feel it's like throwing margaritas ante porcos, oh well...

--
Czerno

[xenos]

Probably because people like you simple post unproven claims without giving any kind of verifiable information, letting all others step in the dark. And judging from the tiny bit of information you disclosed in this thread (regarding MSRs), and your nick appearing in those links I posted, it is rather obvious that there is more than "zero connection" between this thread and my link.