Full transcript of “well this isn't great...”. Click a timestamp to open the video at that moment. Need another video? Use the YouTube transcript generator.
0:00 Now listen, I know what you're thinking. Lowle, this isn't a zero day. This is a bunch of fish. Well, they are related, you goofy goober, so hold your horses, okay? They're talking about a critical security flaw that was found in Chrome. And the even scarier part is that it was found by Google's own internal AI. The CVE in question today is 2025 9478, a use after free vulnerability in Angle. Angle is a piece of the Google Chrome browser. What does this all mean? Well, when you want to display fancy 2D graphics in the browser like this, typically you have to use this thing called WebGL, right? I'm not a WebGL programmer, but I do know JavaScript. And WebGL is just another API within JavaScript that allows you to render things to the screen. Well, to be able to render anything to a screen, at the
0:46 end of the day, you have to hook into calls that touch the GPU, right? And so, Angle is the almost native graphics layer engine. and it's a component of the Chrome browser that allows you to write to the GPU and make things come on the screen, hence the fish. Now, the CVE we're talking about is a use after free vulnerability in Angle. Now, a use after free vulnerability is exactly what it sounds like. It's when you use a chunk of memory that came from the heap after it's been freed. The name itself is simple, but the execution of an exploit with use after free is a little more complicated. And it took me personally a long time when I was in getting started with security research to figure out like how this all works. So let's say for example, we have two structures, right? We have a cat strruct and a dogruct. And you'll see that the strrus only have two fields. They have an
1:32 integer type and a pointer type inside the structure. Now what you'll see though is that the position inside the structure is inverted. So for the first one, the ID is the int and for the second one, the second one is the int. Now the issue that could arise is if I'm able to get the program to confuse these two types, meaning treat one pointer to a cat as a dog or vice versa, I can control this pointer and leak memory out of the program. And you'll see here that the code that I've written, which basically allows us to arbitrarily make a new dog, make a new cat, or delete the dog, delete the cat, or print the dog. kind of like a basic menubased CTF problem. You'll notice that there is no check when I print if that variable has been freed or if it's null. And what I should be doing here is when I do delete
2:18 dog or delete cat, I should delete the pointer. I should, you know, set it to null and then check that in the print. But because I don't do that, this program has an inherent vulnerability, a use after free vulnerability. Now, what I can do is take this program and run it in GDB and run through the series of commands that trigger that vulnerability. Right? So, what I have to do is make a new dog. Then I have to delete the dog. Then I have to make a new cat. And then I have to print the dog. When I'm printing the dog, what I'm doing is I'm using the dog pointer, but the dog pointer has been deleted. And the program has overwritten the contents of the dog structure with cat structure because it's using the same memory chunk. And it's going to treat the dog as a cat. When I do print dog, we got a crash here. And you'll see it's trying to read memory at EAX. This EAX value
3:04 contains this hex 4242 4242 which if we go back to the actual code is going to be the ID that we set for the cat. Right? What's magical about this is if we were able to control the ID of the cat, set this to some arbitrary value. We could treat that as a pointer and leak data out of the program. Very basic type confusion through use after free. But this is a kind of bug that's happening in Chrome right now. And yes, of course, today's video is sponsored by me, yours truly. Guys, I honestly believe that if you want to be a good programmer or a good cyber security analyst, you have to know how computers work at the fundamental level. And in my opinion, the best way to learn how the computers work is to learn a language like C or learn a language like assembly. Now, in low level academy, I have courses that do just that. In zero to her C programmer, we go through and
3:50 learn the entire C language and at the end of the course, you make your own little employee database project. And we've recently added a feature where you can go and as you're making commits to your project on GitHub, it will automatically run tests for you and test to see if you've passed the project. And then eventually if you complete all the modules in the course, you get this cool little certificate here that if I move my fat head, this QR code can be used to cryptographically verify that it is actually your certificate. And guys, we put your email address right here on the site. You can get a free 3-day CC course sent right to you. You'll learn how to write your first couple lines of C to get your feet wet in the world of low-level programming. Anyway, thanks for watching, guys. Let's keep going. Now, the big, I would argue more important part of this video is the fact that this bug was found entirely by Google's AI tool called Google Big
4:36 Sleep, which is, I guess, a function of Google DeepMind and Project Zero researchers. So, I don't know a lot about DeepMind, but Project Zero basically there is a security team inside Google called Google Project Zero. They are like one of the best, if not the best security teams in the world. They are known for finding crazy zero days in Chrome and having great writeups on them. And I guess the collaboration between DeepMind and Project Zero enabled Big Sleep to find this vulnerability. I think going forward guys, this is kind of the nature of security research. We're going to see more and more AI enabled stuff. Now obviously we have a Cindra Joyce here who's a VP of Google threat intelligence says that you know Google is trying really hard to provide agentic AI solutions like big sleep to allow researchers to do research with an AI solution. I personally don't know how
5:21 big sleep works. I'm hoping more comes out about how big sleep works or more details on big sleep. There is some previous research that's a little more public about people finding zero days with AI. Sean Healin's blog is really really good on this. He found a zero day in the Linux kernel SMB implementation uh which is called CVE 202537899. Basically, this article, all it does is go through like his process for taking an old CVE that had a pattern that enabled it to use after free and then use that pattern to find a new CVE in the Linux kernel using AI. Right? But the problem with all of this, and he highlights this very well in this article, I'm not going to read it, I'm just going to kind of highlight it, is that as AI gets a bigger context, right? As you feed AI more data for a single context window, its ability to
6:06 meaningfully think on that window gets very, very bad, right? it gets very difficult. So you basically have to limit the amount of code that you show an AI at a time to be doing this kind of research. Otherwise, if you like just gave it an entire codebase, it would just hallucinate a ton of stuff about the codebase, right? The reason why I think it's so important for these kinds of bugs as well is fuzzing, right? The art of finding vulnerabilities in like memory corruption situations is a lot easier to do for every scenario. But the use after free, the use after free is particularly hard because literally you need to create this weird state where you've traverse the program to make one state happen and then you also have to make another state happen that takes advantage of a vulnerability in the previous state, right? Just from a pure complexity standpoint, it's much more difficult to do. And so I think AI is a great place to be spending time to find
6:53 these kinds of bugs. I'm just not sure how efficient it is. I mean, I think even in Sean's own blog, he said, "Yeah, the signal to noise ratio is one in 50, right?" And so what he means by that is when he's doing this research with AI, the AI is producing these reports of the bugs that it finds, right? It says, you know, short description of the bug. Well, one SMB worker thread is doing a thing, blah blah blah blah. The problem is that it makes 50 of these reports and only one of them is true, right? The rest are hallucinations. So it just makes it very complicated for a security researcher to come in here and be like, "Oh, you know, now I have to go through and triage all of these bugs and I have to make sure that they're all real." And eventually hopefully you're finding the needle in a haststack that is real, right? A signal to noise ratio of 1 in 50 is very very bad, right? From a an
7:38 efficiency standpoint. That being said, if this world of vulnerability research and use after free memory corruption stuff, it does interest you, check out Stack Smash in the description below. And that's it for now, guys. Thanks for watching. I appreciate it. If you enjoy these kinds of videos, please let me know in the comments down below. And we'll see you in the next one. Okay, take care. Goodbye.