intel cpu bug found

[Antilogic]

I just ran a check for Windows updates on my work machine. . . . . apparently there aren't any. Checked the OS version and yep its the applicable one.
This below certainly implies the fix is officially rolled out and not a work in progress to be applied manually.

"This update will be downloaded and installed automatically from Windows Update."

I've been downloading patches for work and MS Servers have been hammered so it might not be accessible for you yet. Or it's been downloaded already for you.

Edit: New note, if your AV Provider hasn't updated a certain reg key yet, it won't be available for you.

[Morkonan]

AFAIK, Microsoft OS consumer patches will be available on Patch Tuesday. (Jan 9)

Before anyone panics and as far as I know, there isn't any evidence this vulnerability has been used in "the wild." (Or, at least, nobody is talking about it if it has.)

https://www.theverge.com/2018/1/4/16848 ... urity-flaw

There's an emergency patch out, now, but there will probably be something a bit cleaner, later.

Update your browsers and any AV software.

[kohlrak]

When OSes, in practice, are providing their own methods of thwarting the protection, why is the cache thing even an issue? The consistent statement of the OSDEVs is that reading the kernel's memory, as well as 2 ring 3 programs reading each other's memories, is not a problem.

Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

Win7, here, and tsearch and cheatengine still work. Yes, they use the same hooks API. It probably has some changes, but it does the same thing. As for not reading access down, you're right, but realistically we always knew what was there. Part of the protection is protecting applications in one ring from each other, which they intentionally thwarted, which then gives rise to other programs that might be in one ring but through some other API step up (poorly made drivers?). Hooks are not necessary for debugging, and the API shouldn't really exist.

Think I'll need a [citation needed] on that? There was a hook API in the Windows API back in 16-bit days that allowed a process to read another process's memory, but I'm not sure the same exists in Win32. In addition, it's never been possible for Ring 3 code to read Ring 0 memory (outside of CPU bugs and timing attacks)--the Ring 0 memory being *visible* in the Ring 3 process doesn't mean it's readable, what *should* happen is that you get an access violation error if you attempt it.

There are APIs like the helpfully named ReadProcessMemory in Win32, but that requires specific privileges and doesn't just allow you to crash around reading anything's memory. kohlrak seems to be unaware of the last decade of work on the separation of privileges in Windows - this would have been a fairly fair characterisation in the XP days when basically everything was administrator and you could load unsigned drivers, but we're a long way from that now. As far as I know Linux has never been as bad as claimed (though they've certainly tightened up kernel isolation too).

Protecting the user from himself. This is a separate issue, and while it supposedly improves security, a user should be able to do with their machine what they want. To be fair, there is a workaround, but it's unhealthy. Signing methods can be thwarted, anyway, so it just ends up being a way to charge devs to be able to develope. I noticed when i used visual studio to make a program on this computer, i sent the demo to people on win10 and they said it wouldn't let them run it.

There never was a bug: people just made incorrect assumptions: the OS devs for assuming they didn't need to use the cache management instructions, and everyone else for assuming that it wasn't an OS design flaw.

Isn't "people just made incorrect assumptions" exactly what a bug is? Just because you think this is obvious in hindsight doesn't mean it was - there's a giant gulf between "this is documented behaviour" and "this documented behaviour allows the following security breaches", and the fact that it's been two decades since Intel introduced speculative execution in the Pentium Pro before anybody figured this out should demonstrate that. I think this particular behaviour ("Meltdown") is surprising, and not an obvious consequence of the way processors work, especially given AMD isn't vulnerable. (The fact that Spectre like attacks are possible is less surprising, and they're also a lot fiddlier to pull off.) I also don't think you can pin all the blame on OS developers, given x86 provides instructions (SYSENTER family) specifically to allow getting to ring 0 without expensive operations like interrupts and cache flushes - this is clearly the way it's meant to be used, or SYSENTER etc would just flush caches.

If sysenter flushed caches automatically, that takes away the ability of the OS dev to control which need flushed. Plus, syscall/sysenter, iirc, is an interrupt, anyway. I forget if it's set in an MSR or tied to a specific number. I never looked that deep into it since my kernel was a toy.

But, no, that's like saying everyone's obligated to tell everyone not to use gets(), because of buffer overflows. It's up to you to figure this out. I'm responsible for the security of my code, not the library I use, unless i was made certain specific guarantees (like with read functions that specify the size of the buffer). The bug is in the OSes, not the processors.

Also, Meltdown also apparently affects the newer ARMs as well, otherwise patches would not have been made for them as well. That means AMD *IS* likely affected. If not, that might be another reason why AMD's been behind. Though, to be fair, I've warned people about Out-of-Order execution potentially being hazardous for other reasons. Lately, processor improvements have circled around trying to tackle Wirth's Law, rather than actual improvements, hence intel's cache size increased processors having creamed AMD's focus on increasing execution speed of individual instructions: compilers overpadd, devs don't seem to set optimization flags, etc.

AFAIK, Microsoft OS consumer patches will be available on Patch Tuesday. (Jan 9)

Before anyone panics and as far as I know, there isn't any evidence this vulnerability has been used in "the wild." (Or, at least, nobody is talking about it if it has.)

https://www.theverge.com/2018/1/4/16848 ... urity-flaw

There's an emergency patch out, now, but there will probably be something a bit cleaner, later.

Update your browsers and any AV software.

Outside of the NSA, you mean? We're finding alot of security holes, as of late, and how did we suddenly catch these?

[Morkonan]

...Outside of the NSA, you mean? We're finding alot of security holes, as of late, and how did we suddenly catch these?

Security issues are found all the time, especially as our tools for finding them get better. Of course, it helps if someone throws up a bunch of tools online for free that were developed by people who's business it developing such things...

Finding new bugs and exploits is going to keep happening and will become more frequent the more packages we have and the more complex they are. It's the way of things.

[greypanther]

I have to admit that I find all this fascinating, ( though obviously lack the education to understand it properly, ) but a question occurs to me: Will it put people off allowing so much of themselves online? Or even just on their connected PC? Identity theft is a frightening thing after all, at least to me.

I have always thought people were way to blasé about their online details and leave way too much information way too open. Now it seems even if you are careful, you may be leaving yourself too open to attack.

Bottom line: will it affect how you use the internet/your PC? Or will most just ignore it and carry on as usual?

[mrbadger]

I'm not desperately concerned by this.

Connecting a computer to a network is probably the worst form of vulnerability yet encountered by technology, and there's no way to prevent that being unsafe.

As for shock horror government agencies being able to scan your stuff!!!!

Well, people are happily filling their houses with network connected surveillance equipment, and queuing up for the privilege of doing it too, not to mention documenting virtually every aspect of their lives online for all to see, so I think that boat has sailed.

[greypanther]

Well, people are happily filling their houses with network connected surveillance equipment, and queuing up for the privilege of doing it too, not to mention documenting virtually every aspect of their lives online for all to see, so I think that boat has sailed.

Speak for your self!

I will avoid all that crap for as long as I am able!

[pjknibbs]

I don't see the point of letting this change your online habits, so long as you're reasonably careful in the first place. After all, the aforementioned dodgy Javascript on a web page isn't going to run if I have it blocked in NoScript, and if it can't run it can't exploit the bug. Of course, I also have an AMD CPU which is apparently not susceptible to Meltdown, and Spectre is (a) hard to exploit and (b) only allows cross-application memory hacking rather than kernel-level stuff AFAIK, so it's intrinsically less dangerous.

[Morkonan]

...Bottom line: will it affect how you use the internet/your PC? Or will most just ignore it and carry on as usual?

Few people ever take proactive measures, even when a big exploit is announced.

But, the thing is that if someone wants "in", they're gonna get in. (Oh, I'm sure someone is going to come along and lecture me on why that can't happen.)

The most important thing you can do is to keep your OS up to date as well as any security software you have.

NEVER, EVER "trust" anything to protect you from your own ignorance.

Don't click on stuff if you don't know what it is.

Don't download stuff if you don't know who made it and what it is.

Don't install stuff you can't authenticate as coming from a trusted source and that does trusted stuff with your trusted stuff.

Don't open emails from senders you don't recognize and, especially, don't accept any attached files from sources you can't authenticate. And, if there isn't a reason they should be emailing you about anything, maybe give them a phone call, just to check.

Don't engage in risky online behaviors, like surfing pron sites, posting incriminating pictures of your private parts, engaging in embarrassing webcam activity, pirating software, blah blah blah.

Even so, if someone wants to get in, they're going to get in. How difficult are you going to make that for them? The more difficult it is, the more determined they have to be in order to succeed. Most issues aren't caused by targeted attacks or, at least, don't start that way.

No hacker worth worrying about is going to spend their time specifically trying to hack some grandma's computer. Everything is automated, which is good for innocent users, since they can get easy protection for "known" common issues without having to turn their boxes into NORAD database servers that are prepared for "anything."

But, you can't protect yourself from yourself unless you take appropriate measures, like learning what and where the risks are.

[red assassin]

Win7, here, and tsearch and cheatengine still work. Yes, they use the same hooks API. It probably has some changes, but it does the same thing. As for not reading access down, you're right, but realistically we always knew what was there. Part of the protection is protecting applications in one ring from each other, which they intentionally thwarted, which then gives rise to other programs that might be in one ring but through some other API step up (poorly made drivers?). Hooks are not necessary for debugging, and the API shouldn't really exist.

tsearch and cheatengine require elevated privileges to run, which is the entire point. The more powerful features of cheatengine require that it installs itself as a hypervisor (i.e., it runs the system with Windows running in a VM), thus installing itself at a privilege level above the kernel. Again, it needs to be highly privileged in the first place to do this.

Further, debuggers by definition allow all of these capabilities - being able to arbitrarily read/write a debugged process is pretty much the definition of a debugger - so I'm not sure why you state debuggers don't need to be able to. I don't think the argument that processes at the same privilege level should be protected from each other reflects modern security thinking very well - if you're the same privilege level, you can access all the same data as the other process, debug it, or modify it and rerun it. Instead, we use multiple levels of privilege which are isolated from each other - separate user accounts, sandboxes, process elevation levels, capabilities, features like the new Virtual Secure Mode in Windows, and the like.

Also, Windows 7 is eight years old at this point, and hardly the very model of a secure operating system.

Protecting the user from himself. This is a separate issue, and while it supposedly improves security, a user should be able to do with their machine what they want. To be fair, there is a workaround, but it's unhealthy. Signing methods can be thwarted, anyway, so it just ends up being a way to charge devs to be able to develope. I noticed when i used visual studio to make a program on this computer, i sent the demo to people on win10 and they said it wouldn't let them run it.

That's... not at all what separation of privileges is about. It protects your documents from your sandboxed browser processes, it protects your login credentials from everything else, it protects your data from other users on the same system, it protects your kernel from things installing themselves as drivers. (The main reason Microsoft cracked down on driver signing enforcement is that the majority of Windows crash reports were caused by badly written drivers, including antiviruses!) As the user you can turn any and all security measures off if you want to, but it's deliberately hard because you shouldn't be doing that unless you have a damn good reason, and you probably don't.

If sysenter flushed caches automatically, that takes away the ability of the OS dev to control which need flushed. Plus, syscall/sysenter, iirc, is an interrupt, anyway. I forget if it's set in an MSR or tied to a specific number. I never looked that deep into it since my kernel was a toy.

But, no, that's like saying everyone's obligated to tell everyone not to use gets(), because of buffer overflows. It's up to you to figure this out. I'm responsible for the security of my code, not the library I use, unless i was made certain specific guarantees (like with read functions that specify the size of the buffer). The bug is in the OSes, not the processors.

Also, Meltdown also apparently affects the newer ARMs as well, otherwise patches would not have been made for them as well. That means AMD *IS* likely affected. If not, that might be another reason why AMD's been behind. Though, to be fair, I've warned people about Out-of-Order execution potentially being hazardous for other reasons. Lately, processor improvements have circled around trying to tackle Wirth's Law, rather than actual improvements, hence intel's cache size increased processors having creamed AMD's focus on increasing execution speed of individual instructions: compilers overpadd, devs don't seem to set optimization flags, etc.

SYSCALL/SYSENTER is not an interrupt - that's literally the entire point of the instruction (replacing the old int 0x80 approach). Also, the Meltdown vulnerability is quite specific - it's not like it's situation dependent; the vulnerability exists as long as the ring 0 memory pages are mapped while executing in ring 3 (i.e. the way every kernel on x86 and similar architectures have always worked), so if this was a known insecure thing the fix would be to have the instructions enforce that, or at the very least have a giant "this is insecure" warning in the documentation.

Speaking of which: Have you read the man page for gets() recently? It starts with "Never use this function." (underline in original). Or have you tried actually using it? It's removed from modern versions of C, and if you deliberately request an older version, the compiler and linker both output warnings (by default, I haven't turned on any extra warnings here). Security isn't about waiting until everyone gets pwned and then chortling "well you should have known not to do that, peasant" at the responsible developer. We can't possibly expect every developer to be intimately aware of every possible security issue. If something's unsafe, you make it as hard as possible for people to do it.

AMD's microarchitecture is quite specifically not vulnerable to Meltdown because they do not do the speculative reads that are responsible; ARM and Intel both do. It's possible there are other flaws in AMD's architecture that lead to similar results, but that would be a separate vulnerability with a separate exploitation approach (and I suspect they'd have had a damn good look before publicly proclaiming their immunity to Meltdown).

Outside of the NSA, you mean? We're finding alot of security holes, as of late, and how did we suddenly catch these?

Because we (fairly abruptly) hit the point as a society at which security issues started costing a serious amount of money, and therefore a serious amount of money started getting thrown at trying to deal with them. Google's Project Zero is responsible for a lot of the big security flaws that have been published in the last couple of years, and it's an incredibly expensive endeavour employing a lot of very expensively talented researchers, for example, and many of the large tech firms have their own security teams with similar goals.

[kohlrak]

I have to admit that I find all this fascinating, ( though obviously lack the education to understand it properly, ) but a question occurs to me: Will it put people off allowing so much of themselves online? Or even just on their connected PC? Identity theft is a frightening thing after all, at least to me.

I have always thought people were way to blasé about their online details and leave way too much information way too open. Now it seems even if you are careful, you may be leaving yourself too open to attack.

Bottom line: will it affect how you use the internet/your PC? Or will most just ignore it and carry on as usual?

Back in the day, there was this company called FunWebProducts that gave away free programs like "Cursor Mania," "Smiley Central," and "Zwinky." They hooked you by annoying ads with sound, and also anyone downloading it would send you content that you could only see via getting it yourself. After using it myself for some time, my antivirus ended up targetting it. I found out it wasn't a false positive, did some research, found out that they openly admit (in legalese) stealing your personal information (including financial information) and that you agree that you won't hold them responsible if one of their workers makes off with this information and sells it or uses it themselves (in case of your debit and credit card numbers). You should've seen people's responses to my posts before all this, and how they responded when i pointed this out. Basically, people started to pretend that i didn't exist, because i was bursting their bubble.

TL;DR: people will respond with apathy.

...Bottom line: will it affect how you use the internet/your PC? Or will most just ignore it and carry on as usual?

Few people ever take proactive measures, even when a big exploit is announced.

But, the thing is that if someone wants "in", they're gonna get in. (Oh, I'm sure someone is going to come along and lecture me on why that can't happen.)

The most important thing you can do is to keep your OS up to date as well as any security software you have.

NEVER, EVER "trust" anything to protect you from your own ignorance.

Don't click on stuff if you don't know what it is.

Don't download stuff if you don't know who made it and what it is.

Don't install stuff you can't authenticate as coming from a trusted source and that does trusted stuff with your trusted stuff.

Don't open emails from senders you don't recognize and, especially, don't accept any attached files from sources you can't authenticate. And, if there isn't a reason they should be emailing you about anything, maybe give them a phone call, just to check.

Don't engage in risky online behaviors, like surfing pron sites, posting incriminating pictures of your private parts, engaging in embarrassing webcam activity, pirating software, blah blah blah.

Even so, if someone wants to get in, they're going to get in. How difficult are you going to make that for them? The more difficult it is, the more determined they have to be in order to succeed. Most issues aren't caused by targeted attacks or, at least, don't start that way.

No hacker worth worrying about is going to spend their time specifically trying to hack some grandma's computer. Everything is automated, which is good for innocent users, since they can get easy protection for "known" common issues without having to turn their boxes into NORAD database servers that are prepared for "anything."

But, you can't protect yourself from yourself unless you take appropriate measures, like learning what and where the risks are.

You ask a bit much from people. On the other hand, I say people deserve the trouble they get into online. That said, enjoy this quote:

Hear me out. Linux is Microsoft's main competition right now. Because of
this we are forcing them to "innovate", something they would usually avoid.
Now if MS Bob has taught us anything, Microsoft is not a company that
should be innovating. When they do, they don't come up with things like
"better security" or "stability", they come back with "talking
paperclips", and "throw in every usless feature we can think of, memory
footprint be dammed".

Unfortunatly, they also come up with the bright idea of executing email.
Now MIME attachments aren't enough, they want you to be able to run/open
attachments right when you get them. This sounds like a good idea to
people who believe renaming directories to folders made computing possible
for the common man, but security wise it's like vigorously shaking a
package from the Unibomber.

So my friends, we are to blame. We pushed them into frantically trying to
invent "necessary" features to stay on top, and look where it got us. Many
of us are watching our beloved mail servers go down under the strain and
rebuilding our company's PC because of our pointless competition with MS.
I implore you to please drop Linux before Microsoft innovates again.

-- From a Slashdot.org post in regards to the ILOVEYOU email virus

Win7, here, and tsearch and cheatengine still work. Yes, they use the same hooks API. It probably has some changes, but it does the same thing. As for not reading access down, you're right, but realistically we always knew what was there. Part of the protection is protecting applications in one ring from each other, which they intentionally thwarted, which then gives rise to other programs that might be in one ring but through some other API step up (poorly made drivers?). Hooks are not necessary for debugging, and the API shouldn't really exist.

tsearch and cheatengine require elevated privileges to run, which is the entire point. The more powerful features of cheatengine require that it installs itself as a hypervisor (i.e., it runs the system with Windows running in a VM), thus installing itself at a privilege level above the kernel. Again, it needs to be highly privileged in the first place to do this.

IIRC, not for 32bit apps, which still exist and will for a very long time, especially given the speed boost writing 32bit apps provides.

Further, debuggers by definition allow all of these capabilities - being able to arbitrarily read/write a debugged process is pretty much the definition of a debugger - so I'm not sure why you state debuggers don't need to be able to. I don't think the argument that processes at the same privilege level should be protected from each other reflects modern security thinking very well - if you're the same privilege level, you can access all the same data as the other process, debug it, or modify it and rerun it. Instead, we use multiple levels of privilege which are isolated from each other - separate user accounts, sandboxes, process elevation levels, capabilities, features like the new Virtual Secure Mode in Windows, and the like.

x86 and many other processors have special dedicated instructions to debugging. Why can't the debugger be added to the EXE on compile time? I've made my own. Linux and Windows both have APIs for writing your own debuggers within the programs. But no, userland is where the sensitive data is most likely to get collected. In windows, for example, the libraries for getting text from the user are userland. All you'd have to do is know the program you want to grab data from. For most cases, IE (edge is IE, i don't care what people say), Firefox, Chrome, etc., to get sensitive information.

Also, Windows 7 is eight years old at this point, and hardly the very model of a secure operating system.

The point is, it still exists in 64bit.

Protecting the user from himself. This is a separate issue, and while it supposedly improves security, a user should be able to do with their machine what they want. To be fair, there is a workaround, but it's unhealthy. Signing methods can be thwarted, anyway, so it just ends up being a way to charge devs to be able to develope. I noticed when i used visual studio to make a program on this computer, i sent the demo to people on win10 and they said it wouldn't let them run it.

That's... not at all what separation of privileges is about. It protects your documents from your sandboxed browser processes, it protects your login credentials from everything else, it protects your data from other users on the same system, it protects your kernel from things installing themselves as drivers. (The main reason Microsoft cracked down on driver signing enforcement is that the majority of Windows crash reports were caused by badly written drivers, including antiviruses!) As the user you can turn any and all security measures off if you want to, but it's deliberately hard because you shouldn't be doing that unless you have a damn good reason, and you probably don't.

Of course it's a separate issue. I asked myself why driver signing was brought up, but felt it a good opportunity. It's my device the software's running on. I should be able to take responsibility for my own actions. I shouldn't need my OS provider to be my nanny. I understand unsigned drivers cause bluescreens, but you could also benefit from not giving device drivers the option to bluescreen. KeBugCheck is callable from device drivers. Is it necessary? Absolutely not. Fix your bad design in the first place. Turn it into a wrapper and restart the device, which, IIRc, is what Linux does.

If sysenter flushed caches automatically, that takes away the ability of the OS dev to control which need flushed. Plus, syscall/sysenter, iirc, is an interrupt, anyway. I forget if it's set in an MSR or tied to a specific number. I never looked that deep into it since my kernel was a toy.

But, no, that's like saying everyone's obligated to tell everyone not to use gets(), because of buffer overflows. It's up to you to figure this out. I'm responsible for the security of my code, not the library I use, unless i was made certain specific guarantees (like with read functions that specify the size of the buffer). The bug is in the OSes, not the processors.

Also, Meltdown also apparently affects the newer ARMs as well, otherwise patches would not have been made for them as well. That means AMD *IS* likely affected. If not, that might be another reason why AMD's been behind. Though, to be fair, I've warned people about Out-of-Order execution potentially being hazardous for other reasons. Lately, processor improvements have circled around trying to tackle Wirth's Law, rather than actual improvements, hence intel's cache size increased processors having creamed AMD's focus on increasing execution speed of individual instructions: compilers overpadd, devs don't seem to set optimization flags, etc.

SYSCALL/SYSENTER is not an interrupt - that's literally the entire point of the instruction (replacing the old int 0x80 approach).

So how does one set up their kernel to accept syscall/sysenter?

Oh, i stand corrected. I looked it up, myself. So instead of using an ISR (which is a function pointed to by the IDT), you write a function that is pointed to by the GDT, and the address is in the MSRs. I made an incorrect assumption from the fact that both int80 and syscall work on linux.

Also, the Meltdown vulnerability is quite specific - it's not like it's situation dependent; the vulnerability exists as long as the ring 0 memory pages are mapped while executing in ring 3 (i.e. the way every kernel on x86 and similar architectures have always worked), so if this was a known insecure thing the fix would be to have the instructions enforce that, or at the very least have a giant "this is insecure" warning in the documentation.

That's not intel's job. You should learn how to use your tools. You can't sit there and write "this needs to be wrapped between calls to accomplish thsi for security" for every instruction or function. It's a fool's errand. Instead, the programmer should understand their tools and foresee this themselves.

Speaking of which: Have you read the man page for gets() recently? It starts with "Never use this function." (underline in original). Or have you tried actually using it? It's removed from modern versions of C, and if you deliberately request an older version, the compiler and linker both output warnings (by default, I haven't turned on any extra warnings here). Security isn't about waiting until everyone gets pwned and then chortling "well you should have known not to do that, peasant" at the responsible developer. We can't possibly expect every developer to be intimately aware of every possible security issue. If something's unsafe, you make it as hard as possible for people to do it.

They must've removed it fairly recently. Anyway, programmers are not toddlers, they shouldn't need nannies. You are supposed to know your tools. I can't nanny every developer out there. What if they make a buffer of size 1024, but then realize they want a larger buffer, but only raise the read function's number? How am i supposed to protect the programmer from themselves? The OS devs made some really stupid mistakes here. It's understandable that they made them, just as people who used gets() and got owned. But they need to accept responsibility for a stupid mistake instead of blaming the library provider for not being their nanny (to be fair, i dn't really see this from the OS devs).

AMD's microarchitecture is quite specifically not vulnerable to Meltdown because they do not do the speculative reads that are responsible; ARM and Intel both do. It's possible there are other flaws in AMD's architecture that lead to similar results, but that would be a separate vulnerability with a separate exploitation approach (and I suspect they'd have had a damn good look before publicly proclaiming their immunity to Meltdown).

So i was right, amd doesn't allow out of order execution.

Outside of the NSA, you mean? We're finding alot of security holes, as of late, and how did we suddenly catch these?

Because we (fairly abruptly) hit the point as a society at which security issues started costing a serious amount of money, and therefore a serious amount of money started getting thrown at trying to deal with them. Google's Project Zero is responsible for a lot of the big security flaws that have been published in the last couple of years, and it's an incredibly expensive endeavour employing a lot of very expensively talented researchers, for example, and many of the large tech firms have their own security teams with similar goals.

They've costed alot of money for a long time now. I honestly think the gravity of the NSA spying finally woke tech people up. Your average joe, unfortuntely, still couldn't care less. Your average Joe still yells at his TV as a joke.

[Tracker001]

"Explaining the Meltdown & Spectre exploits at a top-level, along with how they impact Intel, AMD, and ARM, particularly Intel."

Gamers NEXUS:
https://www.youtube.com/watch?v=-B1OGoVZcUQ

We're talking about Meltdown and Spectre today, two new attacks that affect nearly all modern CPUs. The Meltdown attack is the worse of the two, and presently has known impact to at least 10 years of Intel CPUs, with potential performance deficits in some applications from the solution. AMD and ARM don't get away clean, though, and are also affected by kernel-level exploits which attack using branch prediction vectors, using "Spectre." Between these two attacks, nearly every CPU on the market is impacted in some way. Security advisories and updates are already going out, and we should know more on January 9th about the performance hit from these updates.

Thing that I see as important to take note of is the bondry jump out of the virtural Machine environment .

Looks Like Any slow down that may occur will be application spacific .

Code: Select all

Sets aside reading time for the 9th when the embargo is lifted .

[pjknibbs]

AMD's microarchitecture is quite specifically not vulnerable to Meltdown because they do not do the speculative reads that are responsible

Given that AMD CPUs perform in the same ballpark as Intel ones, I suspect they're still doing the speculative instruction look-ahead, they're probably just more careful about cleaning up after it (or more careful to check for ring transitions when doing so). The problem is, Linux at least have decided to implement the kernel and user space separation across the board, so AMD chips will suffer the same slowdowns as their Intel counterparts--we have no idea as yet what Microsoft will do with their Windows patch.

[muppetts]

Hi! Can anyone give me a layman (as in a man laying down, holding his head and rocking back and forward saying 'this makes no sense to me!') explanation and boil it down for the basic end user? Is this more of a problem for big institutions and companies or is this something we could potentially see going mad across every intel pc?

[pjknibbs]

As I already said, the Meltdown exploit is trivially exploitable--a piece of malicious Javascript in a web page can do it (although Mozilla and Microsoft are both reducing the resolution of the timers their browsers support to mitigate this, since the attack requires very precise timing to work). So, yes, it could be a problem for any PC with an Intel processor. Conversely, there's approximately three-fifths of bugger all that an end user can do to mitigate the problem, so you just have to rely on the mitigations being provided by software and OS developers.

[muppetts]

As I already said, the Meltdown exploit is trivially exploitable--a piece of malicious Javascript in a web page can do it (although Mozilla and Microsoft are both reducing the resolution of the timers their browsers support to mitigate this, since the attack requires very precise timing to work). So, yes, it could be a problem for any PC with an Intel processor. Conversely, there's approximately three-fifths of bugger all that an end user can do to mitigate the problem, so you just have to rely on the mitigations being provided by software and OS developers.

So in essence that would be Microsoft for the majority of systems?

[kohlrak]

Looks Like Any slow down that may occur will be application spacific .

Well, there's 2 ways of doing this. See, and this is another reason why i'm faulting the OS devs, is that rings 1 and 2 probably won't get the same scrubbing, which essentially means we can still access anything that the drivers can, most likely. And what about ring 3 accessing other ring 3 cache? So, my bet is, at the end of the day, this is more mouth movement than fixing. Intel's saying it's not a bug, that devs should've been aware of this by the very nature of caching and out of order execution, and the OS devs are pointing at Intel, so the whole ordeal is buck passing. As much as i loath intel, I agree with them on this one.

[mrbadger]

What we could really do with is to start to seriously push the idea of data backups, so a hacked system becomes an inconvenience, not a disaster.

Some progress has been made with the introduction of the various cloud solutions, but those are a long way from being set in the minds of joe average computing device user.

It should almost be non optional, although how that could be managed I don't know. It's still far too easy to lose things you would regret desperately.

I recently discovered my neighbors had all their photographs from their babies early lives on one temporarily non functioning laptop, which they had zero clue how to fix.

These weren't non technical people, just not technical enough. I resolved their issue, and I have all those pictures in my backup system as well for now too.

Of course my backup system is a NAS, and it has an Intel chip....

Luckily I have two NAS systems. One of them is filled with data but left disconnected from the network and turned off, on the grounds that it can't be hacked if it can't be connected to.

You have to draw a line somewhere, what if there was a vulnerability found in Seagate or Western Digital NAS Hard Drives? I'd be totally borked then, in a big way.

I'd have to buy a DNA encoder or something, start encoding video files into my forearm or something.

One gram of DNA can potentially hold up to 455 exabytes of data, but the readers are still a bit slow, and somewhat bigger than a dvd drive.

[kohlrak]

What we could really do with is to start to seriously push the idea of data backups, so a hacked system becomes an inconvenience, not a disaster.

Some progress has been made with the introduction of the various cloud solutions, but those are a long way from being set in the minds of joe average computing device user.

It should almost be non optional, although how that could be managed I don't know. It's still far too easy to lose things you would regret desperately.

I recently discovered my neighbors had all their photographs from their babies early lives on one temporarily non functioning laptop, which they had zero clue how to fix.

These weren't non technical people, just not technical enough. I resolved their issue, and I have all those pictures in my backup system as well for now too.

Of course my backup system is a NAS, and it has an Intel chip....

Luckily I have two NAS systems. One of them is filled with data but left disconnected from the network and turned off, on the grounds that it can't be hacked if it can't be connected to.

You have to draw a line somewhere, what if there was a vulnerability found in Seagate or Western Digital NAS Hard Drives? I'd be totally borked then, in a big way.

I'd have to buy a DNA encoder or something, start encoding video files into my forearm or something.

One gram of DNA can potentially hold up to 455 exabytes of data, but the readers are still a bit slow, and somewhat bigger than a dvd drive.

You're being sarcastic, right? Because, essentially, data backups are the problem here.

[mrbadger]

No, why would I be, how are they the problem?

You mean this bug stops me copying data onto my NAS?
I'm not seeing it.