Guess this deserves its own thread, since it is not 'Intel' specific. Posted it another thread http://murga-linux.com/puppy/viewtopic. ... 185#979185 but no one seem to read it. Stuff is not just going on with Intel....there are bigger problems out there than just with Intel latest screw-up. There is NO excuse in any universe of chip-design I'm aware of for not knowing about possible bypasses of "memory isolation mechanisms" and then, worse, doing nothing about them all these years. Damn, as mentioned before, this behavior almost makes Microsoft look saintly all these decades releasing OSes with full knowledge they all were (and still are) vulnerable.
http://www.securityweek.com/intel-amd-c ... vices-risk
Intel, AMD, ARM--all chips found to pose huge security risk
Here is what wired says:
https://www.wired.com/story/critical-in ... =social_fbAlthough both attacks are based on the same general principle, Meltdown allows malicious programs to gain access to higher-privileged parts of a computer's memory, while Spectre steals data from the memory of other applications running on a machine. And while the researchers say that Meltdown is limited to Intel chips, they say that they've verified Spectre attacks on AMD and ARM processors, as well.
Does this vulnerability allow for such as encrypting your stuff and demanding a ransom for the key, or does it only allow for poking around in your stuff and reading it?
Edit: more info from
Massive Intel CPU flaw: Understanding the technical details of Meltdown and Spectre
By James Sanders | January 4, 2018
And
How Linux is dealing with Meltdown and Spectre
By Steven J. Vaughan-Nichols for Linux and Open Source | January 4, 2018
Edit: more info from
Massive Intel CPU flaw: Understanding the technical details of Meltdown and Spectre
By James Sanders | January 4, 2018
And
How Linux is dealing with Meltdown and Spectre
By Steven J. Vaughan-Nichols for Linux and Open Source | January 4, 2018
So it would seem that the flaw doesn't allow to execute anything, only to read what's in RAM.... In an email, Red Hat security wrote that the vulnerability affects x86 (Intel and AMD chipsets), POWER 8, POWER 9, System z, and ARM processors. AMD claimed its chips aren't vulnerable. In a statement, AMD said, "AMD is not susceptible to all three [attack] variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time."
Be that as it may, all three attacks have the potential to allow unauthorized read access to memory. There are three unique attack paths that could allow an attacker to execute a side-channel attack to bypass protections to read memory. ...
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
the aftermath begins
First, we should note the start of a legal battle that we will be able to tell grandchildren we saw begin.
Second, it seems people are dishing the dirt on other companies, starting with AMD. I will mention that this parallels Intel's problem with the IME that brings up their high-performance CPUs, though this implementation is very different.
I've had questions about the Trusted Security Platform initiative from the beginning because this was based on the idea of "security through obscurity". It was never opened up to analysis by independent investigators. As a problem limiting competition it served admirably, but I am not at all surprised that multiple implementations failed to address security, and even opened up new modes of attack.
Qualcomm also got in on the excitement.
The fundamental problem goes back to the era when architectures originally designed to be simple and small were scaled up without much consideration for implications. All the major processors today would count as "superscalar" architectures, as well as matching definitions for a list of other supercomputer marketing buzzwords. They also try to be both CISC and RISC processors, depending on the level at which you view them.
Note that MIPS and RISC machines which were designed with RISC architectures from day one do not suffer from these vulnerabilities.
Parallelism is a primary means of gaining a speed-up, and from other experience I can tell you it opens many cans of worms. Even a single-core chip today contains multiple pipelines. You also have multiple architectures on one chip, with CPUs also functioning as DSPs and vector processors. Floating point is still presented to programmers as a zero-address stack processor with limited stack depth. Inside it is implemented by microcode that behaves in a very different manner. The only term I can come up with for this architecture is "baroque".
Memory management was sort of an afterthought, since these designs started at a time when nobody really expected microcomputers to ever need more than a megabyte of main memory. The original x86 design beat designs that were limited to a 64 KB address space by introducing segmentation. This implementation of the previously-known idea of segmentation was so bad the term has been dropped from theoretical computer science. Suffice it to say that there were big machines with segmented memory prior to the x86 that had no such limitation to the size of segments.
Another feature of earlier segmented memory was built-in bounds checking on array accesses. This was deemed too expensive in terms of memory access speed, and was dropped. Spectre is one consequence of this decision.
The fundamental problem is that we tend to think of all computation taking place in one or more CPUs, ignoring the substantial computation involved in memory management before the CPU has anything to work on. We have concentrated on incredibly detailed memory timing, ignoring higher-level abstractions about what memory means.
(Think I exaggerate? Assignment: compare and contrast DDR3 9,9,9, 24 memory with DDR4 15,17,17, 36. Don't stop with bandwidth, explain the impact on average and worst-case latency.)
This neglect was made worse by reliance on passwords for security, with the same processor having several different hats it wears while executing code for different purposes at different levels of security. It should have been obvious all along that we needed to use one-time passwords (OTP) that would be useless if stolen, and that these needed to be generated by hardware that was physically isolated from any processor running untrusted code.
Such special-purpose processors are now remarkably cheap. We should not be having to replace machines worth thousands of dollars to correct a design error. It should be no more difficult than replacing a credit card or ID containing a chip.
Second, it seems people are dishing the dirt on other companies, starting with AMD. I will mention that this parallels Intel's problem with the IME that brings up their high-performance CPUs, though this implementation is very different.
I've had questions about the Trusted Security Platform initiative from the beginning because this was based on the idea of "security through obscurity". It was never opened up to analysis by independent investigators. As a problem limiting competition it served admirably, but I am not at all surprised that multiple implementations failed to address security, and even opened up new modes of attack.
Qualcomm also got in on the excitement.
The fundamental problem goes back to the era when architectures originally designed to be simple and small were scaled up without much consideration for implications. All the major processors today would count as "superscalar" architectures, as well as matching definitions for a list of other supercomputer marketing buzzwords. They also try to be both CISC and RISC processors, depending on the level at which you view them.
Note that MIPS and RISC machines which were designed with RISC architectures from day one do not suffer from these vulnerabilities.
Parallelism is a primary means of gaining a speed-up, and from other experience I can tell you it opens many cans of worms. Even a single-core chip today contains multiple pipelines. You also have multiple architectures on one chip, with CPUs also functioning as DSPs and vector processors. Floating point is still presented to programmers as a zero-address stack processor with limited stack depth. Inside it is implemented by microcode that behaves in a very different manner. The only term I can come up with for this architecture is "baroque".
Memory management was sort of an afterthought, since these designs started at a time when nobody really expected microcomputers to ever need more than a megabyte of main memory. The original x86 design beat designs that were limited to a 64 KB address space by introducing segmentation. This implementation of the previously-known idea of segmentation was so bad the term has been dropped from theoretical computer science. Suffice it to say that there were big machines with segmented memory prior to the x86 that had no such limitation to the size of segments.
Another feature of earlier segmented memory was built-in bounds checking on array accesses. This was deemed too expensive in terms of memory access speed, and was dropped. Spectre is one consequence of this decision.
The fundamental problem is that we tend to think of all computation taking place in one or more CPUs, ignoring the substantial computation involved in memory management before the CPU has anything to work on. We have concentrated on incredibly detailed memory timing, ignoring higher-level abstractions about what memory means.
(Think I exaggerate? Assignment: compare and contrast DDR3 9,9,9, 24 memory with DDR4 15,17,17, 36. Don't stop with bandwidth, explain the impact on average and worst-case latency.)
This neglect was made worse by reliance on passwords for security, with the same processor having several different hats it wears while executing code for different purposes at different levels of security. It should have been obvious all along that we needed to use one-time passwords (OTP) that would be useless if stolen, and that these needed to be generated by hardware that was physically isolated from any processor running untrusted code.
Such special-purpose processors are now remarkably cheap. We should not be having to replace machines worth thousands of dollars to correct a design error. It should be no more difficult than replacing a credit card or ID containing a chip.
-
Sailor Enceladus
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
I've two questions:
1) Can anyone give a reply to Flash's question. I'd never thought of it, but now I am wondering what actually happens when we have encrypted partitions and/or encrypted (i.e. USB and/or HD) plug-ins?
2) Does running all web-facing apps in a tight sandbox help and/or matter? Or is it just window dressing and does not matter either? I run anticapitalista & crew's latest "antiX 64-bit", and since they made using "Firejail" pretty much braindead easy by integrating it & the Firejails great DE app FireTools, I always--100% of the time--always run my web-facing apps inside a Firejail. Am just wondering if this would help with either of these two bugaboos (Spectre 1 and 2) we're facing.
P.S. As a side note, if Sailor's graph represents true, have to say I am bit happy the house is all on AMD, except for the one Intel laptop (which I've decommissioned until more clarity is provided from Intel). But, alas, maybe I am just hoping against hope---in my house there's still a lot of Apple stuff floating around (iphones, ipads, itouches)...sigh
1) Can anyone give a reply to Flash's question. I'd never thought of it, but now I am wondering what actually happens when we have encrypted partitions and/or encrypted (i.e. USB and/or HD) plug-ins?
2) Does running all web-facing apps in a tight sandbox help and/or matter? Or is it just window dressing and does not matter either? I run anticapitalista & crew's latest "antiX 64-bit", and since they made using "Firejail" pretty much braindead easy by integrating it & the Firejails great DE app FireTools, I always--100% of the time--always run my web-facing apps inside a Firejail. Am just wondering if this would help with either of these two bugaboos (Spectre 1 and 2) we're facing.
P.S. As a side note, if Sailor's graph represents true, have to say I am bit happy the house is all on AMD, except for the one Intel laptop (which I've decommissioned until more clarity is provided from Intel). But, alas, maybe I am just hoping against hope---in my house there's still a lot of Apple stuff floating around (iphones, ipads, itouches)...sigh
- Attachments
-
- Firejail-Firetools-GUI-in-latest-antiX-64bit-frugal-install.jpg
- (68.84 KiB) Downloaded 673 times
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
@belham2
I know I am not much of an authority, but here's my response to part of your queries.
Encrypted data has to be decrypted at some point to be used, no matter how it is handled. If there can be leakage between secure and untrusted processes, then the unencrypted data can be exposed. Even public key cryptography needs to be able to decrypt transmitted data using private keys on some processor.
The security principle at work here is that savvy attackers will go after the weakest link in the chain, wherever that might be.
Flash is correct in saying this is only about reading data, not remote execution of code. The problem there is that knowing what is supposed to be hidden opens you up to a wide range of known attacks that have been dealt with previously. There are good reasons for hiding sensitive data.
Simply as a proof of concept, the possibility of acquiring administrator passwords illustrates the danger of data leakage, but this is only the simplest and most obvious approach to compromise. Expect to see a long tail of exploits stemming from this class of vulnerabilities. Most of these will be hard to understand. Even the basic approach presented in the attacks already demonstrated depends on understanding details of processor timing that most programmers don't bother to consider.
I know I am not much of an authority, but here's my response to part of your queries.
Encrypted data has to be decrypted at some point to be used, no matter how it is handled. If there can be leakage between secure and untrusted processes, then the unencrypted data can be exposed. Even public key cryptography needs to be able to decrypt transmitted data using private keys on some processor.
The security principle at work here is that savvy attackers will go after the weakest link in the chain, wherever that might be.
Flash is correct in saying this is only about reading data, not remote execution of code. The problem there is that knowing what is supposed to be hidden opens you up to a wide range of known attacks that have been dealt with previously. There are good reasons for hiding sensitive data.
Simply as a proof of concept, the possibility of acquiring administrator passwords illustrates the danger of data leakage, but this is only the simplest and most obvious approach to compromise. Expect to see a long tail of exploits stemming from this class of vulnerabilities. Most of these will be hard to understand. Even the basic approach presented in the attacks already demonstrated depends on understanding details of processor timing that most programmers don't bother to consider.
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
At this point I can't resist telling an anecdote about a friend who is even older than I am, (there are still a few such people,) who told me that she doesn't do any business by computer.
"What do you do instead?", I asked.
"I call them on my phone, and give them my credit card number by voice."
This led to my anecdote about one time when I did this myself. I heard some clicking in the background, and correctly deduced that they were entering the data in their own computer system.
"What OS are you running?" (This led to a longer exchange I'll omit.)
Bottom line: this was a mom-and-pop shop running Windows-XP, which is no longer supported by Microsoft.
"What do you do instead?", I asked.
"I call them on my phone, and give them my credit card number by voice."
This led to my anecdote about one time when I did this myself. I heard some clicking in the background, and correctly deduced that they were entering the data in their own computer system.
"What OS are you running?" (This led to a longer exchange I'll omit.)
Bottom line: this was a mom-and-pop shop running Windows-XP, which is no longer supported by Microsoft.
You're probably thinking of something like this, quoted from the SA-00088 bulletin:
Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.
I'm not sure that "local access" in this context means PHYSICAL access.
Systems with microprocessors utilizing speculative execution and indirect branch prediction may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.
I'm not sure that "local access" in this context means PHYSICAL access.
I believe you are correct. I think that in security-nerd-speak, "local access" just means the code is running on the local machine, which might include JavaScript in a browser or, for server installations, a VM running something dodgy. It excludes very little.6502coder wrote: I'm not sure that "local access" in this context means PHYSICAL access.
That's what I read recently, anyway. I'm still getting up to speed on all this.
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Right! "Local access" could be HTML, javascript, etc. run in an unsecured process on a browser. Because of cross-site scripting you can't even depend on being safe if you avoid dodgy sites. More often than not ads displayed when you access one site originate elsewhere. This is what pays for the Internet, so it can't simply be prohibited.
Just as an example of how far from your intentions such code can be I'll mention that it has been used for mining Bitcoin while others pay for the equipment and electrical power. This is massively inefficient, but then the attackers aren't paying for it.
Changing browsers can limit the danger from this source. I'm now using Firefox 57.0.4 and/or Google-Chrome-01072018-x86_64. Unfortunately, this means I have to learn how to use No-Script all over again, so that it doesn't stop me from reading articles like the following: Triple Meltdown.
One final irony: defensive measures against these vulnerabilities will likely interfere with antivirus programs or vice versa. There will not be any quick fix, and I hesitate to estimate how long it will take problems to shake out.
One more item: such an attack via code sent over the Internet would not necessarily leave any traces on the machine, the way other hacks do. If intelligence services of nation-states have been exploiting this we might not know.
Just as an example of how far from your intentions such code can be I'll mention that it has been used for mining Bitcoin while others pay for the equipment and electrical power. This is massively inefficient, but then the attackers aren't paying for it.
Changing browsers can limit the danger from this source. I'm now using Firefox 57.0.4 and/or Google-Chrome-01072018-x86_64. Unfortunately, this means I have to learn how to use No-Script all over again, so that it doesn't stop me from reading articles like the following: Triple Meltdown.
One final irony: defensive measures against these vulnerabilities will likely interfere with antivirus programs or vice versa. There will not be any quick fix, and I hesitate to estimate how long it will take problems to shake out.
One more item: such an attack via code sent over the Internet would not necessarily leave any traces on the machine, the way other hacks do. If intelligence services of nation-states have been exploiting this we might not know.
I would like to point out a list by ARM(GB) of affected processors. The listing is here. Please read the full bulletin, dated Jan. 03, 2018.
Google/Android can do what they will, in some cases the ARM-processor needs a patch. Of all the discussion here, almost nothing on ARM, and whats vunerable to what problem.
Regards
8Geee
Google/Android can do what they will, in some cases the ARM-processor needs a patch. Of all the discussion here, almost nothing on ARM, and whats vunerable to what problem.
Regards
8Geee
Linux user #498913 "Some people need to reimagine their thinking."
"Zuckerberg: a large city inhabited by mentally challenged people."
"Zuckerberg: a large city inhabited by mentally challenged people."
I think that the issue is potentially more serious on ARM because I trust popular software on the linux repositories much more then I do google play. We all know how many different aps people try on google play and I don't have much faith in googles oversite of it.8Geee wrote:I would like to point out a list by ARM(GB) of affected processors. The listing is here. Please read the full bulletin, dated Jan. 03, 2018.
Google/Android can do what they will, in some cases the ARM-processor needs a patch. Of all the discussion here, almost nothing on ARM, and whats vunerable to what problem.
Regards
8Geee
Then again maybe google has already pached this and we are safe.
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Just as anticipated, the response to the problem is itself a problem. Some AMD processors (Athlons) have been unable to run anything beyond the startup screen with the Windows logo after the update. I suppose this solves the security problem caused by running Windows in the first place.
Other examples of updates borking various applications have turned up.
To be evenhanded, I will mention that IBM is also having problems with support in this crisis.
Systems which are not bricked only suffer substantial slowdowns. This means you can now get the performance from your high-end system you would have had if you had bought a cheaper system.
Microsoft, as I would have predicted, has decided they can no longer afford to support their OS after sale unless you keep paying them. Here comes software as a service.
Meanwhile, back at some old news, that move by Munich to convert their Linux systems to Windows, which was said to save 4 million Euros in support costs, will now cost 100 million Euros.
Note that after a successful conversion they will then have the privilege of paying whatever M$ decides they should in the future, with no control of source code or data formats. Should negotiations ever become a problem, M$ will have the option of letting them be molested by attackers.
If you read your licenses and terms of service/servitude, you will find they have absolutely no legally-binding responsibilities for your continued operation if anything at all goes wrong. You also have no right to know what is going on inside the machine you are said to own or the software you license from them.
Should you wish to dispute this, you might check on what happened with another lawsuit which has not had a single claim upheld in court. This involved SCO vs the entire Unix/Linux world, but M$ had paid SCO some hundreds of millions to avoid claims, and this fueled further litigation. The total cost of litigation passed $1 billion years ago. SCO had not done nearly the thorough job M$ has done to sew things up legally.
Personally, I doubt that some claims in M$ licensing and TOS are legally valid, but I am also sure that even the U.S. government and EU have failed to enforce any significant court judgment against them.
Other examples of updates borking various applications have turned up.
To be evenhanded, I will mention that IBM is also having problems with support in this crisis.
Systems which are not bricked only suffer substantial slowdowns. This means you can now get the performance from your high-end system you would have had if you had bought a cheaper system.
Microsoft, as I would have predicted, has decided they can no longer afford to support their OS after sale unless you keep paying them. Here comes software as a service.
Meanwhile, back at some old news, that move by Munich to convert their Linux systems to Windows, which was said to save 4 million Euros in support costs, will now cost 100 million Euros.
Note that after a successful conversion they will then have the privilege of paying whatever M$ decides they should in the future, with no control of source code or data formats. Should negotiations ever become a problem, M$ will have the option of letting them be molested by attackers.
If you read your licenses and terms of service/servitude, you will find they have absolutely no legally-binding responsibilities for your continued operation if anything at all goes wrong. You also have no right to know what is going on inside the machine you are said to own or the software you license from them.
Should you wish to dispute this, you might check on what happened with another lawsuit which has not had a single claim upheld in court. This involved SCO vs the entire Unix/Linux world, but M$ had paid SCO some hundreds of millions to avoid claims, and this fueled further litigation. The total cost of litigation passed $1 billion years ago. SCO had not done nearly the thorough job M$ has done to sew things up legally.
Personally, I doubt that some claims in M$ licensing and TOS are legally valid, but I am also sure that even the U.S. government and EU have failed to enforce any significant court judgment against them.
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
ZDnet has a useful explanation of the problem.
Their Vatican library analogy is not perfect, but it could be. Once you have made the request, the time required to process a later request drops dramatically. This is because the librarian now knows that the book exists, and that you are not allowed to see it. In this case the librarian's short-term memory plays the part of the cache.
Trying to use this at the real Vatican would raise suspicions about the reason for so many requests, but computer hardware has no such suspicions. If you can get one bit of information from one request, nothing stops you from playing 20 questions to get more detailed information. Because the memory protection operations take place after data has been fetched for speculative execution you can choose any instruction you like to execute on data you should not be allowed to see. Doing this billions of times a second can suck up all kinds of data.
Their Vatican library analogy is not perfect, but it could be. Once you have made the request, the time required to process a later request drops dramatically. This is because the librarian now knows that the book exists, and that you are not allowed to see it. In this case the librarian's short-term memory plays the part of the cache.
Trying to use this at the real Vatican would raise suspicions about the reason for so many requests, but computer hardware has no such suspicions. If you can get one bit of information from one request, nothing stops you from playing 20 questions to get more detailed information. Because the memory protection operations take place after data has been fetched for speculative execution you can choose any instruction you like to execute on data you should not be allowed to see. Doing this billions of times a second can suck up all kinds of data.
<sarcasm>Just can't wait for WASM to arrive. It will be ... wonderful 
</sarcasm>
</sarcasm>Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
prehistoric
- Posts: 1744
- Joined: Tue 23 Oct 2007, 17:34
Here's another article on how to check if you are protected from Meltdown and Spectre.
The BIOS/UEFI updates are another problem to deal with. What is going on here is motherboard firmware loading new microcode into a writable microcode store used for patching bugs in the hardware. In my experience Intel security about how their microcode works is tighter than government security about major weapons systems. If this has been compromised it is quite possible attackers would use this opportunity to install their own backdoors into computers at a level that would be hard to avoid. A more subtle attack would be to provide bogus updates that do nothing, leaving the machine vulnerable to known attacks.
The major suppliers are providing updates to their BIOS/UEFI code for machines made in the last 5 years. Older machines will remain at risk, and the natural recommendation is to replace all such. This is the way companies can turn a profit from a major blunder. Read licensing and terms of service to see how little legal liability they have.
It is a safe bet that these measures will not be applied to large numbers of systems, leaving attackers the opportunity to find weakest links into organizations. Even if every machine in an organization is protected, it is a safe bet that some employees will have machines at home that are not protected. We can also expect to discover people storing their passwords for secure systems on insecure smart phones.
This will play out over a period of years.
How did we get in this mess?
The answer is that software architects were assuming that hardware protection would isolate processes running untrusted code from the most trusted kernel processes. This meant they did not have to worry about what code might be doing in those processes or containers. Knowing this is not true means you have to worry about every kind of code that might be downloaded, uploaded or compiled in an untrusted process. That covers a lot of territory.
(Many years ago, I showed someone how his neat trick with Word macros could be used to execute arbitrary code via a script. I had sat on this knowledge for about a year to allow a fix. M$ Office greatly expands the possibilities. At the time I first thought of this M$ Office did not exist, and that is really prehistoric.)
The vulnerability also applies to things run in virtual machines, and that means one hell of a lot of the Internet.
The BIOS/UEFI updates are another problem to deal with. What is going on here is motherboard firmware loading new microcode into a writable microcode store used for patching bugs in the hardware. In my experience Intel security about how their microcode works is tighter than government security about major weapons systems. If this has been compromised it is quite possible attackers would use this opportunity to install their own backdoors into computers at a level that would be hard to avoid. A more subtle attack would be to provide bogus updates that do nothing, leaving the machine vulnerable to known attacks.
The major suppliers are providing updates to their BIOS/UEFI code for machines made in the last 5 years. Older machines will remain at risk, and the natural recommendation is to replace all such. This is the way companies can turn a profit from a major blunder. Read licensing and terms of service to see how little legal liability they have.
It is a safe bet that these measures will not be applied to large numbers of systems, leaving attackers the opportunity to find weakest links into organizations. Even if every machine in an organization is protected, it is a safe bet that some employees will have machines at home that are not protected. We can also expect to discover people storing their passwords for secure systems on insecure smart phones.
This will play out over a period of years.
How did we get in this mess?
The answer is that software architects were assuming that hardware protection would isolate processes running untrusted code from the most trusted kernel processes. This meant they did not have to worry about what code might be doing in those processes or containers. Knowing this is not true means you have to worry about every kind of code that might be downloaded, uploaded or compiled in an untrusted process. That covers a lot of territory.
(Many years ago, I showed someone how his neat trick with Word macros could be used to execute arbitrary code via a script. I had sat on this knowledge for about a year to allow a fix. M$ Office greatly expands the possibilities. At the time I first thought of this M$ Office did not exist, and that is really prehistoric.)
The vulnerability also applies to things run in virtual machines, and that means one hell of a lot of the Internet.
-
Sailor Enceladus
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
My Pentium M is safe from Meltdown. The kernel should disable kpti if CPU is <=Core2Duo or <BayTrailAtom (see SA-00088).
Prove me wrong hackers
Prove me wrong hackers
-
B.K. Johnson
- Posts: 807
- Joined: Mon 12 Oct 2009, 17:11
Hi guys and gals
Ask Leo (Leo Notenboom) provides a very good understandable analogy on this page: What Do I Need to Do About Spectre and Meltdown
:
Don't give up before you get to: OK, but, what are these two things?
Ask Leo (Leo Notenboom) provides a very good understandable analogy on this page: What Do I Need to Do About Spectre and Meltdown
:
Don't give up before you get to: OK, but, what are these two things?
[color=blue]B.K. Johnson
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]
tahrpup-6.0.5 PAE (upgraded from 6.0 =>6.0.2=>6.0.3=>6.0.5 via quickpet/PPM=Not installed); slacko-5.7 occasionally. Frugal install, pupsave file, multi OS flashdrive, FAT32 , SYSLINUX boot, CPU-Dual E2140, 4GB RAM[/color]