CCT 361: Bad Epoll - Root Access in 6 Instructions

A six-instruction timing glitch in the Linux kernel can be the difference between “low-priv user” and full root control, and that is why we dig into the Bad EPoll vulnerability from a CISSP-ready, manager-first angle. We start by grounding what the Linux kernel EPoll subsystem does, why it is foundational to high-performance I/O, and why “just disable it” is not a real option when you’re dealing with production Linux servers, desktops, cloud workloads, and Android devices.

Then we unpack the security mechanics in clear terms: a use-after-free race condition, an impossibly thin race window, and the way memory corruption turns into privilege escalation. We also talk about what makes this case extra concerning, including the report that it can be triggered from inside Chrome’s rendering sandbox. If you’ve ever relied on sandboxing, kernel boundaries, or “we run scanners” as your safety net, this story forces a more honest view of defense in depth.

From there we connect the dots to CISSP Domain 8 software development security and real secure SDLC practice. We walk through where SAST, DAST, fuzzing, KASAN-style instrumentation, and AI-assisted code review help and where they fail, especially for concurrency bugs. The real takeaway is a layered detection strategy: automated testing plus manual secure code review for high-blast-radius code, support for external researchers through bug bounty programmes, and a patch management process that moves in days with verification and regression testing so incomplete fixes do not slip through.

If this helps you think like a manager, subscribe, share the episode with a study buddy, and leave a review so more CISSP candidates can find it.

Gain exclusive access to 360 FREE CISSP Practice Questions at FreeCISSPQuestions.com and have them delivered directly to your inbox!  Don’t miss this valuable opportunity to strengthen your CISSP exam preparation and boost your chances of certification success.

Join now and start your journey toward CISSP mastery today!

Transcript

Welcome And Weekly Format

SPEAKER_00 0:00

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is John Gerber, and I'm your host of this Action Act Informative Podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cyberjector in knowledge. All right, let's get started.

SPEAKER_01 0:25

Hey y'all, it's John Gerber with CISSP Cyber Training, and hope you all are having a beautiful blessed day today. Today's Monday, and Monday is the day that we go over a lot of the content that we have related to the CISSP, both in study questions as well as items that you need to know for the CISSP exam. Now, today we're have I'm I'm kind of trying to tie this together. So one of the things that we've done in the past is I would do questions on Thursdays and I would do actually the overall product or the product, the content on Mondays. But what I've come to find out is I'm running out of time. So we are going to kind of merge those two together. And we've been doing that now for probably about a month. But those that have you been listening to it, we are doing the one podcast on Monday. And then sometimes I throw some other podcasts in there just to kind of add a little bit of spice to life. But realistically, we do one podcast a week on Mondays.

Why The Linux Kernel Matters

SPEAKER_01 1:16

So today we're going to be talking about the Linux kernel. Yet this isn't kernel and corn. This is the Linux kernel related to what it needs to run the Linux system. Now, all of you are probably listening to this going, what is that? And some of you are probably going, oh yeah, easy peasy, lemon squeezy. And you know, you'd probably be right. Both of you will be right. So the part of it is this is when I was starting off, I went to school to be an airline pilot, right? And I learned a lot of these aspects. I will tell you point blank, in trans full transparency, Linux is Linux is not my most favorite operating system. But most people, there's a lot of great people out there that think it's the best thing since sliced bread. And it also runs majority of the things that are out there in today's world. So because Linux is so used within AWS, between all the different aspects rely on Android, everything is kind of a Linux-based system. It's important that you understand it. It's it's embedded in many more places than we would ever realize. So there's been a lot of flaws that have been enabled lately. And because of that, there's because of the all the AI stuff that's going out, there's flaws that are years and years old that are now coming to the surface. And this is another one of those. And so again, I tell you right now, I struggled with Linux. So we're going to try to break this down in a way that you can understand it and digest it. Uh, so as we both learn something, because this honestly, as looking through this, reading the article, there's a lot of really great stuff in here that is beyond what I had even known as it relates to Linux and some of the aspects that are going on. So let's kind of put it into this

Bad EPoll Root Escalation Overview

SPEAKER_01 2:48

perspective. You basically are a regular user on a Linux box. You have no admin rights whatsoever, no special permissions, nothing, nada. And basically within a few seconds, you at root. Now, we've talked about this in the past. That is one of the biggest concerns. If you get root within a Linux system, you are the little demigod for that system. So full control of the machine, and this is not a hypothetical scenario. It's real and it's been patched but recently disclosed vulnerability called bad epole. Now, I probably said that wrong, but it's bad epole. And it's a CVE that's 20 2026 46242. Yes, those that understand that, good on you. Yeah, those that know what that one is, awesome. But basically, it hits Linux desktop servers and Android devices. And today I'm going to kind of walk you through how this was all played out. Um, again, this is uh it's really was a hard to catch, even for the AI-assisted vulnerability research. Now, the interesting part in all this is they did release recently with Mythos, and Mythos missed this. So it just proves that just because Mythos is out there, it can't find everything. But AI did find it, and it was just something that popped up as a different AI model that learned it. Now, where is all this coming to play? So we're gonna get into some key pat pieces around domain eight, where software development security. And at the end of this, we're gonna kind of go into some training around software development security. Of my students, the students that I have, and this I've got a cohort going on right now that is just awesome. It's going wonderfully well, and it's really helping our students that are to grow and understand the CISP. But as I do a diagnostic assessment of all of my students when they start up, one of the biggest factors that they are really struggling with is domain eight. And a lot of people are. So this is going to be fitting right into domain eight of the CISSP. So here it is in plain English, right? Linux has a feature called ePoll. And it's how programs efficiency watch a bunch of files or network connections at once without constantly pulling them. So it's doing this automatically. Every high performance web server, database, and browser leans on this specifically. You can just turn it off, it's but you can't turn it off. It's baked in on how the OS handles your input-output, your I.O. So bad e-poll is what is called the use after free vulnerability. So it's a race condition where two parts of the kernel try to clean up the same internal object at the same time. One thread frees up the memory, the other thread is still writing to it. So that collision corrupts the kernel memory, and then from there, an attacker can climb from an ordinary user account all the way down to root. I say down, meaning up or down, depends on how you want to do it, but I go down to root. Now, the researcher who found this, yeah, I can't say Jay Young Chung, built a working exploit that widens the timing window and retries it automatically. And it reportedly landed about 99% of the time it fixed on the tested systems. So again, he tested it in a controlled environment and it happened basically almost all the time. So two things make this one particularly nasty and concerning. It can reportedly be triggered from inside Chrome's rendering sandbox. Okay, this which is which blocks most every other kernel bug, and it can reach Android, which most Linux privilege escalations bugs cannot touch. So why is this hard? Well, here's the part I really want you to kind of sit with. It's the race window. There's only about six machine instructions wide, so it's really small. It's almost impossibly narrow slice of time for two threads to collide in it. It's a random attempt, almost never lands on it, which is exactly why this kind of bug survives in production code for years, because it's theoretically hard to do. It also doesn't reliably trigger Cassan. No, not Kansas, but it's Cassan, K-A-S-A-N, Kilo Alpha Sierra Alpha November. Right? This is where the kernel's built-in memory error detector. So even if you're running instrumented builds looking for exactly this class of bug, this one can still slip through without leaving obvious runtime evidence behind. So here's where the AI piece of this comes into play. So this is where, beyond just the patcher kernel, bad e-pole sits in the same small stretch of EPOL code where Anthropics Mythos model had previously found a different privilege escalation bug. And that was the one that has been out recently that was like the world is falling, is because mythos dug this up. Well, this is one that it missed. So it caught that one, but it didn't catch bad epole. This is where the human researcher, Mr. Chung, did. Now I know that one of the things I read was that he had assistance, obviously, from AI in this case, but the bottom line is Mythos didn't see it. The researcher did. So why the miss? Right? A couple of plausible reasons floated by the researchers. The race window is razor thin, and it's generally hard to reason. Okay, so domain eight, how a flaw like this gets discovered.

Domain 8 Lens On Finding Bugs

SPEAKER_01 7:45

So let's put your CISSP hats on. Let's talk about this. Domain eight is a software development security. And again, like I mentioned earlier, a lot of my uh students are all saying the same thing, right? They go, I don't understand software development, or they understand bits and pieces of it and they struggle with it. They get other parts of the domain, they get other parts of the CISSP, but number eight, domain eight, ends up being just a bit of a challenge. So because it is, it's basically a walking example of the assess the effectiveness of software security objectives in that domain. So, how do you actually find something like this before an attacker does? And we're going to talk about some key terms that you will hear on the CISSP. So listen up. And we talk about this in the training we have at CISSP Cyber Training. Static analysis. Okay, so you have static analysis testing or SAST. This is good at catching a lot of memory safety classes, but the race conditions that only exist for a few CPU instructions are notoriously hard for static tools to model. They just can't do it because they do depend on the runtime thread interleaving and running around as it's happening. So not just the overall code structure itself. So that's again static analysis testing. The next one is dynamic analysis and fuzzing. So your dynamic analysis testing, and well, and they also a lot of times include DAST and SAS will be in the same aspects, but we'll just focus specifically on DAST. Tools like Cassandra, there's also Sneak, there's other ones specifically out there. They exist specifically to catch, use after free and similar memory corruption at runtime. But as we just covered, this bug didn't reliably trip it. It was very thin. And that's the limitation of dynamic instrumentation. It only catches what happens to observe during the test run. So the other thing is this concurrency focused testing. This is the specialist set skill set. Race conditions hunting often needs a dedicated tooling. You have thread sanitizer, stress testing harnesses, and deliberate widened timing windows, plus a reviewer who deeply understands the locking model in the subsystem. So this is where you're dealing with, then that's a high-end kind of testing that's occurring. Now you have a manual secure code review. Now, this is a security critical, high blast radius code like the kernel's I.O. subsystem. This is where human eyes, when you're dealing with manual secure code review, are on the locking logic and as that they're focused on it specifically. This is the kind of code that should get extra scrutiny during design and code review, not just automated scanning. Anytime you're dealing with the kernel's I.O. systems, anything down at the kernel level needs to have a set of eyeballs on it. I would not recommend automated scanning specifically for that, just because of the fact that there's too much at risk in this case. Now it doesn't mean you can't do an automated scanning, but that also means that somebody needs to be looking at it as well to make sure they're understanding the outputs with it. Another aspect is the bug bounty and external research. This flaw was ultimately caught through Google's kernel CTF program, which pays out for working kernel exploits. And this is a great real world example of domain aids point that a mature security program treats external researchers as part of your detection layer. It's a really important. Now we talk about this in the CISSP. You need to have the ability to release these kinds of codes and these kinds of issues in a responsible manner. This gentleman did, right? He had a good plan. It's part of the bug bounty program. He brought this to Google's attention and then did it in a way that is responsible. So it's very important that you out there that are doing this, especially if you're doing any sort of fuzzing, you are doing this in a responsible manner. Then there's the AI assisted review. This is increasingly becoming a part of any toolkit. But as the story shows, this compliment to the above wasn't basically not a replacement. It found it, right? It would actually it didn't find it, Chung found it. But it is one of those things that you can use in combination. I tell people routinely around AI, AI is a great tool. It's a hammer, it's an awesome hammer. But if if you just rely on that hammer, that hammer's not necessarily going to punch holes in the wall. Or actually, it could put in nails, but then if it misses, it's going to punch holes in the wall. So there you gotta be prepared to be able to use AI in a way that's best effective for its use. So as a manager, right? So you are looking at this from the CISSP's perspective. One of the things to think about is there's no single technique that finds everything. And we've talked about that over and over again. There is no shiny button or easy button that you have to click to make this happen. So a layered approach of SAST and DAST met with manual review for critical subsystems and open doors for external researchers is exactly how you bring bugs to light like this. So it's really important that you are working your best to work and incorporate

Manager Takeaways Patch And Verify

SPEAKER_01 12:28

these with you. Okay, so some key takeaways around ePoll. So again, the Linux, the a lot of these flaws are going to continue to come up, and you as security professionals need to be ready and aware of them so that you can put things in place to ensure that you're best protecting your company. Right? So if you're studying for the exam and you're really you're wanting to grow and become a CISO or become a security leader, whatever that is in your career and your future that you want, here's how I'd frame this for the think like a manager answer. So again, you the CISO's job isn't to personally find the six instruction race window of the kernel, just not meant to do it. It's to make sure your organization has a layer detection strategy that doesn't overrely on a single tool. Also, you're supposed to have a patch management process that can move in days, not months, right? We talk about this a lot. You've got to have a good patch management program, even if you're starting off small. When there's no workaround available, that can be a big factor. So you really need to have a good patch management system. A verification step that confirms that the fix has actually been fixed. Because again, you put these things in place, you want to make sure that whatever patch has been done there actually fix the problem. So, and practically speaking, if you're running a Linux 6.4 or newer, or you manage Android fleets, get the patch status of the kernel's version on your radar this week. Start looking at it, don't let it go. So that's bad epole. So a great reminder of the hardest bugs to find are still the ones with the biggest blast radius. So we're gonna get into some training here and we're gonna kind of walk through some key points around the SDLC and domain eight. If you want more of this information, head on over to CISSP Cyber Training. Lots of great content, lots of free content that's available for you, as well as all my blogs. There's tons of videos and audio that's available from a free standpoint. I'm giving gobs and gobs away. That being said, you go look at my paid programs. I have two uh subscription programs that are set up. If you're looking to take the exam here in the next few months, they're great. They're gonna give you all the content you need to be able to pass the exam the first time. If you're interested in my cohort, I have an eight-week cohort that's gonna be kicking off in September. Uh go online, you can check that out as well. Uh, that is a very structured accountability program that is set up specifically for the folks that have a good time or when they want to go take their CISSP and they're willing to basically plant their flag in the sand and say, I'm taking it now. And I just need accountability and I need someone to help me go through this process. That is the CISS pre-sprint cohort that's available. Again, so the next class is starting September 8th. Okay, so let's get into what we're gonna talk about with the training. Okay, so we're gonna get into bad e-poll. Now, you might be listening through this through the podcast, or possibly on my site seeing the actual video itself. But as you're looking at this, you might be saying to yourself, I don't understand this. And so we're gonna break this down in a way that hopefully can help you with that. When I was in your situation, I struggled with all of these things. And I've been doing this for 20-some years. So a lot of knowledge is there. And when I was starting off in getting my knowledge around the CISSP and in cybersecurity, it took time. But that's why we created CISP Cyber Training is to help short circuit some of that for you and give you the knowledge you need now so that you don't have to take 20 years to build your knowledge so you can start making the money, additional income, as well as you can then further your career. So, again, bad e-poll, a race condition case study in secure SDLC.

Case Study Critical Infrastructure Risk

SPEAKER_01 15:55

So, this is where we're gonna kind of get into the details around this. So, we talked about the six instruction window to root. So, what was it? So it's after it's use after free race condition in the Linux kernel e-poll system. So we talked about that just briefly on how that's working. You had two threads working at the same time, and it created basically a rift, and they caused a confusion/slash a collision between those. So the impact is that an unprivileged local user will get full root on a Linux server, desktops, and the Android systems. So it's a big deal, right? You're going from basically a local user to full root. Depending on the system is at, well, let's just say hypothetically it's in a water treatment facility. That would be bad. If it's in your toll booth, well, that's not terrible, but it's not great either. If it's in a system that is in the hospital, yeah, that's not good either. So again, a lot of we talk about with what it comes to Linux systems, they are in critical infrastructure locations. They are very inset and very sensitive locations around the globe. So this is a big deal. The reliability aspects of it, again, 99% success rate once the race window is deliberately widened, once it's opened up. And then it's triggable from inside the Chrome's rendering sandbox, which most kernel bugs cannot do that. Now keep in mind, and the fact is that if it's can if you can run this from the sandbox in Chrome, and what ended up happening in a lot of cases, I'll just kind of use a little bit of history from in the working as a red teamer, we would have systems, and these systems would that people would just basically put a front oh a web front end on these systems that are just out there, right? They're running the water, they're running the power, and they would put a web front end on these. And a lot of times just a regular web server. Well, what we came to find out in many days is that this was a problem, and folks were caught, well, you could basically root these systems. Well, think about it this way: that hasn't changed in 20 years. Now, there are systems out there that have gotten better, and you can purchase those, but in many cases, a lot of these critical infrastructure locations are using this very same similar technology. They got a web server, or maybe the the men or the vendor came up with a program and put a web server inside some sort of Linux platform that's running. All of these things can be vulnerable. So that's why we want to bring this home, is that this, any Linux system, this is a big deal. So as we're getting into this, as we think like a manager, what does the CISO actually own here? So the layer detection, you know, no single tool will find this. So they there's no way to be able to deal with it. So there you have to have a fast move patch process. So when there's no compensating control, there's nothing that you've put in place that will compensate for the situation, your change management process must be able to move in days. It must be able to move quickly. And you should verify this at the end of it, and you don't ever assume that this has happened. We ran out of this as a CISO multiple times where we would put a patch in. Patch came down from the vendor, and this happened a lot in the OT space, where the vendor would come down with a patch, that patch would be great. We would put the patch in, we would roll it in, and then what would happen is in many cases, they would go, hey, patch is in, life is good, bada boom, bada bing, we just move on. But what I've come to find out is that in some cases, if you then would try to get the description of what happened and how it happened, and then you try to reproduce it. Many of these vendors, not all, but many of vendors, they wouldn't even do their own testing. They would roll this thing out, they would say, hey, it addressed the problem. I'm not getting a flag in my sort of my dynamics testing tool. So since I'm not getting a flag, it's good. Let's roll it. And that has bitten a lot of companies on this. So you want to make sure that you don't assume anything. You trust but verify. It's so very important when it comes to any sort of patches that are coming out, especially ones that are in the most critical places within your organization. And this comes down to your risk register, right? We talk about having a risk register and then the importance of that. You have your applications and your data and all these various systems, they're all in this risk register depending upon the level of risk that they are. And you're gonna have to determine what that level of risk is. And then when something affects those, you're gonna need to decide is that something I want to deal with right now, or do I want to put that on the back burner? So here are some challenge questions for you

Compensating Controls And AI Limits

SPEAKER_01 20:13

to think about. And we're gonna get into some CISP questions here in just a minute. So bad ePull didn't reliably trigger CASN. And or you can go CASN, you can remove and replace that and put that with Sneak, whatever you want to do. But if your org relies mainly on automated dynamic analysis, what is your compensating control for bug classes that don't trip your tools? Now, this is where it comes into is that do you have monitoring in place to look for these kinds of things? How are you going to manage that? So it's important that you have layered compensating controls in place for in an event something like this were to occur. Now, again, this is rare, but it is possible for that to happen. The first patch in this flaw was incomplete. So they we didn't really talk about this, but they tried to put a patch out. It didn't work. It took another two months for it to get the right one out. So again, how is your change management process? Would you handle a critical patch that fails the verification on the first attempt? And that can get very frustrating, especially if it's a critical system. So, as a senior leader, what would you do? I've had to deal with this where I've had to go to the business and I go, here are the risks. This is what's going to happen, this is where it's sitting, this is the overall risk to the organization. Now, if it's sitting behind multiple firewalls and it's buried in the bowels of your business, maybe it's not a big deal. If it's front facing and people can gain access to it through the internet, that could be a much bigger deal. So you really need to figure out what is that, but you have to walk through your business on what is critical. Third thing is an AI model, mythos, found a neighboring bug in the same code, but it missed this one. So, as a security leader, how would you calibrate how much weight you give the AI assisted code review versus human review for critical subsystems? So, are you gonna basically say, Man, I don't want to deal with it? Easy button, put it. On AI, let it go. Or are you actually going to have the ability to go, you know what, this is on a critical system. I'm going to run AI on it, but I want to have someone else look at it as well. Then the fourth, a flaw, has no workaround. So EPOL can't be disabled. You got to let it go. So you need to think about what control you'd put in place to reduce the blast radius while waiting on a vendor patch. Or basically it comes down to is that it's a it might be completely unpatchable for a period of time. I've run into this in the OT space, your operational technology space. Lots of systems do not get patched in a timely manner because one, the vendors just struggle with that. And two, they're usually in locations where they're really hard to get at. So you need to have a good plan on how you're going to deal with each of these.

CISSP Practice Questions Explained

SPEAKER_01 22:45

All right, so let's go through some questions, some CISSP questions, and let's see what you all think. So we're gonna, again, we're focusing on bad epole, but we're gonna I want to have it come back to and we're gonna think like the manager aspects. So bad EPOL rarely triggered Cassan once its sibling bug, okay, that's the one that Mythos found, was patched, leaving little runtime evidence behind. This most clearly illustrates a limitation of what type of security control. So A preventative control. Cassan is designed to stop exploitation before it happens. B detective control. Cassan monitors and flags abnormal memory behavior at runtime, and any detective control only catches what happens to observe. C, compensating controls, Cassan exits because EPOL cannot be secured in any other way. And D deterrent control. Cassandra's presence discourages attackers from targeting the kernel. So we know that as we're looking at it, we're studying this as a manager. What are some things we would think about? Well, again, the deterrent control. When you're saying absolutes, we talk about the at CISP cyber training. I actually have a training on spot the trap. It's part of my free stuff. You go check it out, it helps you understand what are some of the traps. Well, right here, you go with deterrent control. Cassand's presence deter discourages attackers from targeting the kernel. Okay, so we know that that's bogus, right? They're gonna go and attack it anyway. And they're not worried about Cassandra. They, one, they may not know about it, but two, they're gonna attack it anyway. So that's one of those that's kind of bogus, and you don't think it discourages. So that's something that wouldn't necessarily fit with what you're looking for. So you'd throw that one out. Now, again, compensating control, Cassandra exists because ePOL cannot be secured in any other way. Okay, so that one right there is that could be it, right? Because it most clearly illustrates a limitation of what type of the security control is. Let's look at preventive control. Cassandra is designed to stop exploitation before it happens. It's not designed for that. It's the time to detect it while it's being run. So that's not basically before it happens. That's not going to be the case. And also understand if you don't know this from a CISSP standpoint, there's I don't know what bugs or what tools out there can actually pick up an exploitation before it actually happens. So that's one that you would throw out. So compensated controls are like, well, maybe, but let's go to detective controls, right? Detective controls, this is where Cassand monitors and flags abnormal memory behavior at runtime. So we know that that's what it's doing. And any detective control only catches what happens to observe. So that answer is B, right? Cassand observes and flags at runtime. It does not block. Detective controls can only catch when they happen to observe what is actually going on. And this is where bad epole comes into play. Next question: the first patch for bad epole failed to fully close the vulnerability. Okay, so they didn't it didn't work and they had to wait two months. And a correct fix took roughly two months. There you go. Which practice, if rigorously enforced, would have most directly caught the incomplete first patch before it shipped? Okay, so what they're saying is that the the company released the patch and they didn't check it. But why did they not check it? Hmm, before it shipped. Let's see. Well, a mandatory two-person peer code review for the patch commit. So when they're gonna go and commit that patch to code and say it is good, they had a two-person peer code review of it. Okay, that maybe will work. They rerun SAS tools against the patch code. Okay, so it's SAS, it's static, right? So it's got to happen against it. They're it's not gonna determine at runtime when that's actually gonna be the case. So rerunning the SAS tool probably isn't the answer. C, regression verification, testing that specifically reattempts the original exploit path against the patched build. Maybe sounds positive. Or D, reacquire requiring the researcher to resubmit through the bug bounty program a second time. Okay, so we know when you're talking D, right? That's bureaucratic poo. That's just making you do something. That doesn't make sense, right? So we're talking right here which practice, if rigidly enforced, would most most directly caught the incomp incomplete, or I would say incompetent first patch before ship. Requiring a researcher doesn't do anything for you. So we break it down to basically two areas code review and regression. So the code review is a good option. However, it's not most it wouldn't have most directly caught the incomplete first patch before it shipped. This is where regression and verification testing are important. So again, peer review and SAS are generally good, but they don't confirm one specific exploit path is now closed. Only reattempting the original attack against the patch does that specifically thing. So again, it comes back to they probably didn't even test it. They go, hep, this is the patch, we fixed it, easy button, and they launched it. So think about that when you're getting patches. Third question, the final question. Researchers noted that bad e-pull can be triggered from inside Chrome's rendering sandbox, opening the door to a chaining a renderer exploit with bad epole for full kernel code execution. Yes, they can get it all, right? So sandboxes are great for blowing stuff up and for cats. Cats love them. We want to avoid sandboxes where cats are at. That's just disgusting. So this finding most directly demonstrates a failure of which security design principle. So now we're looking at a failure of security design. So it busted out of the sandbox. It got free and clear. It's running around, nay-nay, running through the woods, right? It's just streaker. So what does that mean? Well, a least privilege. A renderer process should never have been granted the any system calls at all. So it shouldn't have been called any, well, not called anything. It shouldn't be any sort of calls at all. So that's least privilege. Okay, maybe. Defense in depth. The sandbox and kernel boundary were assumed to be independent layers, but a breach of one leads directly through to the other. Okay. C, separation of duties. No single process should be able to both render content and manage memory. And then D, fail-safe defaults. The renderer sandbox should be default to denying all kernel calls. Okay, so one thing to kind of think about was spotting a trap. So fail-safe defaults. A renderer sandbox should default to denying all kernel calls. Well, we know that all of anything is usually a flag to say, no, that's not right. And you're right. So you don't you want the kernel has to be doing some calls here, right? That's what has to happen. So a fail-safe default for that is not going to work. Um, separation of duties, no single process should be able to render content and manage memory. Okay, well, separation of duties, SOD is usually for people. It's not really done designed for processes. So this would probably be, in my in my mind, this I would throw that one out as well. I'd be like, that doesn't make any sense. It doesn't match. And then least privilege. The renderer process should never be granted any system calls at all. Again, at all. There's another absolutes. When you're dealing with absolutes, we know in security there's very few absolutes in the world. Um there's lots of shades of gray, right? Lots of gray. So the real answer, the most correct answer, is defense and depth. The sandbox and the kernel boundary were assumed to be independent layers, but a breach of one leads directly through to the other. So again, sandbox already enforces least privilege. It's a tempting trap, right? It's it's it's already there, it's already got it. That's one of the things. What failed is the assumption that breaching one independent layer wouldn't hand over you to the next. So when you're dealing with the kernels, this happens a lot. So that's just an important part. They may be independent, but if you start being able, in this case here, it allowed you to breach multiple layers of that system. So very good. Could be very in-depth, right? And I know you guys are going, that there's a lot of junk in here. There's a lot of information. But the point of it comes down to is if you can break through these questions as you are studying for the CISSP, you can then parse these questions off. And if there's areas you don't know, the goal of this podcast is to help you understand these words so that when you hear them or see them on the exam, you at least have a good understanding of what you're actually dealing with. So again, that's

Training Options And Final CTAs

SPEAKER_01 30:53

it. So CISSP cyber training, go check it out. Head on over. Cohort starts September 8th. Go look at that. If you are interested in getting your CISSP before Christmas, that is for you. Two months, September and October, you can be taking the test in November, and then you're moving on with your life. The goal of it was a design to basically get you in a position where you can have a $10,000 boot camp, but you can do it at your pace. That's the same kind of content you're gonna be getting. It's all gonna be there. You're gonna have access to me, you're gonna have access to my content, and you're gonna have access to the community as well. So the cohort is a great option if you are wanting to get your CISSP done in the next three to four months, tops. And then you need a little extra help with it, it's there. All right, that's all I've got for you guys. Have a wonderful day, and we'll catch you on the flip side. See ya. Thanks so much for joining me today on my podcast. If you like what you heard, please leave a review on iTunes as I would greatly appreciate your feedback. Also, check out my videos that are on YouTube and just head to my channel at CISSP Cyber Training, and you will find a plethora or a conocopia of content to help you pass the CISSP exam the first time. Lastly, head to CISSP Cyber Training and sign up for 360 free CISSP questions to help you in your CISSP journey. Thanks again for listening.