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

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

  1. pling_man

    pling_man Registered Member

    Joined:
    Feb 11, 2010
    Posts:
    599
    Location:
    UK
    Intel PDF:

    https://software.intel.com/sites/default/files/managed/c5/63/336996-Speculative-Execution-Side-Channel-Mitigations.pdf
     
    Last edited by a moderator: Jan 16, 2018
  2. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,399
    Location:
    U.S.A.
    Connecting via Wi-Fi? If so, you need to read this:

    MADIoT – The nightmare after XMAS (and Meltdown, and Spectre)
    https://www.welivesecurity.com/2018/01/08/madiot-nightmare-xmas-meltdown-spectre/
     
  3. XIII

    XIII Registered Member

    Joined:
    Jan 12, 2009
    Posts:
    1,109
    MSI will not provide a BIOS update for my 10 year old motherboard.

    I tried this tool for the Intel Core 2 Duo E8400 CPU on that board, but after installation I see "No CPUs needed an update. Your system might not need this driver." in the Event Viewer (the E8400 is included on the Intel download page though).

    Still InSpectre lists my system as vulnerable to Spectre (which I believe it is).
     
  4. Tinstaafl

    Tinstaafl Registered Member

    Joined:
    Jul 30, 2015
    Posts:
    884
    Location:
    USA
    I think that this post sums it up well... https://www.wilderssecurity.com/thr...-xss-where-noscript-isnt.393256/#post-2666796

    I generally run uMatrix with 3rd party scripts denied by default. If you need a site to allow 3rd party scripts to run, and wanted to ensure no XSS was possible, you could run NoScript in tandem with uMatrix with scripts whitelisted, but XSS denied.
     
  5. Tinstaafl

    Tinstaafl Registered Member

    Joined:
    Jul 30, 2015
    Posts:
    884
    Location:
    USA
    Assuming that the code you execute locally on your computer is trusted and signed, then the scripts that run in the browser are the biggest remaining risk.

    I would use some combination of Umatrix, uBlock Origin, (and noScript, but it's Firefox only), to minimize the attack surface.
     
  6. hawki

    hawki Registered Member

    Joined:
    Dec 17, 2008
    Posts:
    5,630
    Location:
    DC Metro Area
    "VMware Retracts Faulty Intel Firmware Patches For Chip Vulnerabilities

    A bug in Intel's firmware update for Meltdown and Spectre that manifests itself when running virtual machines has prompted VMware to rollback a recently issued security patching recommendation. This adds yet another wrinkle of complexity for solution providers looking to protect their customers from the two side-channel vulnerabilities.

    Customers alerted Intel that upgraded systems powered by some older Intel Haswell and Broadwell processors were experiencing unexpected reboots when running the Intel firmware upgrade

    VMware had recently pushed out the Intel microcode upgrades for the physical hardware as a courtesy to its customers, alongside its own patches for ESX hypervisors—a mitigation framework the virtualization vendor recommended in its latest security advisory on the side-channel vulnerabilities...

    On Monday, once Intel alerted VMware of the problem discovered in the field, VMware advised partners to no longer install those patches in tandem. VMware instead referred them to an earlier security advisory document that referenced patch releases not including the code from Intel..."

    http://www.crn.com/news/security/30...firmware-patches-for-chip-vulnerabilities.htm
     
  7. Sampei Nihira

    Sampei Nihira Registered Member

    Joined:
    Apr 7, 2013
    Posts:
    2,224
    Location:
    Italy
    Inspectre new version 0.0.6591.2:

    https://www.grc.com/inspectre.htm
     
  8. paulderdash

    paulderdash Registered Member

    Joined:
    Dec 27, 2013
    Posts:
    4,417
    Location:
    Under a bushel ...
    I had applied the now 'pulled' BIOS update, experienced the WHEA and slowdown problems, so applied the changes you suggested in #582.

    So I am assuming you are saying the respective bits would be best reset to the original '0' and '3' prior to a revised BIOS update, as per: https://support.microsoft.com/en-us...-to-protect-against-the-speculative-execution ?
     
  9. paulderdash

    paulderdash Registered Member

    Joined:
    Dec 27, 2013
    Posts:
    4,417
    Location:
    Under a bushel ...
    I had also previously run uMatrix and personally found it more 'intuitive' (with NS in globally allow mode for XSS and clickjacking).

    Will need to revisit and also how to best combine with uBO. There was previous discussion here: https://www.wilderssecurity.com/threads/enhancing-ublock-origin-with-umatrix.388704/

    I currently run uBO in medium mode, is it best to revert to simple mode when running with uM?

    Edit: Can someone point me to a best synopsis on how to run these together? (from someone who doesn't know his iFrame from his XHR).

    True, script blocking is relevant to this threat but I suppose this discussion should be continued in a uMatrix thread.
     
    Last edited: Jan 17, 2018
  10. stapp

    stapp Global Moderator

    Joined:
    Jan 12, 2006
    Posts:
    17,708
    Location:
    UK
    Rather odd use of the word 'bogus' here as it usually implies deception

     
  11. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Strict site isolation ensures that related sites run in separate processes (at the cost of higher memory use). While this protects against in-process memory scanning, it does NOT defend against all Spectre-class attacks because they can specifically go cross-process. Almost certainly a harder attack, but nothing to stop that.

    It would help defend against more conventional malware where process isolation is more trustworthy.

    Script defences are a more reliable control I think in this instance.
     
  12. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,441
    Location:
    Slovenia
    IMO using separate browser sessions for sensitive data is ATM enough secure.
    Also, I wonder what data browser actually stores in memory if you manually enter credentials to log in. Credentials are sent to remote server, which issues session cookie or something similar. So I don't see a need for browser to store that data in memory (also don't know if it actually does).
     
  13. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    I think you're right about levels of threat here at the moment. The medium term issue though is the industrialisation of malware. I do think the malware will have to be pretty sophisticated to do a practical industrial type job though.

    As a developer interested in securing in-RAM secrets, there are many tricky issues depending on language and platform. But I guess most developers don't bother, which is the big exposure. The memory could contain the secret for some time, and indeed, it might be relatively easy to harvest it from the page you're on by injecting some event listeners, so that the secret is in the DOM and necessarily in memory at that point. And sometimes, you can't avoid keeping the secret in RAM (e.g. Truecrypt).

    Good practice is things like zero-ing out memory once used, and then using garbage collection (but you can't rely on that happening immediately). You can also encrypt secrets and use platform/kernel functions to decrypt (e.g. things like DPAPI on Windows). My ideal is to have some two-factor going on, either locally, or with the remote web site, which is actually the real solution to the browser threats.
     
  14. whitestar_999

    whitestar_999 Registered Member

    Joined:
    Apr 1, 2010
    Posts:
    145
    I am just guessing that whenever a password is entered in any field in webpage,the browser caches it in memory in plain form until you hit the submit button.That is why one can unmask the starred password by clicking on eye logo in IE before clicking submit.
     
  15. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    Browsers use session cookies (that is, a cookie with expiration time empty/null) to pass information between itself and remote server when needing somekind of access control/user authentication.

    Session cookie can be stored to disk but it would not make much sense because by definition, they are valid only for the given session and should be deleted after browser closes (expiration time empty). So it would make more sense to store them into memory and I guess most browsers will.

    Different story are other kinds of cookies like those that are set when some site ask if you want to "keep me logged in" or similar. They are stored to disk and could have also expiration time other than empty.

    Previously, cookies were the only way to pass data because HTTP has no other way to keep user state (it's a stateless protocol).
    But then the HTML5 came and now we have things like local storage (similar to old persistent/tracking cookie but can store more information) and session storage (like old session cookie)

    EDIT: And when I say more information I also mean more. Old cookies can store just 4 KB per cookie of information. HTML5 local/session storage can store several MBs !
    EDIT2: And yeah, any passwords typed to those password fields in forms? Yup, they are really in plaintext in memory internally but of course hashed (or should be!) just before sending them by hitting submit
     
    Last edited: Jan 17, 2018
  16. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,399
    Location:
    U.S.A.
    Glad you brought this up since I was going to myself.

    Appears to me, one mitigation to these current issue is that browsers be modified to store sensitive data in memory encrypted.
     
  17. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    Can be done, but to decrypt, you need the secret somewhere, and that will potentially be accessible. Often gets quite circular! I think in the medium term, some forms of local 2FA/coprocessor may help. But then - a loud message to website operators - SORT OUT DECENT 2FA ON YOUR SITE!!!!! I'd like to see that mandated for any site involved in taking payment, at least as an option. "Decent" does not mean SMS, biometric or smartphone based.

    The other problem is that it's not always easy to be sure that the original plaintext variable is actually disposed of - and you normally have little control over that, especially for interpreted languages (this is normally a Good Thing).
     
  18. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    14,441
    Location:
    Slovenia
    @Stefan Froberg
    Thnx. Can credentials be extracted from session cookies stored in memory? I always thought that it couldn’t.
    Also while login data is in browser memory, is it stored in kernel memory that supposed to be protected by CPU?

    Thanks all others for you answers also.
     
    Last edited: Jan 17, 2018
  19. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    8,399
    Location:
    U.S.A.
    Not really a good analogy here. Disabling privacy related telemetry features is not the same as disabling critical security related mitigations. Personally, I would think that a concern associated with security issues would know better in this regard.
     
  20. whitestar_999

    whitestar_999 Registered Member

    Joined:
    Apr 1, 2010
    Posts:
    145
    You couldn't because you weren't supposed to as per OS rules but you can now provided you can create a meltdown/spectre exploiting script & run it on your pc.All things encryption related(& actively running in OS) require a decryption key which is always stored in kernel memory only when any OS is running.That is why using a separate hardware independent from your pc processor as 2nd factor authentication is the safest way.
     
  21. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Yes, that's correct. Although on non-Server builds of Windows, I believe that you could even delete those registry keys and everything would be returned to default anyway since non-Server builds enforce it by default. So the registry keys in this case are more used to disable the mitigation(s). I would suggest as you said, original '0' and '3' is the best way to go for now.
     
  22. WildByDesign

    WildByDesign Registered Member

    Joined:
    Sep 24, 2013
    Posts:
    2,587
    Location:
    Toronto, Canada
    Some users are reporting success with the VMware tool applying the microcode at boot, while others are reporting failure on that. I have no idea why the success rate is scattered like that, though. I was able to successfully apply the microcode with the VMware driver to my physical system, however, it failed on a Hyper-V guest that I tried it on.

    Regardless, the Intel microcode continued to cause problems (WHEA errors due to CPU page faults) whether I used the VMware driver or built into the BIOS.

    So the best choice right now is to wait until Intel fixes their issues (many reported issues) in their next microcode release. Hopefully they push a fix out this week to manufacturers, but who knows at this point.
     
  23. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,832
    Location:
    UK
    I think you'd expect it to fail on the Hyper-V guest - a hypervisor won't try to emulate all aspects of the Bios, and indeed, if VMWare's anything to go by, there are hypervisor patches specifically to do the correct reporting (like PCID) and mitigations for Spectre & Meltdown.

    Thanks for the feedback on the driver experiments.
     
  24. Stefan Froberg

    Stefan Froberg Registered Member

    Joined:
    Jul 30, 2014
    Posts:
    747
    In theory, yes. Let's say some bad guy knows intimately well where and how some open source browser X stores it's cookie data in memory.
    And not only that but also a way that it could be retrieved with client-side scritpting language, like JavaScript.

    Now, he/she could kick some domain up, copy-paste maybe some interesting stuff from some other site for content and then inject it with a
    piece of JavaScript code that sniffs your browser, sends the evil cookie grabbing payload toward you if the browser happens to be browser X,
    and then send it back to his/her server.

    Only thing left to do is to try to lure all the users of browser X to his/her evil page.

    But that was only theory, because browsers are not supposed to allow grabbing stuff from between different tabs (that is, say one tab where your online bank is open and another tab where the evil page is)

    That theory just became reality with the meltdown+spectre combo.

    @itman is right, there should be some browser standard for encrypting all the cookies/passwords etc.. all the sensitive info that's is keeped in memory.

    Also, there really is no any standard how login stuff is handled or encrypted (if it is encrypted at all!) and it's all implementation dependent.
    Your login security depends of the competence of the web developer. (nothing stops them sending your login stuff in plaintext in those cookies
    and your only hope is that they at least were wise enough to use HTTPS during the whole session...hopefully)

    In the early days (when HTTPS was not yet common) there was HTTP Basic auth but that was laughtably insecure (uses easily reversible base64)
    It was replaced by HTTP Digest Access Authentication (RFC 2069) and later strengthened version (RFC 2617) but unfortunately many of the enchancements to login process were optional and MiTM attack was easy (remember, HTTPS was still rare in those days, around 1997), they could force clients to use weaker RFC 2069 or even just the Basic auth.

    So two standard ways to handle login, one horribly weak and one only little bit stronger. And then all the rest out there are non-standard, ad hoc methods.
    :(

    Only hope is HTTPS, keep all the sensitive stuff as long encrypted as possible, keep machine patched and cross fingers .....
     
  25. Tinstaafl

    Tinstaafl Registered Member

    Joined:
    Jul 30, 2015
    Posts:
    884
    Location:
    USA
    HitmanPro.Alert offers keystroke encryption as an anti-keylogger risk reduction. So the browser dialogue boxes where you enter info are protected by encryption. I wonder if this extends to the data being stored in memory?
     
  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.