[Script Info]
Title: 
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:18.75,Default,,0000,0000,0000,,{\i1}36c3 preroll{\i0}
Dialogue: 0,0:00:18.75,0:00:25.03,Default,,0000,0000,0000,,Herald: So like many operators, in my\Ngroup, we actually use a lot of ESXi
Dialogue: 0,0:00:25.03,0:00:27.87,Default,,0000,0000,0000,,servers. You would think that after using\Nthese things for 10 years, I would know
Dialogue: 0,0:00:27.87,0:00:35.05,Default,,0000,0000,0000,,how to speak, but I do not. We use these\Nfor virtualizing machines. Some of... some of
Dialogue: 0,0:00:35.05,0:00:39.92,Default,,0000,0000,0000,,these actually runs on sandboxes or, you\Nknow, run kind of dubious software on it.
Dialogue: 0,0:00:39.92,0:00:45.53,Default,,0000,0000,0000,,So we really do want to prevent these\Nprocesses from jumping from the virtual
Dialogue: 0,0:00:45.53,0:00:54.49,Default,,0000,0000,0000,,environment to the hypervisor environment.\NWe have today - we have - f1yyy, he wants
Dialogue: 0,0:00:54.49,0:01:02.62,Default,,0000,0000,0000,,to be known by f1yyy, so I'm respecting\Nthat; and he's from Triton Security Labs,
Dialogue: 0,0:01:02.62,0:01:09.67,Default,,0000,0000,0000,,and he's going to show us how the exploits\Nthat he discovered in the, I think it was
Dialogue: 0,0:01:09.67,0:01:15.49,Default,,0000,0000,0000,,the last Chinese GeekPwn capture the flag.\NHe's gonna show us how these things work,
Dialogue: 0,0:01:15.49,0:01:21.97,Default,,0000,0000,0000,,and was that I would like to help. I would\Nlike to ask you, to help me, welcome f1yyy
Dialogue: 0,0:01:21.97,0:01:23.64,Default,,0000,0000,0000,,onto the stage.
Dialogue: 0,0:01:23.64,0:01:28.63,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:01:28.63,0:01:41.67,Default,,0000,0000,0000,,f1yyy: Hello. Thanks for the introduction.\NGood evening, everybody. I'm f1yyy a
Dialogue: 0,0:01:41.67,0:01:49.13,Default,,0000,0000,0000,,Senior Security Researcher at Chaitin\NTechnology. I'm going to present The Great
Dialogue: 0,0:01:49.13,0:01:56.88,Default,,0000,0000,0000,,Escape of ESXi; Breaking Out of a\NSandboxed Virtual Machine. We have
Dialogue: 0,0:01:56.88,0:02:05.46,Default,,0000,0000,0000,,demonstrated this exploit chain before at\NGeekPwn 2018. I will introduce our
Dialogue: 0,0:02:05.46,0:02:12.06,Default,,0000,0000,0000,,experience of escaping the sandbox on the\NESXi. I will also introduce the work we
Dialogue: 0,0:02:12.06,0:02:23.02,Default,,0000,0000,0000,,have done about the sandbox on the ESXi.\NNow let's start it. We come from the
Dialogue: 0,0:02:23.02,0:02:28.69,Default,,0000,0000,0000,,Chaitin Security Research Lab. We have\Nresearched many practical targets in
Dialogue: 0,0:02:28.69,0:02:35.75,Default,,0000,0000,0000,,recent years, including PS4 jailbreak,\NAndroid rooting, IoT offensive research,
Dialogue: 0,0:02:35.75,0:02:43.74,Default,,0000,0000,0000,,and so on. Some of us also play CTF with\NTeam b1o0p and Tea Deliverers. We recently
Dialogue: 0,0:02:43.74,0:02:51.72,Default,,0000,0000,0000,,own the championship at HITCON final. We\Nare also the organizer of the Real World
Dialogue: 0,0:02:51.72,0:02:58.68,Default,,0000,0000,0000,,CTF. We've created some very hard\Nchallenges this year. So if you are
Dialogue: 0,0:02:58.68,0:03:09.40,Default,,0000,0000,0000,,interested in it, we welcome you to\Nparticipate in our CTF game. Now, before
Dialogue: 0,0:03:09.40,0:03:16.15,Default,,0000,0000,0000,,we start our journey to escaping the\Nvirtual machine, we need to figure out
Dialogue: 0,0:03:16.15,0:03:24.93,Default,,0000,0000,0000,,what is virtual machine escape? I like to\Nask some of you that, did anyone use the
Dialogue: 0,0:03:24.93,0:03:32.13,Default,,0000,0000,0000,,virtualization software? If you have used\Nthe virtualization software, like VMware
Dialogue: 0,0:03:32.13,0:03:41.20,Default,,0000,0000,0000,,Workstation, Hyper-V, VirtualBox and so\Non, please raise your hand. Okay, okay,
Dialogue: 0,0:03:41.20,0:03:50.25,Default,,0000,0000,0000,,okay. Thanks, thanks, thanks. Many. So if\Nyou are a Software Engineer or a Security
Dialogue: 0,0:03:50.25,0:03:58.93,Default,,0000,0000,0000,,Researcher, you'll probably have used\Nvirtualisation software, but if anyone has
Dialogue: 0,0:03:58.93,0:04:03.73,Default,,0000,0000,0000,,heard of the word virtual machine escape,\Nif you have heard of that, please raise
Dialogue: 0,0:04:03.73,0:04:12.87,Default,,0000,0000,0000,,your hand again. Oh, oh, surprised.\NThanks, thanks, thanks. It surprises me
Dialogue: 0,0:04:12.87,0:04:20.56,Default,,0000,0000,0000,,that all you know about that, but I have\Nto introduce that again. What's virtual
Dialogue: 0,0:04:20.56,0:04:25.24,Default,,0000,0000,0000,,machine escape? You know, in most\Ncircumstances the host OS runs on the
Dialogue: 0,0:04:25.24,0:04:32.69,Default,,0000,0000,0000,,hypervisor and the hypervisor will handle\Nsome sensitive instructions executed by
Dialogue: 0,0:04:32.69,0:04:40.09,Default,,0000,0000,0000,,the guest OS. Host OS emulates virtual\Nhardware and handles RPC requests from the
Dialogue: 0,0:04:40.09,0:04:49.50,Default,,0000,0000,0000,,guest OS. That's the architecture of\Nnormal virtualization software. And the
Dialogue: 0,0:04:49.50,0:04:59.34,Default,,0000,0000,0000,,guest OS is isolated from each other and\Ncannot affect the host OS. However, if
Dialogue: 0,0:04:59.34,0:05:04.66,Default,,0000,0000,0000,,there are some bugs, or if there are some\Nvulnerabilities existing in the host OS,
Dialogue: 0,0:05:04.66,0:05:13.15,Default,,0000,0000,0000,,it's possible for the guest OS to escape\Nfrom the virtualization environment. They
Dialogue: 0,0:05:13.15,0:05:21.14,Default,,0000,0000,0000,,can exploit these vulnerabilities. And\Nfinally, they can execute arbitrary code
Dialogue: 0,0:05:21.14,0:05:30.88,Default,,0000,0000,0000,,on the host. So this is the Virtual\NMachine Escape. Then why we chose ESXi as
Dialogue: 0,0:05:30.88,0:05:39.22,Default,,0000,0000,0000,,our target? The first reason is we know\Nthat more and more companies are using or
Dialogue: 0,0:05:39.22,0:05:48.55,Default,,0000,0000,0000,,plan to use private cloud to store its\Nprivate data, including these companies
Dialogue: 0,0:05:48.55,0:05:56.67,Default,,0000,0000,0000,,and the vSphere is an enterprise solution\Noffered by VMware. It's popular between
Dialogue: 0,0:05:56.67,0:06:02.60,Default,,0000,0000,0000,,companies. If you are a Net-Manager of a\Ncompany, you may know about VMware
Dialogue: 0,0:06:02.60,0:06:11.81,Default,,0000,0000,0000,,vSphere. And the ESXi is the hypervisor\Nfor VMware vSphere, so it's widely used in
Dialogue: 0,0:06:11.81,0:06:17.81,Default,,0000,0000,0000,,private cloud. That's the first reason.\NThe second one is that it's a challenging
Dialogue: 0,0:06:17.81,0:06:24.74,Default,,0000,0000,0000,,target for us. There are several\Nexploitations of VMware Workstation in
Dialogue: 0,0:06:24.74,0:06:30.79,Default,,0000,0000,0000,,recent years. Hackers escape from the\NVMware Workstation by exploiting some
Dialogue: 0,0:06:30.79,0:06:38.52,Default,,0000,0000,0000,,vulnerabilities. These vulnerabilties\Nexist in graphic cards, network cards and
Dialogue: 0,0:06:38.52,0:06:48.82,Default,,0000,0000,0000,,USB devices and so on. But, there has been\Nno public escape of ESXi before, so it's a
Dialogue: 0,0:06:48.82,0:06:58.31,Default,,0000,0000,0000,,challenging target for us and we love\Nchallenge. Then why is the ESXi so
Dialogue: 0,0:06:58.31,0:07:04.93,Default,,0000,0000,0000,,challenging? The first reason I think is\Nthat there are little documents about its
Dialogue: 0,0:07:04.93,0:07:13.64,Default,,0000,0000,0000,,architecture. The only thing we have found\Nis a white paper offered by VMware. The
Dialogue: 0,0:07:13.64,0:07:20.49,Default,,0000,0000,0000,,white paper only includes some definitions\Nand pictures without details. So let's
Dialogue: 0,0:07:20.49,0:07:29.46,Default,,0000,0000,0000,,take a brief look at the architecture of\NESXi first. ESXi is an Enterprise bare-
Dialogue: 0,0:07:29.46,0:07:35.80,Default,,0000,0000,0000,,metal hypervisor and it includes two\Nparts. The kernel, it uses VMKernel
Dialogue: 0,0:07:35.80,0:07:42.07,Default,,0000,0000,0000,,developed by VMware and the User Worlds\Nand the other part, the User Worlds. The
Dialogue: 0,0:07:42.07,0:07:51.48,Default,,0000,0000,0000,,VMKernel is a POSIX-like operating system.\NAnd it is uses an in-memory filesystem. It
Dialogue: 0,0:07:51.48,0:07:59.29,Default,,0000,0000,0000,,means that all files stored in this system\Nare not persistent. And the VMKernel also
Dialogue: 0,0:07:59.29,0:08:08.47,Default,,0000,0000,0000,,manages hardware and schedules resource\Nfor ESXi. VMKernel also includes VMWare
Dialogue: 0,0:08:08.47,0:08:15.34,Default,,0000,0000,0000,,drivers, I/O Stacks and some User World\NAPIs offered to the User Worlds. And the
Dialogue: 0,0:08:15.34,0:08:25.56,Default,,0000,0000,0000,,word "User World" is used by VMWare to\Nrefer the processes running in VMKernel
Dialogue: 0,0:08:25.56,0:08:31.77,Default,,0000,0000,0000,,operating system and the word "User World"\Nmeans that a group of these processes.
Dialogue: 0,0:08:31.77,0:08:38.30,Default,,0000,0000,0000,,This process can only use a limited /proc\Ndirectory and limited signals and it can
Dialogue: 0,0:08:38.30,0:08:45.07,Default,,0000,0000,0000,,just use some of the POSIX API. For\Nexample, there are some User Worlds
Dialogue: 0,0:08:45.07,0:08:55.88,Default,,0000,0000,0000,,processes like hosted, ssh, vmx and so on.\NThen this is the architecture of ESXi. I
Dialogue: 0,0:08:55.88,0:09:02.81,Default,,0000,0000,0000,,would like to give you an example to show\Nhow a virtual machine works on ESXi. The
Dialogue: 0,0:09:02.81,0:09:09.25,Default,,0000,0000,0000,,VMX process in the User World can\Ncommunicate with the VMM by using some
Dialogue: 0,0:09:09.25,0:09:18.83,Default,,0000,0000,0000,,undocumented customized system call. And\Nthe VMM will initialize the environment
Dialogue: 0,0:09:18.83,0:09:27.42,Default,,0000,0000,0000,,for the guest OS. When guest OS executes\Nsome sensitive instructions, it will cause
Dialogue: 0,0:09:27.42,0:09:35.49,Default,,0000,0000,0000,,a VMExit and return to VMM. The VMX\Nprocess also emulates virtual hardware and
Dialogue: 0,0:09:35.49,0:09:41.45,Default,,0000,0000,0000,,handles RPC requests from the guest.\NThat's how a virtual machine works on
Dialogue: 0,0:09:41.45,0:09:49.34,Default,,0000,0000,0000,,ESXi. Then, how can we escape from the\Nvirtual machine on ESXi? If there is a
Dialogue: 0,0:09:49.34,0:09:57.78,Default,,0000,0000,0000,,vulnerability in the virtual hardware of\Nthe VMX, we can write a driver, or write
Dialogue: 0,0:09:57.78,0:10:07.41,Default,,0000,0000,0000,,an exploit, to escape from it. The driver\Nwill communicate with the virtual hardware
Dialogue: 0,0:10:07.41,0:10:14.48,Default,,0000,0000,0000,,and it can exploit the vulnerability. And\Nfinally we can execute shellcode in the
Dialogue: 0,0:10:14.48,0:10:19.85,Default,,0000,0000,0000,,VMX process. So it means that we have\Nsuccessfully escaped from the virtual
Dialogue: 0,0:10:19.85,0:10:28.27,Default,,0000,0000,0000,,machine on the ESXi. So the second reason\Nabout why ESXi is so challenging, is that
Dialogue: 0,0:10:28.27,0:10:40.28,Default,,0000,0000,0000,,User World API. The VMX uses many\Nundocumented and customized system calls
Dialogue: 0,0:10:40.28,0:10:46.52,Default,,0000,0000,0000,,and if you want to reverse some code of\NVMX it is hard for you to understand which
Dialogue: 0,0:10:46.52,0:10:55.63,Default,,0000,0000,0000,,API the VMX is using. But luckily we found\Ntwo system call tables after compromising
Dialogue: 0,0:10:55.63,0:11:04.66,Default,,0000,0000,0000,,the k.b00 field. There are 2 system call\Ntables we found with symbols so this field
Dialogue: 0,0:11:04.66,0:11:11.74,Default,,0000,0000,0000,,will be useful if we want to reverse some\Ncode of the VMX. This is the second
Dialogue: 0,0:11:11.74,0:11:20.87,Default,,0000,0000,0000,,reason. Thirdly, there are some security\Nmitigations here, including ASLR and NX.
Dialogue: 0,0:11:20.87,0:11:27.41,Default,,0000,0000,0000,,It means that we need to link some address\Ninformation before we start our exploit
Dialogue: 0,0:11:27.41,0:11:34.67,Default,,0000,0000,0000,,to break the randomness of the address\Nspace. Furthermore after testing we found
Dialogue: 0,0:11:34.67,0:11:43.97,Default,,0000,0000,0000,,that there is another mitigation on the\NESXi. There is a sandbox that isolates the
Dialogue: 0,0:11:43.97,0:11:50.72,Default,,0000,0000,0000,,VMX process. So even if you can execute\Nsome shellcode in the VMX process you can
Dialogue: 0,0:11:50.72,0:11:57.95,Default,,0000,0000,0000,,not execute any commands, you can not read\Nany sensitive fields, unless you escape
Dialogue: 0,0:11:57.95,0:12:06.72,Default,,0000,0000,0000,,from the sandbox either. And finally, we\Nthink that the VMX of ESXi has a smaller
Dialogue: 0,0:12:06.72,0:12:13.65,Default,,0000,0000,0000,,attack surface. After comparison of the\NVMX binary between the Workstation and the
Dialogue: 0,0:12:13.65,0:12:20.92,Default,,0000,0000,0000,,ESXi we found that there are some function\Nthat have been moved from the VMX in User
Dialogue: 0,0:12:20.92,0:12:28.08,Default,,0000,0000,0000,,World to the VMKernel. For example the\Npacket transmission function in the e1000
Dialogue: 0,0:12:28.08,0:12:37.68,Default,,0000,0000,0000,,net card has been moved from the VMX to\Nthe VMKernel. And if you have read some
Dialogue: 0,0:12:37.68,0:12:44.57,Default,,0000,0000,0000,,security advisories published by VMware\Nrecently, you can notice that there are
Dialogue: 0,0:12:44.57,0:12:52.85,Default,,0000,0000,0000,,many vulnerabilites existing in the packet\Ntransmission part of the e1000 net card.
Dialogue: 0,0:12:52.85,0:13:00.69,Default,,0000,0000,0000,,And all these vulnerabilites only affect\NWorkstation. So we think that the VMX of
Dialogue: 0,0:13:00.69,0:13:09.54,Default,,0000,0000,0000,,ESXi has a smaller attack surface. Now\Nlet's start the journey of escaping from
Dialogue: 0,0:13:09.54,0:13:17.60,Default,,0000,0000,0000,,the ESXi. Let's overview the entire\Nexploit chain first. We use 2 memory
Dialogue: 0,0:13:17.60,0:13:23.71,Default,,0000,0000,0000,,corruption vulnerabilites in our exploit.\NThe first one is an uninitialized stack
Dialogue: 0,0:13:23.71,0:13:31.53,Default,,0000,0000,0000,,usage vulnerability which CVE Number is\NCVE-2018-6981. And the second is an
Dialogue: 0,0:13:31.53,0:13:40.82,Default,,0000,0000,0000,,unitialized stack read vulnerability and\Nthe CVE number is CVE-2018-6982. And we
Dialogue: 0,0:13:40.82,0:13:46.80,Default,,0000,0000,0000,,can do arbitrary address free by using the\Nfirst vulnerability, and we can get
Dialogue: 0,0:13:46.80,0:13:52.91,Default,,0000,0000,0000,,information leakage from the second one.\NAfter combining of these two
Dialogue: 0,0:13:52.91,0:14:00.06,Default,,0000,0000,0000,,vulnerabilites we can do arbitrary\Nshellcode execution in VMX process. And
Dialogue: 0,0:14:00.06,0:14:09.59,Default,,0000,0000,0000,,finally we use a logic vulnerability to\Nescape the sandbox of VMX and reverse a
Dialogue: 0,0:14:09.59,0:14:16.96,Default,,0000,0000,0000,,root shell from the ESXi. So that's the\Nentire exploit chain we use. Now let's
Dialogue: 0,0:14:16.96,0:14:24.33,Default,,0000,0000,0000,,start the first one. The first\Nvulnerability is an uninitialized stack
Dialogue: 0,0:14:24.33,0:14:32.75,Default,,0000,0000,0000,,usage vulnerability. It exists in VMXNET3\Nnetcard. When the VMX VMXNET3 netcard
Dialogue: 0,0:14:32.75,0:14:39.94,Default,,0000,0000,0000,,tries to execute command\NUPDATE_MAC_FILTERS it will us a structure
Dialogue: 0,0:14:39.94,0:14:47.75,Default,,0000,0000,0000,,on the stack, the PhysMemPage structure.\NThis structure is used to represent the
Dialogue: 0,0:14:47.75,0:14:54.41,Default,,0000,0000,0000,,memory mapping between the guest and the\Nhost. And it's also been used to transport
Dialogue: 0,0:14:54.41,0:15:01.81,Default,,0000,0000,0000,,data between the guest and the host. Then\Nthe VMXNET will call function
Dialogue: 0,0:15:01.81,0:15:07.80,Default,,0000,0000,0000,,DMA_MEM_CREATE to initialize the structure\Non the stack first, then it will use this
Dialogue: 0,0:15:07.80,0:15:16.38,Default,,0000,0000,0000,,structure to execute this command. And\Nfinally it uses PhysMemRelease to destroy
Dialogue: 0,0:15:16.38,0:15:23.41,Default,,0000,0000,0000,,the structure, the physical memory page\Nstructure. So it seems that there are no
Dialogue: 0,0:15:23.41,0:15:30.83,Default,,0000,0000,0000,,problems here. But if we look at the\Nfunction DMA memory create, we can notice
Dialogue: 0,0:15:30.83,0:15:39.61,Default,,0000,0000,0000,,that there is a check before the\Ninitialization of the PhysMemoryPage
Dialogue: 0,0:15:39.61,0:15:47.40,Default,,0000,0000,0000,,structure. It will check the argument\Naddress and the argument size and if the
Dialogue: 0,0:15:47.40,0:15:54.41,Default,,0000,0000,0000,,check passes then it will initialize the\Nstructure. But if the check fails, it will
Dialogue: 0,0:15:54.41,0:16:02.35,Default,,0000,0000,0000,,never initialize the structure on the\Nstack. And finally we found that we can
Dialogue: 0,0:16:02.35,0:16:13.27,Default,,0000,0000,0000,,control the address argument by writing a\Nvalue to one of the registers of VMXNET3.
Dialogue: 0,0:16:13.27,0:16:18.39,Default,,0000,0000,0000,,What is worse is that in function\NPhysMemoryRelease there are no checks
Dialogue: 0,0:16:18.39,0:16:24.82,Default,,0000,0000,0000,,about if the PhysMemoryPage structure had\Nbeen initialized and it just frees a
Dialogue: 0,0:16:24.82,0:16:34.19,Default,,0000,0000,0000,,pointer of this structure. So that's it\Nabout it. If we can pad the data on the
Dialogue: 0,0:16:34.19,0:16:42.43,Default,,0000,0000,0000,,stack it's possible for us to do arbitrary\Naddress free. We can pad a fake
Dialogue: 0,0:16:42.43,0:16:47.99,Default,,0000,0000,0000,,PhysMemoryPage structure on the stack and\Nthen make the check fail in the function
Dialogue: 0,0:16:47.99,0:16:53.76,Default,,0000,0000,0000,,DMA memory create and finally when it\Ncomes to the PhysMemoryRelease it will
Dialogue: 0,0:16:53.76,0:17:01.67,Default,,0000,0000,0000,,free a pointer of our PhysMemoryPage\Nstructure. So we just try to find a
Dialogue: 0,0:17:01.67,0:17:09.71,Default,,0000,0000,0000,,function to pad the data on the stack.\NThere is a design pattern in software
Dialogue: 0,0:17:09.71,0:17:18.03,Default,,0000,0000,0000,,development, where we store the data into\Nthe stack, if the size is small, when we
Dialogue: 0,0:17:18.03,0:17:25.54,Default,,0000,0000,0000,,allocate some memory. And otherwise we\Nwill output it to the heap. And we found a
Dialogue: 0,0:17:25.54,0:17:33.72,Default,,0000,0000,0000,,function that fits this pattern. This\Nfunction will be used when our guest OS
Dialogue: 0,0:17:33.72,0:17:40.66,Default,,0000,0000,0000,,executes the instruction outsb. It will\Ncheck the size, if the size is smaller
Dialogue: 0,0:17:40.66,0:17:48.41,Default,,0000,0000,0000,,than 0x8000 it will use the stack to store\Nthe data. And finally it will copy the
Dialogue: 0,0:17:48.41,0:17:55.64,Default,,0000,0000,0000,,data we send from the guest into the\Nstack. So we can use this function to pad
Dialogue: 0,0:17:55.64,0:18:02.80,Default,,0000,0000,0000,,the data on the stack. Then how do we\Ncombine this to do arbitrary address free?
Dialogue: 0,0:18:02.80,0:18:10.97,Default,,0000,0000,0000,,We can use outsb instruction in guest OS\Nfirst to pad the data on the stack. This
Dialogue: 0,0:18:10.97,0:18:19.26,Default,,0000,0000,0000,,data should contain fake PhysMemoryPage\Nstructure and the page count of this fake
Dialogue: 0,0:18:19.26,0:18:25.80,Default,,0000,0000,0000,,structure should be zero. The page array\Nof this fake PhysMemoryPage structure
Dialogue: 0,0:18:25.80,0:18:34.17,Default,,0000,0000,0000,,should be the address we want to free.\NThen we set some registers of the vmxnet3
Dialogue: 0,0:18:34.17,0:18:41.17,Default,,0000,0000,0000,,to make the check fail in the function DMA\Nmemory create. And finally, we order the
Dialogue: 0,0:18:41.17,0:18:50.32,Default,,0000,0000,0000,,vmxnet3 netcard, to execute the command to\Nupdate MAC filters and then in the VMX it
Dialogue: 0,0:18:50.32,0:18:57.23,Default,,0000,0000,0000,,will use the PhysMemRelease to destroy the\Nstructure we pad before. This structure is
Dialogue: 0,0:18:57.23,0:19:04.90,Default,,0000,0000,0000,,a fixed structure with pad in the first\Nstep and it will check the page count if it's 0. If
Dialogue: 0,0:19:04.90,0:19:12.11,Default,,0000,0000,0000,,it's 0, it will free the page\Narray of this fake PhysMemPage structure.
Dialogue: 0,0:19:12.11,0:19:17.86,Default,,0000,0000,0000,,So we can do arbitrary address free now by\Nusing the first uninitialized stack usage
Dialogue: 0,0:19:17.86,0:19:25.99,Default,,0000,0000,0000,,vulnerability. Here come the next one, the\Nsecond vulnerability also exists in the
Dialogue: 0,0:19:25.99,0:19:34.05,Default,,0000,0000,0000,,vmxnet3 net card. The vmxnet3 net card\Ntries to execute command get_coalesce. It
Dialogue: 0,0:19:34.05,0:19:43.43,Default,,0000,0000,0000,,will first get a length from the guest,\Nand the length must be 16. Then it
Dialogue: 0,0:19:43.43,0:19:51.50,Default,,0000,0000,0000,,initializes the first eight byte of a\Nstructure on the stack. But it's just for
Dialogue: 0,0:19:51.50,0:19:57.89,Default,,0000,0000,0000,,guest to initialize the next 8 byte of\Nthis structure and just write this
Dialogue: 0,0:19:57.89,0:20:07.08,Default,,0000,0000,0000,,structure back to our guest OS. So we can\Nlink 8 byte uninitialized data on the
Dialogue: 0,0:20:07.08,0:20:14.19,Default,,0000,0000,0000,,stack from the host to our guest. And\Nafter debugging the guest VMX process, we
Dialogue: 0,0:20:14.19,0:20:20.31,Default,,0000,0000,0000,,realized that there are fixed offsets\Nbetween the images, so it's possible for
Dialogue: 0,0:20:20.31,0:20:31.20,Default,,0000,0000,0000,,us to get all the information about the\Naddress space by using this vulnerability.
Dialogue: 0,0:20:31.20,0:20:38.32,Default,,0000,0000,0000,,Now, what do we have now? We can do\Narbitrary address free by using the first
Dialogue: 0,0:20:38.32,0:20:45.22,Default,,0000,0000,0000,,one. And we can get all information about\Nthe address space by using the second one.
Dialogue: 0,0:20:45.22,0:20:50.97,Default,,0000,0000,0000,,What do we want to do? We want to do\Narbitrary shell code execution in the
Dialogue: 0,0:20:50.97,0:20:58.33,Default,,0000,0000,0000,,VMX. So how do we combine these two\Nvulnerabilities to achieve our target?
Dialogue: 0,0:20:58.33,0:21:03.49,Default,,0000,0000,0000,,It's hard for us to do arbitrary shell\Ncode execution by using arbitrary address
Dialogue: 0,0:21:03.49,0:21:09.32,Default,,0000,0000,0000,,free. But it's easy for us to do arbitrary\Nshell code execution by using an arbitrary
Dialogue: 0,0:21:09.32,0:21:16.60,Default,,0000,0000,0000,,address write. So our target changes into\Nhow to do arbitrary address write by using
Dialogue: 0,0:21:16.60,0:21:25.65,Default,,0000,0000,0000,,arbitrary address free. Then we realized\Nthat we need a structure and this
Dialogue: 0,0:21:25.65,0:21:33.62,Default,,0000,0000,0000,,structure should include pointers we can\Nwrite and the size. So last we can
Dialogue: 0,0:21:33.62,0:21:40.44,Default,,0000,0000,0000,,overwrite this structure. We can do\Narbitrary address writes usually. When we
Dialogue: 0,0:21:40.44,0:21:48.51,Default,,0000,0000,0000,,first tried to exploit this vulnerability,\Nwe used some structures in the heap, but
Dialogue: 0,0:21:48.51,0:21:56.86,Default,,0000,0000,0000,,we've found that we can not manipulate the\Nheap's layout stably because VMX
Dialogue: 0,0:21:56.86,0:22:03.50,Default,,0000,0000,0000,,frequently allocates and releases\Nmemory. So we cannot use the structures in
Dialogue: 0,0:22:03.50,0:22:11.87,Default,,0000,0000,0000,,the heap. And after reversing some code of\NVMX, we have found a structure. The
Dialogue: 0,0:22:11.87,0:22:20.21,Default,,0000,0000,0000,,structure's name is channel and it's used \Nin VMWare RPCI. What's VMWare RPCI?
Dialogue: 0,0:22:20.21,0:22:26.85,Default,,0000,0000,0000,,VMWare has a series of RPC mechanisms to\Nsupport communication between the guest
Dialogue: 0,0:22:26.85,0:22:33.00,Default,,0000,0000,0000,,and the host. And here it has an\Ninteresting name: backdoor. RPCI is one of
Dialogue: 0,0:22:33.00,0:22:40.23,Default,,0000,0000,0000,,them. And the other one we may be familiar\Nwith is VMWare tools. I'd like to ask
Dialogue: 0,0:22:40.23,0:22:47.20,Default,,0000,0000,0000,,again if anyone has installed VMWare tools\Nin your guest OS, please raise your hands
Dialogue: 0,0:22:47.20,0:22:58.23,Default,,0000,0000,0000,,again. Oh, not as much as before. So if\Nyou use VMWare workstation, you'll
Dialogue: 0,0:22:58.23,0:23:04.85,Default,,0000,0000,0000,,probably have installed VMWare tools in\Nyour guest because once you installed it,
Dialogue: 0,0:23:04.85,0:23:12.79,Default,,0000,0000,0000,,you can use some convenient functions such\Nas copy and the paste text fields between
Dialogue: 0,0:23:12.79,0:23:20.94,Default,,0000,0000,0000,,the guest and the host, drag and drop\Nfiles, create shared folder and so on.
Dialogue: 0,0:23:20.94,0:23:29.61,Default,,0000,0000,0000,,VMWare tools are implemented by using some\NRPCI commands. And here are some examples
Dialogue: 0,0:23:29.61,0:23:37.76,Default,,0000,0000,0000,,about about some RPCI commands. For\Nexample, we can use info-set guestinfo to
Dialogue: 0,0:23:37.76,0:23:44.35,Default,,0000,0000,0000,,set some information about our guest and\Nwe can use info-get to retrieve this
Dialogue: 0,0:23:44.35,0:23:54.79,Default,,0000,0000,0000,,information back. Then what happens when\Nwe execute this RPCI command in our guest?
Dialogue: 0,0:23:54.79,0:24:03.23,Default,,0000,0000,0000,,For example, if we execute this RPCI\Ncommand 'info-set guestinfo.a' 123 in our
Dialogue: 0,0:24:03.23,0:24:12.94,Default,,0000,0000,0000,,guest OS. What happens in VMX? It will\Ncall VM Exit first and finally it will return
Dialogue: 0,0:24:12.94,0:24:22.69,Default,,0000,0000,0000,,to the RPCI handler of VMX. Then the RPCI\Nhandler will choose a subcommand to use by
Dialogue: 0,0:24:22.69,0:24:31.50,Default,,0000,0000,0000,,checking the value of the registers of our\Nguest OS. The RPC tool in our guest OS
Dialogue: 0,0:24:31.50,0:24:39.65,Default,,0000,0000,0000,,will use the subcommand, 'Open' first to\Nopen a channel and initialize it. Then it
Dialogue: 0,0:24:39.65,0:24:49.88,Default,,0000,0000,0000,,will use a subcommand, 'SendLen' to set\Nthe size of our channel and allocate heap
Dialogue: 0,0:24:49.88,0:24:56.11,Default,,0000,0000,0000,,memory to install the data of our RPC\Ncommand and suddenly it will use the
Dialogue: 0,0:24:56.11,0:25:07.78,Default,,0000,0000,0000,,'SendData' subcommand to pad the data of\Nthe memory we allocated before. And once
Dialogue: 0,0:25:07.78,0:25:15.75,Default,,0000,0000,0000,,the length of the data we sent from the\Nguest re-calls to the sizeof from the
Dialogue: 0,0:25:15.75,0:25:23.22,Default,,0000,0000,0000,,'SendLen' subcommand the VMX will use a\Ncorresponding RPCI command handler
Dialogue: 0,0:25:23.22,0:25:31.41,Default,,0000,0000,0000,,function after a string combination. And\Nfinally, it will use a 'Close' subcommand
Dialogue: 0,0:25:31.41,0:25:37.98,Default,,0000,0000,0000,,to destroy the channel structure including\Nsetting the size to zero and freeing the
Dialogue: 0,0:25:37.98,0:25:46.72,Default,,0000,0000,0000,,data pointer. That's what happens when we\Nexecute this RPCI commend in our guest.
Dialogue: 0,0:25:46.72,0:25:54.85,Default,,0000,0000,0000,,Furthermore, there is a channel structure\Narea in the data segment we can use. So
Dialogue: 0,0:25:54.85,0:26:03.74,Default,,0000,0000,0000,,this is a perfect structure for our\Nexploit. Now, you got all the things we
Dialogue: 0,0:26:03.74,0:26:09.72,Default,,0000,0000,0000,,want. We've got two vulnerabilities and\Nwe've got the structure we want. How do we
Dialogue: 0,0:26:09.72,0:26:20.28,Default,,0000,0000,0000,,combine this? We notice that the VMX uses\Nptmalloc of Glibc to manage its heap. So
Dialogue: 0,0:26:20.28,0:26:26.23,Default,,0000,0000,0000,,we just choose to use a fast-bin attack.\NWhat's the fast-bin attack? Fast-bin
Dialogue: 0,0:26:26.23,0:26:32.11,Default,,0000,0000,0000,,attack is a method to exploit heap\Nvulnerabilities of ptmalloc by using the
Dialogue: 0,0:26:32.11,0:26:41.25,Default,,0000,0000,0000,,singly-linked list. And it's the easiest\Nexploit method to exploit ptmalloc, I
Dialogue: 0,0:26:41.25,0:26:48.64,Default,,0000,0000,0000,,think. It's also the first method to\Nexploit ptmalloc that I learned when I
Dialogue: 0,0:26:48.64,0:26:56.84,Default,,0000,0000,0000,,just started to learn how to how to\Nexploit. Then after considering the check
Dialogue: 0,0:26:56.84,0:27:05.59,Default,,0000,0000,0000,,existing in the Glibc, we decided to free\Nthe address at the Reply Index of channel.
Dialogue: 0,0:27:05.59,0:27:15.24,Default,,0000,0000,0000,,Because by doing that, the Glibc will treat\Nthis address as a fake chunk and the Glibc
Dialogue: 0,0:27:15.24,0:27:23.31,Default,,0000,0000,0000,,will check the current chunk's size. And\Nafter doing that, the size of the fake
Dialogue: 0,0:27:23.31,0:27:30.36,Default,,0000,0000,0000,,chunk is also the size of the\N'channel[N]', so we can set a valid value
Dialogue: 0,0:27:30.36,0:27:38.69,Default,,0000,0000,0000,,to the size of the 'channel[N]' to bypass\Nthe check. So we can bypass the check.
Dialogue: 0,0:27:38.69,0:27:47.02,Default,,0000,0000,0000,,Once we've freed this address this fake\Nchunk will be put into the fast-bin linked
Dialogue: 0,0:27:47.02,0:27:59.12,Default,,0000,0000,0000,,list first. Then we can reallocate this\Nfake chunk by using another channel, N+2.
Dialogue: 0,0:27:59.12,0:28:08.00,Default,,0000,0000,0000,,Now we have a data pointer pointed at the\Nreply index of channel[N] and we can
Dialogue: 0,0:28:08.00,0:28:16.04,Default,,0000,0000,0000,,easily overwrite the channel[N+1] by using\Nchannel[N+2]. We can send a data to
Dialogue: 0,0:28:16.04,0:28:23.71,Default,,0000,0000,0000,,channel[N+2] and finally it will overwrite\Nsome parts of the channel[N+1]. So it's
Dialogue: 0,0:28:23.71,0:28:29.49,Default,,0000,0000,0000,,easy now for us to do arbitrary address\Nwrite by faking some parts of the channel
Dialogue: 0,0:28:29.49,0:28:39.33,Default,,0000,0000,0000,,structure. Do remember our target? Our\Ntarget is to do arbitrary shell code
Dialogue: 0,0:28:39.33,0:28:46.96,Default,,0000,0000,0000,,execution in VMX and we can do arbitrary\Naddress write now. There are many ways to
Dialogue: 0,0:28:46.96,0:28:52.37,Default,,0000,0000,0000,,do arbitrary shell code execution by using\Narbitrary address write. We choose to use
Dialogue: 0,0:28:52.37,0:29:02.85,Default,,0000,0000,0000,,a ROP. We can override the '.got.plt'\Nsegment. We can fake the channel[N+1],
Dialogue: 0,0:29:02.85,0:29:10.62,Default,,0000,0000,0000,,structure first, overwrite the data\Npointer at channel[N+1] to the address of
Dialogue: 0,0:29:10.62,0:29:21.94,Default,,0000,0000,0000,,.got.plt segment. Then we can overwrite\Nthe function pointer on the .got.plt
Dialogue: 0,0:29:21.94,0:29:30.94,Default,,0000,0000,0000,,segment. So once the VMX uses this\Nfunction we overwrite, it will jump to our
Dialogue: 0,0:29:30.94,0:29:40.78,Default,,0000,0000,0000,,ROP gadget. So it's also easy for us to do\Narbitrary shell code execution by using
Dialogue: 0,0:29:40.78,0:29:50.28,Default,,0000,0000,0000,,ROP. So now we can do arbitrary shell code\Nexecution in the VMX process. We're seeing
Dialogue: 0,0:29:50.28,0:29:56.82,Default,,0000,0000,0000,,that we have escaped from the virtual\Nmachine of the ESXi fully, we tried to
Dialogue: 0,0:29:56.82,0:30:06.35,Default,,0000,0000,0000,,execute some command by using a system\Ncall execve, but it fails. We tried to
Dialogue: 0,0:30:06.35,0:30:13.55,Default,,0000,0000,0000,,open and read some sensitive files just\Nlike password, it fails again. Then we
Dialogue: 0,0:30:13.55,0:30:22.75,Default,,0000,0000,0000,,realize that there is a sandbox. We cannot\Nexecute any commands unless we escape the
Dialogue: 0,0:30:22.75,0:30:31.65,Default,,0000,0000,0000,,sandbox either. The next part come to\Ncomes to the how we analyze and the
Dialogue: 0,0:30:31.65,0:30:41.54,Default,,0000,0000,0000,,escape the sandbox. After realizing that\Nthere is a sandbox in the ESXi, we reverse
Dialogue: 0,0:30:41.54,0:30:47.62,Default,,0000,0000,0000,,some code of the VMkernel and we find the\Nkernel module named as VM Kernel SAS
Dialogue: 0,0:30:47.62,0:30:54.54,Default,,0000,0000,0000,,control system. And this system, this\Nmodule, implements the fine grained checks
Dialogue: 0,0:30:54.54,0:31:04.01,Default,,0000,0000,0000,,for the system call. And it seems that\Nthis sandbox is a rule-based sandbox. So
Dialogue: 0,0:31:04.01,0:31:09.52,Default,,0000,0000,0000,,we just tried to find the configuration\Nfile of this sandbox. We finally found it
Dialogue: 0,0:31:09.52,0:31:15.93,Default,,0000,0000,0000,,at this directory,\N/etc/vmware/secpolicy/domains, and it
Dialogue: 0,0:31:15.93,0:31:24.56,Default,,0000,0000,0000,,seems that there are many different\Nsandboxes offered by VMWare to the
Dialogue: 0,0:31:24.56,0:31:33.74,Default,,0000,0000,0000,,different processes in the userworld. Like\Napp, plugin and the globalVMDom is a file
Dialogue: 0,0:31:33.74,0:31:43.82,Default,,0000,0000,0000,,for our VMX process and for our VM. After\Nreading that, it's obvious for us that the
Dialogue: 0,0:31:43.82,0:31:51.31,Default,,0000,0000,0000,,/var/run directory is the only directory\Nwhere we have read and write permissions.
Dialogue: 0,0:31:51.31,0:31:58.71,Default,,0000,0000,0000,,Then we look at the files existing in this\Ndirectory. We got a lot of pid filess just
Dialogue: 0,0:31:58.71,0:32:07.61,Default,,0000,0000,0000,,like crond, dcui, inetd and so on. And\Nit's also obvious that inetd.conf
Dialogue: 0,0:32:07.61,0:32:19.35,Default,,0000,0000,0000,,configure file is only configure file we\Ncan write. What's inetd? inetd is open
Dialogue: 0,0:32:19.35,0:32:27.63,Default,,0000,0000,0000,,source software and it's a super-server\Ndomain that provides internet services.
Dialogue: 0,0:32:27.63,0:32:34.93,Default,,0000,0000,0000,,Then we just analyze the contents of the\Ninetd.conf. The content of the inetd.conf
Dialogue: 0,0:32:34.93,0:32:44.23,Default,,0000,0000,0000,,is here on the ESXi. We can find that it a\Ndefines two services, ssh and the authd.
Dialogue: 0,0:32:44.23,0:32:50.30,Default,,0000,0000,0000,,And some of it defines which binary will\Nbe used by different services. For
Dialogue: 0,0:32:50.30,0:33:02.75,Default,,0000,0000,0000,,example, the authd will be used by the\Nauthd services. Also after some testing,
Dialogue: 0,0:33:02.75,0:33:08.90,Default,,0000,0000,0000,,we realize that the authd service is\Nalways enabled, while the sshd service is
Dialogue: 0,0:33:08.90,0:33:16.65,Default,,0000,0000,0000,,not. So this is the only configure file we\Ncan write. So we got an idea. How about
Dialogue: 0,0:33:16.65,0:33:24.14,Default,,0000,0000,0000,,overwriting this configure file? Or we can\Noverwrite the binary part for authd like
Dialogue: 0,0:33:24.14,0:33:31.81,Default,,0000,0000,0000,,that, we can override the /sbin/authd to\N/bin/sh. So once can restart the inetd
Dialogue: 0,0:33:31.81,0:33:41.36,Default,,0000,0000,0000,,process we can bind the shell to the port\Nauthd is using. Then we just find a way to
Dialogue: 0,0:33:41.36,0:33:48.51,Default,,0000,0000,0000,,restart the inetd process. We analyzed the\Nconfigure file of the sandbox again, and
Dialogue: 0,0:33:48.51,0:33:55.13,Default,,0000,0000,0000,,we found out the queue system call we can\Nuse in the VMX process. Then we just use
Dialogue: 0,0:33:55.13,0:34:03.52,Default,,0000,0000,0000,,the queue HUP to restart the inetd\Nprocess. Once the inetd process restarts,
Dialogue: 0,0:34:03.52,0:34:11.73,Default,,0000,0000,0000,,we can execute any commands by sending\Nthem to the port the authd is using. So
Dialogue: 0,0:34:11.73,0:34:23.89,Default,,0000,0000,0000,,that's the method we use to escape from\Nthe sandbox. And here's a demo.
Dialogue: 0,0:34:23.89,0:34:43.26,Default,,0000,0000,0000,,Oh, sorry.
Dialogue: 0,0:34:43.26,0:34:49.50,Default,,0000,0000,0000,,Oh, it seems not, I cannot play this\Nvideo, but it's OK. You can find it on
Dialogue: 0,0:34:49.50,0:34:58.53,Default,,0000,0000,0000,,YouTube and we created this demo after\Nthe GeekPwn 2018, we get a reverse shell
Dialogue: 0,0:34:58.53,0:35:10.73,Default,,0000,0000,0000,,after excuting the exploit in our guest\NOS. That's all. And if you want to get
Dialogue: 0,0:35:10.73,0:35:17.41,Default,,0000,0000,0000,,more details about our exploit chain,\Nplease check our paper here and that's
Dialogue: 0,0:35:17.41,0:35:19.08,Default,,0000,0000,0000,,all. Thanks.
Dialogue: 0,0:35:19.08,0:35:30.01,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:35:30.01,0:35:33.63,Default,,0000,0000,0000,,Herald: So I don't think I'm actually\Nworthy to share the stage with
Dialogue: 0,0:35:33.63,0:35:39.87,Default,,0000,0000,0000,,f1yyy, that was awesome. If you have\Nquestions, we have microphones, you need
Dialogue: 0,0:35:39.87,0:35:45.100,Default,,0000,0000,0000,,to come up to the microphone, line up\Nbehind them and we'll take your question.
Dialogue: 0,0:35:45.100,0:35:53.19,Default,,0000,0000,0000,,Meanwhile, does the signal angel have\Nanything? No questions yet. Do we not have
Dialogue: 0,0:35:53.19,0:35:57.71,Default,,0000,0000,0000,,questions from the audience? There is one.\NCan I have number six, please?
Dialogue: 0,0:35:57.71,0:36:04.28,Default,,0000,0000,0000,,Mic 6: Do you talk to VMWare for this\Nlittle hack?
Dialogue: 0,0:36:04.28,0:36:11.33,Default,,0000,0000,0000,,f1yyy: We have reported all these\Nvulnerabilities to VMWare after the
Dialogue: 0,0:36:11.33,0:36:18.63,Default,,0000,0000,0000,,GeekPwn 2018, and it has been one year\Nsince after they repair it.
Dialogue: 0,0:36:18.63,0:36:24.58,Default,,0000,0000,0000,,Mic 6: OK, Thanks.\NHerald: That's definitely a relief. Number
Dialogue: 0,0:36:24.58,0:36:28.64,Default,,0000,0000,0000,,one, please.\NMic 1: First of all, thanks for the great
Dialogue: 0,0:36:28.64,0:36:33.86,Default,,0000,0000,0000,,talk. I just want to know if there is any\Nmeaningful thing a system administrator
Dialogue: 0,0:36:33.86,0:36:41.75,Default,,0000,0000,0000,,can do to lock down the sandbox further so\Nthat we can have some preventative,
Dialogue: 0,0:36:41.75,0:36:48.33,Default,,0000,0000,0000,,basically tasks, for our ESXi setups. Or\Nif there is nothing we can do except
Dialogue: 0,0:36:48.33,0:36:55.16,Default,,0000,0000,0000,,patching, of course.\Nf1yyy: Could you repeat your question?
Dialogue: 0,0:36:55.16,0:37:01.98,Default,,0000,0000,0000,,It's so fast for me. Sorry about that.\NMic 1: Basically, is there anything you
Dialogue: 0,0:37:01.98,0:37:08.72,Default,,0000,0000,0000,,can do as an administrator to lock down\Nthe sandbox even more so that this is
Dialogue: 0,0:37:08.72,0:37:11.95,Default,,0000,0000,0000,,impossible or that it is harder than what\Nyou showed?
Dialogue: 0,0:37:11.95,0:37:19.13,Default,,0000,0000,0000,,f1yyy: OK. This is the first question.\NYour can set the sandbox down by executing
Dialogue: 0,0:37:19.13,0:37:30.15,Default,,0000,0000,0000,,a command on the ESXi shell. I didn't put\Nthe command here. I found the command to
Dialogue: 0,0:37:30.15,0:37:38.56,Default,,0000,0000,0000,,set the sandbox down. You can find it by\Nsearching the documents about the ESXi.
Dialogue: 0,0:37:38.56,0:37:48.86,Default,,0000,0000,0000,,Wait, wait, wait, wait. I found it, just\Nby myself by using the command offered on
Dialogue: 0,0:37:48.86,0:38:00.43,Default,,0000,0000,0000,,the ESXi shell. It's not documented by the\NVMWare. OK, I will share this command on
Dialogue: 0,0:38:00.43,0:38:05.88,Default,,0000,0000,0000,,my Twitter later. Sorry about that. I\Ndidn't put this command into my slides.
Dialogue: 0,0:38:05.88,0:38:09.96,Default,,0000,0000,0000,,Mic 1: But would this have prevented the\Nattack?
Dialogue: 0,0:38:09.96,0:38:16.77,Default,,0000,0000,0000,,f1yyy: Prevented it?\NHerald: By doing that change, by doing
Dialogue: 0,0:38:16.77,0:38:22.52,Default,,0000,0000,0000,,that command, would be possible to prevent\Nthe attack that you just showed?
Dialogue: 0,0:38:22.52,0:38:33.59,Default,,0000,0000,0000,,f1yyy: The sandbox is used to protect the\NVMX process. So if you update your ESXi, I
Dialogue: 0,0:38:33.59,0:38:40.67,Default,,0000,0000,0000,,think that it will be safe.\NHerald: Okay, great. We have a we have a
Dialogue: 0,0:38:40.67,0:38:44.71,Default,,0000,0000,0000,,question from the Internet.\NSignal Angel: Yes. Does this exploit also
Dialogue: 0,0:38:44.71,0:38:51.82,Default,,0000,0000,0000,,work on non-AMD VTx enabled VMs using binary\Ntranslation?
Dialogue: 0,0:38:51.82,0:38:57.61,Default,,0000,0000,0000,,Herald: Is it is it more universal than\Njust the AMD-VX?
Dialogue: 0,0:38:57.61,0:39:03.42,Default,,0000,0000,0000,,f1yyy: Yeah, can you repeat that again?\NI just hear the, okay.
Dialogue: 0,0:39:03.42,0:39:13.30,Default,,0000,0000,0000,,Signal Angel: Does it also work on non-AMD\NV or VTX-enabled VMs using binary
Dialogue: 0,0:39:13.30,0:39:19.98,Default,,0000,0000,0000,,translation?\Nf1yyyy: Yes, because all these
Dialogue: 0,0:39:19.98,0:39:26.53,Default,,0000,0000,0000,,vulnerabilities exist in the virtual\Nhardware. You will need to use virtual
Dialogue: 0,0:39:26.53,0:39:35.29,Default,,0000,0000,0000,,hardware in your virtual machine.\NHerald: So any further questions? I'm not
Dialogue: 0,0:39:35.29,0:39:40.44,Default,,0000,0000,0000,,seeing anybody on the microphones. Any\Nfurther questions from the internet?
Dialogue: 0,0:39:40.44,0:39:48.23,Default,,0000,0000,0000,,That's it then. Good. Please, everybody help \Nme in thanking f1yyyy for this fantastic talk.
Dialogue: 0,0:39:48.23,0:39:51.14,Default,,0000,0000,0000,,{\i1}applause{\i0}
Dialogue: 0,0:39:51.14,0:39:55.99,Default,,0000,0000,0000,,{\i1}36c3 postroll music{\i0}
Dialogue: 0,0:39:55.99,0:40:18.00,Default,,0000,0000,0000,,Subtitles created by c3subtitles.de\Nin the year 2020. Join, and help us!