Skip to content
HomeVideos
AllLongsCategoriesPlaylists
BooksBlogsPodcasts
HistoryListsWatch laterLiked videosFollowing

The videos, books, blogs and podcasts Hacker News keeps recommending, all in one place.

VideosBooksBlogsPodcastsAboutPrivacySettings

Data from Hacker News, HackerTube, HackerBooks, HackerBlogs and Open Library. Credits · Not affiliated with Y Combinator.

HomeVideosBooksBlogsPodcasts
Ctrl K

    The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation

    Black Hat

    1 HN recommender · recommended in 5 months, 2017–2022

    YouTube

    46:34 · 169K views · Dec 29, 2015

    Christopher Domas's Black Hat 2015 talk on a long-unnoticed x86 design flaw that lets an attacker reach System Management Mode, a ring below the OS. It explains how the legacy architecture allows universal privilege escalation and persistent, hard-to-detect malware.

    Cited in discussions of CPU hidden features, Intel's security failures and SMM malware as a concrete example of a forgotten processor feature being exploited.

    Systems, Networks & SecuritySecurity & hackingComputer architecture & CPUs
    1. 44:29
      Breaking the x86 Instruction SetBlack Hat381K views • 9 years ago
    2. 51:00
      GOD MODE UNLOCKED - Hardware Backdoors in x86 CPUsBlack Hat319K views • 8 years ago
    3. 44:29
      Behind the scenes of iOS and Mac SecurityBlack Hat36K views • 6 years ago
    4. 5:22
      Lest We Remember: Cold Boot Attacks on Encryption Keyspucitp749K views • 18 years ago
    5. 54:35
      BlueHat IL 2023 - David Weston - Default SecurityMicrosoft Israel R&D Center47K views • 3 years ago
    6. 45:14
      DEF CON 19 - Artem Dinaburg - Bit-squatting: DNS Hijacking Without ExploitationDEFCONConference4K views • 13 years ago
    7. 46:04
      DEF CON 26 - Christopher Domas - GOD MODE UNLOCKED Hardware Backdoors in redacted x86DEFCONConference86K views • 8 years ago
    8. 48:02
      BlackHat USA 2011: SSL And The Future Of AuthenticityChristiaan00895K views • 15 years ago
    9. 26:28
      Nicholas Carlini - Black-hat LLMs | [un]prompted 2026unprompted389K views • 7 months ago
    10. 21:28
      DEF CON 26 - Christopher Domas - The Ring 0 Facade Awakening the Processors Inner DemonsDEFCONConference24K views • 8 years ago
    11. 51:32
      Behind the Scenes of iOS SecurityBlack Hat127K views • 10 years ago
    12. 45:14
      DEFCON 19: Bit-squatting: DNS Hijacking Without Exploitation (w speaker)Christiaan00824K views • 14 years ago
    13. 33:36
      Black Hat 2013 - Exploiting Network Surveillance Cameras Like a Hollywood HackerHackersOnBoard1.1M views • 12 years ago
    14. 10:58
      Flaw in the Enigma Code - NumberphileNumberphile5.4M views • 13 years ago
    15. 24:28
      Ichthyology: Phishing as a ScienceBlack Hat38K views • 9 years ago
    16. 59:23
      28c3: The Science of Insecurity28c342K views • 14 years ago
    17. 1:32:33
      C++ and Beyond 2012: Herb Sutter - atomic Weapons 2 of 2alexsmail29K views • 9 years ago
    18. 1:09:16
      Defeating Ssl Using Sslstrip (Marlinspike Blackhat)TheSecurityTube61K views • 14 years ago
    19. 21:20
      Cracking Enigma in 2021 - ComputerphileComputerphile2.9M views • 5 years ago
    20. 50:06
      Protected KVM on Arm64: A Technical Deep Dive - Quentin Perret, GoogleThe Linux Foundation6K views • 4 years ago

    6 comments from Hacker News

    1. @sabas123Jul 2022· in “Intel Microcode Decryptor”

      This is a thing and was used in this fantastic piece: this video However the way they obtained these dumps is by going deep into debugger mode of the cpu which makes me doubt anything spooky would be going on.

      RecommendsView on HN
    2. @jerfJan 2018· in “Reading privileged memory with a side-channel”

      I can imagine some ways to armor the branch predictor, similar in principle to how languages like Perl have to include a random seed in their hash code (in some circumstances) to avoid being able to pre-compute values that will all hash to the same thing [1]. There should be some ways to relatively cheaply periodically inject such a randomization into the prediction system enough to prevent that aspect of the attack. This will cost something but probably not be noticeable to even the most performance-sensitive consumers. But no solution leaps to mind for the problem of preventing speculative code from leaking things via cache, short of entirely preventing speculating code from being able to load things into the cache. If nobody can come up with a solution for that, that's going to cost us something to close that side channel. Not sure what though, without a really thorough profiling run. And I'd put my metaphorical $5 down on someone finding another side channel from the speculative code; interactions with changing processor flags in a speculative execution, or interaction with some forgotten feature [2] where the speculation ends up incorrectly undone or something. Yuck. [1]: [LINK] [2]: this video - The Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation (Dec 29, 2015)

      CitesView on HN
    3. @throwaway47292Dec 2021· in “Professional maintainers: a wake-up call”

      I can make an argument that money will make it even worse, as people will full-time make even more useless features that just increase the attack surface. This particular class of problems (same as the sqlite fts tokenizer exploit and most of openssl exploits, even lots of the sendmail exploits) are just obscure unused features. It happens even in CPUs themselves. (e.g. this video ) Removing code is twice harder than adding code, why do you think paid maintainers would improve anything? Just look at the code written in FAANG or any enterprise, and those maintainers are very well paid, imagine this code being public, we will have 1 new exploit per day per company... and that is assuming non malicious developers that can be shipping trojan code [LINK] (it is also hard to assume all millions of developers are non malicious, even if we assume 1 in 100000, things look really bad) Less code is the one solution. Regardless if open source or enterprise code. We are stuck, and change is needed, but money is not a solution, and might even be the cause of the problem. (incentive to write more code)

      CitesView on HN
    4. @kogepathicNov 2017· in “MINIX – The most popular OS in the world, thanks to Intel”

      > adding the possibility to turn it off should suffice. How could Intel/AMD reasonably communicate this to customers and have it taken at face value? "Here's a flag to disable this black box we ship in every CPU. The product design and source code are proprietary, so please take our word for it that this flag disables everything." There was a blackhat talk on embedding malware in SMM and triggering it with a magic number written to a register to escalate the process privileges. [0] So there will always be suspicion of special triggers to re-enable the black box that you turned "off" I think there is a very slim chance that Intel and AMD can regain credibility when it concerns the IME/PSP. Especially after it emerged Intel created a special ME disabled mode intended for US agency customers. [1] [0] this video [1] [LINK]

      CitesView on HN
    5. @ryackoNov 2017· in “Qubes OS: A reasonably secure operating system”

      Then from recent Defcon and Black Hat talks, they are an absymal failure. ( this video Memory Sinkhole - Unleashing An X86 Design Flaw Allowing Universal Privilege Escalation ) (I don't understand it beyond what everyone says it can achieve) Intel should be considered to be totally unreliable and incompetent. I mean, no one buys office store safes and expects their things to be secure in them. But a processor is a little more expensive than a cheap safe and holds more valuable things. Edit: and besides, Fortezza is an SSL protocol option.

      CriticalView on HN