I heard from a guy that's involved in low-level (assembler, C for drivers and OSes) programming, that meltdown and spectre weren't actually vulnerabilities discovered only so recently, but they were openly known as debug tools. It seems quite unlikely, but could anyone confirm or deny this?

  • 20
    Spectre and Meltdown aren't actually bugs or breaches per se. They are vulnerabilities. They happen to exploit a 'bug' in the CPU architecture, resulting in a breach of the memory isolation. Even the CPU architecture is arguably not a bug, as it's performing following the conception requirements.
    – M'vy
    Jan 12, 2018 at 10:07
  • 31
    @M'vy That's just what Intel's PR says - but if they correctly implemented flawed specifications, then you can still rightfully call it a bug, only the bug is on the concept level instead of the programming level. In a way that's even worse.
    – Nobody
    Jan 12, 2018 at 15:01
  • 8
    It's arguable. There's a difference in correctly implementing flawed specification, and incorrectly implementing flawless specifications. I haven't dug what are the requirements, but I think they never intended to design chip with cache side-channel resistant property. We know 'now' that the design is faulty, so I wouldn't immediately call blame on them. If they did this knowingly, that's another problem. Anyway, we're digressing here, you can show up in The DMZ if you want to discuss.
    – M'vy
    Jan 12, 2018 at 15:10
  • 38
    Hey @Antek, I believe the guy who told you this was referring to the Intel Management Engine exploit, which has since been patched but was discovered recently enough that all these exploits could have easily been mixed up; wired.com/story/… Jan 12, 2018 at 15:38
  • 5
    @BooleanCheese seems very likely, 'cause later he diverted to tell me as well about possibility to execute remotely from ethernet (with no net activity on the network adapter visible)
    – Antek
    Jan 12, 2018 at 15:49

3 Answers 3


A normal debugger uses documented API/syscall/instruction to look at state of a process it is permitted to access. Just being a debugger alone cannot bypass OS memory protection, otherwise anyone who knows how to download stuff can gain admin access on any system.

Meltdown and spectre attacks use (previously) undocumented and unintended side-effects of certain internal processor design flaws to exfiltrate information that the attacking code are not permitted to access.

In addition, these attacks (Meltdown in particular) are not very good for debugging purposes as they can only passively observe memory on a probabilistic level. A deliberate backdoor used for debugging, e.g. JTAG on embedded systems, would allow direct and realtime memory access.


It's not even remotely true. Although you can use a Meltdown or Spectre attack to inspect the internals of a program in the way a debugger can, a proper debugger is much faster, easier, and more reliable.

  • 94
    a proper debugger is much faster, at least a couple billion times faster.
    – ThoriumBR
    Jan 12, 2018 at 13:27
  • 4
    even though it was the first, is the most voted for and is the most brief answer, I decided to change the accepted answer to the one that is more comprehensive in my mind. Feel free to comment on this move from me, as I'm a novice regarding security. I also definitely think I just accidentally rode a wave of a popular topic, gaining as much rep points in two days as during whole 2 years of programming on Stack Overflow.
    – Antek
    Jan 14, 2018 at 17:34
  • 1
    There is a necessary distinction between a debugger and a debugging aid. It is always useful to have on chip methods to peek at what is going on. Otherwise how could we trust the marketing animations for these features?
    – mckenzm
    Jan 14, 2018 at 19:36
  • 3
    I like this answer better because it more directly and simply addresses the thrust of the question. The other one also appears accurate and goes into more detail but I fear that getting into too much detail muddies the issue and may lose some people unfamiliar with the technical terms; the fact of the matter is that the claim is not remotely true and there is an easy non-technical argument showing why. Jan 15, 2018 at 1:14
  • 4
    @Antek Your question is pretty much as preposterous as "Do cows fly?". You don't need comprehensive explanation on why they don't. When challenging common sense, the burden of proof lies on the asker. You haven't provided a single hint how meltdown and spectre could be useful for debugging, so you can't expect the answerer to provide any details on that.
    – Agent_L
    Jan 15, 2018 at 9:14

I heard from a guy that's involved in low-level (assembler, C for drivers and OSes) programming, that meltdown and spectre weren't actually vulnerabilities discovered only so recently, but they were openly known as debug tools

They may've gotten their wires crossed with another major vulnerability that was apparently recommended as a debugging tool about 1.5 months back.

The vulnerability's described in

which was disclosed in a thread on the Apple Developer Forums as a potential solution about 2 weeks before it made the news as a major security flaw:

Solution 1:

On startup, click on "Other"

Enter username: root and leave the password empty. Press enter. (Try twice)

If you're able to log in (hurray, you're the admin now), then head over to System Preferences>Users & Groups and create a new Admin account.

-response in "Updated to High Sierra, all Admin accounts now Standard", Apple Developer Forums

This vulnerability made a lot of news, and folks were cracking jokes about how it was casually disclosed as a helpful hint on the forums.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .