Page 1 of 2 12 LastLast
Results 1 to 15 of 22

Thread: Fantastic : bypass segmentation AND paging, access phys memory

  1. #1

    Fantastic : bypass segmentation AND paging, access phys memory

    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.

  2. #2
    Czernobyl
    Please describe briefly the essence

  3. #3
    Quote Originally Posted by Indy View Post
    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.

  4. #4
    for AFAIK even from ring zero access to physical addresses should not be possible,
    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.

  5. #5
    Quote Originally Posted by Czernobyl View Post
    hint : undocumented AMD specific MSR again - this one has no known name, even.
    But doesn't MSR access itself require kernel privileges?

  6. #6
    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...
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  7. #7

    Question Will this help malware ?

    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

  8. #8
    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.

  9. #9
    Quote Originally Posted by Indy View Post
    Silly question.
    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]Limit aspirations vx - creating the exploit(privilege escalation). At the zero level of privileges available to the entire system, it is nonsense.
    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

  10. #10
    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.

  11. #11
    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 !

  12. #12
    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...
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  13. #13
    Quote Originally Posted by Maximus View Post
    I think indy is meaning that: once you have r0 access, game is over.
    Indy is best left in the scatological abyss where he belongs, if you can read Russian you'll understand, 'nough said :=)

    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.
    Uh ? I'm rather well aware of SMM and SMRAM mapping/relocating/locking, I don't see the connection.

    If you discover you are running in a VM, you could 'edit' the code of the VM hypervisor that is caging you.
    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 ?

  14. #14
    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.
    I want to know God's thoughts ...the rest are details.
    (A. Einstein)
    --------
    ..."a shellcode is a command you do at the linux shell"...

  15. #15

    SMRAM

    Quote Originally Posted by Maximus View Post
    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...

Similar Threads

  1. access memory via segment:[offset]
    By Smith Goga in forum OllyDbg Support Forums
    Replies: 2
    Last Post: February 17th, 2006, 02:41
  2. Getting the debugger to reveal memory access to a string
    By 5aLIVE in forum OllyDbg Support Forums
    Replies: 6
    Last Post: August 22nd, 2005, 07:50
  3. how do you breakpoint on memory access?
    By FireRaven in forum OllyDbg Support Forums
    Replies: 4
    Last Post: April 11th, 2005, 10:05
  4. How to LOG memory access?
    By nexus in forum OllyDbg Support Forums
    Replies: 2
    Last Post: December 13th, 2003, 09:54
  5. Conditional breakpoint on memory read access*
    By ollynewby in forum OllyDbg Support Forums
    Replies: 2
    Last Post: March 25th, 2003, 06:12

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •