'Kernel memory leaking' Intel processor design flaw forces Linux, Windows redesign

Discussion in 'other security issues & news' started by Minimalist, Jan 2, 2018.

  1. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,001
    Location:
    Member state of European Union
    Some OSes can upload microcode to CPU at boot time. It was already discussed in several posts.

    Not to mention that motherboard/laptop manufacturer needs that microcode from Intel.

    On Intel site I still see date 1/8/2018 as latest microcode update. In this update I see in release notes:
    I don't see there Sandy Bridge.
     
  2. pling_man

    pling_man Registered Member

    Joined:
    Feb 11, 2010
    Posts:
    599
    Location:
    UK
    To get the Tech details I had to click on the "ghost" not the X.

    InSpectre provides some useful information in easy to understand language.
     
  3. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Yes, that is correct. The "ghosted" box symbol shown. I will update my posting.
     
  4. pling_man

    pling_man Registered Member

    Joined:
    Feb 11, 2010
    Posts:
    599
    Location:
    UK
    Yes that works too. You can right click anywhere in the title bar. But I meant the ghost = "specter" on the left hand side. You can left click that one too.
     
  5. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    I just ran Inspectre sandboxed, according to my results, you can disable mitigations.

    Sin tít.jpg

    Sin título.jpg

    What I cant understand is why one screen shows my W10 as not being vulnerable to Meltdown but the other one does show it as vulnerable.

    Bo
     
  6. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Did you add the override key value to the registry previously? Again, it does not enable either disable option on my Win 10 1709 build.

    -EDIT- I just noticed from your screen shot that you ran release #5. I ran #4. Appears it was just updated. Will try the latest release.

    Nope! Same behavior w/release 5. Both screen boxes for enabling/disabling are non-functional.
     
    Last edited: Jan 18, 2018
  7. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Because the CPU mitigation for Meltdown i.e. BIOS update has not been applied.

    -EDIT- Also if you look at the screen you posted, only the Meltdown Disabled box is enabled.

    Appears these options are dependent on the test results. That is if Meltdown is not fully mitigated, it will allow you to disable it.
     
    Last edited: Jan 18, 2018
  8. guest

    guest Guest

    InSpectre Release #5 v0.0.6792.5 (January 18, 2018)
    Website
    What's New:
     
  9. pling_man

    pling_man Registered Member

    Joined:
    Feb 11, 2010
    Posts:
    599
    Location:
    UK
    All the buttons in inspectre do is toggle the bits in the registry key we have discussed before. You can always disable one of the protections by setting a bit to 1. But you can’t enable spectre protection unless you have the necessary microcode support.

    Just listened to Steve talk about this on twit.tv. He notes the possibility of providing an on boot microcode patch for windows. I don’t know if he will write one though.
     
  10. roger_m

    roger_m Registered Member

    Joined:
    Jan 25, 2009
    Posts:
    8,627
    With release 5, there has been no change for me. I can still disable Meltdown protection and as always, the Enable Spectre Protection button is greyed out, because I have not updated the BIOS. The BIOS update for my computer should be available very shortly.
     
  11. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
  12. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    I finally figured out how GRC got approval on this from MS since it is no longer blacklisted by ScreenScreen.

    As mentioned, all this utility is doing is allowing for the "bit flipping" in the reg. Override key but with one important caveat.

    For example, the results of my AMD test stated I was not vulnerable to Meltdown. Therefore the disable box option for that was not available. However, I am vulnerable to Sprectre due to the microcode update not being applied. However, my overall system performance was rated "Good" by the tool. Therefore, the disable button was also not available to nullify the OS patch option applied. In other words, disabling of the OS patches is conditioned upon system performance impact. -EDIT- That is for the Spectre mitigation. A previous screen shot showed that it appears the Meltdown mitigation can be disabled unconditionally if not fully mitigated.:confused: However, the tool was running sandboxed which might have altered its normal behavior.

    Since Microsoft has updated their documentation to specifically now state that the Override reg. key value can also accomplish the same for client OSes, they had no choice but to also allow this tool to do the same. Again, only if it was shown via the test tool performance tests there was an issue.

    I will also state this. If a 300K assembler program can accomplish these reg. modifications, malware running with Admin privileges can do the same. Therefore I am monitoring any reg. changes to the Memory Management reg. key where the Override key value can be set.
     
    Last edited: Jan 18, 2018
  13. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Very good point, interesting. :thumb:
    MS probably should have protected that further.
     
  14. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    I just made a little, naive test of how easy it is to read other process memory from another process.
    Turns out, it's pretty darn easy at least on Linux.

    First, let's write some oh, so super secret program :D
    Code:
    #include <stdio.h>
    
    int    main(void)
    {
    
        static char* buffer __attribute__((used)) = "Top SECRET!";
    
        while(1) {
        }
        return(0);
    }
    
    That __attribute__((used)) just prevents that the "Top SECRET!" string is not optimized out by GCC compiler, works only for static variables.

    Next let's run it:

    upload_2018-1-19_3-19-14.png

    In another terminal, let's find out it's PID with top command

    upload_2018-1-19_3-19-53.png

    Then let's find that PIDs memory mapping

    upload_2018-1-19_3-20-35.png

    Any line that has "r" and also not empty the last line (like /home/wizard/secret) is accessible.

    Let's make some code ....
    Code:
    https://www.orwell1984.today/process_memory_test1.c
    
    And then try to read the first 100 bytes of PID 4940 (the secret program running in other terminal) from address 00400000:
    upload_2018-1-19_3-25-24.png

    Hmmm...nothing yet, just ELF file header and other garbage...
    Okay let's try 1000 bytes this time:

    upload_2018-1-19_3-26-14.png

    Still nothing...Okay let's just read 4096 bytes!
    upload_2018-1-19_3-26-45.png

    Bingo!

    This was of course very crude example with lot's of the steps manually done and the test program will not currently handle gaps in memory range.

    A real secret diggin malware would do all the above steps automatically (enumerate PIDs, automatically get their memory mappings and then scan the memory for some juicy, pre-determined keywords like "admin", "root", "password" etc...)

    This is at the same time fascinating and little scary.

    I can only guess what those writing for "living" shellcodes, exploits and other stuff could maybe do ...
    :eek:
     
  15. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Skyfall and Solace
    More vulnerabilities in modern computers.

    Link: https://skyfallattack.com/

     
  16. bo elam

    bo elam Registered Member

    Joined:
    Jun 15, 2010
    Posts:
    6,144
    Location:
    Nicaragua
    I didn't make any changes to the registry. I ran Inspectre sandboxed as all I wanted was to see the results and did not want the program to make changes either.

    Bo
     
  17. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,881
    Location:
    Slovenia, EU
    Just great. I guess we will see more of new implementations exploiting this vulnerability. At least for Spectre, they say that it's a whole class of attacks, so researchers will always find new ways of exploiting it.
     
  18. reasonablePrivacy

    reasonablePrivacy Registered Member

    Joined:
    Oct 7, 2017
    Posts:
    2,001
    Location:
    Member state of European Union
    Does this work when victim and adversary processes run on different, non-root user accounts? As far as I know user changing via sudo leaves some inherited privileges, so I would suggest logging through sshd/ssh (can be on the same OS and machine) or log to different account via ctrl-alt-Fx.
     
  19. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Thanks - if you have time, it might be interesting to observe the practical lifetime if disposed by gcc, because some of the PoC Spectre attacks require a long time to get their data.

    I think this also illustrates the continued importance of regular controls such as sandboxes. The "normal" way of gathering data such as enumerating processes would be through system utilities (and sometimes escalation), which sandboxes can restrict.

    Regarding locating the payload, it's not necessary to look for the pre-determined keywords. Whether open or closed source, the attacker can seed a test instance with searchable data and hence find the address to extract.

    It seems to me that a robust cross-process Spectre-only attack is going to require a lot of hard work because of the levels of indirection to get the process list in kernel memory, then assess it somehow for the version of the target you want to hit, and then exploit the target on the half-chance it will have useful secrets in memory. I think that will be really hard to do in practice, but as you say, there are cunning and $-motivated people out there. Given the level of difficulty, the bad guys may just use the many "normal" exploits instead. After all, if you've been able to escalate, the attack can simply be on the basis you've done, no Spectre required.

    The lower hanging fruit for Spectre is going to be own-process scanning, which I think in practice means password harvesting.
     
  20. hawki

    hawki Registered Member

    Joined:
    Dec 17, 2008
    Posts:
    6,065
    Location:
    DC Metro Area
    "75% of PCs Not Patched Against Meltdown and Spectre...

    A survey conducted by Barkly reveals that less than 26 percent of the systems managed by IT and security pros have received the Meltdown and Spectre updates, with only 4 percent of the respondents saying that all their machines got them...

    ...No less than 46 percent of the organizations that were part of the survey said they weren’t aware that in order to deploy Meltdown and Spectre patches antivirus solutions needed to be compatible and a registry key was required to deal with it..."

    http://news.softpedia.com/news/75-o...ltdown-and-spectre-companies-say-519466.shtml

    The Barkly Survey:

    https://blog.barkly.com/have-not-received-meltdown-spectre-updates-statistics
     
  21. emmjay

    emmjay Registered Member

    Joined:
    Jan 26, 2010
    Posts:
    1,540
    Location:
    Triassic
    The only thing that surprises me about the survey results is the high percentage of those who were unaware of the situation. I fully understand the reluctance to install the fixes that are currently available, considering how unreliable they have been.

    I bet consumers are even less aware (90% maybe) and for those who are aware, their reluctance to install is probably well above 60%; their ability to understand and inability to implement, even higher.
     
    Last edited: Jan 19, 2018
  22. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    3,342
    Location:
    Italy
    WOW !! :D
    TH.
     
  23. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    This is not the same as a speculative execution attack. In a speculative execution attack, the data is being captured as it is transferred to/from the CPU catch memory.
     
  24. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    It seems that there will be a wave of momentum for side-channel CPU attacks in general, particularly with the abundance of interest and available research already available.

    CPU "microcode" updates may very well become more frequent over the next year or so.
     
  25. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,592
    Location:
    U.S.A.
    Also if you read the few published articles where the authors have had the "guts enough" to state so, these BIOS mitigations are nothing more than "Band-Aid" fixes. Only new chip design will fully mitigate the issue.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.