Transcription
I decided to make an AI zeroday pipeline. A bot that you feed code into at one end and it spits out zero days at the other. Simple. Except like nothing about that was simple.
About a month ago, I received an email from Anthropic that told me I'd been accepted into their CVP program, their cyber verification program. And what this is is a program that allows verified security practitioners access to the current uh generation models but without certain guard rails. So in my case, my version has no guardrail against writing malware and no guardrail against finding vulnerabilities or writing exploits for them. So of course my first thought was, well, I'm going to try and build a machine to find zero days. So I'm basically going to test Claude Opus' ability to find and exploit zero days in software entirely autonomously.
But I basically saw people freaking out about Claude Mythos. And I wanted to learn more about the risks. I felt like a lot of the theories were overblown. the arguments that this is going to give script kitties the ability to just churn out zero days like there's no tomorrow. The sky is falling. Cyber security is over. And I felt like a lot of that was missing the nuance. And I thought, well, what better way to illustrate my points than to actually make my own version.
Now, obviously, I don't have the resources to build a machine that can just exploit any vulnerability in any software. So I decided to pick a specific class of vulnerability in a specific software and just go from there. Now I was very deliberate in what class I wanted to pick and it had two main reasons. So the class that I picked was privilege escalation and the operating system that I picked was Windows 11. So I specifically wanted to get privilege escalation to kernel mode via third-party vendor drivers.
Now this is a technique known as BYOVD. Basically on Windows you have your standard uh privilege levels, you have standard user administrator, but above that you have kernel access. Now it used to be that you could just load drivers into the kernel and do whatever you want. Uh but Microsoft realized that that was a problem because the EDR and all the security products, they live in the kernel. So if I can get into the kernel, I can simply just disable your organization's multi-million dollar security product, which is not very great.
So then in Windows 10, Microsoft came out with a new feature which is that you have to have your driver signed by Microsoft. So you sign the driver, you then have to submit it to Microsoft and they will audit it and decide whether it actually gets approved for use or not. which makes things a little bit harder for criminals because if I say go and steal some company's uh digital signature and I sign a malicious driver, I still have to submit it to Microsoft and at least in theory they should see that my driver is malicious and just deny it.
Which has been a massive problem for thread actors because EDR ransomware detection has gotten so good that in a lot of cases if you run ransomware on an endpoint it'll just stop it because having to open and close millions of files and encrypt them is very very noisy and it's very easy to detect. So ransomware actors have been struggling against EDR ransomware protection for quite a while. So then the easiest thing to do is if you can get into the kernel you can just disable the EDR. you don't have to worry about the ransomware protection.
And this is actually what had started happening. Essentially, what thread actor has found is you don't need to sign your own malicious driver. You don't need to steal a digital signature or get your own through a front company with administrative privileges on a Windows system. You can load drivers, but they still have to be validly signed by Microsoft. You can take someone's legitimate signed driver, look for a vulnerability in it, and then exploit that vulnerability to get kernel access. And that's where the name bring your own vulnerable driver comes from. And this is an attack that's been going on for a while, and you see it a lot with ransomware actors. And I would argue it is probably the most common zeroday exploit that you see cyber criminals using. So that's why I felt like this research was relevant.
Now, exploiting kernel drivers is not easy. it is binary exploitation which is widely considered to be one of the most difficult classes of software exploitation. So I don't want to make things too easy for the LLM. Like if I hand it uh some cross-sight scripting challenges or some SQL injections, it's going to breeze through those easily. I need something that it's actually going to struggle with. So I picked binary exploitation. But the problem is if I'm looking for like remote code executions in like the most hardened OSS on the planet, that's going to cost a lot of AI tokens and a lot of my time and this research is probably going to take years.
So I picked what I call the bottom of the top, the easiest of the most difficult class of software vulnerabilities to exploit. Vulnerable vendor kernel drivers. It's still binary exploitation. It's still uh relatively difficult, but these third party vendor drivers are terrible. The code is awful. It's full of security holes. They do stuff that should just not be allowed in any driver ever. And it makes them fairly easy to exploit. So, it sort of sits in that balance where it's still difficult enough where the LLM is going to struggle a bit, but it's easy enough that I'm not going to have to spend like hours and hours of time and millions of dollars in AI tokens and building out this infrastructure.
So, my goal was to basically build a pipeline where I feed the kernel drivers in at one end and then I get zeroday privilege escalation exploits out at the other. So, I decided to follow Anthropic's lead with coming up with Greek names. Um, so I decided to name my bot Althios, which is Greek for complete [ __ ] idiot.
Now, when it comes to working with large language models, I follow a variant of Murphy's law, which I made up myself. Murphy's law basically states anything that can go wrong will go wrong. Now, my law basically states that anything an LLM can mess up, it will mess up. So, if a task does not need to be done by an LLM, it shouldn't be. So the goal was to make as much of the pipeline that didn't need to use LLMs just use Python scripts.
To start out it was pretty easy. We need to find drivers. So I built a script that scrapes the internet for drivers. Now we need to make sure they are validly signed and will run on Windows 11. So the script then runs them through a process that first uh checks if it has a valid signature. It then checks if that signature uh belongs to the Microsoft WHQL program which is the program that decides whether this is allowed to run on newer systems or not. And then we check it against the vulnerable driver block list cuz we don't want to be finding uh vulnerabilities in already known vulnerable drivers. So the first stage of the script just sort of weeds out anything that's not going to be useful to us.
And then the final stage of driver selection is I have a VM which the uh AI agent logs into and will load the driver on and make sure that it actually loads because there are uh other systems that it can fail. Um it might just crash the system. Um but also uh Windows Defender application control works a bit like an antivirus. So it might block certain drivers based on criteria we just don't know. like they have some machine learning model on the back end that decides is this driver good or bad and we don't necessarily know what that is. So the only way to check is to just load the driver and see if it loads successfully.
So once we've done that we get a much smaller list of drivers. I started with something like 100 drivers and then once we'd run through all of those different processes we were down to about 84.
Now the next process is reverse engineering. Um, when it comes to LLMs, they don't do a very good job of reverse engineering. They are much better at finding vulnerabilities in source code, except I don't have the source code for any of these drivers, and I'm not going to be able to get it. So, the goal was to basically reverse engineer the drivers back into source code so that I could feed the source code into the LLM. This was great because I happen to know a professional reverse engineer. Um, except I would be cheating if I reverse engineered the drivers myself because the whole point is making an automated pipeline. So I basically tried to put as much of my skill and knowledge into a simple script as I could and then basically built an IDA pro script to sort of automatically do some reverse engineering. It would do things like give types descriptive names, uh, name functions based on any obviously detectable behavior.
One of the sort of big issues I started running into with the LLMs is a lot of drivers use something known as KMDF or kernel mode driver framework. And this sort of uh operates through a bunch of pointers. Like rather than calling functions directly, it'll call through a vtable and then the the vtable will direct the call somewhere else. Now the LLM was really really struggling to figure out like what are any of these calls doing? Like where are they going? there just it just sees like a call going to an address and then the address points somewhere but we don't know until load time where that address actually points. So I built a simple script that actually pauses the uh KMDFV table and notates all of those functions so that the LLM can know where the calls are going.
So I build this script that the driver gets open in IDA automatically. The script applies all of these descriptive names and types and it notates the KMDFV table and then it goes on to the next stage which is using the IDA decompiler which basically allows us to decompile the uh assembly code to not technically C but something that looks like C. It's called IDEO code but it is close enough to C that I then just built a simple script to turn it into C. Now it's not going to compile. It's nowhere near valid, but it's descriptive enough and clean enough that the LLM is going to be able to work with it. So, all of the drivers go through this process. It's entirely automated. It runs either in headless mode, uh, disassembles, notates, decompiles, and then it spits out a C file. So, my 84 uh driver.cis files become 84 C files, and now they're ready to go into the large language model. And we've avoided using LLMs up until this point because there's so much that they can mess up. As I mentioned a minute ago, they do really seem to struggle with reversing the kernel mode driver framework. Um, which is really easy to do statically. Like it's a very simple Python script. So I did that for them.
Now the next step was to build a prompt to sort of find the vulnerabilities. So, my prompt basically explained what a BYOVD attack is, what kind of vulnerabilities tend to be used in BYOVD attacks, uh, certain drivers that wouldn't be useful, certain drivers that would be useful, and then I told it to give every single driver a score. And the prompt does a lot of housekeeping cuz when I would run it, the LLMs would run into certain failure cases. So then I'd put that failure case into the prompt and explain uh like do do it this way or avoid this or make sure to check this. Um, so I just sort of iterated and I kept building this prompt up to get better and better and better until I had something that I was pretty happy with.
Now interestingly my first version of the prompt which was a test prompt that literally just said find vulnerabilities in this driver was actually successful in finding valid vulnerabilities. it just had like a very high false positive rate. So I spent a bit of time iterating and then when I finally was happy with my prompt, I added a bit on the end that basically just says generate two scores. An exploitability score on a scale of 0 to 100 on how exploitable or how vulnerable you think this driver is and then a BYOVD usability score, which is how usable you think this driver is for a BYOVD attack. And then it just sort of spits out all the reports into a directory and then it creates a JSON file scoring each driver on a scale of 0 to 100 which means I can then go and I can look and I can pick like what are the highest scoring drivers.
Now this is the part that actually surprised me. The LLM was finding valid vulnerabilities that I myself confirmed by hand. And the reason why this surprised me is simply I just have a very low opinion of LLMs. Like for me, the bar is in the floor. Um, but it also didn't surprise me in that I realized that LLMs are essentially glorified pattern matching machines and all vulnerability research really is is pattern matching. Whenever I go and look for vulnerabilities manually, whenever I'm like looking for zeroday exploits, I would go and I would reverse like existing patches like patches for known vulnerabilities. I would look at what sort of situation led to that vulnerability arising. To give a very very simple example, think about how a stack overflow works. A stack overflow occurs when too much memory is uh copied to a finite sized buffer like a finite sized region of memory. So you simply just need to look for the pattern of we have a finite region of memory and a function that copies a non-finite amount of data to that region of memory. Now stack overflows aren't something you find a lot in modern software. They're super rare and even when you do find them, all of the mitigations that have been built against them usually make them non-exloitable. But this is just kind of an example like once you have that pattern of fixed-sized memory, non-fixedized copy operation, we can then go and look for that in any code. So my personal favorite was integer overflows. So I basically made up this mental pattern of like what does a standard integer overflow look like? And then every codebase I'd look at, I would look for that specific pattern. So, it's not really a surprise that LLMs are very good at this because it is really just pattern matching. Most of the work was actually refining the prompt to reduce false positives, not increasing the true positive rate because it was already doing a pretty good job at finding uh the stuff that I would want to find.
So, I run my script that feeds the C file in along with the prompt into the uh API and then it gets back the response and saves it to a text file. So, we get 84 vulnerability reports for 84 different drivers.
Now, this was notably expensive. I ran the bot and I just noticed my balance just dropping and dropping and dropping. Like, every time I refreshed the page, it was going down by $5. Now, I knew not to put too much money into my account because I had foreseen the chance that it's going to just go wild and it's going to drain my entire bank balance and I don't want a 30k AI bill. So, I think I ended up putting about $200 into my account. And then every time that would drop below, say $50, I'd put in another $100. And as the AI was sort of like failing and succeeding and failing and succeeding, I honestly felt like I was using a slot machine. I was putting $100 into the slot machine and praying that this time I get a usable zeroday vulnerability.
Now this is the part where math can be used like really disingenuously to instill fear or I can just be honest with you. Now, the disingenuous framing is that it only cost about a dollar to $2 to find vulnerabilities per driver. My first production prompt cost about a dollar per driver. And then as I sort of iterated to get the best possible prompt I could, that cost about $2 per driver. So, I scanned about 400 drivers and I found one which was the perfect candidate for a privilege escalation uh to kernel zeroday attack. Now, because it cost me $2 per driver, I could tell you I just found a kernel privilege escalation zero day for $2. Except I didn't because I had to go through those 400 other drivers in order to find this one sort of diamond in the rough. So, what it actually cost me is $800 just to find this one driver. And we are not at exploit yet. We are not at the exploit stage. This is just to generate vulnerability reports. We still need to triage these and then pick which uh driver we want to exploit and then exploit that driver.
So the driver that I picked is commonly referred to as a god mode driver. It basically exposes an IOCTO interface, an IO control interface which allows a user mode process to talk to the driver to pass data to it or receive data from it. Now what kind of process can actually talk to the driver is uh 100% up to the driver. It has to set certain security controls and certain uh privilege checks, but the driver that I found doesn't set any at all. Which means that not only do we not need to be a system process, we don't even need to be admin. Theoretically, any privilege level process that can actually open a handle to the driver will be able to exploit it. So, this might actually work uh from a guest account or even from within a sandbox.
Now in terms of what the driver actually does, it has a couple of different IO control codes. One allows us to read memory and the other allows us to write memory. Now the way that it does this is via a function known as mm map IO space which basically maps a physical address. So the system's actual underlying RAM. So where does that address come from? Well, the user mode process just passes it in. There's no sanity checks on it whatsoever. So essentially what this means is the user mode process can pass any address in the systems RAM and this driver will map it into memory and then allow us to read to it or write from it. And because we're not dealing with virtual addressing, we don't need to worry is this address mapped, is it readable? We can just scan through the entire RAM until we find whatever we need. So that completely breaks ASLR. And then we can do the same with writing. We can write to any address we want. So once we find something that we want to write to, say an area of executable memory, we can just write shell code straight into that address. So we don't need an execute primitive at all because the write is the execute primitive. We can just write some shell code into any executable region of memory and then override a pointer that we know gets called. The kernel is calling all kinds of addresses all the time and all we need to do is overwrite one with the address of our shell code.
So, this is one of the most powerful exploits that you can get when it comes to kernel drivers because it essentially allows us to read and write the entire systems RAM. And because the RAM isn't just for system memory, it's also for talking to hardware devices. We can do a lot more than just mess with the operating system. We could theoretically overwrite firmware in things like the hard disk, the graphics card, and even the systems uh BIOS or UEFI. So, this is an extremely powerful vulnerability, and it's actually kind of surprising that Microsoft still even allows these to be signed.
Now, this is the part of the video where I admit I actually skipped a step. I was so excited to see that one perfectly vulnerable driver that I ran with it and then I started building the uh the exploit part of the process, the uh the LLM prompt to turn this vulnerability report into an exploit. Now, I actually ran into a really big problem here, which is I couldn't get it to exploit the driver, and it was costing so many tokens for each attempt that I was down like $200 with nothing to show. So, I ended up moving to the UI. And on the UI, you just pay like a flat fee of $20 a month and you get like essentially infinite tokens. It's not infinite, but it's close enough. So, I moved to the UI where I wouldn't have to pay per token. And it took about four hours of back and forth until I could figure out everything that Claude was doing wrong, like every step of the way where it was going wrong. And then I built that into my prompt. And I kept like iterating on the prompt, saying you've got to take this into account and you've got to take that into account and so on. Um, but I skipped an entire step there, which is this is an autonomous pipeline that takes in code and spits out zeroday vulnerabilities. But I picked the vulnerability. I went through the reports and I picked the best uh vulnerabilities to use. And this is where I think actually a lot of skilled vibe coders go wrong. They end up attributing a lot of what they're doing to the capabilities of the LM model. So essentially I just went and I used my like decades of vulnerability research knowledge to pick out the perfect exploit candidate. Um, and I was like, "Wow, I got an exploit." But then when I went back while doing this video, I was like, "Hang on, I did that." Like the LLM didn't do that. So, I need to go back and I need to get the LLM to select the vulnerability.
Uh the LLM only allows me to upload 20 files per request. And uh we have 400 drivers, so I can only upload 20 of them at a time. So, I was like, "Okay, that's easy. We just do like semi-finals and finals. We uh take a batch of 20 drivers, another batch of 20, another batch of 20, and then we tell the LLM, pick the best of these 20, and then we take the best of each batch, and then we put them into the final, and then we say, pick the best of this 20, and then we finally get out our exploit. Now, my driver didn't even win its heat. Like, it was it didn't even go through to the next round. And I was like, >> huh? So I started trying to like figure out the LLM's logic like where it was going wrong. So I looked at what drivers it did pick and it was quite clear what it was doing wrong. Essentially you have like three different classes of exploit primitives. You have read, write, and execute. Now execute seems like that might be the better of them because that allows you to execute code. But let's think of the simplest version of each of these primitives. I can put in an address and the kernel will read that address for me. That's the most basic uh read primitive. The same for write. I put an address and the kernel will write that address for me. The most basic execute primitive is I put in an address and the kernel calls that address. But how does the code we want to get execute get into the kernel? Like just calling stuff doesn't give us code execution. We need to get our shell code into the kernel. So without a write primitive, an exploit primitive is useless. So essentially what the LLM had inferred is we want code execution, right? So the execute primitive is going to be the most valuable which does intuitively make sense if you don't have vulnerability research experience. The way in which the kernel works is it's executing all kinds of code all the time. It's calling function pointers. It's running driver code. If we overwrite some code with our own that's going to get executed. So a write primitive will allow us to execute code. We don't need an execute primitive. Whereas an execute primitive on its own doesn't allow us to do anything because we have to still somehow get our code into the kernel. But then with our write primitive, we can write our code into the kernel and have it executed.
Except most modern systems have something known as ASLR, address space layout randomization. Basically, every time you start your operating system up, the system just reorders everything in memory. Like it just puts everything at random addresses. So if we wanted to say overwrite a driver or overwrite a pointer that would be great and all except we have no idea where in memory what we want to overwrite is located because of the address space randomization. So that's where a read primitive comes in. We need some way to leak uh addresses from the kernel so that we can figure out the memory layout so that we can figure out where we need to write our uh shell code or write our like whatever exploit primitive we're using. Execute primitives are pretty much irrelevant. Sometimes they can be helpful but a good read and write is way more powerful than any execute primitive.
But the AI doesn't know this, right? And this is what I think people mean when they say in order to have AGI these u machines need to have a world model because it doesn't know uh like any of this stuff. It's just sort of regurgitating text from its training data. So unless I prompt it and say look we want read and write primitives not execute primitives. It's just going to naturally infer oh executing code execute primitive. And it doesn't have a world model. It doesn't know how a system works. It can explain ASLR. If we ask it what is ASLR, it will perfectly explain it because it has that data in its training set. If we ask it what is a read primitive, what is a right primitive, it can perfectly explain that. But because it doesn't have a world model and it can't sort of put all these pieces together and understand how it's interacting with the system, it can't come to the conclusion we don't actually want an execute primitive at all. We want a good read and write.
So I basically had to explain what I've just explained to you to the large language model. I had to build into my prompt um a big framework that basically said look uh kernel address base layout randomization does this. This mitigation does this that mitigation does that. You're looking to do this. Here's why execute primitives aren't useful. Uh here's what kind of read and write primitives are. And I was eventually able to get the LLM to do the same thing I did and pick the correct most vulnerable driver uh as the exploit candidate. But this was a lot of my own work. This wasn't the LLM doing it. It was me sort of like taking my thought process and putting it into text for the LLM.
And this is sort of where I push back on this idea that LLMs are just going to keep getting better and better and at some point script kitties will just be able to type in hack windows and it gives them a zero day. Because what actually made the difference here was not the large language model. While I was using Opus 4.6, notice I didn't say 4.7 which is out at the time of making this video. It just feels like they completely labboized it somehow. So I'm using Opus 4.6 which is like a frontier model. I honestly think I could have done this with a pretty mediocre LLM because what's making the difference isn't the LLM, it's the framework that I'm building around it, the instructions that I'm giving it. I'm essentially taking my like decades of vulnerability research and reverse engineering knowledge and I'm sort of like distilling it into an LLM prompt. And that's the part that your average script kitty or your average nonvulnerability researcher doesn't have.
I think what a lot of people are thinking is that Claude Mythos is just an LLM. Like it's an LLM that's so good it can just oneshot exploits which I think is very very unlikely. If we look at the trajectory of large language models, they have improved like drastically on each iteration but it's not the kind of improvement where they're like gaining world models or gaining an understanding of the underlying data they produce. They're still just sort of regurgitating text. So I think what really makes Claude Mythos Claude Mythos is they probably built a massive framework around it that does what I've done but for every class of exploit every class of operating system they've given it sort of all of the right harnessing and all of the right frameworks to work well within every single class of vulnerability. Um, and that's what I had to do here. Like if I log into the clawed UI and be like find me a zero day privilege escalation in Windows, it's not going to know where to start. It's not going to find anything. Whereas, if I build this multi-step system, I can actually get it to do that. The LLM is not teaching me exploitation. I'm teaching it exploitation. So, that's kind of the big difference.
I'm not trying to make me sound like I'm some amazing like top tier vulnerability researcher. I'm just pointing out that a lot of skills actually go into working with these LLMs. I don't think that someone without significant vulnerability research knowledge could just pick up an LLM and build a system like that. So there is a barrier to entry and anyone who is going to do this is going to already know how to find these vulnerabilities. Like I did not just gain the ability to find zero days in drivers. I've been doing this manually for years. So it was my knowledge of knowing how to do this already that enabled me to automate it with an LLM. And the same is going to be true I think for anything Claude mythos anything that gets built in the private sector. It's going to require expert knowledge to build out this system.
So, in order for like hackers or criminals or script kitties to get access to these systems, someone has to actually build this pipeline and hand it to them. And can I assure you that no one's going to do that? Absolutely not. But anyone who is going to do that is likely going to want to sell the exploits. So, it's not like exploits are suddenly free or they're suddenly like $4 a piece, which is a really weird narrative I've seen a lot of people running around with. I don't know where it came from, but everyone has been like, you can generate zero days for $4 now. Like, you $4 a piece? No, you can't. It's complete nonsense. Um, but anyone who was to build a system like say the one that I've just built would probably want to sell the exploits at a markup. They're not going to sell them at whatever the tokens cost. And the tokens cost a lot. Like I actually ended up falling for local LLM propaganda as a result of making this video. I think we're at like $800 in spending in just a week. And I was like I I can't keep spending this much money. Like I'm not making any money with this. Like these vendors don't have bug bounty programs. Like there is no return on investment for anything I'm doing unless I start selling exploits to criminals, which I promise I'm not going to do. Um, so it's like super super expensive and I'm like, "Wow, like this costs a lot more than I expected and if I was going to be selling exploits, I would probably be selling them for close to the price that they already go for preai."
But like, let's think about the most extreme case, which is I just go and I post this onto GitHub. I just say, "Hey everyone, I built a nice user interface that you feed drivers into and out pop zeroday exploits. Go have at it." How much damage would that cause to security? And I think it would be a lot like when fuzzers came about. Like fuzzers was like a one of the first automated ways to find binary uh vulnerabilities. And the problem was that because most fuzzers worked in the same way, most fuzzers would find the same vulnerabilities. So this system is like semi non-deterministic, but for most intents and purposes, if you put the same driver into it, you will get the same output. And essentially what would happen is security researchers would use the system. They'd find vulnerabilities and they would either make detections or they would report them and get them fixed. Uh meanwhile, the criminals would obviously try and exploit them for financial gain. Uh but because there's only a finite uh amount of vulnerabilities this system can find, they would just get used up very quickly. People would just feed their drivers through it, patch them, and there would be like a very sharp spike in the number of zero days around, but then that spike would immediately drop off. And then without me changing the system, that system is now done. It's not going to magically find more zero days.
I don't think the sky is falling. I don't think Claude Mythos is going to end security. It's actually most likely going to lead to a significant improvement in security over time. Now more people have the resources to uh find and fix vulnerabilities than before. Cuz as I said, in order to build this system, you need vulnerability research and exploit development knowledge. Whereas if someone with that knowledge builds the system for you and they say here like go and uh find the vulnerabilities in your code and fix them that is providing a new capability to those people. So now you can have any software engineer able to find and fix vulnerabilities in their code. But of course that's going to depend on us actually providing the capability in a meaningful way.
But that's where we get into a catch 22 because these models still cost a phenomenal amount of money to run. So all we're really doing is replacing vulnerability researchers with LLMs. So someone still has to pay for either a vulnerability researcher or an LLM. Maybe the LLM makes the work a little bit cheaper, but it doesn't make it zero. It doesn't mean that an open- source project with no budget who couldn't afford to hire a single vulnerability researcher now magically has $10,000 worth of uh tokens to feed into an AI. So I think there needs to be a discussion about finding a way to socialize the cost so that we can all donate towards these indie developers and open source projects and small tomedium businesses so that they can secure their code because that's where the gap actually is.
Sure, there are vulnerabilities in Microsoft and Apple and Google products, but they have the resources to find and fix them already. Sure, they're a little bit backlogged, but they do have the resources. Whereas all of these people over here, they have no resources to fix vulnerabilities at all. and they're completely reliant on people reporting bugs for free. Like they can't afford bug bounty programs. They can't even afford to give out a free t-shirt. Whereas if you look at a company like say Apple, they offer like $2 million for certain vulnerabilities in their platform. So that sends all of the vulnerability researchers and all of the LLM resources over that way when really they need to be over here because sure like vulnerabilities in iOS do have a massive impact. So do vulnerabilities in the open source software that we all rely on. And those are just as critical, but they don't have the resources to fix them.
Now imagine if a Linux kernel remote code execution vulnerability got out. That's like 99% of the non-destop workload. That's all of the hosting providers, the AI providers, uh like the big data providers, cloud, like everything runs on Linux. Only desktop systems tend to be Mac and Windows. Everything else is Linux and Linux is not a gazillion dollar company with an infinite security budget. So that's where I think we really need to be prioritizing resources.
But anyway, those are just some of my thoughts. Let me know what you think in the comments. And if you did enjoy this video, please do consider liking or subscribing to my channel. It super helps me out. And I'll be back with a new video shortly.