Fantastic! Direct access to _physical_ memory, in any mode (CPL=0 required all the same). bypassing segmentation and paging completely !

I've been writing a new short item for the Collaborative Library, that for some unspeakable reason doesn't want to take when I press (Submit), nothing happens (yes I enabled scripts)

Too bad guys, you'll have to wait since Mr. Operator sorts the problem out.

Just to make you hold your breaths, this one /is/ sort of a security issue, for AFAIK even from ring zero access to physical addresses should not be possible, assuming a real secured OS that is.

Czernobyl
Please describe briefly the essence

No, no, I want the library system sorted : (niark)

hint : undocumented AMD specific MSR again - this one has no known name, even.

Elements(PTE, PDE etc.) through which the paging is performed may not have the access level below zero(V-mode is not considered), ie the r0 access to all physical memory.
Moreover using paging, ie the physical memory is not the target region, it is saved to disk. Without generation of #PF can not get it. And this is possible only through paging.
In general, the ability to access physical memory from user mode is very interesting.

But doesn't MSR access itself require kernel privileges?

I think he is referring to the fact that, if you can access the physical memory directly, then "The Emperor Has No Clothes".

Think of your VM hypervisor, your SMM, whatever - everything is in memory, and so everything can be then read/overwritten, just like the old physical memory access you got via driver before MS banned its access from your administrator account...

Finally I'm not so sorry the collab Library breakdown has prevented my releasing full disclosure for a moment. Although I am all in favor of openness, as you all can testify, in this occurrence I'd like first to consult on the dangers, if any, of disclosing a backdoor to physical memory. If nothing more I don't want to be accused of jeoparding systems security, nor of harming AMD, inco.

Welcoming your opinions (technical, rather than ethical) : assuming there existed a backdoor access to physical memory from CPL0 tasks and drivers, similar to 32-bit flat real-address mode, independent of OS, does it fundamentally "change the rules" as far as e.g. malware is concerned ? How and how much so ? Or shall we consider that, once malware is allowed to run in ring zero, it's "game over" as the saying goes ?

I'll be posting the question to usenet group comp.lang.asm.x86 too .


--
Czerno

Czerno
Silly question. Limit aspirations vx - creating the exploit(privilege escalation). At the zero level of privileges available to the entire system, it is nonsense.

Maybe, maybe not. I'm afraid there is a communication problem with you, Indy, or rather your English <-> Russian translator which makes things more difficult than they could be.



I apologize, can't make sense of your phrase once again. On your side, are you sure you understood the question clearly ?

And so, can someone try to rephrase in plain basic words what Indy is trying to tell ?
Sorry I can't decrypt

Czernobyl
Trash it if does not give an opportunity to raise privileges. If you do not understand, I can write in Russian.

By the way your undocumented features of AMD too trash completely useless.

What one finds useless, others may consider invaluable.

This thread is nowhere about raising privileges, vx writing or any other of your obsessional mania - it's about processor fundamentals, /not/ whatever OS deficiencies nor exploits.

And no thanks, no Russian language necessary here, your English albeit queer is understandable enough. I'm done with you, Indy, go away and farewell !

I think indy is meaning that: once you have r0 access, game is over.

The biggest issue is escalating privileges from user mode up to kernel mode. However, your discovery could be useful to break into SMM once it is locked down, or other purposes.

Theoretically, at first i'd say:
* on system with SMM: you might be able to overwrite the SMRAM, normally not accessible. Thus, you can hide/insert your code there, even if you normally cannot access it.
* If you discover you are running in a VM, you could 'edit' the code of the VM hypervisor that is caging you.

The above approach looks more theorical than practical, however still very interesting vulnerabilities, I think.
You could i.e. hide a rootkit, or escape from a VM environment and attack the hosting machine...

Uh ? I'm rather well aware of SMM and SMRAM mapping/relocating/locking, I don't see the connection.



Perhaps, but my discovery won't help you here, because from a VM you can't access the host's MSRs, only those few that are emulated in the guest.

In what way are these thought examples of yours related to, or facilitated by, having direct access to physical addresses, rather than through virtual -> physical conversion ?

Hi, about the VM - I were thinking to 'not-complete' VM implementations like in a rootkit, where you i.e. might not be 'locked'. I werent thinking about it in a complete, full emulated environment (it might be worth the time of a check, maybe, but I highly doubt it is not emulated as well).
For the SMRAM, i were thinking that it might be a way to circumvent the dlock: we can locate/alter the SMRAM mapping in physical memory, thus overwriting it without being in SMM mode.

Bank switching the SMRAM on/off is a function of the "Northbridge", the memory controller, not the processor - even though on recent processors it is integrated in the same chip (not so on the K7). In any case, the new "window" to physical memory is agnostic with respect to that, it will "see" the SMRAM or standard RAM, whatever is currently mapped at the address you directed it to look at. It will access SMRAM if the processor is in SMM of course, or in other modes if SMRAM happened to be mapped in by whatever means, but it won't change or unlock SMRAM mappings ! Sorry :=)

According to principles set by Intel, once SMRAM is locked it shouldn't be possible to unlock it without complete reset. Whether this lock is properly implemented, or if there is a backdoor, might depend on the "chipset" (for external NB) or, you /might/ dream of another undocumented processor hack (for integrated NB) - I don't have such a hack...

Indy, for the love of god, stop insulting competent, well-meaning members of this board!

aaah damn! well, was worth asking anyway -thanks

My happy new year's present folks, this blog entry ("http://blogs.mail.ru/mail/czernobyl/99E0961664ED43E.html") http://blogs.mail.ru/mail/czernobyl/99E0961664ED43E.html provides full programming details for physical memory access on the K7 (and no, it won't work on K8 and later AMD-64 processors).

Enjoy!


--
Czerno

Sweet, nice reversing work there Czerno.

So what's not satisfied with the basic legal mechanism(paging)?
Why use any perversions ?

why go on the moon? why study galaxies? why warping space instead of trajectories (Eninstein's relativity)?
Knowledge.

It's enough.

Right on mark There is so much left to discover... Since you mentioned Einstein, my late father was a junior assistant to professor of mechanics Ostwald in Zurich in the early 30s and had the rare privilege to (silently) attend private discussions between the 2 men in Einstein's office at the university.

Ostwald's comments : "he (prof. Einstein) doesn't understand his Theory; unlike I understand my Mechanics." LOL.


Happy new year !