The Infosec Thread: Yes, time to move off Entrust

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›509 »

Achmed Jones: Oct 16, 2004

If you�re getting Event 69 errors you basically have won at Windows, the next step from here is to try to catch exit code 420 on Linux

# ? Jan 1, 2018 08:14

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 17:28

bobfather: Sep 20, 2001; I will analyze your nervous system for beer money

anthonypants posted:

I have no idea where you're getting this information.

I posted above, but it was a fever dream confusing Enterprise with LTSB.

# ? Jan 1, 2018 13:11

Craptacular: Jul 11, 2004

https://vimeo.com/148946917

# ? Jan 1, 2018 17:50

Rexxed: May 1, 2010; Dis is amazing!
I gotta try dis!

I'd rather not click to enable adobe flash player, thanks.

# ? Jan 1, 2018 18:13

BlankSystemDaemon: Mar 13, 2009

2018 is off to a great start, with at least one theory that it's a priv-esc exploit against hypervisor(s) like the ones being used by Amazon and Google.

# ? Jan 1, 2018 19:54

Thanks Ants: May 21, 2004; #essereFerrari

# ? Jan 1, 2018 20:31

CLAM DOWN: Feb 13, 2007; nesaM killed Masen

D. Ebdrup posted:

2018 is off to a great start, with at least one theory that it's a priv-esc exploit against hypervisor(s) like the ones being used by Amazon and Google.

Amazing

# ? Jan 1, 2018 20:39

Double Punctuation: Dec 30, 2009; Ships were made for sinking;
Whiskey made for drinking;
If we were made of cellophane
We'd all get stinking drunk much faster!

Wait. How are VMs supposed to get enough continuous access to the address bus to cause DIMMs to fail? Eventually, another VM is going to do some memory-intensive work.

# ? Jan 1, 2018 22:06

some kinda jackal: Feb 25, 2003; �
�

Rexxed posted:

I'd rather not click to enable adobe flash player, thanks.

https://www.youtube.com/watch?v=7E2w4sTLKtA&t=2s

# ? Jan 2, 2018 01:44

unknown: Nov 16, 2002; Ain't got no stinking title yet!

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

quote:

... (much clipped) ...

Impact

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs � from database applications to JavaScript in web browsers � to discern to some extent the contents of protected kernel memory.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful � such as write to a file or open a network connection � it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.

... (more clipped) ...

However, it may be that the vulnerability in Intel's chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

"AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault."

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to perform, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked � such as reading kernel memory from user mode � and completes that instruction before the privilege level check occurs.

... (more clipped) ...

unknown fucked around with this message at 02:31 on Jan 3, 2018

# ? Jan 3, 2018 02:28

Judge Schnoopy: Nov 2, 2005; dont even TRY it, pal

unknown posted:

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

The worst part about this vulnerability is that it impacts every Intel CPU, but is going to be drat near impossible to even sum up for non-tech people. High level overviews are still complicated as gently caress.

# ? Jan 3, 2018 02:42

anthonypants: May 6, 2007; by Nyc_Tattoo; Dinosaur Gum

Judge Schnoopy posted:

The worst part about this vulnerability is that it impacts every Intel CPU, but is going to be drat near impossible to even sum up for non-tech people. High level overviews are still complicated as gently caress.

I'm pretty sure it's still under embargo.

# ? Jan 3, 2018 02:44

Trabisnikof: Dec 24, 2005

Judge Schnoopy posted:

The worst part about this vulnerability is that it impacts every Intel CPU, but is going to be drat near impossible to even sum up for non-tech people. High level overviews are still complicated as gently caress.

its likely a similar flaw impacts at least some ARM chips as well: https://lwn.net/Articles/740393/

# ? Jan 3, 2018 03:05

CLAM DOWN: Feb 13, 2007; nesaM killed Masen

The more I read about the vulnerability the more I want to exit the technology industry and just watch it all burn from the outside

# ? Jan 3, 2018 03:27

Evis: Feb 28, 2007; Flying Spaghetti Monster

I�m enjoying watching it burn from the inside.

# ? Jan 3, 2018 03:34

Jedi425: Dec 6, 2002; THOU ART THEE ART THOU STICK YOUR HAND IN THE TV DO IT DO IT DO IT

CLAM DOWN posted:

The more I read about the vulnerability the more I want to exit the technology industry and just watch it all burn from the outside

I�m getting out of the managed hosting business in a couple of weeks and let me tell you, seeing this unfold a week after signing the offer letter is just the best feeling. I don�t even want to know what kind of poo poo is going to happen here once the details get revealed.

# ? Jan 3, 2018 03:59

Potato Salad: Oct 23, 2014; nobody cares

Soooooooo, hypervisors? Tell me if I'm going astray here, my daily interaction with virtualization is largely though an orchestration stack.

This is an exploit on the fact that an Intel cpu can be tricked into running a process while supposedly in kernel mode on user memory. The physical kernel on a hypervisor is the hypervisor's own kernel that determines whether (A) a guest's process can run straight on the cpu as is or whether (B) it's a call for privileged functionality that needs to be emulated by the hypervisor kernel or run directly on hardware with a security identifier tagging alongside.

So, we have ExploitProcess (EP) running on vm CompromisedGuest (CG). CG and HaplessGuest (HG) are on esxi metal VmwareHost (VH).

EP makes a system call that is first prediction bait then "Show me random memory lol" afterward. HG is really a vm whose system call is trapped by VH, which emulates the expected results of the call, and does so with prediction. The cpu goes on to run "show me some random memory" in what should be machine-specific space but isn't because it's not checking whether it should actually be doing this poo poo at all. poo poo in HG is slowly bled.

Like, this loving exposes guests to each other, right?

# ? Jan 3, 2018 04:45

deimos: Nov 30, 2006; Forget it man this bat is whack, it's got poobrain!

Potato Salad posted:

Like, this loving exposes guests to each other, right?

Yes.

# ? Jan 3, 2018 04:51

Bunni-kat: May 25, 2010; Service Desk B-b-bunny...
How can-ca-caaaaan I
help-p-p-p you?

Okay, this is bad, I get that. What I don�t get is, if you�re running VMs for private use and there�s no direct connection to the WAN, they�re ostensibly safe, right?

I�m just trying to figure out the full scope of how hosed this is.

# ? Jan 3, 2018 05:04

The Fool: Oct 16, 2003

Good write up and fits my understanding of the issue as well.

Now imagine how big of the deal this is on something like AWS or Azure with potentially thousands of guests on the same hardware.

E:

Avenging_Mikon posted:

Okay, this is bad, I get that. What I don�t get is, if you�re running VMs for private use and there�s no direct connection to the WAN, they�re ostensibly safe, right?

I�m just trying to figure out the full scope of how hosed this is.

The risk is minimized in your scenario, yes.

# ? Jan 3, 2018 05:05

Bunni-kat: May 25, 2010; Service Desk B-b-bunny...
How can-ca-caaaaan I
help-p-p-p you?

The Fool posted:

Good write up and fits my understanding of the issue as well.

Now imagine how big of the deal this is on something like AWS or Azure with potentially thousands of guests on the same hardware.

E:

The risk is minimized in your scenario, yes.

Thanks. Now tomorrow I�m going to grill our infrastructure team on what lives on what physical host. I know our terminal server is in trouble with this.

# ? Jan 3, 2018 05:10

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

This has been crossposted a few times as a possibly-related cause for this:

https://cyber.wtf/2017/07/28/negative-result-reading-kernel-memory-from-user-mode/

I'm probably not reading this right, but I think what it's saying is that you can probably read kernel memory by using speculative execution to create a race condition where the CPU will load a memory address that triggers a page fault and then load another offset address based on its contents before the page fault goes through, and the contents can be iteratively resolved based on the cache timing.

# ? Jan 3, 2018 05:13

Potato Salad: Oct 23, 2014; nobody cares

So, bets on the brand name of the vulnerability?

My money is on "Give Intel Half A Trillion Dollars This Year As Everyone Rushes To Increase The Raw Amount Of Silicon On Earth By 25% Above Existing Demand Trend"

# ? Jan 3, 2018 05:48

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Speculative Hypervisor Ownage by Repeatedly Testing Information Not Typically Expected to Load

# ? Jan 3, 2018 05:59

CLAM DOWN: Feb 13, 2007; nesaM killed Masen

OneEightHundred posted:

Speculative Hypervisor Ownage by Repeatedly Testing Information Not Typically Expected to Load

Thread title

# ? Jan 3, 2018 06:01

Potato Salad: Oct 23, 2014; nobody cares

Too late, ceo already sold a bunch

# ? Jan 3, 2018 06:09

Absurd Alhazred: Mar 27, 2010; by Athanatos

Potato Salad posted:

Too late, ceo already sold a bunch

AKA the Equifax Platinum Parachute

# ? Jan 3, 2018 06:28

Klyith: Aug 3, 2007; GBS Pledge Week

code:

+ * On Intel CPUs, if a SYSCALL instruction is at the highest canonical
+ * address, then that syscall will enter the kernel with a
+ * non-canonical return address, and SYSRET will explode dangerously.
+ * We avoid this particular problem by preventing anything executable
+ * from being mapped at the maximum canonical address.
+ *
+ * On AMD CPUs in the Ryzen family, there's a nasty bug in which the
+ * CPUs malfunction if they execute code from the highest canonical page.
+ * They'll speculate right off the end of the canonical space, and
+ * bad things happen.  This is worked around in the same way as the
+ * Intel problem.

Page Table Shut Up and Jam Gaiden: This bug is canonical

Klyith fucked around with this message at 08:01 on Jan 3, 2018

# ? Jan 3, 2018 07:13

The Fool: Oct 16, 2003

Lol, so much for amd being immune

# ? Jan 3, 2018 07:17

Kazinsal: Dec 13, 2011

That looks like a separate problem as the processor will probably just fail to resolve addresses in the speculative fetcher and do something undefined -- I would love to know exactly what, but LOL at the magic that is Free Software coding standards; "will explode dangerously" and "bad things happen" like come on now Linux people you can loving comment better than that.

# ? Jan 3, 2018 08:10

anthonypants: May 6, 2007; by Nyc_Tattoo; Dinosaur Gum

Kazinsal posted:

That looks like a separate problem as the processor will probably just fail to resolve addresses in the speculative fetcher and do something undefined -- I would love to know exactly what, but LOL at the magic that is Free Software coding standards; "will explode dangerously" and "bad things happen" like come on now Linux people you can loving comment better than that.

Source your quotes

# ? Jan 3, 2018 08:12

Klyith: Aug 3, 2007; GBS Pledge Week

The Fool posted:

Lol, so much for amd being immune

They're different bugs, the AMD one is much less severe security-wise. From what I can tell on AMD the malicious user process will hard crash the host machine, including from inside a VM. which is unfortunate but not as bad.

Seems that linux at least is applying the the fix globally to all x86 cpus, no matter what. So AMD is gonna get hit by the performance slowdown as well on linux systems. Who knows what the MS patch will do, MS may have been able to target better. Working on a secret embargoed bug in open source is probably a lot harder than having a team of employees who can do the work quietly and behind closed doors.

# ? Jan 3, 2018 08:38

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

You realize the things you posted are a totally different set of bugs from the "we're introducing page table isolation (with the corresponding performance hit) to mitigate this" intel bug, right?

# ? Jan 3, 2018 08:47

I would blow Dane Cook: Dec 26, 2008

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

# ? Jan 3, 2018 13:25

Thanks Ants: May 21, 2004; #essereFerrari

All those admins with a separate 12-year-old Proliant for each application would probably feel quite smug if they kept up with any sort of tech news.

# ? Jan 3, 2018 14:14

apropos man: Sep 5, 2016; You get a hundred and forty one thousand years and you're out in eight!

Would it be possible to have two verions of the kernel: one for Vee-Emming and one for plain desktop/laptop use? I don't wanna lose up to 30% performance.

This is probably a bad idea, but fuckit: hit post.

# ? Jan 3, 2018 14:55

Pile Of Garbage: May 28, 2007

apropos man posted:

Would it be possible to have two verions of the kernel: one for Vee-Emming and one for plain desktop/laptop use? I don't wanna lose up to 30% performance.

This is probably a bad idea, but fuckit: hit post.

You'd need two separate computers, one with the patch (Whatever it is) installed and the other without the patch installed. Of course I'd refrain from running out and buying poo poo or whatever until the embargo is lifted and we actually find out how big a deal the issue really is.

# ? Jan 3, 2018 15:15

Klyith: Aug 3, 2007; GBS Pledge Week

apropos man posted:

Would it be possible to have two verions of the kernel: one for Vee-Emming and one for plain desktop/laptop use? I don't wanna lose up to 30% performance.

This is probably a bad idea, but fuckit: hit post.

I mean if you control those VMs yourself and know there's nothing bad running in them, it's not a big deal and just use the one?

Anyways there's a kernel switch nopti to boot without FUCKWIT, so you just add a new line to your bootloader to avoid it. edit: on linux that is, maybe you're talking about windows.

# ? Jan 3, 2018 15:40

apropos man: Sep 5, 2016; You get a hundred and forty one thousand years and you're out in eight!

Klyith posted:

I mean if you control those VMs yourself and know there's nothing bad running in them, it's not a big deal and just use the one?

Anyways there's a kernel switch nopti to boot without FUCKWIT, so you just add a new line to your bootloader to avoid it. edit: on linux that is, maybe you're talking about windows.

I was talking about Linux. Thanks for the advice about that kernel parameter.

I suppose I've got nothing majorly exposed to the outside world on my server VM's, so it aint a problem.

It's the performance drop in desktop use that's really got the potential to piss me off. I just spent �1150 on a brand new Thinkpad and I'm running Fedora on it. I got an i5 because I think an i5 is 'plenty' for Linux. That thought might turn out to bite me. This thing is literally a week old.

# ? Jan 3, 2018 15:52

Adbot: ADBOT LOVES YOU

# ? May 19, 2024 17:28

Potato Salad: Oct 23, 2014; nobody cares

Linux workstations run clean and efficient. My thoughts and prayers are with you.

# ? Jan 3, 2018 17:04

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Infosec Thread: Yes, time to move off Entrust

«‹›509 »