Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Security
General Security Discussions
Spectre and Meltdown
Message
<blockquote data-quote="Deleted member 65228" data-source="post: 712659"><p><strong><em>All of these issues stem from optimisation.</em></strong></p><p></p><p>The issue with Meltdown is due to lack of security checks, hence why it's for Intel only right now. Intel didn't do enough checks, it assumed the caller is trusted, whereas this isn't the case with AMD. However, some of the Spectre variants still apply for AMD CPUs.</p><p></p><p>The LFENCE mitigation is a good one to battle one of the Spectre variants though. It stands for "load fence" and causes the memory load operations to change. This means if we have a block of code which uses an array to access memory nested within a conditional statement, and we apply the LFENCE instruction (part of the x86 instruction set), then the memory operations using the array nested within the conditional statement won't be executed unless the conditional statement turns out to follow execution flow to the block of code nested within it. Without the LFENCE instruction, the load operations are optimised and thus the block of code performing the memory access may occur in advance, even if it turned out that it shouldn't have been executed in the end for that session.</p><p></p><p>The latest version of Visual Studio (by Microsoft since they own Visual Studio) implemented a new linker feature which will support automatic analysis and identification of code potentially vulnerable to one of the Spectre variants, and insertion of the LFENCE instruction where deemed necessary. However, LFENCE usage does reduce performance because you miss out on that speculative execution optimisation feature for that location of execution flow - when used correctly it won't be necessarily noticeable and have a real effect on performance, although when over-used irresponsibly/incorrectly it will potentially cause noticeable performance issues, hence why Microsoft implemented the feature after the recent media outbreak to help developers re-compile their software and be automatically strengthened against Spectre should their code have been vulnerable to the specific variant that the LFENCE usage technically "mitigates".</p><p></p><p>Meltdown was the easiest one out of the two to exploit since Spectre is dependent on actual software packages. Meltdown was due to the how the OS kernel works, and thus Kernel Page Table Isolation (KPTI) prevents the attack, whereas Spectre is software-dependent. Meltdown allows read-access to kernel-mode memory whereas Spectre allows read-access to memory for user-mode processes (when read-access shouldn't be allowed, that is). Spectre works by tricking the software in question to access areas in memory arbitrarily.</p><p></p><p>Spectre is a lot harder to utilise with security software, or any software which is "protected" from access on the local environment because you have to be executing under the context of the target process to cause it to read memory arbitrarily. If a software package doesn't allow arbitrary code execution, then you have to find a work-around to that protection mechanism. An example of gaining arbitrary code execution would be via code injection (e.g. shell-code or DLL), hence why self-defence mechanisms incorporated into mainstream AV products are beneficial to AV vendors to prevent them from being that "affected".</p><p></p><p>It should be possible for the browser to be exploited via Spectre with JavaScript due to JavaScript being executed locally under the browser process, and because of features JavaScript supports. The multiple process security feature is beneficial because it separates each loaded document (with it's corresponding scripts) under a separate process, meaning each tab window is on another process. This means that if Spectre did happen to be exploited via a web-based exploit using JavaScript (for example), only the memory for the process for that tab could be potentially read without consent, instead of it being for all of the browser processes. This minimises impact damage in the case of browser-based exploitation because it prevents a potential data-leak for the data stored in-memory for the other browser processes; the attacker will have less data which can be accessed with the exploit.</p><p></p><p><em><strong>For anyone wondering why the multiple processes for web-browser tabs/the recent security features help mitigate the attack further, now you know why. It's because if the vulnerability is exploited, only the memory for that new individual process can be accessed arbitrarily.</strong></em></p><p></p><p>If you keep self-defence mechanisms enabled for your security software then it'll be safer against Spectre as well. An attacker would need to find a way around the self-defence mechanisms (which is certainly not easy from user-mode with the big vendors like Avast and Kaspersky) for remote-code execution, and they'd also need to do it for all of the security software package process' for it to be effective (especially the SYSTEM process for that security software package).</p><p></p><p><strong>Meltdown:</strong></p><p>- Access kernel-mode memory with read access. Due to the target being the OS' kernel itself and not a specific third-party kernel-mode software component, it potentially provides read-access to the entire kernel... Thus exposing third-party kernel-mode software's memory as well as all user-mode process' memory</p><p>- Not very efficient in terms of speed. It would take a long time to go through everything and may be difficult to access certain areas at the same time, you'd need to know where to look</p><p>- You'd need to be capable of making use of the read memory with the returned buffer/s</p><p>- Mitigated further with Kernel Page Table Isolation (KPTI) which is implemented into Windows, OS X and Linux now</p><p></p><p><strong>Spectre:</strong></p><p>- Access to user-mode memory with read access</p><p>- Requires arbitrary code execution within the process holding the memory which is wanted to be read arbitrarily, which also means the vulnerability (when exploited) can only be used for specific targets</p><p>- The attacker must know of a target on the local environment which holds vulnerable code and actually trigger code execution of the vulnerable code (AFAIK)</p><p>- Mitigated further with automatic insertion of the LFENCE instruction when required and general safe practices when developing software and working with sensitive data/memory</p><p></p><p>Neither of them are very useful to the average attacker due to the resources/time consumption required to make it effective. It's much more efficient and simpler for an attacker to take a standard, common approach. If they are after sensitive data, they will just use local-based malware pushed via online downloads and malicious e-mail attachments and get it from victims. They could always go for the spear phishing approach targeting business employees. It really depends on the sensitive data which the attacker is after and also the victim target.</p><p></p><p>In all fairness, manufacturers tried hard with optimisation to make us happy because all of us are impatient. This doesn't mean it isn't their fault though, if the technology is vulnerable, then that's on them. The issue isn't only CPU manufacturers though, the issue is also insecure/unsafe programming practices which lead to bugs which can be taken advantage of to actually make these vulnerabilities effective (this note is regarding Spectre - as I noted, safe and secure programming practices and reduce the risk and even prevent Spectre attacks from actually being of any use/not being possible).</p><p></p><p>It's a pretty big mess but things will clear up eventually in-time. We'll never forget about it entirely, and Intel is doing not so good because of it all (although they are not the only one who had "issues"), but that is life.</p></blockquote><p></p>
[QUOTE="Deleted member 65228, post: 712659"] [B][I]All of these issues stem from optimisation.[/I][/B] The issue with Meltdown is due to lack of security checks, hence why it's for Intel only right now. Intel didn't do enough checks, it assumed the caller is trusted, whereas this isn't the case with AMD. However, some of the Spectre variants still apply for AMD CPUs. The LFENCE mitigation is a good one to battle one of the Spectre variants though. It stands for "load fence" and causes the memory load operations to change. This means if we have a block of code which uses an array to access memory nested within a conditional statement, and we apply the LFENCE instruction (part of the x86 instruction set), then the memory operations using the array nested within the conditional statement won't be executed unless the conditional statement turns out to follow execution flow to the block of code nested within it. Without the LFENCE instruction, the load operations are optimised and thus the block of code performing the memory access may occur in advance, even if it turned out that it shouldn't have been executed in the end for that session. The latest version of Visual Studio (by Microsoft since they own Visual Studio) implemented a new linker feature which will support automatic analysis and identification of code potentially vulnerable to one of the Spectre variants, and insertion of the LFENCE instruction where deemed necessary. However, LFENCE usage does reduce performance because you miss out on that speculative execution optimisation feature for that location of execution flow - when used correctly it won't be necessarily noticeable and have a real effect on performance, although when over-used irresponsibly/incorrectly it will potentially cause noticeable performance issues, hence why Microsoft implemented the feature after the recent media outbreak to help developers re-compile their software and be automatically strengthened against Spectre should their code have been vulnerable to the specific variant that the LFENCE usage technically "mitigates". Meltdown was the easiest one out of the two to exploit since Spectre is dependent on actual software packages. Meltdown was due to the how the OS kernel works, and thus Kernel Page Table Isolation (KPTI) prevents the attack, whereas Spectre is software-dependent. Meltdown allows read-access to kernel-mode memory whereas Spectre allows read-access to memory for user-mode processes (when read-access shouldn't be allowed, that is). Spectre works by tricking the software in question to access areas in memory arbitrarily. Spectre is a lot harder to utilise with security software, or any software which is "protected" from access on the local environment because you have to be executing under the context of the target process to cause it to read memory arbitrarily. If a software package doesn't allow arbitrary code execution, then you have to find a work-around to that protection mechanism. An example of gaining arbitrary code execution would be via code injection (e.g. shell-code or DLL), hence why self-defence mechanisms incorporated into mainstream AV products are beneficial to AV vendors to prevent them from being that "affected". It should be possible for the browser to be exploited via Spectre with JavaScript due to JavaScript being executed locally under the browser process, and because of features JavaScript supports. The multiple process security feature is beneficial because it separates each loaded document (with it's corresponding scripts) under a separate process, meaning each tab window is on another process. This means that if Spectre did happen to be exploited via a web-based exploit using JavaScript (for example), only the memory for the process for that tab could be potentially read without consent, instead of it being for all of the browser processes. This minimises impact damage in the case of browser-based exploitation because it prevents a potential data-leak for the data stored in-memory for the other browser processes; the attacker will have less data which can be accessed with the exploit. [I][B]For anyone wondering why the multiple processes for web-browser tabs/the recent security features help mitigate the attack further, now you know why. It's because if the vulnerability is exploited, only the memory for that new individual process can be accessed arbitrarily.[/B][/I] If you keep self-defence mechanisms enabled for your security software then it'll be safer against Spectre as well. An attacker would need to find a way around the self-defence mechanisms (which is certainly not easy from user-mode with the big vendors like Avast and Kaspersky) for remote-code execution, and they'd also need to do it for all of the security software package process' for it to be effective (especially the SYSTEM process for that security software package). [B]Meltdown:[/B] - Access kernel-mode memory with read access. Due to the target being the OS' kernel itself and not a specific third-party kernel-mode software component, it potentially provides read-access to the entire kernel... Thus exposing third-party kernel-mode software's memory as well as all user-mode process' memory - Not very efficient in terms of speed. It would take a long time to go through everything and may be difficult to access certain areas at the same time, you'd need to know where to look - You'd need to be capable of making use of the read memory with the returned buffer/s - Mitigated further with Kernel Page Table Isolation (KPTI) which is implemented into Windows, OS X and Linux now [B]Spectre:[/B] - Access to user-mode memory with read access - Requires arbitrary code execution within the process holding the memory which is wanted to be read arbitrarily, which also means the vulnerability (when exploited) can only be used for specific targets - The attacker must know of a target on the local environment which holds vulnerable code and actually trigger code execution of the vulnerable code (AFAIK) - Mitigated further with automatic insertion of the LFENCE instruction when required and general safe practices when developing software and working with sensitive data/memory Neither of them are very useful to the average attacker due to the resources/time consumption required to make it effective. It's much more efficient and simpler for an attacker to take a standard, common approach. If they are after sensitive data, they will just use local-based malware pushed via online downloads and malicious e-mail attachments and get it from victims. They could always go for the spear phishing approach targeting business employees. It really depends on the sensitive data which the attacker is after and also the victim target. In all fairness, manufacturers tried hard with optimisation to make us happy because all of us are impatient. This doesn't mean it isn't their fault though, if the technology is vulnerable, then that's on them. The issue isn't only CPU manufacturers though, the issue is also insecure/unsafe programming practices which lead to bugs which can be taken advantage of to actually make these vulnerabilities effective (this note is regarding Spectre - as I noted, safe and secure programming practices and reduce the risk and even prevent Spectre attacks from actually being of any use/not being possible). It's a pretty big mess but things will clear up eventually in-time. We'll never forget about it entirely, and Intel is doing not so good because of it all (although they are not the only one who had "issues"), but that is life. [/QUOTE]
Insert quotes…
Verification
Post reply
Top