Is that a penguin in my Windows? - Spencer McIntyre

our speaker today is Spencer McIntyre he works for secure state he's a vulnerability researcher and I will let him take it away from here all right thanks everyone can you all hear me in the back no you cannot how about now sup better ok Bob bad yeah I don't want listen to that all right so my name is Spencer McIntyre and we're going to talk about the window subsystem for linux all right so real quick here's the agenda of what we can go over and talk real briefly about Who I am but then when we go right over into the windows subsystem for linux overview so if you haven't been keeping up on it we're going to do

a real quick overview basically what Microsoft has said but then after that we're going to go over my wanting to take two approaches to this talk I want to talk about the real gritty details the technical details of how the sub system actually works what it is what it might mean if you're looking for bugs if you're a vulnerability researcher the kind of things do you be looking for on that on the flip side I kind of wanted to take a another sort of higher level approach and kind of apply these to what this might mean as your job for a penetration tester so just so I can kind of get a feel for the audience how many

of you here are actually in the business of penetration testing okay so a good number of you okay on anybody like bug hunting vulnerability researchers like real technical okay so yeah so there's a couple of you so hopefully there will be enough for anybody but you ever talk about the implementation details and how this might affect you and then in the second half we talked about what this actually means types of things you might want to look for things like that so that's going to be in those those attacker notes so real quick about me like she said I to McIntyre I work for secure say I've been there for a little bit over five years now I was on

penetration testing team I am now head of the research and development team so we do vulnerability research on primarily a lot of tool development as well I do a lot of Windows kernel stuff I like windows in Colonels so I I induce a lot of bsods there's a lot of that I'm an avid open source contributor I really believe in open source and one of the things I am most proud of is I'm actually one of the members of the metasploit came so really proud of that but I'm also a Python enthusiast and so that's enough about me alright so the overview of what is this windows subsystem for Linux or what we're going to be referring to as wsl so

the objective of this project of what Microsoft wanted to introduce was the ability to be able to run 64-bit elf executables that are built and intended for linux on Windows as a native solution this is not virtualization a lot of people might be getting this confused with virtualization and one of the key points about this is that there is no virtualization level in between what there is instead is there is actually a couple of drivers which can go over and some details that allow executables to be run on the native hardware of windows so because it's not virtualization and this is a key point these executables are going to be running at native speeds of about as

fast as you would expect them to run on a full-blown Linux system because you're not going through all those other all those other levels of the virtualization and that scheduler that ultimately gets down to the host there's none of that it's on the windows hardware so it's not sation it's a bit more akin to like a container type of a type of architecture so one of the big things is like all the Linux processes that are running in the wsl environment are referred to as pico processes which is kind of a newer term it's kind of a newer concept for windows but it's actually been around for a little bit I'm going to talk about pico

processes pretty extensively now the functionality that's actually leverage by windows is provided in two particular drivers there's the LX core driver which implements the functionality that you're actually using it implements the drive file system so the ability to read and write files as well as interact with the with the colonel and I do air quotes around that because there's not actually a kernel but it emulates the ability to get Colonel settings in some cases change those settings and things of that nature as well as others the LX SS now the LX SS driver is actually very very interesting sort of on this are protector of these two drivers is most of the functionalities actually providing the LX core driver the LX SS

driver is very very small it's about one-twentieth of the size of the LX core driver but it's actually the primary namespace and so it's going to be what is actually managing and sort of providing all this functionality to windows at a higher level but underneath it hood LX SS is utilizing LX core so this is diagram first and foremost I did not make this diagram this is the only sort of image I kind of stole from Microsoft but this is how all the processes are actually intercommunicating so when you're on your Windows system and you utilize bash dxd you're going to communicate with the LX this session manager and this can be over the comm communications that's then

in turn going to issue an IO CTL routine and that is going to call that LX sis driver those drivers that I'd refer to before which are then in turn going to initialize the subsystem and start to provide the functionality that you would expect now the subsystem is initialized exactly once per user so if you run open up cmd.exe and you run ash in two or three windows at the same time it's only going to initialize it for that first one and the remaining windows are all going to share what is going to be the kind of the pseudo Linux container so those are all going to be together so the first time that actually runs is

going to initialize all the information that's necessary it's going to start that init process and ultimately the native 64-bit bash elf executable is going to run this is going to allow you to run things like apt-get a Python said ah crap all your favorite of Linux command line utilities okay so implementation details like I mentioned the LX SS driver does not actually have a whole lot of functionality within it is a very small driver when the LX SS driver is actually loaded on its entry point simply calls the LX initialized routine that's provided by the LX core driver so we have this sort of laid out right here on moving down a sort of time

of how these drivers are actually loaded so the service as the system boots up it's going to load the LX SS driver is going to call an exported function within LX core and it's going to pass it its driver object now when LX courgettes that driver object it's actually going to initialize all the internal structures that Windows expects a normal driver to register so it's going to register all those functions in the major functions array the driver entry point how to unload the driver and all of those things those are actually all done in LX core but it's kind of sort of interesting about this is that LX core is registering all these under the name

of LX SS so the LX core driver when that one is actually initialized its driver entry point doesn't doesn't do anything at all there is no LX core driver from an object perspective in the Windows kernel because while it exists there and assist file and the PE executable is loaded there is no driver object as initialized specifically for it alright so pico processes what are these what are these tico processes so these pico processes are a lot different than the native windows processes that were used to using on a daily basis you know whenever you run like Internet Explorer kalkaji exe anything like that these are full-blown windows processes that are using the win32 like API and subsystem

and all of that pico processes are more similar to to hollow container it is a process level structure in in the colonel but as far as windows is concerned that's running but not a whole lot as well as those processes have a limited access to the outside environment outside of it which we're going to talk about a little bit in the attacker section so pico processes are not specific to the wsl system at all Pico processive actually they came out of Microsoft's drawbridge research and they've actually been around since Windows 8.1 and server 2012 that's when the function value was actually included inside of Windows now to my knowledge there's actually no other major uses of

Pico processes so while these have been actually around for quite a while the functionality all existed in Windows it hasn't been until recently that this functionality is actually exposed in a way that's actually usable from beyond sort of like a research computer science perspective but now it's actually usable by using the wsl system for for an end users they're going to leverage this pico process functionality um originally the pico processes were introduced by Microsoft as as a new form of sandboxing so these hollow processes don't actually contain the structures that a standard windows process has so when you run and start a new typical process on Windows you start calc idx a year notepad.exe or anything

like that you're going to get a copy of NT dll you're going to get a shared memory region up by the pointer of user32 in memory that facilitates reading objects out of memory and shared with the colonel and stare for performance reason so you don't have to switch the context all the time none of this actually exists in a pico process it is a hollow process structure and so the access that it has outside of that is very limited because it does not have any of these ap is one of the more one of the other changes that it has is it actually has a separate syscall interface so that when it makes a system

calling it transitions its context into the kernel it's not executing the same code that a standard windows assist call would utilize but the key point about about the pico processes is the windows kernel is still going to provide the functionality that's leveraged by threading as well as memory management some of the real basic low-level stuff is still going to be handled by the windows kernel all right so like I mentioned pico processes get a separate system called disp now this is very important because this is how those 64-bit linux binaries are going to expect to communicate with the underlying system the system call interface and the file system interfaces are kind of the two largest interfaces

that that the Linux binaries are going to expect to be present in order to be able to execute on a system thinking that they're actually on Linux so when the pico when the LX core driver is loaded and it initializes that L xs/s driver object it registers itself as a pico process provider and as part of this it is stating to the windows Colonel that pico processes that are associated with it have its own system call interface and that is how system calls that would normally expect to go through linux are actually being routed through the LX core driver which actually ultimately provides the functionality um so now this is very important so now all the system calls

are actually implemented in LX core excuse me I shouldn't say all of the system calls but all of the system calls that are implemented are implemented in LX core so one of the first things I wanted to actually look at when I started this research as I wanted to look at what system calls are actually implemented so now this is going to directly affect what binaries are going to be able to successfully run on linux versus which ones are not quite going to be supported yet so the wsl system reports that it is a linux kernel three point 4.0 so when i pull down the source code to that and i looked at all the

exported system calls and i compared those to those ones that are actually provided in the driver about 62 points six percent of system calls actually are implemented the remaining system calls are going to error out and binaries which leverage those system calls are going to they're not going to be able to run they're gonna have segmentation faults they're not going to be able to utilize the functionality that they would expect to be available some of the notable missing system calls are actually 32-bit equivalents now the standard ones that the Linux kernel provides that don't have the suffix of 32-bit are typically you designing a 16-bit structure so the 32-bit equivalent which are some of the newer

ones or some of the system calls that are missing in the wsl iron mint okay so when a 64-bit linux binary runs it's going to start to make a bunch of system calls there's going to be memory map regions it's going to need to open processes all these kinds of things and it's going to expect that the colonel that's running on in this case the windows kernel is going to be able to handle those so when a call is actually made it goes into the system called dispatcher that's provided by windows which notices that the process is the pico process and it's registered to the Alex poor driver so it ultimately gets routed to that

on from there the LX core driver is going to either on its going to modify the arguments and forward it to an equivalent windows system call if one is available such as NT create file NT all those all those system calls that Windows provides to be able to file operations memory management things like that those of course all exist so the LX core driver is going to modify the arguments so that they can be forwarded and provided and fulfilled by the windows kernel now in certain conditions the windows kernel does not actually have an equivalent system call and in those cases LX core is going to fulfill it itself so the point of this is that

it's either going to translate the system call or it's going to fulfill it itself for all those six to two point six percent that are actually implemented now when the calls are actually made because these are being made by Linux binaries these are not using the standard windows calling convention um it's both them through both of them utilize the are ax register to implement the pass in the system call number but all the parameters are different in windows vs linux so it's going to utilize this alternative calling convention and windows just simply forwards that on to the provider and the provider handles that itself so this might be a little bit difficult to see but this is actually a the call

stack for when a system call is made to and map so depending on if you are going to be bug hunting or if you're gonna be reverse engineering this bottom entry down here is going to be the initial the initial dispatcher when the in the context to switch over from user mode into kernel mode that's going to be the first one that gets it and it's going to realize that it's a pico process and it's going to dispatch it to the PSP co system processor dispatcher and then from there it goes into LX core which is this elack piece is called dispatch so it's going to pass it over to the Alex core driver to dispatch it however it

sees fit and then LX core ultimately maps it into an L XP underscore and map which is going to fulfill the M map system call so why this is useful is that if you're reverse engineer the implementation of a specific system khalix you want to look at it for vulnerabilities or anything along those lines it's very important to know where exactly you can set your break points so that you you can actually start to look so if you wanted to catch all system calls that are from kiko processes you can do that third one on that that middle one as well as if you only want to pico processes for LX core that's second from the top

ultimately if you just want to em map can do that that top once you can actually go in and register that something else to keep in mind is that if you actually did want to look at em map there are a ton of em map calls it's going to be very difficult because every process is constantly like allocating memory if you just do like dot slash and one basically any binary you can get hammered with all these calls so in order to filter them you need to remember that this is going to use the calling convention that is utilized by Linux and not by windows so it's going to use that are dirs i calling

convention that's actually also specified by the system ba bi alright so next up is the file system so this is the other major way in which linux communicates whereas on Windows almost everything is represented as an object you have objects processors excuse me processes objects for threads objects for drivers everything is an object on linux linux does things a bit differently and a lot of interactions are actually done through the file system on windows if you want to get information about a process you open a handle to the process object then you can use the win32 api to query information change information things like that on linux linux actually exposes this information through a special file system and then you can

read the files on that system video to process out on the information so it's exposed actually through the file system but there are actually two major file systems that are provided by Linux so there's the the voi FS which is the virtual file system so now this is going to have the Linux root directory this is going to have et Cie lib VAR opt all those directories that typical files exist in one of the important things to note about this file system as opposed to the other is that it is not accessible through windows one of the interesting implications of this is that if you were to store a malicious file that would typically trigger like an anti-virus

exception on this file system you could store without worrying about it getting picked off because it is not actually accessible through the windows environment there are no api is currently documented and exposed by microsoft for reading this file system yes the other one is the dr f essence oh the other way yes using the dr FS you can access all the file systems on the windows root drive barring barring permissions which are going to talk about so his question was what about what about the other way so the other file system is the drive FS which allows access to all of the windows drives so when you are in your bash see if you want to access a file in your see users

Spencer desktop directory you can do that and windows kindly mounts the c drive under / MNT /c so all of your drives are going to mountain there underseat on and then you can access all of those files on and there's there's some nuances that we're going to talk about so this is the major file systems for reading and writing your standard typical files now the other file systems are actually implemented for proc and cysts which allow a basic communication with with the colonel that's what they're used on a full native colonel implementation you can read out information about the the networking configuration you can read out processes you can get Colonel options at runtime things like that these are very these

are implemented in very limited fashion on the wsl so you don't have access to nearly even close to all of all of that that you would expect to have on a normal Linux system um specifically one of the things I wanted to call out is the proc net is not implemented enough for ifconfig to be able to run at this time on it's something I should have mentioned at the beginning of my talk is that the wsl is actually in the windows tech insider program so you have to opt into it to be able to get this functionality it is publicly available but you have to register you provide your email address you don't have to pay anything and then

it takes a long time to download it took me probably about like six hours like download all the updates i'm running in a vm but it takes a long time to download it so they are still updating it so i would be willing to bet a large amount of money that it is going that Microsoft is going to continue to implement the missing sis costs that 62.6 percent number is going to hopefully go up as well as some of the the basic file system controls like the proc Nets probably one of the ones that's gonna be a high priority for them to implement because right now it's breaking ifconfig you cannot list interfaces on your system you can still

utilize socket you can bind you can connect things like that all work we've try to run ifconfig you're going to have bad time alright so drive FS specific notes so this is very interesting this is the file system that allows the wsl environment to be able to access all the files under under the windows environment um so when a process is created when one of these pico processes is created it's always going to have the permissions of the windows process that created it so if i run bash it's always going to run as me Spencer even when I elevator ooh when I do like pseudo die or something like that it's still going to run as me which is something I

haven't actually read anything about Microsoft addressing specifically and this is kind of going to be a common motif throughout the rest of my presentation is that route really doesn't mean anything um so when your route and you create a file in the drive FS it's going to have all the all the file permission it's going to have 777 and you're not gonna be able to change those you're not going to change the user and if you try to write a file with like 600 permissions because you don't want your user to be able to read it you're doing that as root all the user has to do is exit out a bash and they can go over and from their windows user

they can access that file and they have they have full permissions to it in addition if they drop out of root permissions because you actually can't change the 777 you can still access the file so it's kind of interesting is that within the drive FS the the permissions aren't are not honored the way you would expect them to be all right so here's kind of a kind of an example of this so I understand this is a little bit hard to read but up here I'm in the mntc directory um so I'm in my windows users home directory and I just echo out super secret into a file and below that we can tell that the the permissions are

777 and the file is owned by root what I think is kind of problematic and one of the things that I am predicting is going to be a problem in the future is this next command where we do cho mod 600 on that file and we actually check the the exit code of cho mod and it comes back an exit of zero so cho mod says like hey there was no problem we would expect that the permissions on that file would have been updated accordingly and that file would now be protecting you know it's owned by root nobody else you'd be able to read it but right after that we're able to see that it is still 777

and we exit out the my user not root can still access that file with those permissions so in my opinion this is kind of problematic because users that are used to running in a Linux environment they're going to expect that things would work in the way that they would intend now this is only the case on the drive file system on the virtual file system and those Linux files if you go into like et Cie they the permissions do work the way you would expect them to work so if your route and you go into ET c and you know hopefully your shadow file permissions are six hundred and somebody compromises your root user they're not going to be able to get your

shadow file they're not gonna be able to read that which when you start up w SL for the first time it prompts you to make a password so it's not even associated with your windows password anyways also kind of interesting okay so those are all the the actual the technical details of how it's implemented so we're going talk about what are the implications of this for an attacker hopefully you're kind of already starting to see this with the problems of how root permissions are being handled so one of the first things I wanted this section to be you know if you were a pen tester and you compromised a system that was wsl where some of the basic things you would need

so that way we can sort of answer answer these questions of the low-hanging fruit so identifying wsl so on the first things you want to if your honor system you suspect that it's windows on Linux how would you identify this this is actually ridiculously easy there are quite a few different ways so I have them and one of the obvious ways is that Microsoft the actual word microsoft is in a couple of locations in relation to the colonel despite the colonel being from canonical and being from ubuntu it does say Microsoft in them so you can you can search from Microsoft in those in those titles you can also look at the MNT directory you can look to see what

exactly is mounted you should see the the drives being mounted in there so these are things that may in the future be changeable so Microsoft might update you know drop the Microsoft string or whatever if it starts to get abused by attackers so there's a couple of behavioral clues that I want to point out because these ones are probably less likely to be changed because it's not going to be as easy as just dropping the word microsoft out of the titles so there's exactly one module in the cysts modules interface I find this very unlikely on a standard Linux system because you're going to have drivers that are going to be loaded it's not a

sure thing but chances are pretty good you're going to have a couple of drivers loaded on your on your linux system proc is missing modules module entries because there's not a whole lot of files that are excuse me processes that are running additionally there is no there is no init system there is no upstart system d or anything like that is very bare-bones so there's no uh as of this time there is no ability to be able to like register a service in the wsl environment and probably my favorite which is actually very interesting is um the strictness of how the flags are passed into the M map system call on this one I find very interesting because

this is definitely a good behavioral clue and now the standard the standard Linux systems are less restrictive and don't check the for the adherence of the flags to the standards quite as much so what we can actually see right here is in my example call and I left off the back so that you could have a font that was big enough to read it but this third parameter right over there where the permissions for the region of memory that you're trying to map are specified um if you specify a one thing in hex which is not a standard flag Linux will will ignore it just won't change anything the the region of memory will be mapped and you can go along your

way however in Windows if you specify a flag that's not defined it's going to throw an error code so if you try to run the same exact function on linux versus on w SL w SL will cause it to fail whereas linux will have it run successfully and this is that that i was mentioning a three point four point oh dash microsoft very very subtle but pretty pretty easy way to be able to identify that that this is probably not the linux system that you're looking for so one of the other things like i said i once hit on what what penetration testers would really want to know when working in this environment so the

metasploit framework what payloads are going to actually work in this environment so i went through the list and i tested these now each one of these i tested as a 64-bit on elf executables using MSF venom to put the shell code into the your standard elf file and random from there something interesting is the wsl system strictly supports 64 bit binaries whereas on i'm using fedora i don't know if anybody noticed the i run linux on my hardware i can run a 32 bit binary 32-bit l file on my fedora host and and it works just fine on wsl though it only supports 64 bit off executables so that's why these ones going down so the metal of payloads like

brand-new it came out i think was like three or four weeks ago once one of the great works by brent cook and there's like I'm noticeably log about it that one will not work the reason why that will not work was actually that exact M map call that i had just pointed out and that's what we noticed as we are doing the testing of this is that because the metal stager needs to be very small it's a standard exploit stage or size is very key on it leveraged that nuance in the linux system that wasn't as strict about checking those flags in order to work but windows is being much more strict about those flags and so in this

particular case than metal payload was failing with our verse TCP stager and was not actually running because of that next up the unstaged 64-bit shell worked just fine on the so it was a typical reverse shell you can use it not meterpreter so not quite as good as you would hope on the 32-bit version of Linux there isn't a 64-bit version of Linux meterpreter and like I said when the wsl system only supports 64 bit elf executables so the 32-bit one is of course not going to work and then last but not least and not just because I helped out with it was the Python interpreter on this one was the only working meterpreter instance that worked

on wsl now I say that it worked but on there were still some problems in the functionality that it was expecting to leverage and one of those things was like the ifconfig so right here we can actually see the output of what I was able to get from the Python interpreter running on this the only mature / to that ran on it and so we can see the Linux three point four point oh now this information does not include Microsoft's because the kernel version is actually stored in multiple locations the particular location where sis info actually pulls it from doesn't say Microsoft so it might not be as as obvious but down here ifconfig failing

this is because even the native ifconfig object on on Linux doesn't work the actual native binary does not function so meterpreter is not be able to work it out either alright so the Linux kernel protection so because the Linux kernel doesn't actually exist in this environment it's not there microsoft claims to have done a clean room implementation of all the system calls and all the functionality that's provided there is no linux kernel so what I want to do is I want to look at some of the protections that a binary that's running on the Linux environment would expect to be provided by the kernel and unfortunately all the basic ones that I checked for are all actually

provided now the reason why all of these are provided on between user mode aslr depth and no page prevention is all of these are our memory protections and those memory AP is our is going to be very common and when a map call is actually made it is fulfilled by the windows kernel it's not actually implement implemented by LX core so in being fulfilled by windows you get all of those protections that windows already offers so data execution prevention ASLR no page mapping all those things work as would be expected something I did notice however I mean that I did want to point out is that the randomized VA space that option that allows you to modify how aslr it's

implemented on a Linux system at runtime you actually can control that so if you echo out 0 and wsl into that control file you can disable a SLR yes SOR for your session on the flip side the null page mapping that's typically controlled through the em Mad Men address that is not available and that's one of those control files that you can't read that you can't modify or anything like that it's just not implemented ok so cross process access so let's say we're going to go over the scenarios of if you're if you have a compromised system in a wsl process what type of access can you get out into windows and vice versa ok so

this would be a desirable of course if you're if you're on a pen test if you compromise you know an ssh server which doesn't work yet tomcat or if you if you compromise the windows host via some sort of like a SMB vulnerability things like that so the bottom line is linux can't really list windows processes and that's because like i said windows processes are stored as objects in the kernel and their accessed by AP eyes which are windows system calls which aren't available because none of that is exposed to the Linux processes windows however can enumerate out Linux can tell that it exists and it can tell that the processes are there but the pits don't

match so Linux into windows access there's not really any functionality for that reason that I'd mentioned is that you can't actually call the necessary api's to get the information out of it I'm you can access other Linux processes through the proc interface that functionality is available which is important to know if you need to debug a Linux process using like gdb or something like that it will work correctly because you don't have access to the win32 native system calls in the API you can't get into into Windows processes if you wanted to infect the Windows host what I would recommend doing is going up through the file system and trying to infect some kind of a file from that

perspective unfortunately like I mentioned even if you elevate to root your still effectively running as your Windows user you certainly cannot just go into the C Drive and start overriding dll's or use like the mof method by writing a file into the wbem directory you can't do that because from windows perspective even though your route it doesn't care you're still actually running as that user and all those those file AP eyes are all still checking the windows permissions which are which are going to be as the user that you start at bash as windows access into linux though is a little bit different so while you can't access the root filesystem you can get a little bit of

information available from from the processes you cannot debug any of the Linux processes open process fails and that's because a lot of debuggers all need to be able to have extensive access to the processing to be able to open it with like process with all the permissions to be able to read virtual memory right virtual memory create beds they need to be able to do all of that if you're familiar with the open process API all the permissions are broken out and I checked every single one of them and the only two that you're able to open a Pico process with is the query limited information and the synchronized function and so another thing to point

is like you you're not going to migrate into these processes from from interpreter meterpreter need to be able to leverage these api calls in order to be able to inject itself over it into it on with the query limited information and synchronize permissions though you can do a little bit of work you can check to see that of course the process is running probably the most useful thing that you can do however is you can wait for the process to exit and you can immediately get the status code out of the process now in Linux when a process exits the status code is is significant zero is success and there's a few other a bunch of other status codes that mean

different things from resources not available permission denied user configuration error things like that you can actually get this exit code out of the Linux process from the windows host by waiting for the process to exit and then querying it with that process query limited information you can actually get the low 8 bits and get the status that that that process had exited out with and so because once again the root process is still running as the same windows user you can still do the same exact stuff for a process that is running in the context of Rousseau if I'm on bash and i start a new instance of bash as root if my if my account has

been compromised somebody can with my permissions check and wait for that root process to exit and get the status codes they can tell if it had a segmentation fault if it wasn't run correctly and there's a configuration problem anything along those lines that information is still exposed to the other windows processes okay so on the cross user access environments of wsl so we're talking across windows user access so in the case of like server 2012 when multiple users we login and things along those lines if you install wsl as one user and login as another the environment is not there it doesn't exist you have to install it again so it's going to download all those files

and it's going to start it up so because of that you can't if both users are running bash at the same time they cannot communicate to each other the file systems are isolated it's effectively a separate user process on for all intents and purposes there isn't really cross contamination there now in theory if you were to elevate yourself up into into system or something like that you could of course migrated over to that other user and you'd be able to do it from there but from two separate user levels on the wsl environment is not is not shared ok I'm so closing thoughts when the last things root really doesn't mean anything and I'm definitely guessing that that's going to

cause problems by users that are expecting to be able to leverage the permissions and the security that you know sending a file to use the ER as owner as rude or anything like that is expected to provide and I'm going to be guessing that that's going to be causing a problem one of the things that I forgot to mention I don't have a slide on is actually in that i found interesting was that the repositories that are set up so when you run like apt kid there is no evidence that Microsoft has either a certificate installed in there and there are no microsoft apt repositories in there so when you run apt-get update or you're trying to

install anything none of that is actually coming from Microsoft all of that is still coming from canonical like you would expect from a typical ubuntu installation one of the last thing so I was doing all this I was looking through all of the the windows internals I was trying to find vulnerabilities in the wsl and Microsoft was enough to send me this desktop for being in the insider program it has this like sweet ninja cat on it so that's pretty cool all of these references right here I started this a couple of months ago and I spent a lot of time looking into specifically like the system called dispatching functionality only for like three weeks

ago for Microsoft to implement an entire blog that laid it all out and was basically actually like telling me so that was kind of interesting but at least I was I'd already figured all that out and there was no way to really know that they would cover all of that those are all my references just about all of them are are actually from the Microsoft blog series that they had been been doing on this so with that thank you very much for your time I'm this topic I was really excited to present on and thank

we have plenty of time if anybody has any questions anybody nope okay thank you everybody