53

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?

Antek
  • 663
  • 1
  • 5
  • 9
  • 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 '18 at 10:07
  • Most CPUs do contain a hardware debugger facility, usually a JTAG access port. But Meltdown and Spectre are unrelated to these. – Lie Ryan Jan 12 '18 at 14:16
  • 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 '18 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 '18 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; https://www.wired.com/story/intel-management-engine-vulnerabilities-pcs-servers-iot/ – BooleanCheese Jan 12 '18 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 '18 at 15:49
  • 2
    @Nobody, Spectre is an inevitable side effect of having a branch predictor and speculative execution without having an architecture-level concept of "process" -- various processor features can make it easier or harder to perform, but you can't speculatively execute without observable side effects. Meltdown, on the other hand, is the result of a questionable-at-best design decision on Intel's part. – Mark Jan 12 '18 at 19:24
  • @Mark: Letting speculation read data already present in L1 and L2 cache but never cause cache loads/evictions would go a long way toward prevention. Sure, you'd still have timing dependent on which cache line you were accessing, and that might still be a side channel usable for communication in some way, but the connection between the improper data read and the side channel is broken. – Ben Voigt Jan 12 '18 at 23:45
  • @BenVoigt, you don't need a cache at all to perform the attack. Anything that makes a controllable change to the CPU's microarchitecture can be used: for example, on most CPUs you could perform an IDIV on the speculatively-read data and measure how long it takes, since the common implementation of integer division takes a varying amount of time depending on the numbers being operated on. The proof-of-concept attacks use the cache as their side channel because of the favorable signal-to-noise ratio. – Mark Jan 13 '18 at 00:00
  • @Mark: It's not sufficient for a speculatively-executed instruction to take a data-dependent length of time, you have to be have an observable effect. Having cache shared between speculative and non-speculative execution is what makes that possible. You flippantly say "measure how long it takes" but you can't actually do that unless there is a measurable delay on a non-speculative instruction. – Ben Voigt Jan 13 '18 at 04:40
  • @BenVoigt, cache isn't the only thing that's shared. Execution units are shared (an ALU that's busy performing an IDIV can't also perform an ADD), load/store units are shared, the instruction dispatcher is shared -- in a modern superscalar processor essentially everything except the instruction retirement unit is shared. – Mark Jan 13 '18 at 05:20
  • @Mark: I can't imagine that any datapath designer would give precedence to a speculative instruction when there is another instruction waiting for the same resource. So while that concept is a theoretical possibility, it would be a rare architecture where it actually turns out to be a vulnerability in the real-world implementation. – Ben Voigt Jan 13 '18 at 05:24
  • @Ben I doubt that a long running speculative instruction (say a division) would be stopped halfway through to execute a non-speculative instruction. Doesn't seem implausible to use that. – Voo Jan 14 '18 at 19:26
  • 1
    If they were "openly known as debug tools", then where's the technical documents from, say, more than half a year ago, which describe how to use them as such with any significant degree of reliability, and with less effort than more normal means (such as, say, a kernel debugger)? There's tons of good books on low-level programming out there. Can this guy cite even one single reference which would support his claim? – user Jan 15 '18 at 12:11
  • 1
    Possible duplicate of Meltdown and Spectre Vulnerabilities – DonielF Jan 15 '18 at 16:30
  • @Nobody The problem with calling it a flawed specification is that you have to say what is flawed about the specification. The CPU is doing nothing that it shouldn't; and doing everything it should. In order to criticize the specification you have to point out where any problem is. You might complain that all processors are vulnerable to side-channel attacks; but all processors are vulnerable to side-channel attacks. – Ian Boyd Jan 15 '18 at 21:47
  • @Joshua it's rather unprobable, as the guy said also that he even attended Intel's trainings on using this (whatever this was) – Antek Jan 17 '18 at 12:09
  • 2
    Hi @Antek - no, your question is purely about an odd claim someone has made. The canonical is for discussion on the vulnerability and performance. – Rory Alsop Jan 17 '18 at 12:47

3 Answers3

164

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.

Mark
  • 34,646
  • 9
  • 87
  • 137
  • 94
    a proper debugger is much faster, at least a couple billion times faster. – ThoriumBR Jan 12 '18 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 '18 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 '18 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. – thomasrutter Jan 15 '18 at 01: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 '18 at 09:14
  • 1
    Maybe the CIA used them as debug tools ;) – Robert Niestroj Jan 15 '18 at 09:52
  • @Agent_L I agree with the question being preposterous. Regarding which answer should I accept I need to think a while about it – Antek Jan 15 '18 at 12:05
  • @Agent_L ok, what would you suggest me to do altogether? Should I delete the question (and perhaps merge it into https://security.stackexchange.com/questions/176803/meltdown-and-spectre-vulnerabilities )? – Antek Jan 15 '18 at 15:14
  • 1
    @RobertNiestroj NSA, probably. – Wayne Werner Jan 15 '18 at 15:49
  • Naming the "proper debugger" would add weight to the argument. Outside of Intel nobody would have access to such a debugger? Remember we are talking about debugging the processor here, not code execution. Interesting that this cannot be suppressed or masked with microcode/firmware tweaks though? – mckenzm Jan 15 '18 at 18:33
  • @mckenzm, which debugger? All of them. Any competently-written debugger will be able to access (with proper permissions) process memory, kernel memory, and register contents; neither can (directly) access cache contents or other processor-internal state. The difference in capabilities between Meltdown/Spectre and a debugger is that Meltdown/Spectre doesn't require permission. – Mark Jan 15 '18 at 19:08
  • 1
    @Antek By all means, do not delete this question! You wouldn't be doing anybody a favour. Yes, you did get a lot of rep due to asking a popular question... But there's nothing wrong about it, it happens all the time. Just enjoy it! Also, choosing which answer to accept is your right. The only piece of advice I'd give you is not to be hasty choosing one, especially when your question gets a lot of attention and more answers are likely to come. That's all. Welcome to Security Stack Exchange! – Fabio says Reinstate Monica Jan 15 '18 at 22:38
  • @Mark , I believe debugwire accesses on-chip states. Only SOC CPU's will have on-die process memory (SRAM) . I know of no software debugger that can track out of order execution at a physical level (pipeline view). All I have seen are animated infographics, and possibly some thermal imaging. – mckenzm Jan 16 '18 at 01:26
79

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.

user
  • 7,795
  • 2
  • 31
  • 57
billc.cn
  • 3,936
  • 1
  • 18
  • 25
22

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.

Nat
  • 1,441
  • 2
  • 12
  • 13