Kernel Side-Channel Attack using Speculative Store Bypass - CVE-2018-3639

Man at this rate I'm not going to upgrade my desktop for another 2 years until the architectures have a chance to catch up to mitigate some of the speculative attacks.

Haswell is getting a little long in the tooth though.

So what you are saying is that this is an Intel only fault yet again, and could only theoretically affects others

>remote code execution as root if a linux machine gets its IP address from dhcp
Windows doesn't even have shit like that.

How many years back was that one?

So why hasn't anyone taking advantage of this bug yet? It's been almost a year now, is it just too complex, requires physical access or what?

Like .0003 years?

Attached: i guess it cant be helped.jpg (750x563, 62K)

CVE-2018-1111
It was an redhat added feature to their packaged version of NetworkManager, not a linux bug per se.

Ah, I thought it was Shellshock.

Attached: 1523040418990.png (447x378, 11K)

Just rely on kernel mitigations until the spectre-ng patched CPU's come out, by then microcode updates should work and be mostly stable

Affected products:
Intel® Core™ i3 processor (45nm and 32nm)
Intel® Core™ i5 processor (45nm and 32nm)
Intel® Core™ i7 processor (45nm and 32nm)
Intel® Core™ M processor family (45nm and 32nm)
2nd generation Intel® Core™ processors
3rd generation Intel® Core™ processors
4th generation Intel® Core™ processors
5th generation Intel® Core™ processors
6th generation Intel® Core™ processors
7th generation Intel® Core™ processors
8th generation Intel® Core™ processors
Intel® Core™ X-series Processor Family for Intel® X99 platforms
Intel® Core™ X-series Processor Family for Intel® X299 platforms
Intel® Xeon® processor 3400 series
Intel® Xeon® processor 3600 series
Intel® Xeon® processor 5500 series
Intel® Xeon® processor 5600 series
Intel® Xeon® processor 6500 series
Intel® Xeon® processor 7500 series
Intel® Xeon® Processor E3 Family
Intel® Xeon® Processor E3 v2 Family
Intel® Xeon® Processor E3 v3 Family
Intel® Xeon® Processor E3 v4 Family
Intel® Xeon® Processor E3 v5 Family
Intel® Xeon® Processor E3 v6 Family
Intel® Xeon® Processor E5 Family
Intel® Xeon® Processor E5 v2 Family
Intel® Xeon® Processor E5 v3 Family
Intel® Xeon® Processor E5 v4 Family
Intel® Xeon® Processor E7 Family
Intel® Xeon® Processor E7 v2 Family
Intel® Xeon® Processor E7 v3 Family
Intel® Xeon® Processor E7 v4 Family
Intel® Xeon® Processor Scalable Family
Intel® Atom™ Processor C Series (C3308, C3338, C3508, C3538, C3558, C3708, C3750, C3758, C3808, C3830, C3850, C3858, C3950, C3955, C3958)
Intel® Atom™ Processor E Series

Intel® Atom™ Processor A Series
Intel® Atom™ Processor X Series (x5-E3930, x5-E3940, x7-E3950)
Intel® Atom™ Processor T Series (T5500, T5700)
Intel® Atom™ Processor Z Series
Intel® Celeron® Processor J Series (J3355, J3455, J4005, J4105)
Intel® Celeron® Processor N Series (N3450)
Intel® Pentium® Processor J Series (J4205)
Intel® Pentium® Processor N Series (N4000, N4100, N4200)
Intel® Pentium® Processor Silver Series (J5005, N5000)

my pentium 4 and atom n270 not affected. nice.

That is correct. There is no need to patch your CPU if it is AMD.

>So what you are saying is that this is an Intel only fault yet again
No you dipshit. PowerPC processors offered speculative execution years before Intel designed the P6 Pentium.

>Intel® Atom™ Processor Z Series
Wait what? Where did you get this list from? If this is right, then this really isn't good since the Atom Z series wasn't affected by previous Spectre class vulnerabilities, meaning more processors are being added as these vulnerabilities come out. Did Intel come out with a new Atom Z series other than the 2008 and 2010 Z series Atom processors that I'm not aware of?

*stops having these problems*

Attached: 2018-05-22-124045_2358x1090_scrot.png (2358x1090, 1.49M)

From Red Hat's simple explanation of the issue: youtube.com/watch?v=Uv6lDgcUAC0

AMD's response: amd.com/en/corporate/security-updates
Intel's response: newsroom.intel.com/editorials/addressing-new-research-for-side-channel-analysis/

Both whitepapers have a switch for patching this and the default is off. God, this is going to kill performance if you have it on, isn't it?

Fuck, the list is from Intel's site, so the list of processors being affected by Spectre is increasing:
intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html

I was going to start trying to push SBCs based on the ARM Cortex A7 since those are still being made and haven't been affected, but now I'm worried that those will may be affected in the near future. I really hope the N series Atom processors don't get affected by this.

All microprocessors.

So it's an Intel only thing again?

Nope
ARM A53 quad core master race
Serious question,
How many of you guys believe this
And keep buying broken hardware
You're teaching Intel that this is OK
That you will keep buying any steaming shit they dump out
No new hardware with speculative execution for me

>ARM A53 quad core master race
Don't get your hopes up. Intel just added the old Atom Z series to the list of affected processors when previously they were saying all their Atom processors prior to 2013 were okay. It's still possible that we may see the currently unaffected ARMv7-a and ARMv8-a processors be added to the list of affected processors in the future.

>MUH *nix is secure mem
Hahah haha

>commit 764f3c21588a059cd783c6ba0734d4db2d72822d
>AMD does not need the Speculative Store Bypass mitigation to be enabled.
AHAHAHHAHAH

Attached: o0706061912226370991.png (706x619, 122K)

You have no idea what you're talking about
A53 cores do not do speculative execution
at all

raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

I think you are misunderstanding this. The patch says that AMD doesn't need a generic migitation because they have their own way to disable it via processor chicken bit.

If you read patchwork.kernel.org/patch/9697991/, it seems the bit they refer to in that patch is the following:

>14h Errata 551
>"Processor May Not Forward Data From Store to a Page Crossing Read-Modify-Write Operation"

So yeah, it probably sucks less than needing a generic fix but it still means they are venerable. Hoping this gets added into Zen 2 before it releases.

>t. Intel damage control team
That's unrelated to this. Also ctrl+f 17h No results found.

I have to restart all my servers don't I?

>Errata 551
14h is bobcat APUs from 2011 and AMD's docs last revised in 2013 have mentions of that specific errata. Talk about grasping at straws

Ubuntu has a fix out. Debian is still vulnerable security-tracker.debian.org/tracker/CVE-2018-3639

That link seems to be listing out of order execution as a requirement for a processor to be vulnerable to Spectre, when it's not. The ARM Cortex A8 is listed as being vulnerable to Spectre by ARM and is a completely in order processor.

>A53 cores do not do speculative execution
The Cortex A53 (along with all ARMv8-a, ARMv7-a, and even ARMv6 cores) has a branch predictor and will fill the pipeline with instructions past a branch before that branch actually happens.

Yeah
cat /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
Mitigation: Speculative Store Bypass disabled via prctl and seccomp

>mfw Ubuntu is not Debian Sid with Amazon botnet anymore

Attached: 1393020993476.jpg (689x720, 107K)

Okay, hear me out if I am misunderstanding AMD's whitepaper from their website but from what I read, the paper at developer.amd.com/wp-content/resources/124441_AMD64_SpeculativeStoreBypassDisable_Whitepaper_final.pdf states the following:

>AMD processors families 15h, 16h, and some models of family 17h have logic that allow loads to bypass older stores but lack the architectural SPEC_CTRL or VIRT_SPEC_CTRL. For software that requires protection, software can directly manipulate non-architectural MSRs.

Which just means, unless I'm mistaken, Bulldozer, Puma and some Zen models are all affected.

Quoting the kernel patch:

>AMD does not need the Speculative Store Bypass mitigation to be enabled. The parameters for this are already available and can be done via MSR C001_1020. Each family uses a different bit in that MSR for this.

Putting 2 and 2 together, this means that using the correct machine specific registers and turning on/off the right chicken bits, you can turn on the mitigation via disabling speculative loads?

Someone correct me if I got it wrong.

nobody except low level developers read the technical documents and definitely not people on Jow Forums. Most normal people just install the update.

Just like with spectre v2, it looks like it's only theoretically possible to exploit this but just in case they still provide a way to disable speculated memory loads if it's past a store instruction to unknown address. They are literarily telling to leave the default as is because of the low risk

Attached: o0800057612134453719.png (800x576, 192K)

lol you know thats stupid to say and you know it.
The exploits are to fix it not to throw it out idiot.

Could someone please explain to me the exact criteria for a processor being affected by Spectre if out of order execution isn't a part of it? Does it depend on what is happening at each stage of the pipeline? That ARM A8 being vulnerable despite not offering out of order execution is bothering me, as that would seem to open a ton of other processors to potentially being vulnerable.

Is OoO execution the worst idea on CS history then?

No, the whole thing reads that if the store bypass mitigation is specifically requested (the default auto doesn't enable it on amd) and the processor is h15 to h17 then use the bits instead of the generic mitigation code. lrn2kernel senpai.

It's an awesome idea and the same concept should be expanded from the within single core context to multithreaded work as well. Imagine being able to split work that is inherently sequential to multiple threads i.e baking a cake by having one thread mix the ingredient and one or more other threads baking the predicted mixtures at the same time. The moment the mix thread is done, if one of the prediction was correct, you can just pick the baked result and not have to wait for the baking time like you normally would.

>os is responsible for (known but hidden) hardware fuck ups
haha haha

It affects all systems. There will be many more CVEs related to the same bug.

Is that 8% performance drop on Intel with this fix on top of the existing spectre fixes or combined perfromance loss?

>a user
>has to have access to the system

literally nothing.

SOURCE OR DELET THIS

>He thinks this can't be combined with other exploits.

The lack of critical thinking in this thread is alarming.

Only if you cut corners in implementing it for muh performance like Intel

>like a web-browser

Pot kernel blacked

Attached: 1526303349046.gif (524x276, 1.52M)

>4.14.39
C'mon son.

Attached: SLACKMOTHERFUCKERtdotsuperchunk.png (1148x595, 545K)