GPUs, the next frontier for security professionals

Welcome everyone. Uh this talk is on GPUs for security professionals. If that's not the talk you thought you were going to hear, it's probably in a different room. My name is Ted Gould. Um I currently work for Stealthium. We're building out an endpoint detection system for GPUs. I coordinate the group of security researchers and engineers that uh work on those products. And this is important for two reasons. One, thank you for Stealthium for sending me here to give this talk. And two, a lot of these things aren't things that I do directly. I have got a team that works on uh looking through these vulnerabilities and analyzing GPUs. And so, I'm representing a lot of other people's work, and they deserve some credit for that, too. Um I'm lead engineer, so that means that I get all the leftover engineering tasks that nobody wants to do. Um and that's just kind of the nature of the job. But, that's kind of fun of it. Um previously, I worked at Axiom. Uh I don't know if you've heard of them. They built a uh cloud data platform. They do observability and AI. And I worked at Canonical, and I did uh application confinement and security uh life cycle on the Ubuntu phone. So, I've been Oh, yeah. >> [laughter] >> A fan in the audience. Um so, been doing the security domain. Okay, who here has heard of AI? >> [laughter] >> It might have been in the media a little bit, and there might be a lot of people talking about it. Um It It It turns out lots of people are buying GPUs right now. And there's it's growing very, very quickly. It's uh go I want to say almost out of control. Um it's probably irrational buy at this point. It's like toilet paper during COVID. But, everyone needs to have a few of them. Uh infrastructure teams are building out uh GPU workloads very, very quickly. Um so quickly, they're not thinking about how to secure them. Um just some numbers that were out there that I can to understand the scope of the problem. XAI says they're going to have a million GPUs by the end of the year. Um which is a lot. Coreweave uh you can apparently rent up to a quarter million GPUs already in their data centers. Um that doesn't include Microsoft and AWS who are a little bit more cagey about how many they have. Um but the numbers are big and it's a huge compute infrastructure. It's it's changing the way teams work, but these are the big numbers. These are the big numbers of the big cloud providers. We also see a lot of businesses buying them for their own internal use uh for training their own models and building things out uh internally. So uh this is some level of the tip of the iceberg because a lot of people have them in places that aren't covered by press releases that I can look up. The interesting part about it is that it's also a change in the kind of the economics of attacks um from a security perspective because actually getting the GPUs because it's such a restricted resource, people are attacking GPU clusters to actually just get the GPUs because they can't get them otherwise. Um so they're doing things like crypto mining on them. They're even just shutting them down as a potential denial-of-service type attack so you can't use them and they just cost money. Um and that just comes down to the economics of them. They're very very expensive. They're very very hard to get. Um They just yeah, some numbers on the slide just talking about it as it starts to scale up. But if you've got 2,000 GPUs which is a reasonable-size cluster, if you uh buy all that just straight up, it's a 700 $70 million investment. If someone else is using it and you're not, that's a huge cost to your teams. So it's it's it just changes the economics of attacks and what we've got as we start to go um into the problems and the changes that we're seeing as GPUs become more available. So when I was making this presentation, I'm like, humans have done this before. We're We're pretty predictable. And so, I got nerd type sniped a little bit by Wikipedia. So, I'm going to share some nerd snipe with you cuz I think it's kind of fun. Um but it also talks to just about how these problems have progressed. I mean, it's interesting to see the historical precedent for this overcapacity where we were continually building so fast that we can't figure out exactly where the space that we're in. And I think as security professionals, we end up at the end of that a lot of the time. Um but we need to start to get some perspective on what's going on and how we can help make it not a total disaster. So, the oldest one I was able to find was actually in 1865. It's a steam boom. Um so, apparently, and I I you know, I I'm old, but I wasn't alive in 1865. Um Uh they were building steam engines, and they're trying to build them faster and faster and bigger and bigger. And they you know, you got to these big boats, and they they tried to make them as fast as they could, and they just kind of Oh, I hope it stays together. As they were pushing the envelope. So, the boilers got bigger, and they also got um uh more of them. So, they had to put like four of them in a ship to make the ship bigger and go faster. And safety valves were a cost. So, that caused the Sultana disaster. Um and apparently, there's a museum and a a whole thing out on the Mississippi for this. It was basically a steam boat that exploded. Uh the boat was supposed to hold 300 people, and so there was 2,000 people on it. Um about 1,000 people died. It It was interesting to try to find the number cuz I didn't want to put a number on the slide that I didn't know, but it seems like there's different reports of how many people died. Uh I saw numbers as high as 1,500 or 1,600, um and some as low as 1,000. So, I went with 1,000 plus. Um but a lot of people died just because of these boilers. Um it is the deadliest maritime disaster in US history. Which was an interesting statistic. But we we recovered afterwards. And I I I I don't want this talk to be all doom and gloom. I There there was hope. And so this is actually what created the American Society of Mechanical Engineers is responding this. And we started to make uniform standards of how boiler codes work and how the safety valves have to be in place. And we built systems on top of that after we recognized the problem. So, recognizing the problem is the key part and we'll get there. Early aviation, same category. So, they're building planes. They're like, "Oh, cool. We We know we can make things that fly." They're basically wood and paper with glue on them. And they were pushing the envelope. We Let's make them faster. Let's make them go higher. The glue failed. Um this is I don't know how to say this. I'm going to go with Canoe Rock Knee crash. Um revealed a fatal structural flaw in how wing was designed. And so, then people died. And we went to a safety-first environment. And I think the airlines actually are really interesting in this regard because they really felt like for people to trust air travel, we had to make it reliable and safe. And so they created systems to do that. And these incident reports that were developed at the time actually kind of if you look at the path of them or the incident reports we have to file today when our systems go down. And it's the same process. And so this process is almost 100 years old um about how we start to deal with these problems and how to um analyze them and ensure that they don't happen again. So, I I found that super intriguing. Then this one was a little more depressing cuz I I I've lived through this one. And if you think about it like with IoT explosion, I think everyone in the security room is twitching a little bit because they're they know all these IoT devices are out there. Basically, we had a bunch of cell phone chips that were connected and they're last generation. So, the people are trying to ship them out and they said, "Oh, we can make internet things with them." And those people didn't really know about security. Um well, or they may have known, but they ignored it. And so, the Mirai botnet is the one one example here where it was a basically a bunch of devices they had they were insecure they didn't have encryption, but they also had default passwords. They were hijacked and everything from baby monitors to cameras were hijacked and um controlled because we have just a rapid expansion of IoT. Now, the scary part to me about the IoT one is it's still bad. Um this was a statistic from a couple years ago, but they say that almost 90% 98% I guess is of the traffic from IoT devices is still unencrypted like all the command and control, all your metrics, everything is still unencrypted. Um so, yeah, that's exciting. Put it on your Wi-Fi. Um anyway, and this was the other one that was uh scary. Almost 50% have like a CVE or a critical vulnerability in them. Um they're not getting patched, they're not getting updated. And so, we see this rapid expansion. I you know, everything probably every US household on average has an IoT device in it today. Um but security came last. And so, the reality is from a GPU perspective is what we're seeing is we're watching basically the last 10 years of like we made things more secure, we got clouds more secure, we added containers, we built defense in depth, and people are just throwing it away as they're rushing to build out these huge GPU clusters. And you know, I'm sympathetic because they're that's what their boss is telling them to do. Like, hey, how many GPUs you got in the in deployment? I don't care about anything else. But, the reality is that we all know as security professionals that there's going to be a hack. It's going to get in Harvard Business Daily or Harvard Business Review, and then a CEO's going to read it and he's like, "Oh, why don't we do this?" Um And so, there's going to be that crisis. And so, we can prepare for that crisis and start to understand the problem um as we're starting to go through. One of the interesting parts about my job is I talk to people in all different parts of the stack. And so, I talk to people who are cloud providers, and I talk to people who are applications providers, and different users. And one of the things we ask them is, "Hey, you know, who's in charge of your security?" And they're like, "Oh, the cloud provider is." And so, I talk to cloud provider, and the cloud provider is, "Oh, no, we just rent that stuff out. The application guys, they handle all the security." Like, "Well, you guys talk?" And so, one [laughter] one of the things if you if you get anything out of this talk today, I I really want you to say like, know who's providing your security. Like, who's in charge of it? It may be you. >> [laughter] >> Um and if it is you, own it. And we're going to talk about some things to do that and some mitigations and and stuff like that. But, I I I I I think that the first step and the first step of probably any security problem is know who's responsible for what. And as we talk about these things, some of them can be solved at different levels in the stack, and you're probably not responsible for all the levels in the stack. So, know what your responsibilities are and make sure that you're solving the security for your level of the stack. Um it's crazy how many how much finger pointing there is going on. Yeah. >> And add know what exists as a fundamental toward who's responsible for it. >> Um So, I mean, it's so I guess let me let me phrase the question. >> Inventory. >> Inventory. So, I I think that there's a a question of what exists and who who is We were of it. Um And the a lot of times the runtime is not just security from a inventory perspective, it's also runtime like clearing memory. Um we're going to talk about and who's responsible for clearing the memory when the device is done. Um is it the the VM that came in or is it the um cloud when it initializes the new VM, should it clear all the memory before it does it? Um it it is a simple example of who owns it. So, it's not just hardware. Um I wanted to talk a little bit about the CPU and GPU relationship. I know that a lot of people probably are somewhat familiar with this, but I want to make sure we've got some of the same context. Um in general, you're probably familiar with a CPU. It's got your operating system on it. Probably most security teams have put like some sort of EDR on there, a CrowdStrike, a Datadog, and they use that for a lot of their security data. They get the security data from different applications. They're taking hashes, they're taking network data. Um I don't know, all kinds of security metrics and information are coming from the CPU side, and they're asking the kernel for that information. Maybe you've got something that's eBPF based. That's where the information is available. Um the main security going on there is this isolation. Um we can isolate by containers, namespaces. Um uh your C groups, all that type of fun stuff that you've got as tools on Linux. This is a Linux conference, so I'll assume everyone's running Linux on their OS. Um I hear other operating systems have similar features. Um but we won't talk about them here at scale. Uh but anyway, so that's kind of your CPU world. A lot of people think of the GPU like a network card, like it's just something that exists. It's just a chip that's there. They don't think about it as an active device. And the reality is that they're very active devices. They have a firmware that boots up. Firmware is almost I mean, they don't call it an operating system, but it really is. It's doing scheduling, it's doing management, it's doing memory management, it's taking information. Um it can can communicate on the PCI bus. You can actually do PCI commands that call into the CPU's world. You can do communication between devices. They can copy memory without the CPU being involved at all. Um some of the Nvidia cards, the higher Nvidia cards, have a back channel network called NVLink that they can copy memory. Um so it it's very much its own thing that's running autonomously. It's it's much much different than you consider like a network card or an SATA controller or something like that. It's just wildly smarter. Um the isolation that people use is unfortunately largely CPU defined. And so they say, "Oh well, I I you know, I allocated it and I told the GPU that I told the CPU that it could only get access, you know, memory rows 1 through 100. It would never access 101, would it?" And And that that's just largely a trust as we hey, we told the driver it don't do this and it's enforced on the CPU side, but the GPU side is the wild west. And so that's kind of a little bit how that happens on the GPU CPU side. I wanted to talk about just a simple example of kind of how this comes into play in this correlation cuz you have this full flexible system on the other side. And so this is the coffee loader. Um it's a it's I wouldn't say it's an attack. It's a it's a way to get an attack and they can load several different types of attacks. Um so what it does is it takes a payload and the payload is encrypted with a trivial key. It's not an important key as much as that means that your traditional EDR can't identify the payload because it's a randomized, it's got a salt in there, it's different. It loads that over to the GPU. Now that EDR is out of the way. There's nothing it can do. It can't see that GPU stuff anymore. And so then it runs its trivial decryption. Now we've got our payload. Normally the EDR would detect that, but the EDR is not going to actually scan memory because that would be too expensive. So it pulls it back from the GPU to the CPU load and side and executes it. So we've got our payload. It came down. We couldn't detect it. It actually gets unpackaged on the GPU. Now we can pull it onto the CPU side and do our baddie things whatever whatever we're trying to do. And so this is how you can kind of coordinate this GPU CPU relationship to exploit a machine. So I um this is it it comes down to also that the memory is managed on the CPU side. Um >> [snorts] >> the first thing I want to talk about is just the memory isolation aspect. So uh with Spectre we saw this with on the CPU side. We broke user isolation by being able to access memory we weren't allowed to by tricking the CPU. On the GPU side we see what's called CVE 2023 4969 um which was a VRAM local memory exploit. Um this showed that if you got to into a system after it already been used to um This is a while back. I'm guessing like chat GPT-2 or something. I don't remember exactly what it was, but it run it in the memory. It run it in the VRAM. And then they were able to come in afterwards, see that the driver does not clear the memory, the system does not clear the memory, and pull that memory out. And so they pulled out the memory, they parsed it, and were able to get information. And it was actually a shocking amount of information they were able to get. This is a long chat log. They were able to get about 180 megs of information. Um but this has all the contacts of the LLM, um, it has the conversations, it has the text, the back and forth. All that was available. And so, in this case, when they were trying to steal exactly what the conversation was, they're very much easy a very easy to do that just because of the leftover locals attack. Um, the mitigation is obviously clear the memory. You could do this in several ways. It's just comes down to actual responsibility, um, framework of who's responsible for clearing the memory. I mean, no one wants to pay for it because it does take time. And so, you need to agree with either your cloud provider or your different departments, your infrastructure department, your security department, like, "Okay, who's clearing the memory?" Um, another solution is just kind of simply don't run things that can't use each other's memory on the same systems. This decreases your efficiency of GPU loads, but if everyone I know that's going to run on this GPU has the same security context, I don't need to clear the memory. Um, it's a solution. I don't I don't I don't think a lot of people can do it because the GPUs are so expensive, but if you want to lower your utilization, that can also be a solution. So, container escapes, um, those are a thing. I think we know about those. Those are usually those patches you get really quickly out to your kernel, um, or live kernel updates are how you get them. Um, we've seen container escapes that are coming from, uh, the NVIDIA toolkits. Um, so the NVIDIA escape is this one. And what it does is, uh, for those who aren't familiar with the NVIDIA container toolkit, it takes all of your Kubernetes containers and it injects, um, a bunch of binaries, all the NVIDIA drivers and handles to those. It also has a socket to a common controller, but also then access to the actual hardware. And so, it injects all that in the container. It requires a whole boatload of hooks and connections to be able to do that. Those have had problems. And so, you can actually exfiltrate escape from the container that is actually using NVIDIA container toolkit. Um that's bad, as we know. The you escape from the container, then you can actually go to the other container, you can take whatever data you want, and suddenly oscillations broke down. Um obviously hyper level uh hypervisor level monitoring um where you can actually monitor the GPUs and start to look at uh observability of what's happening on the GPUs cuz if the second up container is accessing the GPU and it's not supposed to, that's a good sign that it was com- compromised. Um it also just comes down to the least privilege. I don't think that's new to anybody in security, but I've seen a lot of infrastructure teams that set up the NVIDIA container toolkit to just share it with all the all the containers because it's uh it's not a big deal, right? Uh and so, they'll have all the containers get the uh GPU connected into them. So, they get access to the drivers, they get access to the GPU, um and they can execute things on it. And so, ensure that even if you're doing things with like NVIDIA container toolkit, you specify which ones actually need the GPU. >> Do you know if this took place at any of the hyperscalers? >> Um I I don't know of anyone who confirmed that it did, but it was in the NVIDIA container toolkit. So, I can't imagine that it didn't. Um I I haven't seen any publicly say it. Um sorry, the question was whether it had if there was uh any of the hyperscalers have it had this exploit happen to them. Um and I haven't seen any confirm it, but I I can't imagine cuz it was in the base software that they're all using. Supply chain. Um we we know about supply chain. There's supply chain attacks. It's also connects nicely with persistence attacks. Um interestingly enough in this case. Um So, there's we we've taken all the models on hugging face. We downloaded them to look at them and analyze what was going on. Um we found that for the most part the the the attacks there weren't that sophisticated. Um they're, you know, typo squatting, stuff like that. The attacks that are there are very blatant. Like take all the data and ship it to this IP address. They're not doing any tricks. No coffee loaders are going on. It's it's it's pretty brute force right now. Clearly, attackers are going to get better. And so, when you're loading models from something like hugging face or any other place that you're loading models from, if you're using some of the frontier models or uh or you're downloading them and uh you're training them, you have the chance to have a supply chain attack. And the other thing that um I guess I didn't realize until we did that investigation was those models that you download from hugging face also have some Python scripts in there that kind of deal with the loading and unloading and, you know, kind of the nicety of making it easy to use. And those run as root. Yay. >> [laughter] >> That's exactly what I wanted. Something randomly downloaded from the internet that runs as root. Um it's super exciting. It's it it exciting time for security professionals. Um So, then this was interesting cuz they uh they poisoned the CUDA kernels and then they came in and they um actually wrote the firmware in the GPU to get persistence. Um because the GPU doesn't get written uh firmware doesn't get written every time. So, that that's an exploit. Um this is just a I mean, the mitigation here is probably pretty obvious. You need to know what firmware is in your GPU. Um when it boots up, you've got an attestation. Nvidia does support frameworks for that, and they can figure out, you know, where it came from and whether it's signed by Nvidia. You can get information on that. Also, you can put in uh audits for ensuring, like, someone's writing the firmware to my GPU. That seems a little weird. Um >> [laughter] >> I I don't think that should be a normal case. So, you want to put detectors in for stuff like that because it is memory on your system that will affect things if it gets overwritten and compromised. Um denial of service. Another common attack that we see on the uh the world of CPUs. Um usually it's like on the CPU world, it's usually like network load or causing a lot of database accesses. On the GPU, we've also seen it from a they call it the gang scheduling death spiral, which I think is hilarious, but um it's basically just causing the GPU to be busy all the time, so it can't schedule all the other processes. So, you have a shared GPU type scenario. One of the containers it chooses to do this, and it actually locks the whole GPU, so it can't schedule the other processes for the other containers. Um what that does is that then makes it so your entire GPU is useless. So, you bought that $35,000 GPU, and no one can use it. And while this is not necessarily, you know, taking your data, it does affect the company significantly economically. Oop. I was a slide ahead. So, anyway, yes, so this is a uh GPUs, there's there's different tools. Uh one of the tools that CloudWeave CloudWeave provides is CloudWeave provides a sunk that does scheduling. There's other tools. Stealthium can do some of this detection as well, but there's lots of tools that can do look at the scheduling, look at what your GPUs are doing. But the real story here is figure out what your GPUs are doing, understand it, and look for anomalies. Because if it's scheduling all jobs from one container, it's probably not what you want. It's probably not doing things you expect. Intellectual property theft, this is this is actually becoming bigger in the GPU world just because the amount of the amount of intellectual property that's stored in these GPUs. Um as companies are training models and they're training those models based on internal documents or internal customer documents and stuff like that, the value of those models to that company is very high. So, if an attacker comes in and they can download that model and exfiltrate it, that becomes valuable to them. Now, they may be it may be hard for them to recreate a customer document. I think that's the the worry is that they'd actually recreate like a loan application if you trained it on a bunch of loan applications. Um I haven't seen an attack that did that, but it's theoretically possible. Um but we have seen idea that people are trying to steal models. Another one is that the Anthropic claims that people have been trying to steal their model just by querying small things one by one. Um it's another attack just to get the model out in pieces. Oh. >> So, rate limiting is a good way to do the slow route. There's also looking at memory behavior analysis. The chances are that your GPUs loads, at least for inferencing, is almost always load up a huge model and then create a few times. If there's a huge download from the GPU to the CPU, that's probably not a good thing. Um unless you're model training, and then it's the other way around. Here you're going to do a big download at the end. There's probably going to be some uploads in between, and know these patterns. Watch these patterns. You can see what the GPU is doing, see how the memory is being accessed, and start to see this behavior and match it to your workloads. Um I I we've got different customers that we deal with. Um some of them want to detect crypto mining, and some of them wanted to detect not crypto mining. Um so, know the patterns for your company and what you're trying to do and what it makes sense, but watch these memory patterns cuz they're really are distinctive about what type of thing is happening. Yeah. >> Who wants to find not crypto mining? >> The crypto miners. >> [laughter] >> The um so, the people who don't want to want crypto mining not happening is like the crypto miners. Now, I think that they're They don't have a lot of people running joke servers on their stuff, but they want to make sure that they're used at a utilization and make sure they're not dropped out. So, overall, we're talking about a risk to business. Um there's the I think the if you're talking to your boss, you're like, "Oh, why do I why should I care about GPU security?" The reasons come down to intellectual property. There's a lot of money there. There's potentially a lot of training or expense that your organization has spent to train these models and build them. Getting them stolen is not a good thing. There's waste in that we've got these GPUs that we paid a lot of money for and we want to make sure they're utilized and not being stolen by somebody else. And then there's just compliance situation at least for businesses that need it and I don't think all businesses need compliance, but you probably have some some sort of sock two requirement or something else that you need to make sure that you've got security. And so this GPU domain, you need to actually ensure that it's secure as well as the traditional CPU domain. So some actual steps you can take. Um I I don't I don't want to make this all everyone cries and goes home, but visibility. You need to treat your GPUs as first class citizens. Stop thinking of them as something that just is in your network and I don't know, some geek in the corner deals with. It's like it's very important and it's important from a security perspective. So I hope that you walk away from that. This is really important to our business. Verified scrubbing is scrubbing is a a simple example, but I think that the the pop in there. I think the scrubbing is a simple example, but I think it's about knowing the responsibility. Like know what your responsibility is, know what your cloud provider's responsibility is or your infrastructure team or whoever you're dealing with. Like determine that because we don't have the traditional social contract of how things get cleared. I was talking to a friend and he goes, "Oh, you know, when I get a VM on Amazon, it's always all the memory is cleared." Well, that's been what we decided and how that that is a society things work and what we expect. There isn't that for GPUs. Nobody's really had that contract and maybe 5 years from now this slide will look stupid, but right now I can tell you nobody's clearing those GPUs on most cases. So, make sure you got it. Um and look at patterns for abuse. You've got access to a lot of information. GPUs do behave in a interesting way and that's a lot different than other workloads. Watch that. Understand the patterns for your department, your organization and look for anomalies on those patterns. And always look at tamper availability to make sure you're getting a tamper evident accountability. Watch your firmware versions. These are all kind of things you could probably do with the tools you have today. So, I'm happy to take questions. I've got the slides online. That's a QR code to the slides if you want the slides. Um