If you can’t book the vaccine appointment for your 5-11 year-old child, here are the solutions to fix that problem!
Many Parents Can’t Book 5-11 Yo Vaccine Appointment!
Many parents are complaining that they are unable to book the vaccine appointment for their 5-11 year-old children!
They received the link in MySejahtera to book their child’s vaccine appointment, but the link does NOT work!
No matter how many times they tap / click on it, nothing happens.
Note : If you did not receive the “Click here to book your dependent’s appointment” link, please wait. The MySejahtera team appears to be releasing that option in batches to reduce load on their servers. Your turn will come shortly.
Can’t Book 5-11 Yo Vaccine Appointment? Here’s The Fix!
If you can’t book the vaccine appointment for your 5-11 year-old child, here are the solutions to fix that problem!
Solution #1 : Update MySejahtera
As I mentioned in my earlier guide, the booking system is only available in MySejahtera 1.1.6 and above.
You may see the vaccine booking option appear in an earlier version of MySejahtera, but it will NOT work until you update to version 1.1.6 or later.
So if you have this problem, first go to the Apple App Store / Google Play Store / HUAWEI AppGallery and update to MySejahtera 1.1.6 or later.
If MySejahtera does not update properly in your Android smartphone, please make sure you allow the Files and media permission :
Step 1 : Go to Settings > Apps > MySejahtera > Permissions.
Step 2 : Tap on Files and media under the Denied list.
Step 3 : Tap on Allow all the time.
Solution #2 : Force Close MySejahtera
If you had earlier updated to MySejahtera 1.1.6 (or newer), then you should try restarting MySejahtera by “force closing” it. Not just use the Home button, which only minimises it.
In Android, tap on the App Overview button, and swipe up / press on the X button to “force close” it.
For iOS devices with a Home button, double tap on the Home button, and swipe up to “force close” it.
For iOS devices without a Home button, swipe up and hold, and then swipe up on MySejahtera to “force close” it.
Then reopen MySejahtera, and see if the booking system now works.
Solution #3 : Clear MySejahtera App Cache
If the two solutions above still does not work, you can try to clear the App Cache if you are using an Android device.
Step 1 : Go to Settings > Apps > MySejahtera
Step 2 : Scroll down and tap on the Storage option.
Step 3 : Tap on the Clear cache option at the bottom.
Step 4 : Log into MySejahtera and see if the booking system works!
Solution #4 : Delete MySejahtera App Data
If Solution #3 did not solve your problem, you can repeat the steps above, and tap on Clear data instead of just tapping on Clear cache.
But be warned that this step will wipe out your login data, so you will need to log into MySejahtera after this. It will be similar to deleting and reinstalling MySejahtera.
I hope this guide helps you solve the vaccine appointment booking problem in MySejahtera!
Don’t forget to SHARE this guide with your friends!
Please Support My Work!
Support my work through a bank transfer / PayPal / credit card!
Name : Adrian Wong Bank Transfer : CIMB 7064555917 (Swift Code : CIBBMYKL)
Credit Card / Paypal : https://paypal.me/techarp
Dr. Adrian Wong has been writing about tech and science since 1997, even publishing a book with Prentice Hall called Breaking Through The BIOS Barrier (ISBN 978-0131455368) while in medical school.
He continues to devote countless hours every day writing about tech, medicine and science, in his pursuit of facts in a post-truth world.
macOS Monterey continues to be plagued by an insidious memory leak problem that Apple does not seem able to fix.
So here are a few workarounds that you can try!
macOS Monterey Memory Leak : What’s Going On?
Ever since it was released on 25 October 2021, macOS Monterey has been plaguing users with an insidious memory leak problem.
And even as Christmas approaches, Apple is still unable to fix the problem. Here is what we know so far…
It Gobbles Up Insane Amounts Of Memory
The memory leak quietly eats up insane amounts of memory, creeping up on users without warning.
A single affected app like Firefox can gobble up almost 80 GB of memory. Even a critical macOS process like WindowServer can end up using 24 GB of memory, while the Mail app can use more than 100 GB of memory!
Unless you have been keeping an eye on memory usage, you will only realise this is happening when you get the warning that “Your system has run out of application memory” with a request to Force Quit apps you are not using.
It Appears To Be An OS Issue
This Monterey memory leak affects many different apps with no obvious culprit in sight :
Internet browsers like Firefox and Safari
Apps like Tweetbot and Final Cut Pro
macOS features like Control Center, Mail and Finder
macOS processes like WindowsServer
That strongly suggests that it is an operating system issue, and not a bug in any particular app.
It Affects Intel + Apple Silicon Models
This Monterey memory leak problem is not platform-specific, and affects both Intel and Apple Silicon models.
So you are not going to be able to “escape” this memory leak problem by upgrading to the new M1 Pro / Max-powered MacBook Pro laptops.
macOS Monterey Memory Leak : Possible Solutions
Unfortunately, Apple still does not seem to be able to plug this insidious macOS Monterey memory leak. So here are some solutions that may work for you…
Revert To Standard Mouse Pointer
One of the new features macOS Monterey is the ability to change the mouse pointer’s size, as well as its outline and fill colours.
However, the developers at Mozilla discovered that using a non-standard mouse pointer in macOS Monterey causes a large memory leak!
This memory leak is not limited to Firefox, but occurs anytime the non-standard mouse pointer changes its look, like when you mouse over a button or a text field.
To fix this, you will need to revert to a standard mouse pointer, and here’s how to do that :
Step 1 : Go to Settings and select Accessibility.
Step 2 : Tap on the Display option, and select the Pointer tab.
Step 3 : Move the Pointer size all the way to the left (Normal).
Step 4 : Click on the Reset button to the right of Pointer outline colour and Pointer fill colour.
Step 5 : Restart your Mac, and fingers crossed – this fixes your Monterey memory leak problem!
Relaunch Finder
If you notice Finder using a prodigious amount of memory, that memory leak happens when you use the Find (⌘ F) feature in to search for files.
The easiest way to prevent this memory leak is to avoid using Finder’s Find feature. Try using the Search option on the upper right corner.
But once you get a Finder memory leak, you must relaunch it to release the leaked memory…
Option A : While in the Finder window, click on the Apple menu. Then press and hold the Shift key and click on Force Quit Finder.
Option B : Click on the Apple menu. Click Force Quit (Command + Option + Escape). Then select Finder and click on Relaunch.
Limit Use Of Control Center
Some users have reported that the Control Center can use upwards of 20GB of RAM, but most users fortunately do not encounter such terrible waste of memory.
This memory leak is easily reproducible – every time you use a control, it uses a little more RAM but does not release it.
Unfortunately, there is no way to release the leaked memory short of restarting the computer. So the best way to avoid this memory leak is to limit the use of Control Center.
Restart Apps Whenever Memory Use Is Too Much
Well, this seems obvious, but I have to throw it in anyway.
If any app, whether it’s Safari or Final Cut Pro starts using way too much memory, just close and reopen it. That should quickly recover the leaked memory.
Of course, this is only a stopgap solution until Apple releases a fix for this truly pesky memory problem in macOS Monterey…
Please Support My Work!
Support my work through a bank transfer / PayPal / credit card!
Name : Adrian Wong Bank Transfer : CIMB 7064555917 (Swift Code : CIBBMYKL)
Credit Card / Paypal : https://paypal.me/techarp
Dr. Adrian Wong has been writing about tech and science since 1997, even publishing a book with Prentice Hall called Breaking Through The BIOS Barrier (ISBN 978-0131455368) while in medical school.
He continues to devote countless hours every day writing about tech, medicine and science, in his pursuit of facts in a post-truth world.
Apple just rushed out macOS Big Sur 11.2.3, iOS 14.4.1, iPadOS 14.4.1 and Safari 14.0.3 to patch a critical security bug.
Find out what they fix, and why you need to update your MacBook, iPhone and iPad right away!
Apple Rushes Out macOS, iOS, iPadOS, Safari Critical Bug Fixes!
Released on 8 March 2021, macOS Big Sur 11.2.3 patches only one bug, which may mislead users into thinking that it’s not very important.
WebKit
Available for: macOS Big Sur
Impact: Processing maliciously crafted web content may lead to arbitrary code execution
Description: A memory corruption issue was addressed with improved validation.
CVE-2021-1844: Clément Lecigne of Google’s Threat Analysis Group, Alison Huffman of Microsoft Browser Vulnerability Research
On the same day, Apple also released iOS 14.4.1 and iPadOS 14.4.1 – both patching the same CVE-2021-1844 vulnerability.
WebKit
Available for: iPhone 6s and later, iPad Air 2 and later, iPad mini 4 and later, and iPod touch (7th generation)
Impact: Processing maliciously crafted web content may lead to arbitrary code execution
Description: A memory corruption issue was addressed with improved validation.
CVE-2021-1844: Clément Lecigne of Google’s Threat Analysis Group, Alison Huffman of Microsoft Browser Vulnerability Research
Apple also released Safari 14.0.3, which patches the same vulnerability for macOS Catalina and macOS Mojave :
WebKit
Available for: macOS Catalina and macOS Mojave
Impact: Processing maliciously crafted web content may lead to arbitrary code execution
Description: A memory corruption issue was addressed with improved validation.
CVE-2021-1844: Clément Lecigne of Google’s Threat Analysis Group, Alison Huffman of Microsoft Browser Vulnerability Research
Why Install These macOS, iOS, iPadOS, Safari Bug Fixes ASAP?
While they appear to only patch WebKit in macOS Big Sur, iOS, iPadOS and Safari, they are CRITICAL bug fixes that you need to install right away.
They patch the new CVE-2021-1844 vulnerability, which was discovered by Clément Lecigne of Google’s Threat Analysis Group and Alison Huffman of Microsoft Browser Vulnerability Research.
This vulnerability allows a remote attacker to trigger a buffer overflow when the victim opens a specially-crafted web page, allowing the attacker to execute arbitrary code on the target system.
It is not known if this vulnerability has been exploited yet, but it is critical to install the new updates to prevent that from happening.
If you like our work, you can help support us by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Nokia 3.4 users received a New Year surprise, when its camera stopped working from New Year 2021 onwards!
Find out what happened, and the two workarounds you can try!
Nokia 3.4 Camera Started Crashing On New Year 2021!
Many Nokia 3.4 users are complaining that their camera stopped working around New Year 2021 – either on the eve – 31 December 2020, or New Year’s Day – 1 January 2021.
Specifically, the Nokia camera app would crash within a second of opening it. Those who managed to take a shot before it crashed would only get a photo of a grey square.
Like the camera failures affecting the Nokia 8.3 5G, the problem partly due to the recent firmware updates, but the problem only manifested around New Year 2021.
In fact, it will affect brand new Nokia 3.4 phones that were sold and opened up on and after 1 January 2021.
Nokia 3.4 Camera New Year Bug Workarounds
Restarting the phone won’t help, and even a soft reset or hard reset won’t work.
It appears that the Nokia 3.4 camera malfunction is a date bug (like the famous Y2K or Millennium Bug) affecting their Camera app version 97.10.1400.01.
Nokia says they are working on a fix, but until they release a working update, here are two ways to fix the Nokia 3.4 camera failure.
Use A Third-Party App
The Nokia 3.4 camera is still functioning – it’s just their Camera app that’s broken.
So you can use a messaging app like WhatsApp or Telegram to take photos and videos.
However, you may not get the full resolution or quality since these apps use a much lower photo and video resolution to reduce file size.
If you like our work, you can help support us by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Kaspersky recently discovered a Google Chrome zero day exploit that was being used in Operation WizardOpium.
Here are the full details, but the TLDR message is – make sure you update Google Chrome ASAP!
The WizardOpium Exploit : What Is It?
Kaspersky’s automated Exploit Prevention subsystem detected the exploit, which they dubbed WizardOpium. It used a zero day vulnerability that had hitherto not known to developers.
The WizardOpium Exploit : How Does It Work?
The attacks, which Kaspersky called Operation OpiumWizard, began with an infiltration at a Korean news website, where attackers managed to inject malicious code.
It loads a script from a third-party site that first checks if the system is suitable for infection – they were interested only in Chrome for Windows, not older than version 65.
If the operating system and browser requirements are met, the script downloads the WizardOpium exploit piece by piece, reassembles and decrypts it.
The script then runs another check on the version of Google Chrome, working exclusively with Chrome 76 or 77.
After verifying that it has the right Chrome version, the script then leverages the use-after-free vulnerability CVE-2019-13720, based on the improper use of system memory.
By manipulating the system memory, the exploit gains permission to read and write data, which it immediately uses to download, decrypt and run the malware package.
The WizardOpium Exploit : Solution
Kaspersky cybersecurity products will detect the exploit, and identify it as Exploit.Win32.Generic.
On discovering it, they reported it to Google with the identifier CVE-2019-13720.
Google fixed the bug in Chrome 78.0.3904.87 for Windows, macOS and Linux. Just make sure you update to that version, or newer… ASAP!
To make sure you have the update, follow these steps :
Click on the 3 vertical dots at the upper right corner of Chrome (Customise and control Google Chrome)
Select Help > About Google Chrome.
In the About Chrome page, it should say that you have Version 78.0.3904.87 or higher
If not, Chrome will automatically start looking for, and installing the latest update
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Chromageddon is upon us! The world woke up today to a world of silent Chromecast and Google Home devices. What the heck is going on??? How do we fix it???
Updated @ 2018-07-01 :Google still refuses to tell us what caused Chromageddon. But let’s see what we can dig out about this debacle.
Updated @ 2018-06-28 :Google just reported they have a fix! We added details on what we need to do to restore the affected devices, and an update on a bad firmware being the cause of Chromageddon.
Originally posted @ 2018-06-27
Chromageddon – The Day Chromecast + Home Died Worldwide
Chromageddon took down Chromecast and Google Home devices worldwide sometime in the evening of 26 June 2018 (US Pacific Time). Since then, they have all refused to obey their masters’ commands.
Users of Google Home were greeted with the dreaded “There was a glitch. Try again in a few seconds.” response to every command. No matter how long and hard they cajoled their Google devices, they stayed silent.
They were all still alive, still connected to the network, but functionally nothing more than space-heating paperweights.
It took Google more than 12 hours to fix the problem after they realised Chromageddon was real. The real tragedy though was the complete lack of communication with their users.
Sure, Google responded to messages on Twitter, but even when people alerted them to the issue, it took more than 12 hours before they realised something truly bad was happening. Even then, they did not inform their other customers who are probably spending hours trying to troubleshoot their non-functioning devices.
Needless to say, other than informing those who reported issues when a fix was available, they steadfastly refused to tell us WHY Chromageddon happened. I suppose Google expects us to trust them to learn something from this debacle…
What Devices Are Currently Affected? Updated!
For most part, they are almost all Google Chromecast 2 and Google Home devices, but here is the full list of devices reported to be affected by Chromageddon :
Google Chromecast (1st Gen)
Google Chromecast (2nd Gen)
Google Home
Google Home mini
Surprisingly, both Google Chromecast Ultra or Chromecast Audio do not seem to be affected, although they are far less popular and their users have not yet realised the downtime.
How Do We Fix Chromecast + Home? Updated!
So far, all efforts to self-fix the problem have failed spectacularly :
Screaming futilely at the silent devices – Failed
Restarting Chromecast or Google Home – Failed
Rebooting the modem and/or router – Failed
Resetting Chromecast or Google Home to factory defaults – Failed
Asking Google tech support for help – Failed
Praying to the Google Gods – Failed
Although Google refuses to confirm, Chromageddon is most likely due to a problem with their servers. So when their servers have a hiccup, everything goes down. Google hinted at that with these tweets :
Our Engineering team is already on it. Hang in there — we’ll keep you updated.
There’s an ongoing issue with Chromecast and our team is already working on a fix ― we’ll keep you posted.
Our team is aware of this issue and working on a stable fix. Stay tuned.
At 6:18 AM (GMT+8) on the 28th of June, Google announced that they have a fix for Chromageddon that will automatically roll out over the next 6 hours. To get your Chromecast and Google Home running immediately, all you have to do is REBOOT them.
“We’ve identified a fix for the issue impacting Google Home users and it will be automatically rolled out over the next 6 hours. If you would like an immediate fix please follow the directions to reboot your device. If you’re still experiencing an issue after rebooting, contact us at Google Home Support. We are really sorry for the inconvenience and are taking steps to prevent this issue from happening in the future.
While there is a way to reboot your Google devices via the Google Home app, many people cannot actually get connected to the affected devices. So the simplest way to get them working again is to physically turn off power to those devices, and then turn them back on again.
Isn’t Chromageddon Due To A Firmware Update? Updated!
At first, everyone thought it might have been a firmware update that bricked the devices. Some even claimed that it only happened after their affected devices were updated.
[adrotate group=”2″]
However, many of those who could still connect to their Chromecast reported that they were still on the 1.29.104827 production firmware. That firmware is several months old, or it’s not possible for it to suddenly act up globally.
Some have reported that their Chromecast is on the 1.30.113131 preview firmware. That is only possible if they had specifically opted to participate in the Google Preview Program. Even so, this preview firmware was released in sometime in April 2018.
When Google announced a fix, and that all we needed to do was to reboot our devices, it confirmed our deduction that it was a server-related issue on their end. We can safely confirm that Chromageddon was NOT due to any firmware update.
What Chromageddon Teaches Us
We all know that personal assistants like Google Home and Amazon Echo (Price Check) are always connected to cloud servers, and come with their fair share of privacy concerns. However, most of us are probably not aware that “dumb” video streaming devices like Chromecast connect to such servers as well.
Privacy concerns with devices “dialling home” are bad enough. Chromageddon is now proof of just how vulnerable such a system design can be, if these devices have to be connected to Google’s servers to even function.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The speculative execution CPU bug that literally kneecapped Intel, also affects many AMD and ARM processors. This means BILLIONS of CPUs around the world, including those powering smartphones, are affected by Meltdown and/or Spectre.
Our article Everything On The Meltdown + Spectre CPU Flaws! summarises the key details of the speculative execution bug, and what we can do about it. This guide is to help those who want a full list of affected CPUs. Because we intend this to be an exhaustive list, we split it into multiple sections.
Article Update History
Click here for the Article Update History
Updated @ 2018-03-07 : Added a new list of 5 IBM z/Architecture CPUs. Added a new list of 22 VIA desktop and mobile CPUs. Added 1 ARM mobile CPU, 1 Intel server CPU, and 1 Intel mobile CPU. Also added 20 mobile SoCs, 9 digital TV or media player SoCs, and 43 industrial SoCs.
Updated @ 2018-02-15 : Added 96 Intel server CPUs, 91 Intel desktop CPUs, and 127 Intel mobile CPUs.
Updated @ 2018-02-07 : Added 128 AMD server CPUs, 11 AMD workstation CPUs, 128 AMD desktop CPUs, and 59 AMD mobile CPUs.
Updated @ 2018-02-02 : Added 11 Intel server CPUs, 96 AMD server CPUs, 168 AMD desktop CPUs, 77 AMD mobile CPUs, 10 IBM POWER CPUs, 9 HiSilicon Kirin mobile SoCs, 10 MediaTek mobile SOCs, 4 MediaTek digital TV SoCs, and 6 NVIDIA devices to the lists of vulnerable CPUs.
Updated @ 2018-01-14 : Added 416 Intel server CPUs, 8 Intel desktop CPUs, and 29 Intel mobile CPUs to the lists of vulnerable CPUs. Added a new list of 51 Intel mobile SoCs.
Updated @ 2018-01-12 : Added 71 AMD server CPUs, 71 AMD desktop CPUs, 29 AMD mobile CPUs and 3 AMD server SoCs based on a vulnerable ARM CPU. Also added a table summarising the number of vulnerable processors.
Updated @ 2018-01-11 : Added 18 Intel desktop CPUs and 165 Intel server / workstation CPUs. Also added a list of vulnerable Apple iOS devices, and expanded the list of vulnerable mobile SoCs used by smartphones.
Originally posted @ 2018-01-08
What Are Meltdown And Spectre?
Meltdown and Spectre are two exploits that take advantage of three variants of the speculative execution bug that affects billions of CPUs around the world.
The Spectre exploit targeted Variants 1 and 2, while the Meltdown exploit targets Variant 3, of the CPU bug.
The CPUs Vulnerable To Meltdown / Spectre Updated!
For easy reference, we divided the affected CPUs by Company (arranged ALPHABETICALLY – no conspiracy, we promise), and subsequently by Segment (Workstation / Desktop / Mobile), or affected variants.
As of Revision 8.0, we believe we have covered all of the affected AMD, Apple, ARM, IBM, Intel and VIA CPUs. But we will add more CPUs (and devices) as and when they’re noted to be vulnerable to the Meltdown and Spectre exploits.
Note : It’s arguable that all CPUs that uses speculative execution to any degree are potentially vulnerable to Meltdown or Spectre or a future exploit. We will only focus on CPUs that are confirmed to be vulnerable to Meltdown or Spectre.
Vulnerable CPUs By The Numbers Updated!
Here is a quick summary of the number of CPUs vulnerable to Meltdown or Spectre, according to the company, and the type of processor.
Company
Spectre 1
Spectre 2
Meltdown
AMD
295 Server CPUs
42 Workstation CPUs
396 Desktop CPUs
208 Mobile CPUs
295 Server CPUs
42 Workstation CPUs
396 Desktop CPUs
208 Mobile CPUs
None
Apple
13 Mobile SoCs
13 Mobile SoCs
13 Mobile SoCs
ARM
10 Mobile CPUs
3 Server SoCs
10 Mobile CPUs
3 Server SoCs
4 Mobile CPUs
3 Server SoCs
IBM
5 z/Architecture CPUs
10 POWER CPUs
5 z/Architecture CPUs
10 POWER CPUs
5 z/Architecture CPUs
10 POWER CPUs
Intel
733 Server / Workstation CPUs
443 Desktop CPUs
584 Mobile CPUs
51 Mobile SoCs
733 Server / Workstation CPUs
443 Desktop CPUs
584 Mobile CPUs
51 Mobile SoCs
733 Server / Workstation CPUs
443 Desktop CPUs
584 Mobile CPUs
51 Mobile SoCs
Affected Variants :AMD CPUs are affected by both Variants 1 and 2 of the speculative execution CPU bug. Colloquially, many people refer to them as Spectre 1 and Spectre 2.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The AMD Workstation CPUs Vulnerable To Spectre
Affected Variants :AMD CPUs are affected by both Variants 1 and 2 of the speculative execution CPU bug. Colloquially, many people refer to them as Spectre 1 and Spectre 2. They are not vulnerable to Meltdown.
AMD Summit Ridge (2017)
AMD Ryzen Threadripper 1950X
AMD Ryzen Threadripper 1920X
AMD Ryzen Threadripper 1900X
AMD Vishera (2012)
AMD FX-9590
AMD FX-9370
AMD FX-8370E
AMD FX-8370
AMD FX-8350
AMD FX-8320E
AMD FX-8320
AMD FX-8310
AMD FX-8300
AMD FX-6350
AMD FX-6300
AMD FX-6200
AMD FX-4350
AMD FX-4320
AMD FX-4300
AMD Zambezi (2011)
AMD FX-8170
AMD FX-8150
AMD FX-8140
AMD FX-8120
AMD FX-8100
AMD FX-6130
AMD FX-6120
AMD FX-6100
AMD FX-4170
AMD FX-4150
AMD FX-4130
AMD FX-4120
AMD FX-4100
AMD Windsor (2006)
AMD Athlon 64 FX-74
AMD Athlon 64 FX-72
AMD Athlon 64 FX-70
AMD Athlon 64 FX-62
AMD Toledo (2005)
AMD Athlon 64 FX-60
AMD San Diego (2005)
AMD Athlon 64 FX-57
AMD Athlon 64 FX-55
AMD Clawhammer (2004)
AMD Athlon 64 FX-55
AMD Athlon 64 FX-53
AMD Sledgehammer (2003)
AMD Athlon 64 FX-53
AMD Athlon 64 FX-51
[adrotate group=”1″]
AMD Desktop CPUs Vulnerable To Spectre
Affected Variants :AMD CPUs are affected by both Variants 1 and 2 of the speculative execution CPU bug. Colloquially, many people refer to them as Spectre 1 and Spectre 2. They are not vulnerable to Meltdown.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
AMD Mobile CPUs Vulnerable To Spectre
Affected Variants :AMD CPUs are affected by both Variants 1 and 2 of the speculative execution CPU bug. Colloquially, many people refer to them as Spectre 1 and Spectre 2. They are not vulnerable to Meltdown.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The Apple CPUs Vulnerable To Meltdown / Spectre
Apple makes custom processors based on the ARM microarchitecture. They have not released specific information on which of their processors are affected by which exploit, but this is what we know so far.
Affected Variants : Apple only issued a general notice that their processors are affected by both Meltdown and Spectre, not the specific variants.
Apple A4
Apple A5
Apple A5X
Apple A6
Apple A6X
Apple A7
Apple A8
Apple A8X
Apple A9
Apple A9X
Apple A10 Fusion
Apple A10X Fusion
Apple A11 Bionic
Vulnerable iOS or tvOS Devices : Apple was vague about the iOS devices that were affected, but based on the affected CPU cores, here are the iOS devices that are vulnerable to Meltdown and Spectre :
Apple TV 2nd Generation, 3rd Generation, 4th Generation and 5th Generation
The ARM CPUs Vulnerable To Meltdown / Spectre
ARM CPUs Vulnerable To All Three Variants
Affected Variants :Variants 1 and 2, and either Variant 3 or Variant 3a, of the speculative execution CPU bug. They are vulnerable to Meltdown and both variants of Spectre.
ARM Cortex-A75
ARM Cortex-A72
ARM Cortex-A57
ARM Cortex-A15
Mobile SoCs Using These ARM CPUs (Not Exhaustive)
HiSilicon Kirin 955
HiSilicon Kirin 950
HiSilicon Kirin 928
HiSilicon Kirin 925
HiSilicon Kirin 920
MediaTek Helio X27 (MT6797X)
MediaTek Helio X25 (MT6797T)
MediaTek Helio X23 (MT6707D)
MediaTek Helio X20 (MT6797)
MediaTek MT8173
MediaTek MT8135 / MT8135V
MediaTek MT6795
NVIDIA Tegra X2
NVIDIA Tegra X1
NVIDIA Tegra K1
NVIDIA Tegra 4
Qualcomm Snapdragon 845
Qualcomm Snapdragon 810 / 808
Qualcomm Snapdragon 670
Qualcomm Snapdragon 653 / 652 / 650
Qualcomm Snapdragon 640
Samsung Exynos 7420
Samsung Exynos 5800
Samsung Exynos 5433
Samsung Exynos 5422 / 5420
Samsung Exynos 5410
Samsung Exynos 5260
Samsung Exynos 5250
Samsung Exynos 5 Dual (Exynos 5250)
AMD Server SoCs Using These ARM CPUs
AMD Opteron A1170
AMD Opteron A1150
AMD Opteron A1120
NVIDIA Devices Using These ARM CPUs (Not Exhaustive)
NVIDIA SHIELD TV (ARM Cortex-A57)
NVIDIA SHIELD Tablet (ARM Cortex-A15)
NVIDIA Jetson TX2 (ARM Cortex-A57)
NVIDIA Jetson TX1 (ARM Cortex-A57)
NVIDIA Jetson TK1 (ARM Cortex-A15)
NVIDIA Jetson Tegra K1 (ARM Cortex-A15)
Digital TV / Media Player SoCs Using These ARM CPUs (Not Exhaustive)
Rockchip RK3399
Industrial SoCs Using These ARM CPUs (Not Exhaustive)
Embedded Computers Using These ARM CPUs (Not Exhaustive)
VIA VAB-1000
VIA VAB-820 / VAB-800
VIA VAB-630 / VAB-600
VIA ALTA DS
VIA QSM-8Q60
VIA SOM-6X50
VIA VTS-8589
IBM POWER CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These IBM POWER CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
IBM POWER4
IBM POWER4+
IBM POWER5
IBM POWER5+
IBM POWER6
IBM POWER6+
IBM POWER7
IBM POWER7+
IBM POWER8
– including IBM Murano, IBM Turismo, PowerCore CP1
IBM POWER8 with NVLink / POWER8+
IBM POWER9
– IBM Nimbus, IBM Cumulus
IBM z/Architecture CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These IBM z/Architecture CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
IBM z14
IBM z13
IBM zEC12
IBM z196
IBM z10
[adrotate group=”1″]
Intel UMPC / Smartphone SoCs Vulnerable To Meltdown + Spectre
Affected Variants : These Intel SoCs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Intel Server / Workstation CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These Intel CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Intel Desktop CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These Intel CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Intel Mobile CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These Intel CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
VIA Desktop CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These VIA CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
VIA Nano QuadCore (2011)
VIA Nano QuadCore L4800E
VIA Nano QuadCore L4700E
VIA Nano QuadCore L4650E
VIA Nano Dual Core 2011)
VIA Nano X2 E L4350E
VIA Nano X2 E L4350E
VIA Nano 3000 Series (2009)
VIA Nano L3600
VIA Nano L3050
VIA Nano L3025
VIA Nano 2000 Series (2008)
VIA Nano L2200
VIA Nano L2100
VIA Mobile CPUs Vulnerable To Meltdown + Spectre
Affected Variants : These VIA CPUs are affected by all three variants of the speculative execution CPU bug. They are vulnerable to the Meltdown and both Spectre exploits.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The efforts to mitigate the threat of the Meltdown and Spectre exploits is officially WORSE than the threat itself. Many Intel systems are randomly and spontaneously rebooting after installing Intel Spectre 2 patches. No shit. Here is our continuing coverage of the Intel Spectre Reboot Issue!
Article Update History
Click here for the Article Update History
Updated @ 2018-03-06 :Added the latest updates on the issue, as well as the new Intel Spectre 2 microcode revision guidance slides.
Updated @ 2018-02-22 :Added the latest updates on the issue, as well as the new Intel Spectre 2 microcode revision guidance slides.
Updated @ 2018-02-14 :Added the latest updates on the issue, as well as the new Intel Spectre 2 microcode revision guidance slides.
Updated @ 2018-02-10 :Added a new section on the Intel Spectre 2 Microcode Update Schedule, and updated various parts of the article. Removed 80 Intel processors that have just been confirmed not to be affected by the buggy microcode updates.
Updated @ 2018-01-26 :Added the Intel Coffee Lake, Intel Xeon Scalable and Intel Xeon W family of processors to the list of affected CPUs. Added the updated Intel Spectre 2 Microcode Update Guidance.
Updated @ 2018-01-23 :Added a new section on the root cause of the spontaneous reboot issue, and updated guidance on what you should do about this problem. Also added the Intel microcode revision lists. Removed 129 workstation / server CPUs, 105 desktop CPUs and 143 mobile CPUs.
Updated @ 2018-01-18 :Added the latest development on the Intel spontaneous reboot issues, including a greatly-expanded list of affected Intel CPUs.
Updated @ 2018-01-16 :Added the full list of Intel CPUs with reboot issues
Originally posted @ 2018-01-13
Spontaneous Reboots With Spectre 2 Patches Updated!
On 11 January 2018, the WSJ reported that Intel was quietly asking their cloud computing customers to hold off installing Meltdown and Spectre patches because “the patches have bugs of their own“. Specifically, there were three bugs in the microcode patches they released.
In a blog post posted on the same day, Intel Executive Vice President and General Manager of the Intel Data Center Group, Navin Shenoy confirmed that Intel received reports of “higher system reboots” after applying those updates.
Basically, these systems would randomly and spontaneously reboot after installing those patches. Not something you want your computer to do, never mind servers that cater to tens or hundreds of thousands of users.
He initially confirmed that the affected systems were running Intel Broadwell and Intel Haswell CPUs, and that the issues affected both client (desktop, mobile, workstation) PCs, as well as data center servers.
But in an update a week later, Navin revealed that the newer Kaby Lake and Skylake CPUs, as well as older Sandy Bridge and Ivy Bridge processors, were also experiencing spontaneous reboot issues after updating their firmware.
Although not explicitly mentioned, the latestIntel Coffee Lake CPUs are also affected by spontaneous reboots. Hidden in their microcode revision guidance was a reference to the Coffee Lake-S processors.
In their 24 January 2018 microcode revision guidance, they further added the Intel Xeon Scalable and Intel Xeon W processor families to the list of affected CPUs.
But there’s good news – on 8 February 2018, Intel confirmed that 80 CPU models previously marked as affected have been certified to be free from the buggy microcode updates.
On 12 February 2018, Intel released beta microcode updates for some of their Coffee Lake, Broadwell and Haswell processors, and pre-beta updates for their Arrandale, Clarkdale and Gulftown processors.
On 20 February 2018, Intel released production microcode updates for their Coffee Lake, Kaby Lake and Skylake processors, with new beta microcode updates for their Haswell, Ivy Bridge and Sandy Bridge processors.
On 26 February 2018, Intel released production microcode updates for the remaining Broadwell and Haswell processors, except for their Broadwell EX and Haswell EX (server) processors.
On 1 March 2018, Intel released new beta microcode updates for their Arrandale, Clarkdale, Gulftown, Nehalem EP, Nehalem WS, Westmere EP, Westmere WS and Ivy Bridge EX (server) processors. They also started releasing pre-beta updates for their Lynnfield and Westmere EX processors. With the release of the Skylake Xeon E3 production update, the entire Intel Skylake family is fully patched.
On 22 January 2018, Navin Shenoy announced that Intel :
has identified the root cause for Broadwell and Haswell platforms, and
is making good progress in developing a solution to address that root cause.
They revealed that the spontaneous reboot issues seen with the affected Intel CPUs were caused by Spectre 2 mitigations in those microcode updates.
Notably, Intel only confirmed that Spectre 2 mitigations were the root cause in those two platforms. They have not confirmed Spectre 2 mitigations as the cause in the Coffee Lake, Kaby Lake, Skylake, Ivy Bridge and Sandy Bridge platforms that are also affected.
In fact, Intel shared that “The progress we have made in identifying a root cause for Haswell and Broadwell will help us address issues on other platforms. Please be assured we are working quickly to address these issues.”
What CPUs Are Affected By The Buggy Intel Spectre 2 Patches?
All of the systems suffering from spontaneous reboot issues were running on Haswell, Broadwell, Skylake, Kaby Lake and the latest Coffee Lake CPUs. Workstation and server CPUs based on Ivy Bridge and Sandy Bridge were also affected, but thankfully not their desktop brethren.
On 8 February 2018, Intel revealed that some of the microcode updates that they suspected were buggy, were actually not buggy. They include :
The Intel Skylake H/S/U/Y Desktop Processors
The Intel Xeon E3-1200 v5 Processor Family (Skylake)
We prepared the full list of CPUs affected by the buggy Intel Spectre 2 patches, but it is a VERY LONG LIST with 801 CPUs, so we split them into three sections.
As you can see, many more server and workstation CPUs are affected than desktop and mobile CPUs combined. That’s because Intel prioritised the patching of their server and workstation CPUs, over desktop and mobile CPUs.
What Is Being Done About The Buggy Intel Spectre 2 Patches?
When he first posted on the spontaneous reboot issue, Navin said that Intel was working to “understand, diagnose and address this reboot issue“.
In his latest update, he shared that Intel had already issued an early version of the new microcode updates to their partners for tests, and will release them “once that testing has been completed“.
These new microcode updates basically have Spectre 2 mitigations removed. This will restore stability to the affected Intel CPUs, while Intel fixes the problems in those mitigations.
The Intel Spectre Microcode Update Schedule Updated!
On 7 February 2018, Navin Shenoy announced that Intel has released “production microcode updates for several Skylake-based platforms” to their OEM customers and industry partners, with more platform updates “in coming days“.
The schedule was updated on 12,20, 26 February and 1 March with more details, including production (final), pre-beta and beta versions of the new Intel Spectre microcode updates.
What Should YOU Do?
While Intel initially advised end-users to “apply updates” from system and operating system providers, they have now changed their guidance, as of 22 January 2018 :
We recommend that OEMs, Cloud service providers, system manufacturers, software vendors and end users stop deployment of current versions on the below platforms, as they may introduce higher than expected reboots and other unpredictable system behavior.
We also ask that our industry partners focus efforts on testing early versions of the updated solution for Broadwell and Haswell we started rolling out this weekend, so we can accelerate its release. We expect to share more details on timing later this week.
For those concerned about system stability while we finalize the updated solutions, we are also working with our OEM partners on the option to utilize a previous version of microcode that does not display these issues, but removes the Variant 2 (Spectre) mitigations. This would be delivered via a BIOS update, and would not impact mitigations for Variant 1 (Spectre) and Variant 3 (Meltdown).
Please note that there has been no actual recorded threat or attack using the Meltdown or Spectre exploits. The damage, or risk of damage, every time your system or server spontaneously reboot is FAR WORSE than the (currently) non-existent threat of a Meltdown or Spectre exploit.
Therefore, we recommend that you DO NOT apply any microcode update for your Intel system, if you are using any Intel processor manufactured since 2011.
If you have already applied the latest Intel Spectre microcode update, and are affected by spontaneous reboots; you should upgrade to the new firmware (if they are available), or revert to the older firmware.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Server / Workstation CPUs With Buggy Intel Spectre Patches
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Updated @ 2018-02-28 :Added a new page on the AMD Spectre 2 hardware mitigation options.
Originally posted @ 2018-02-01
Only Spectre
Now that the dust has settled, we know that AMD processors are completely invulnerable to Meltdown, but are vulnerable to both Spectre exploits. Therefore, AMD only needs to mitigate against the two Spectre exploits.
In the Spectre 1 (GPZ Variant 1) exploit, a malware can make use of the processor’s speculative execution capability to bypass the memory bounds check, thereby accessing memory that it did not have permission for.
AMD is recommending software-only solutions for Spectre 1, which include operating system kernels, JIT (Just In Time) compilers, browsers and other user applications.
AMD recommends the V1-1 (lfence) software solution for the GPZ Variant 1 (Spectre 1) exploit.
GPZ Variant 2 (Spectre 2)
In the Spectre 2 (GPZ Variant 2) exploit, a malware may trick the CPU branch predictor into mis-predicting the wrong path, thereby speculatively executing code that would not otherwise be executed.
AMD offers both software-only, and software + hardware mitigations, for Spectre 2.
AMD recommends the V2-1(retpoline) option for the GPZ Variant 2 (Spectre 2) exploit.
Technique : Clear out untrusted data from registers (e.g. write 0) when entering more privileged modes, or sensitive code.
Effect : By removing untrusted data from registers, the CPU will not be able to speculatively execute operations using the values in those registers.
Applicability : All AMD processors.
Note : Instructions that cause the machine to temporarily stop inserting new instructions into the machine for execution and wait for execution of older instructions to nish are referred to as dispatch serializing instructions.
AMD Spectre Mitigation G-2
Target : Spectre 1 and Spectre 2
Technique : Set an MSR in the processor so that LFENCE is a dispatch serializing instruction and then use LFENCE in code streams to serialize dispatch (LFENCE is faster than RDTSCP which is also dispatch serializing). This mode of LFENCE may be enabled by setting MSR C001_1029[1]=1.
Effect : Upon encountering an LFENCE when the MSR bit is set, dispatch will stop until the LFENCE instruction becomes the oldest instruction in the machine.
Applicability : All AMD family 10h/12h/14h/15h/16h/17h processors support this MSR. LFENCE support is indicated by CPUID function1 EDX bit 26, SSE2. AMD family 0Fh/11h processors support LFENCE as serializing always, but do not support this MSR. AMD plans support for this MSR and access to this bit for all future processors.
Effect : The processor will never speculatively fetch instruction bytes in supervisor mode if the RIP address points to a user page. This prevents the attacker from redirecting the kernel indirect branch to a target in user code.
Applicability : All AMD processors that support SMEP (Family 17h, Family 15h model >60h)
Note : The load-store unit is a key area for controlling speculation because information leakage comes from the residual nature of cache lines after a speculative fill.
Effect : The processor will never initiate a fill if the translation has a SMAP violation (kernel accessing user memory). This can prevent the kernel from bringing in user data cache lines. With SMEP and SMAP enabled the attacker must nd an indirect branch to attack in the area marked by SMAP that is allowed to access user marked memory.
Applicability : All AMD processors that support SMAP ( family 17h and greater)
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
AMD Spectre 1 Mitigation Options
AMD Spectre Mitigation V1-1
Target : Spectre 1 only
Technique : With LFENCE serializing, use it to control speculation for bounds checking. For instance, consider the following code:
2: ja out_of_bounds ; if greater, index is too big
3: mov ebx, [eax] ; read buffer
In this code, the CPU can speculative execute instruction 3 (mov) if it mispredicts the branch at 2 (ja). If this is undesirable, software should implement:
2: ja out_of_bounds ; if greater, index is too big
3: lfence ; serializes dispatch until branch
4: mov ebx, [eax] ; read buffer
Effect : In the second code sequence, the processor cannot execute op 4 because dispatch is stalled until the branch target is known.
Applicability : All AMD processors.
AMD Spectre Mitigation V1-2
Target : Spectre 1 only
Technique : Create a data dependency on the outcome of a compare to avoid speculatively executing instructions in the false path of the branch. For instance, consider the following code:
2: ja out_of_bounds ; if greater, index is too big
3: mov ebx, [eax] ; read buffer
In this code, the CPU can speculative execute instruction 3 (mov) if it mispredicts the branch at 2 (ja). If this is undesirable, software should implement:
3: ja out_of_bounds ; if greater, index is too big
4: cmova eax, edx ; NEW: dummy conditional mov
5: mov ebx, [eax] ; read buffer
Effect : In the second code sequence, the processor cannot execute op 4 (cmova) because the ags are not available until after instruction 2 (cmp) nishes executing. Because op 4 cannot execute, op 5 (mov) cannot execute since no address is available.
Applicability : All AMD processors.
AMD Spectre Mitigation V1-3
Target : Spectre 1 only
Technique : Create a data dependency on the outcome of a compare to mask the array index to keep it within bounds. For instance, consider the following code:
2: ja out_of_bounds ; if greater, index is too big
3: mov ebx, [eax] ; read buffer
In this code, the CPU can speculative execute instruction 3 (mov) if it mispredicts the branch at 2 (ja). If this is undesirable, software should implement:
2: ja out_of_bounds ; if greater, index is too big
3: and eax, $MASK ; NEW: Mask array index
4: mov ebx, [eax] ; read buffer
Effect : In the second code sequence, the processor will mask the array index before the memory load constraining the range of addresses that can be speculatively loaded. For performance it is best if $MASK is an immediate value.
Applicability : All AMD processors. This mitigation works best for arrays that are power-of-2 sizes but can be used in all cases to limit the range of addresses that can be loaded.
Note : In the case of RET instructions, RIP values are predicted using a special hardware structure that tracks CALL and RET instructions called the return stack bu er. Other indirect branches (JMP, CALL) are predicted using a branch target bu er (BTB) structure. While the mechanism and structure of this buffer varies significantly across AMD processors, branch predictions in these structures can be controlled with software changes to mitigate variant 2 attacks.
[adrotate group=”1″]
AMD Spectre 2 Mitigation Options
AMD Spectre Mitigation V2-1
Target : Spectre 2 only
Technique : Convert indirect branches into a “retpoline”. Retpoline sequences are a software construct which allows indirect branches to be isolated from speculative execution. It uses properties of the return stack bu er (RSB) to control speculation. The RSB can be lled with safe targets on entry to a privileged mode and is per thread for SMT processors. So instead of
1: jmp *[eax] ; jump to address pointed to by EAX2:
To this:
1: call l5 ; keep return stack balanced
l2: pause ; keep speculation to a minimum
3: lfence
4: jmp l2
l5: add rsp, 8 ; assumes 64 bit stack
6: push [eax] ; put true target on stack
7: ret
and this 1: call *[eax] ;
To this:
1: jmp l9
l2: call l6 ; keep return stack balanced
l3: pause
4: lfence ; keep speculation to a minimum
5: jmp l3
l6: add rsp, 8 ; assumes 64 bit stack
7: push [eax] ; put true target on stack
8: ret
L9: call l2
Effect : This sequence controls the processor’s speculation to a safe known point. The performance impact is likely greater than V2-2 but more portable across the x86 architecture. Care needs to be taken for use outside of privileged mode where the RSB was not cleared on entry or the sequence can be interrupted. AMD processors do not put RET based predictions in BTB type structures.
Applicability : All AMD processors.
AMD Spectre Mitigation V2-2
Target : Spectre 2 only
Technique : Convert an indirect branch into a dispatch serializing instruction sequence where the load has nished before the branch is dispatched. For instance, change this code:
1: jmp *[eax] ; jump to address pointed to by EAX2:
To this:
1: mov eax, [eax] ; load target address
2: lfence ; dispatch serializing instruction
3: jmp *eax
Effect : The processor will stop dispatching instructions until all older instructions have returned their results and are capable of being retired by the processor. At this point the branch target will be in the general purpose register (eax in this example) and available at dispatch for execution such that the speculative execution window is not large enough to be exploited.
Applicability : All AMD processors. AMD plans that this sequence will continue to work on future processors until support for other architectural means to control indirect branches are introduced.
AMD Spectre Mitigation V2-3
Target : Spectre 2 only
Technique : Execute a series of CALL instructions upon entering more privileged code to ll up the return address predictor.
Effect : The processor will only predict RET targets to the RIP values in the return address predictor, thus preventing attacker controlled RIP values from being predicted.
Applicability : All AMD processors. The size of the return address predictor varies by processor, all current AMD processors have a return address predictor with 32 entries or less. Future processors that have more than 32 RSB entries are planned to be architected to not require software intervention.
AMD Spectre Mitigation V2-4
Target : Spectre 2 only
Technique : An architectural mechanism, Indirect Branch Control (IBC), is being added to the x86 ISA to help software control branch prediction of jmp near indirect and call near indirect instructions. It consists of 3 features: Indirect Branch Prediction Barrier (IBPB), Indirect Branch Restricted Speculation (IBRS) and Single Thread Indirect Branch Predictors (STIBP).
Effect : These features give software another mechanism through architectural MSRs to provide mitigation for different variant 2 exploits.
IBPB – Places a barrier such that indirect branch predictions from earlier execution cannot in uence execution after the barrier. IBRS – Restricts indirect branch speculation when set. STIBP – Provides sibling thread protection on processors that require sibling indirect branch prediction protection
Applicability : As a new feature, these mechanism are available in only a limited number of current AMD processors and require a microcode patch. These 3 features are individually enumerated through CPUID and all processors do not support all features. These features also require software updates to write the MSR where appropriate.
Note : After a RIP value is predicted, the new RIP value is sent through a TLB and table walker pipeline before instruction bytes can be fetched and sent for execution.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
AMD Spectre 2 Hardware Mitigation Options
On 7 February, AMD revealed three AMD64 mechanisms to mitigate against Spectre 2 (indirect branch target injection). They are designed to increase control of indirect branches, and identified by CPU ID bits.
Feature
AMD Version (CPUID Function)
MSR Exist
Indirect Branch Prediction Barrier (IBPB)
8000_0008 EBX[12]=1
PRED_CMD (MSR 49)
Indirect Branch Restricted Speculation (IBRS)
8000_0008 EBX[14]=1
SPEC_CTRL (MSR 48)
Single Thread Indirect Branch Prediction (STIBP)
8000_0008 EBX[15]=1
SPEC_CTRL (MSR 48)
AMD IBPB Hardware Mitigation
Target : Spectre 2 only
Technique : This is a write-only MSR (model-specific register) that, when written with a 0, prevents older indirect branches from influencing predictions of indirect branches in the future. This applies to jmp indirects, call indirects and returns.
As this feature prevents the processor from using all previous indirect branch information, it is meant to be used only when a software switches from one user context to another that requires protection.
CPUID Function 8000_0008, EBX[16]=1 indicates an IBRS always on mode. The processor prefers that IBRS is only set once during boot and not changed.
If IBRS is set on a processor supporting IBRS always on mode, indirect branches executed in a less privileged prediction mode will not influence branch predictions for indirect branches in a more privileged prediction mode.
This also reduces the performance impact of the WRMSR (Write to Model Specific Register) on less privileged to more privileged entry point and the WRMSR on more privileged to less privileged exit points.
AMD IBRS Hardware Mitigation
Target : Spectre 2 only
Technique : Indirect Branch Restricted Speculation (IBRS) exists at MSR 0x48 (SPEC_CTRL) bit 0.
When this bit is set, it keeps indirect branches that occurred in a lesser prediction mode from before it was set from influencing the future indirect branches that are going to execute now while IBRS is 1. A lesser prediction mode is CPL 3 vs CPL[2-0] and Guest vs Host mode.
If software clears IBRS, it is now allowed for the older indirect branches that occurred when IBRS was 0 to be used to influence the indirect branches.
It is also possible that while IBRS is 1, another write of 1 to IBRS bit 0 occurs. This starts a new window where older indirect branches should not influence future indirect branches.
Therefore if IBRS were set in a lesser privilege mode, on a transition to a more privileged mode the more privileged mode would have to set IBRS to 1 to indicate to hardware that it wants branches in the more privileged mode separated from those in the lesser privileged mode with IBRS set.
On processors with a shared indirect branch predictor, IBRS being set provides protection from being influenced by a sibling thread’s indirect branch predictions. For the ret type of indirect branch, software is responsible for clearing out the return stack buffer with 32 calls that have a non-zero target.
Processors that support more than 32 RSB (Return Stack Buffer) entries will be responsible for clearing the extra RSB entries. Clearing out the return stack buffer maybe required on the transition from CPL3 to CPL0, even if the OS has SMEP enabled.
CPUID Function 8000_0008, EBX[18]=1 indicates that the processor prefers using the IBRS feature instead of other software mitigations such as retpoline. This allows software to remove the software mitigation and utilize the better performing IBRS mechanism.
[adrotate group=”1″]
AMD STIBP Hardware Mitigation
Target : Spectre 2 only
Technique : The Single Thread Indirect Branch Predictor (STIBP) exists at MSR 0x48 (SPEC_CTRL) bit 1.
When this bit is set in processors that share branch prediction information, indirect branch predictions from sibling threads cannot influence the predictions of other sibling threads. Return instructions are always immune to influence by the other thread and do not require this bit to be set for protection.
Any attempt to write SPEC_CTRL bits 63:2 results in general protection fault (GP fault). If a processor only supports STIBP (bit 1) for ease of software implementation, the processor does not GP fault attempts to write bit 0. In a similar manner, if a processor only supports IBRS, attempts to set STIBP do not GP fault.
Both SPEC_CTRL and PRED_CMD are not architecturally serializing WRMSRs. They are still execution serializing and prevent any execution of future instructions until they have completed.
CPUID Function 8000_0008, EBX[17]=1 indicates an STIBP always on mode. The processor prefers that STIBP is only set once during boot and not changed. This reduces the performance impact of the WRMSR (Write to Model Specific Register) at the necessary toggle points.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Ever since the Meltdown and Spectre exploits were exposed, Microsoft has been working overtime to patch Windows against them. Unfortunately, they were quite secretive about their Spectre and Meltdown patch list and schedule. We usually only find out when something bad happens, like when some patches bricked AMD systems.
They changed that stance recently, quietly releasing their Windows Spectre and Meltdown patch schedule. This schedule listed the patches they have released so far, or are about to release. For your convenience, we have divided and sorted them according to the applicable Windows version.
Please note that the current Microsoft Spectre and Meltdown patch schedule covers the January and February 2018. We will update the schedule as and when Microsoft releases them.
Article Update History
Click here for the Article Update History
Updated @ 2018-02-22 :Added the late January and early February 2018 Spectre and Meltdown patch schedule for Windows 10 and Windows Server 2016.
Originally posted @ 2018-01-24
The Spectre + Meltdown Patch Schedule For Windows 10
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The Meltdown and Spectre CPU flaws that the Google Project Zero team discovered are arguably the worst we have ever known. These vulnerabilities were built into BILLIONS of CPUs that we have been using for the last decade or so.
Not just Intel CPUs, but also CPUs made by AMD, Apple and ARM. Even those that power our smartphones and other smart devices!
Let’s take a look at what we know so far about Meltdown and Spectre, how they affect you, and what we can do about them.
This story is still developing. We will update the article as and when new details emerge. Be sure to check back and refresh the page for the latest information!
Article Update History
Click here for the Article Update History
2018-02-17 :Updated the table of CPUs vulnerable to Meltdown and Spectre.Updated four sections with new information.
2018-02-05 :Added a table of CPUs vulnerable to Meltdown and Spectre.Updated three sections with new information.
2018-01-25 :Revamped the entire article. Added a new section on the difference between Meltdown and Spectre, and a new section on InSpectre. Updated the list of vulnerable processors, mitigation efforts by Microsoft and Apple, as well as the Intel spontaneous reboot issues with their Spectre 2 patches.
2018-01-16 : Updated the list of vulnerable processors, and added a new section on Intel CPUs spontaneously rebooting after applying Meltdown and Spectre patches. Also added cautionary advice on holding off these updates.
2018-01-12 : Updated the article with the AMD confirmation that their processors are vulnerable to both Spectre exploits. Also added details on the Google Retpoline mitigation technique against Spectre attacks.
2018-01-11 : Added new sections on the performance impact of the Meltdown and Spectre mitigation patches, and reports of those patches bricking some AMD PCs. Also expanded the list of affected CPUs, and corrected information on the Intel-SA-00086 Detection Tool.
Between 2018-01-09 and 2018-01-10 : Numerous updates including details of patches and affected CPUs.
Originally posted @ 2018-01-09
The Meltdown + Spectre Vulnerabilities
The Project Zero team identified these vulnerabilities in 2017, reporting it to Intel, AMD and ARM on 1 June 2017.
These vulnerabilities take advantage of the Speculative Execution and Branch Prediction features of the modern processor, that have been used for many years to improve performance.
Speculative Execution lets the CPU predict and pre-execute the next instruction, allowing it to “instantly” deliver the results if it’s correct.
Branch Prediction helps the CPU predict future execution paths that should be speculatively-executed for better performance.
There are THREE (3) variants of the speculative execution CPU bug :
The Spectre attack (whitepaper) exploits variants 1 and 2.
The Meltdown attack (whitepaper) exploits variant 3.
There is a Variant 3a, which appears to affect only certain ARM processors.
What’s The Difference Between Meltdown & Spectre?
Spectre tricks the CPU branch predictor into mis-predicting the wrong path, thereby speculatively executing code that would not otherwise be executed.
Meltdown takes advantage of the out-of-order execution capability of modern processors, tricking them into executing malicious code that would normally not be allowed.
The Spectre name is based on both the root cause – speculative execution, and the fact that it is not easy to fix, and will haunt us for a long time like a spectre (ghost).
The Meltdown name was chosen because the vulnerability “basically melts security boundaries which are normally enforced by the hardware“.
How Bad Are Meltdown & Spectre?
The Spectre exploits let an attacker access and copy information from the memory space used by other applications.
The Meltdown exploit lets an attacker copy the entire physical memory of the computer.
Unless patched, the affected processors are vulnerable to malware and cyberattacks that exploits this CPU bug to steal critical information from running apps (like login and credit card information, emails, photos, documents, etc.)
While the Meltdown exploit can be “fixed”, it is likely that the Spectre exploit cannot be fixed, only mitigated, without a redesign of the processors. That means we will have to live with the risks of a Spectre attack for many more years to come.
The Intel-SA-00086 Detection Tool does NOT detect the processor’s susceptibility to these vulnerabilities. It only checks for different vulnerabilities affecting the Intel Management Engine.
InSpectre
Our reader Arthur shared that the Gibson Research Corporation has an aptly-named utility called InSpectre.
It checks for Meltdown and Spectre hardware and software vulnerabilities in a Windows system. It will help you check if your system is getting patched properly against these vulnerabilities.
What Is Being Done??? Updated!
Note : The terms “mitigate” and “mitigation” mean the possibility of a successfully attacked are reduced, not eliminated.
Intel has started issuing software and firmware updates for the processors introduced in the last 5 years. By the middle of January 2018, Intel expects to have issued updates for more than 90% of those CPUs. However, that does not address the other Intel processors sold between 2010 and 2012.
Microsoft and Linux have started to roll our the KPTI (Kernel Page Table Isolation) patch, also known as the KAISER (Kernel Address Isolation to have Side-channels Efficiently Removed) patch.
The KPTI or KAISER patch, however, will only protect against the Meltdown exploit. It has no effect on a Spectre attack.
Microsoft Edge and Internet Explorer 11 received the KB4056890 security update on 3 January 2018, to prevent a Meltdown attack.
Firefox 57 includes changes to mitigate against both attacks.
Google Chrome 64 will be released on 23 January 2018, with mitigations against Meltdown and Spectre attacks.
For Mac systems, Apple introduced mitigations against Spectre in macOS 10.13.2 (released on 8 January 2018), with more fixes coming in macOS 10.13.3.
For iOS devices, Apple introduced mitigations against Meltdown in iOS 11.2 and tvOS 11.2.
On 8 January 2018, Apple released iOS 11.2.2, which mitigates the risk of the two Spectre exploits in Safari and WebKit, for iPhone 5s, iPad Air, and iPod touch 6th generation or later.
Google patched Android against both exploits with the December 2017 and January 2018 patches.
Google shared details of their Return Rrampoline (Retpoline) binary modification technique that can be used to protect against Spectre attacks. It is a software construct that ensures that any associated speculative execution will “bounce” (as if on a trampoline) endlessly.
On 11 January 2018, AMD announced that the “majority of AMD systems” have received the mitigation patches against Spectre 1, albeit some older AMD systems got bricked by bad patches. They also announced that they will make “optional” microcode updates available for Ryzen and EPYC processors by the same week.
In the same 11 January 2018 disclosure, AMD also shared that Linux vendors have started to roll out OS patches for both Spectre exploits, and they’re working on the “return trampoline (Retpoline)” software mitigations as well.[adrotate group=”2″]
On 8 February 2018, an Intel microcode update schedule revealed that their Penryn-based processors are also vulnerable, adding an additional 314 CPU models to the list of vulnerable processors.
On 14 February 2018, Intel revealed an expanded Bug Bounty Program, offering up to $250,000 in bounty awards.
Some AMD PCs Got Bricked
In the rush to mitigate against Meltdown and Spectre, Microsoft released Windows 10 patches that bricked some AMD PCs. They blamed the incorrect / incomplete documentation provided by AMD.
Intel’s rush to patch Meltdown and Spectre resulted in buggy microcode patches, causing several generations of their CPUs to randomly and spontaneously reboot.
So far, over 800 Intel CPU models have been identified to be affected by these spontaneous reboot issues. If you have one of the affected CPUs, please hold off BIOS / firmware updates!
Intel has identified the cause as the Spectre 2 patches in their microcode updates for some of these processors. They’re still investigating the cause of the other affected CPU models.
Fortunately for Windows users, Microsoft issued the KB4078130 emergency update to stop the reboots while Intel worked to fix the issue.
First and foremost – DO NOT PANIC. There is no known threat or attack using these exploits.
Although we listed a number of important patches below, the buggy updates are worse than the potential threat they try to fix. So we advise HOLDING OFF these patches, and wait for properly-tested versions a few weeks down the line.
If you are using an iOS device, get updated to iOS 11.2 or tvOS 11.2.
If you are using Firefox, update to the latest Firefox 57.
If you are using Google Chrome, make sure you watch out for Chrome 64, which will be released on 23 January.
Download and install the latest software firmware updates from your PC, laptop, motherboard brands. In particular, install the latest driver for the Intel Management Engine (Intel ME), the Intel Trusted Execution Engine (Intel TXE), and the Intel Server Platform Services (SPS)
If you are using an Intel system, hold off updating your firmware, unless you have already verified that your CPU is not affected by the buggy Intel patches, or Intel has already issued corrected patches.
The Performance Impact Of The Mitigation Patches
Many benchmarks have been released, showing performance impacts of between 5% to 30%, depending on the type of benchmark and workload. Microsoft has called those benchmark results into question, stating that they did not cover both operating system and silicon microcode patches.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The Intel Bug Bounty Program was launched in March 2017, but after Meltdown and Spectre, Intel kicked it up a notch. Find out how you can earn up to $250,000 hunting bugs!
The New Intel Bug Bounty Program
The Intel Bug Bounty Program was created to incentivise security researchers to hunt for bugs in Intel’s products. However, it was an invitation-only program, which greatly limited the pool of eligible bug hunters.
On 14 February 2018, Rick Echevarria, the Vice President and General Manager of Platform Security at Intel, announced the expansion of the Intel Bug Bounty Program. Here are the changes :
The Intel Bug Bounty Program is no longer invitation-only. Anyone who meets the minimum requirements are eligible to participate.
Intel created a new bounty targeted specifically at side channel vulnerability (like Meltdown and Spectre). This bounty ends on 31 December 2018, and pays up to $250,000.
Intel also raised bounty awards across the board, with awards of up to $100,000 for other vulnerabilities.
The New Intel Bug Bounty Awards
Vulnerability Severity
Intel Software
Intel Firmware
Intel Hardware
Critical (9.0 – 10.0)
Up to $10,000
Up to $30,000
Up to $100,000
High (7.0 – 8.9)
Up to $5,000
Up to $15,000
Up to $30,000
Medium (4.0 – 6.9)
Up to $1,500
Up to $3,000
Up to $5,000
Low (0.1 – 3.9)
Up to $500
Up to $1000
Up to $2,000
Intel will award a Bounty for the first report of a vulnerability with sufficient details to enable reproduction by Intel.
Intel will award a Bounty from $500 to $250,000 USD depending on the nature of the vulnerability and quality & content of the report.
The first external report received on an internally known vulnerability will receive a maximum of $1,500 USD Award.
The approved CVSS calculators which may be used for determining the baseline Severity of all reported vulnerabilities shall be either the NVD CVSSv3 calculator or the FIRST CVSSv3 calculator at Intel’s sole discretion.[adrotate group=”2″]
Intel will publicly recognize security researchers on advisories and Bug Bounty collateral, at or after the time of public disclosure of the vulnerability, if & as agreed to by the researcher who reported the vulnerability.
Awards are limited to one (1) Bounty Award per eligible root-cause vulnerability. If that vulnerable component is present in other Intel products, a Bounty Award will be paid only for the first reported product instance. Intel, at its sole discretion, will decide whether the reported vulnerability is the first reported product instance of that root-cause vulnerability.
The Side Channel Vulnerability Bounty Awards
This is a time-limited bounty that ends on 31 December 2018, and is limited to bugs that are :
root-caused to Intel hardware
exploitable via software
Vulnerability Severity
Intel Hardware w/ Side Channel Exploit through Software
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The New Intel Bug Bounty Program Requirements
To qualify for the new Intel Bug Bounty Program, you must meet ALL of the following requirements.
You are reporting in an individual capacity or, if employed by another company, you have that company’s written approval to submit a report to Intel’s Bug Bounty program.
You are at least 18 years of age, and, if considered a minor in your place of residence, you have your parent’s or legal guardian’s permission prior to reporting.
You are not a resident of a US-embargoed country.
You are not on a US list of sanctioned individuals.
You are not currently nor have been an employee of Intel Corporation, or an Intel subsidiary, within 6 months prior to submitting a report.
You are not currently nor have been under contract to Intel Corporation, or an Intel subsidiary, within 6 months prior to submitting a report.
You are not a family nor household member of any individual who currently or within the past 6 months meets or met the criteria listed in the two bullet points directly above.
You agree to participate in testing mitigation effectiveness and coordinating disclosure / release / publication of your finding with Intel.
The New Intel Bug Report Requirements
For your Intel bug reports to be eligible for bounty award consideration, they must meet the following requirements :
Must pertain to an item explicitly listed below as “Eligible Intel products and technologies”.
Must identify an original and previously unreported & not publicly disclosed vulnerability.
Must have been tested against most recent publicly available version of the affected product or technology.
Must include clear documentation on the vulnerability and instructions on how to reproduce the vulnerability.
Must include your assessed CVSS v3 vector string, score, and rating using one of the approved CVSS v3 calculators referenced below.
The following are vulnerabilities that will not qualify for bounty awards :
Vulnerabilities in pre-release versions (e.g., Beta, Release Candidate).
Vulnerabilities in versions no longer under active support.
Vulnerabilities already known to Intel.
Vulnerabilities present in any component of an Intel product where the root-cause vulnerability in the component has already been identified for another Intel product.
Vulnerabilities considered out of scope as defined below.
[adrotate group=”1″]
Eligible Intel Products & Technologies
Intel Hardware
Processor (inclusive of micro-code ROM + updates)
Chipset
FPGA
Networking / Communication
Motherboard / System (e.g., Intel Compute Stick, NUC)
Solid State Drives
Intel Firmware
UEFI BIOS (Tiano core components for which Intel is the only named maintainer)
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Microsoft has stopped pushing a number of Windows 10 updates, including the Meltdown and Spectre mitigation patches, because they were bricking some AMD PCs. Frustrated users were left with their AMD PCs in an unbootable state after installing those updates. The cure was, in this case, worse than the disease!
Updated @ 2018-01-16 : Added another affected CPU, a new section on Microsoft’s confusing statement, and a new section on what you should do.
Updated @ 2018-01-15 : Added 6 more CPUs affected by these Windows 10 updates, as well as the official word from AMD.
Updated @ 2018-01-11 : Added more AMD CPUs that were reported to have failed to boot up, after applying these Meltdown and Spectre patches.
Originally posted @ 2018-01-10
These Windows 10 Updates Are Bricking AMD PCs!
Following reports of users unable to boot up their AMD PCs after applying Windows 10 updates, Microsoft has identified the following security patches and updates from 3-9 January 2018 as the culprits :
In the affected AMD systems, the Windows logo will appear after the PC reboots to complete the upgrade process. However, it won’t complete the boot process.
What AMD CPUs Are Affected? Updated!
Neither Microsoft nor AMD have revealed what AMD CPUs are affected but based on user reports, here is a list of affected AMD CPUs.
AMD Ryzen Threadripper 1950X
AMD Ryzen 7 1700
AMD FX-8350
AMD A10-7800
AMD FX-6350
AMD Phenom II X6 Black Edition 1090T
AMD Opteron 180
AMD Athlon X2 5050e
AMD Athlon X2 4850e
AMD Athlon X2 4450B
AMD Athlon X2 L310
AMD Athlon 64 X2 6400+
AMD Athlon 64 X2 6000+
AMD Athlon 64 X2 5600+
AMD Athlon 64 X2 5400+
AMD Athlon 64 X2 5200+
AMD Athlon 64 X2 5000+
AMD Athlon 64 X2 4600+
AMD Athlon 64 X2 4400+
AMD Athlon 64 X2 4200+
AMD Athlon 64 X2 4000+
AMD Athlon 64 X2 3800+
AMD Athlon 64 X2 3200+
AMD Athlon 64 X2 TK-57
AMD Athlon 64 X2 TK-55
AMD Athlon 64 FX-62
AMD Athlon 64 FX-60
AMD Athlon 64 1640B
AMD Sempron 3200+
AMD Turion Neo X2 L625
AMD Turion 64 X2 TL-60
AMD Turion 64 X2 TL-56
AMD Turion X2 RM-72
AMD Turion X2 RM-70
There has been at least one case each involving the newer Ryzen 7 and Threadripper processors, but these are outliers. So far, this issue affects mostly older AMD Athlon processors. However, there
Needless to say, the list above is NOT EXHAUSTIVE. We will update the list, as and when, people report them.
On 11 January 2018, AMD stated that the problem affected AMD Opteron, Athlon and Turion X2 Ultra processors.
How Did This Happen?
Microsoft is blaming documentation from AMD, stating that “some AMD chipsets do not conform to the documentation previously provided to Microsoft to develop the Windows operating system mitigations to protect against the chipset vulnerabilities known as Spectre and Meltdown.“
Technically, Meltdown and Spectre are CPU, not chipset, vulnerabilities. So Microsoft was probably referring to CPU documentation provided by AMD.
What Is Being Done?
Because Windows 10 forcibly installs updates, Microsoft has temporarily stopped pushing those Windows 10 updates to the affected AMD processors. They’re now working with AMD to correct the problem with those patches.
According to AMD, the new patches will be issued sometime in the week of 15-21 January 2018. At the time of this update (16 January 2018), the new patches have not been released.
Microsoft’s Confusing Statement New!
[adrotate group=”2″]
Microsoft invited some confusion when they stated on 11 January 2018 that “Microsoft has resumed updating the majority of AMD devices with the Windows operating system security update to help protect against the chipset vulnerabilities known as Spectre and Meltdown.”
As far as we can tell – they only resumed Windows 10 updates for the AMD CPUs that are NOT affected by this problem. They merely identified the affected subset of AMD CPUs, and only blocked updates to them – “A small subset of older AMD processors remain blocked to avoid users getting into an unbootable state after installation of recent Windows operating system security updates.”
Should You Install Windows 10 Updates? New!
As Microsoft claims to have accurately determined which subset of AMD CPUs are affected, it is theoretically safe to continue installing Windows 10 updates. Windows 10 should be able to identify your CPU and block the updates if it’s one of the affected models.
That said, there is still NO RISK of a Meltdown or Spectre attack. For all of the hype and panic, there are no know exploits of the speculative execution bug in the wild. The Meltdown and Spectre exploits also require physical access to the system.
So we still think it is better to be safe than sorry and HOLD OFF your Windows 10 updates, if you have an OLDER AMD CPU, until Microsoft releases the proper patches in the next few days.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Lemi Orhan Ergin did not give Apple any forewarning when he publicly revealed the massive macOS root bug on Twitter. He basically exposed a zero-day vulnerability for hackers to use, while Apple rushed on a bug fix. The good news is Apple just issued the root bug fix in Security Update 2017-001.
This is really fast work, but it also showed their sloppiness. Hopefully, the bug fix does not introduce additional bugs!
macOS Security Update 2017-001
[adrotate group=”2″]
Apple released macOS Security Update 2017-001 just a day after the macOS root bug was revealed. They also gave us more information on the bug that caused so much ruckus around the world (and rightly so).
The bug only affected macOS High Sierra 10.13.1.
The bug did not affect computers running macOS Sierra 10.12.6 or earlier.
They confirmed that it allowed an attacker to “bypass administrator authentication without supplying the administrator’s password“.
The macOS root bug fix is now available for download via the App Store. If it doesn’t appear yet, just click on the Updates icon to refresh.
Please note that this bug fix will reset and disable the root user account. If you need to use the root user account, you will need to re-enable it, and change its password, after applying the update.
Terminal Users, Watch Out!
If you’re using Terminal to update though, you may face some complications due to Apple’s sloppiness. Chai discovered that Apple accidentally used a space instead of the version number.
This is not an issue if you are downloading the patch through the App Store. But if you’re applying the patch via Terminal, you need to add a space.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
The Internet is abuzz with the shocking revelation that now everyone can hack an Apple computer… as long as it’s using the latest macOS High Sierra operating system. Let us explain what’s going on, and share with you the workaround for the macOS High Sierra root bug.
Updated @ 2017-11-30 : Added a new section on the Apple bug fix (Security Update 2017-001) [1], and additional information on the root bug [2].
Originally posted @ 2017-11-29
What Is Root User?
If you are the primary user of a MacOS X system, you have an administrator account with administrator privileges. This gives you more privileges and access than a standard user account. However, that is not the highest access level possible.
There is a Mac superuser account called “root” that gives you elevated read and write privileges to hidden or protected areas of the system. With the Mac root user account, you can even access files in other user accounts.
In fact, it gives you such God-like powers, you can modify or even delete critical system files. In fact, a Mac root user can use the rm -rf * command to delete the contents of every mounted drive in the computer, until macOS crashes when a crucial file or folder is deleted.
So this Mac root user account should only remain disabled unless you really, REALLY need to use it.
On Tuesday, 28 November 2017, Turkish software developer Lemi Orhan Ergin revealed the macOS High Sierra root bug. With a few simple steps, anyone can gain elevated root user privileges in any computer running macOS High Sierra! Here is a summary of what we know about the root bug :
The root bug exploit requires a computer running macOS High Sierra, with multiple user accounts.
When prompted for a username and password, use these steps to gain root user access without any password :
Type “root” as the username and leave the password field blank.
Just click “Unlock” twice.
The root bug cannot be exploited remotely, unless screen sharing is enabled.
The root bug was introduced in macOS High Sierra 10.13.1. Earlier versions of macOS were not affected.
Apple confirmed that the bug was due to “a logic error… in the validation of credentials“.
Apple also confirmed that the bug would allow an attacker to “bypass administrator authentication without supplying the administrator’s password“.
Several security researchers successfully replicated the bug.
The macOS High Sierra root bug is EXTREMELY serious, because it allows a hacker to easily bypass all of the macOS operating system’s security protections.
It doesn’t matter if you encrypted your computer, and secured it with an extremely long and complex password. Anyone who gains root user privileges using this bug can access (read, copy or move) the files in any user account (even those of an administrator) without knowing the password.
What’s even more troubling is that the root bug works even with a disabled root user account. This means the vast majority of Apple computers running on High Sierra are compromised, as the root user account is disabled by default.
How To Fix The Root Bug?
Unlike other security researchers, Lemi Orhan Ergin did not forewarn Apple before publicly revealing the bug, on Twitter no less. He basically exposed a zero-day vulnerability for hackers to use, while Apple rushes to fix the bug.
1. Install macOS Security Update 2017-001 New!
Apple just released Security Update 2017-001. This update will remove the root bug and improve credential validation. INSTALL THIS UPDATE NOW!
Note : This bug fix will reset and disable the root user account. If you need to use the root user account, you will need to re-enable it, and change its password, after applying the update.
Note : Apple rushed out this update so quickly that they accidentally used a space instead of the version number. You can read more about this in our article – Apple Rushed Out macOS Root Bug Fix & It Shows…
This is not an issue if you are downloading the patch through the App Store. But if you’re applying the patch via Terminal, you need to add a space.
Alternatively, you can opt to move your sensitive data to encrypted containers or drives using third-party encryption utilities like VeraCrypt. Hackers may use the High Sierra root bug to gain access to the encrypted containers or drives, but without the correct password, the actual data won’t be accessible.
4. Physically Protect Your Apple Computer
The good news is the High Sierra root bug generally requires physical access to your Apple computer. Until this bug is fixed, you should make sure your Apple computer is never left unsupervised.
Keep it in a locked room or bag, whenever you are not using it. If no one can get to it, they cannot use the bug to gain root access.
5. Disable Screen Sharing
The High Sierra root bug can be exploited remotely if Screen Sharing is enabled. So make sure you disable Screen Sharing.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
Errata 123 refers to the 123rd bug identified in AMD Athlon and Opteron processors. This bug affects the cache bypass feature in those processors.
These processors have an internal data path that allows the processor to bypass the L2 cache and initiate an early DRAM read for certain cache line fill requests, even before receiving the hit/miss status from the L2 cache.
However, at low core frequencies, the DRAM data read may reach the processor core before it is ready. This causes data corruption and/or the processor to hang.
This bug affects the following processor families :
Dual Core AMD Opteron (Socket 940, 939)
AMD Athlon 64 X2 (Socket 939)
The Errata 123 BIOS feature is a workaround for the bug. It allows you to disable the cache bypass feature and avoid the bug from manifesting.
When enabled, the processor will not bypass the L2 cache to prefetch data from the system memory.
When disabled, the processor will continue to bypass the L2 cache for certain cache line fill requests. This improves its performance.
When set to Auto, the BIOS will query the processor to see if it is affected by the bug. If the processor is affected, the BIOS will enable this BIOS feature. Otherwise, it will leave it disabled.
If your processor is affected by this bug, you should enable this BIOS feature to prevent the processor from hanging or corrupting data. But if your processor is not affected by this bug, disable this BIOS feature for maximum performance.
Details
As processors get more and more complex, every new processor design inevitably comes with a plethora of bugs. Those that are identified are given errata numbers.
Errata 123 refers to the 123rd bug identified in AMD Athlon and Opteron processors. This bug affects the cache bypass feature in those processors.
These processors have an internal data path that allows the processor to bypass the L2 cache and initiate an early DRAM read for certain cache line fill requests, even before receiving the hit/miss status from the L2 cache.
However, at low core frequencies, the DRAM data read may reach the processor core before it is ready. This causes data corruption and/or the processor to hang.
This bug is present in AMD’s processor revisions of JH-E1, BH-E4 and JH-E6. These revisions affect the following processor families :
[adrotate banner=”4″]
Dual Core AMD Opteron (Socket 940, 939)
AMD Athlon 64 X2 (Socket 939)
The processor families that are not affected are :
AMD Opteron (Socket 940)
AMD Athlon 64 (Socket 754, 939)
AMD Athlon 64 FX (Socket 940, 939)
Mobile AMD Athlon 64 (Socket 754)
AMD Sempron (Socket 754, 939)
Mobile AMD Sempron (Socket 754)
Mobile AMD Athlon XP-M (Socket 754)
AMD Turion Mobile Technology
The Errata 123 BIOS feature is a workaround for the bug. It allows you to disable the cache bypass feature and avoid the bug from manifesting.
When enabled, the processor will not bypass the L2 cache to prefetch data from the system memory.
When disabled, the processor will continue to bypass the L2 cache for certain cache line fill requests. This improves its performance.
When set to Auto, the BIOS will query the processor to see if it is affected by the bug. If the processor is affected, the BIOS will enable this BIOS feature. Otherwise, it will leave it disabled.
If your processor is affected by this bug, you should enable this BIOS feature to prevent the processor from hanging or corrupting data. But if your processor is not affected by this bug, disable this BIOS feature for maximum performance.
Support Tech ARP!
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
