BSides Prishtina 2025 - Day 2 Live

In terms of security implications, there will be uh in a large number of cases, you can just get a crash, horribly mangled mess or in a lot of instances that there's likely to be privilege escalation. uh it's really arises from this uh privileged uh privileged parts like the kernel or other privileged process using user controlled memory with a lack of sufficient checks in terms of exploitation. And I'll show you a very sort of simple demo of some deliberately vulnerable code which looks a bit like this. This very contrived code is just for demonstration purposes. It's not a real vulnerability in a real product product. But what this will do is take take a password and a user ID number on

Linux and we'll then uh if the user's entered the right password and a uh ID number that is not zero, it will give the user that uh that ID and let them continue as that. It's deliberately had a long sleep placed in it so that the exploit in a couple of pages works. Uh we got some uh relatively simple exploit code now that has uh a much shorter sleep in it and then actually carries out the prives.

What you can see here is that this uh takes that correct password, sends that through, waits a very short time and then reassigns zero as the user ID. Uh obviously not expecting you to read all this now. There's a link at the end and I will put all this online for people. But uh that does allow that sort of short sleep and exploitation and privilege escalation. In terms of detection, this stuff used to be much much harder to detect. There is uh dynamic analysis can take a real long time because you're just sort of examining so many processes at once and trying to debug the entire operating system. But there has been a really good paper

not that long ago that uses uh some customized sort of approach on clang that uses taint checking through throughout a piece of code. uh the guy uh Pengal Wang he he did uh this is a vast improve well okay it's an improvement on another paper he did that sort of really improves on his dynamic checking for this stuff where it will uh go through examine the codes do the taint check and we'll highlight whenever user a tainted code has been passed into the kernel like that. some of the dynamic checking. I I've tried to run some of this stuff, but it's uh it really needs a lot of resources and a lot of power to run some

of this because of the number of processes and the num the amount of monitoring that you're actually doing. But uh there there are some very interesting good papers on that.

in terms of how to fix this stuff. Fixing a double fetch from coding practices that's uh much easier to do. Uh the there's a very simple couple of operations or couple of options that you can take to this that there's either more checks before the code is used or there is copying that variable to a a kernel controlled variable in memory space. Don't rely on the original user controlled variable. So if we go back to that original MS8061 blog post that is the fix that's in there what uh Fermine has sort of demonstrated there after that uh CP he's got two new variables CP data captured and LP data captured the user control data is copied

over into those two new variables and so the kernel controlled process just uses that data that is now out of reach of the user and can't be modified by the user. Uh you probably notice I keep referring to it as MS8061. I think the whole blog post got a bit overshadowed because it was such a short time before 08067 that there isn't even any exploit code for this because one of the most stable and reusable Windows vulnerabilities ever happened about two weeks after he'd done this for the uh compiler introduced double fetch uh your uh volatile variables is uh the the the main sort of recommended or the the only recommendation I could make to fixing

this. The the there are two alternatives. You could either switch off all optimization or you can use a volatile variable. Both of those will cause the code to execute more slowly. But uh slower but not vulnerable I guess is uh an improvement. So if we we look at the fix to this, the only difference between this and the original code is that that pointer to PS is now volatile and that completely alters the way that the C compiler treats that variable. uh it the the compiler can't really uh use that as if qualifier that was a sort of get out clause in the original C compiler definition and it produces this totally different kind of object

codes for the vulnerability as you can see now if you can remember that push RBX near the start was the original uh part of the assembly that caused or or that register was what caused all that issue in the first set of code. That is now uh just fetched once, read once and there is no sort of reuse of the same variable throughout the code.

So, as a bit of a summary of what I've just said, those uh that those double fetch bugs that they they the exploitable versions will always allow some sort of privilege escalation. that Zen uh vulnerability that is the only known case where the GCC compiler introduces that vulnerability. There's nothing else documented. Uh last time I checked the compiler still behaves that way. So that qualifier about using volati uh volatile variables still is should is still a recommendation. the exploitable bugs. I I guess the uh privesque bugs they they are a relatively small subset. There's a large number where nothing happens and uh a large number where there will just be a crash rather than an exploitable vulnerability.

Uh my main sort of claim on this uh deliberately classifying these as two separate things coding practices caused by double fetch and compiler introduced double fetch and as I say as we've been through earlier the uh the the manual code review is one way of detecting ing the uh the vulnerability. Best way I've found so far is that uh that paper I'm going to show you the links to in a moment that's really uh highlights that taint checking and good ways of tracking the this vulnerability. And if you've got uh an enormous amount of computing power, you can always try out the dynamic analysis.

So for uh as I say I'll put all this up on GitHub that uh original MS08061 blog the Tom Keech blog explains fully that compiler introduced double fetch and those are various other online explanations and tools. The middle one there, scalable fuzzing for double fetch. That is the best paper or link to use for that tool I explained about that does the tape

checking. Okay, I appreciate we've covered some complex stuff on a for a Sunday morning. Are there any questions?

Uh thank you again. I was wondering uh for developers um are any any of the like the more common IDE uh have any kind of like training wheels like Clippy popping up and it looks like you're doing a double fetch here maybe you want to not um that you know of or are you just like straight up coding in in V or something and like good luck everybody. Uh, I don't know if there's anything where where this situation's more vulnerable. It's certainly I've never heard of of any sort of way of yeah using that type of control or over developers. The the the best thing I've seen is some of these more recent white papers.

Okay. Thank you. Any other questions?

Thank you. [Applause]

So our second speak.