शैडोइंग अभ्यास: Watch this before you boot up another device - वीडियो के साथ अंग्रेजी बोलना सीखें

Ladies and gentlemen, boys and girls, lend me, lend me, lend me your ears.

I want to show you this really neat vulnerability in U-Boot that everyone's talking about.

Not everyone, but I am.

So if you run the script here, QEMU drive, QMU, bada bing, bada boom, you will see the magical values.

The 41414141, the 41414141, and the 4242423E.

What the hell is even going on?

What are we talking about?

Guys, we're talking about a vulnerability in U-Boot,

the bootloader that allows you to bypass signature verification by exploiting a vulnerability in the bootloader itself.

Bugs like this are really, really neat because they actually invalidate an entire trust chain in the way that weird devices like this, like embedded ones and even ones that you sit in your pocket,

validate if they use U-Boot.

Obviously, this one does not.

This one might.

Anyway, I'm going to break down the bug, what went wrong, what you can do about it, and then also what the hell all this stuff means.

The finding today was found by a company named Binarly.

I've done videos on their stuff before.

They do a really good job on finding vulnerabilities in like lower level.

That's the name of the channel, by the way.

Low level.

Low level systems like bootloaders or BMC, board management controllers, stuff like that.

Again, not an ad for this company, just they do a lot of good work.

So the vulnerability today is a stack buffer underflow, kind of hard to say, in uBoot during the FIT image signature verification,

specifically in the FDT find regions functions.

A lot of words said there.

I'm gonna go into what all that means here in a little bit.

Okay, so enter uBoot, right?

What is uBoot?

Well, uBoot, kind of like the name of this folder that I had, I called it Das Boot.

uBoot is a system that allows you to, in an embedded world, boot other OSes, right?

So typically, the way these weird devices work is you have to bring them up.

You gotta get the board to be alive, you have to bring the CPU to live.

And then the first thing that you run on a router like this is this thing called a bootloader.

A bootloader is a piece of code that allows you to run other code.

The idea being, you don't have to make that piece of code know how to boot against every other CPU.

You just bring the CPU up to the bootloader, and the bootloader does the rest of the work, right?

You can use that bootloader to run your OS, like Linux or Windows or whatever.

So if the job of the bootloader is to run code that we want it to run, why does RCE in a bootloader matter?

Why does the vulnerability in U-Boot matter to anybody?

Great question.

What actually is interesting about U-Boot is its ability to facilitate this thing called verified boot, okay?

There's this whole world of boot processes

that the entire job is to make sure that code

that is not meant to be ran does not run on the device.

And we do this thing where we use a bunch of cryptographical algorithms using asymmetric encryption with like RSA keys

and public keys and stuff to sign the software image before it tries to get loaded.

And then using a public key on the device, we verify if that manufacturer signed image is actually what we want.

Is it the proper thing that is allowed to run on this device?

because maybe we just don't want anyone to be able to

run any software they want on random piece of Chinese router, right?

Maybe that's a thing that they don't want.

Okay.

So the issue that happens here is when you go to boot with a U-boot image in this fit format, this flattened image tree format,

it is signed with a signature.

It is basically taking a private key that the manufacturer owns.

We use that to embed a signature cryptographically that says, yup, it was signed by this manufacturer.

And then we use the public key on the device to verify the signature

that it was manufactured and it is the proper image.

But we can invalidate this entire signature verification process.

We can upload and execute a piece of code that is not intended by the manufacturer

if we can find and exploit a vulnerability inside of the bootloader.

And this is exactly what Binarily did.

And I'm sorry if you're worth with Binarily and I'm mispronouncing the company's name.

I'm not very good at English.

Okay, so stack buffer underflow in uBoot during the FIT image signature verification and FDT find regions.

Basically, there's code in the bootloader that is finding different regions of the actual image itself.

And the vulnerability is based on the same issue as one above, where we rely on the fact that FTT getName, which is a call that happens above, can fail.

But this time we're interested in what it writes to the length argument upon failure.

The error code.

Very interesting.

So there's this function called FTT getName, that if for any reason in this searching of the image during this FTT getName process,

where it's getting the name of a leaf of this image format, right?

If for some reason it's searching and it finds that one of the leaves does not have a slash, right?

So strrcare is a thread-safe version of strcare, which basically looks for a token in a string.

If that fails, we set error equal to some value and we go to fail.

And then in the fail label, we say if the length pointer exists, we are going to write out that length pointer, which should be the output of the actual length of the name.

Instead, we're going to output an error value, and that error value is FTT error bad structure.

And then notice that later on in the code we're going to do is we're going to say start copy onto end, the name that we found from that function, oh, and also end plus equals length.

Well, the issue here is that length holds a negative value.

It is a large negative error code.

So instead of actually moving the end of that cursor of parsing forward, the pointer moves backwards.

It'll go backwards by the size or the value of error bad structure, which is negative 11th.

And then it will increment that and add a slash.

As the amount of code generated by AI increases, one thing that scares me is the ability to maintain that volume of code.

And that's why today's video is sponsored by CodeRabbit.

CodeRabbit is an AI code review tool that helps engineers manage the world of AI generated PRs.

For one of my platforms, Lillava Labs, I added a feature to add bookmarks to the site, right? a fairly simple feature, but adding new API endpoints like anything does create potential new security vulnerabilities

and someone at the end of the day has to review this code.

Now CodeRabbit's new change stack feature makes this really, really easy.

If you go to the PR overview page, you get a nice walkthrough of how the code changed, what the major changes are, and also it does some really nice things where it generates diagrams for you

that you can easily put into your code's documentation.

One of the hardest things about a growing code base is not only tech debt, but knowledge debt, right?

Making sure there's documentation that explains exactly how the code works.

Now, if you go inside the change stack, you actually see that there's layers here.

What CodeRabbit is doing is breaking down the PR into the separate layers that it affects, right?

We have the first layer, which is just the bookmark system, right?

These single couple of Go files that maintain the bookmarks.

But what's even more important is you get a very clean view here of, okay, now how does this system integrate to the overall backend API?

This gives you your semantic diff of the code base, showing you what changes and how it changes as a function of the new feature.

You know, then we have the last layer here.

100

We have the TypeScript interface

101

that shows you how the new webpage created for the bookmarks is integrated into the rest of the TypeScript system.

102

Breaking down the PR like this, guys, gives you a much better idea of exactly what the PR does.

103

You can go through and review the code, obviously, but knowing systematically how it affects the overall code base is a much cleaner path to a secure development life cycle.

104

And guys, CodeRabbit is used all over the world.

105

You can actually try CodeRabbit for free at this URL below.

106

Go try CodeRabbit out and see if your pull request needs some more work and if CodeRabbit can help you get there.

107

Thank you for sponsoring the video, CodeRabbit.

108

Let's get back to it.

109

So the end result is like actually beautiful, right?

110

So what you have here is a stack frame for the function in question, right?

111

You have the stack frame for this function and you have this end pointer, right?

112

So it's end is this and it's saying end plus equals length.

113

So the pointer for end should go up and up and up the stack grows more positively down.

114

That is important for you to know.

115

If you don't know that, you should know that watching this channel.

116

Damn it.

117

But what's actually happening is we have another stack frame above us, and every time we exploit this vulnerability with these sections that have bad names, that don't have a slash in them,

118

we're actually subtracting the end pointer back and back and back, 11 bytes at a time,

119

until eventually the end pointer points to the return address of the previous stack frame.

120

And I know you're thinking, if you're like a binary exploiter person, and you're like, wait, if this is its own stack frame here, isn't there nothing above it?

121

Well, no, the actual, the contents of this buffer lives in another stack frame below it.

122

So just trust me, this is how it works.

123

So N goes up, up, up.

124

And then using a new malformed section name that does have a slash,

125

we can write arbitrary data we want to the program counter and get it to return to whatever address we want.

126

Again, if this is, you know, 32-bit, like ARM, we're going to have like A, A, A, B, right?

127

And if you're new to the world of exploitation, right, what's happening here, by overriding the program counter value,

128

we now have the ability to arbitrarily run or at least point the CPU to a place to run other code, right?

129

Like we could have put code in like another part of the image

130

and we can like wrap around to like mProtect or whatever, like set the page table entry to make it executable.

131

We do a bunch of evil stuff, right?

132

The end goal here is

133

that we're able to run code in the context of a bootloader that is doing signature verification without a valid signature.

134

We are exploiting the code that is doing signature verification, and this could invalidate an entire secure boot-like process.

135

I want to highlight that this in and of itself is not secure boot.

136

This image would have to be signed by a secure boot key, like the manufacturer key that the actual motherboard has.

137

But that being said, right, it's a really interesting primitive in the world of U-Boot, of bootloader vulnerabilities.

138

Not going to dive super deep into a ton of these, but you have another bunch of vulnerabilities, like, you know, the same kind of bug, denial of service in U-Boot using an FIT image signature because of an unchecked size value.

139

There are other parts of the code that use a name pointer where that name pointer can be null pointer.

140

And because of that, it's going to do a bunch of other stuff.

141

There's a whole bunch of interesting bugs on this write-up.

142

I'll put it in the description below.

143

But it's an interesting case study in the world of U-Boot, of bootloader vulnerabilities.

144

And the question for the class, the question that everyone probably wants to know the answer to, would Rust have fixed this?

145

Sort of.

146

So again, U-Boot, the whole point of this is to have the CPU be brought up, the CPU runs a bootloader, the bootloader then enables the OS, right?

147

We are at the super, super low level, name of the channel, by the way, in the boot process, okay?

148

Now, doing this in Rust is actually like there are these things called peripheral access crates

149

or these things called hardware abstraction layer crates

150

that allow you to write code that is not unsafe for the board in question.

151

That being said, doing things like raw MMIO

152

that maybe there isn't a peripheral extraction crate written for is very hard to do.

153

And it always does depend on unsafe code, even inside of the peripheral abstraction crates or access crates.

154

There is there has to be by the nature of how embedded software works, right?

155

It's global mutability, which is what Rust is designed to get rid of.

156

Inside of even this code, there has to be a piece of unsafe code, unfortunately.

157

But that being said, it's possible, just not easy.

158

And yes, Rust would have fixed bugs like this, right?

159

You would, well, actually, kind of think about it.

160

I don't think you're able to fix this bug

161

because all you're doing here is writing out to a pointer and a value, right?

162

And then from there, it's causing the underflow.

163

So I'm not necessarily sure if that's the case.

164

You can't raw pointers in rust

165

so there you go that's that's the answer actually you know the rust um error

166

and not error the the okay and error type the result type would fix this

167

because what this is actually the classical issue in c where

168

you're using the error code in the error state as the

169

actual value slot right this is like the entire problem

170

that the rust t e or rust result type fixes

171

and before we leave by the way in the code here what we're showing you

172

so what i did here is i i wrote um i compiled uboot the vulnerable version

173

which there is no patch for by the way yet.

174

I compiled UBoot to run in QMU.

175

QMU is like a system emulator, emulates an arm chip.

176

And then I ran UBoot and I tried to signature validate with the FIT image that has the vulnerable structures in it.

177

And then by using this, I was able to take control of the registers that are put on the stack, right?

178

So R10, the frame pointer, and ultimately PC, where PC is the return address that we're going to execute next, right?

179

And by doing that, this proves

180

that I have at least the the ability to point the CPU to other places in the code

181

that I want to run my evil stuff right now.

182

Obviously, the question of like NX and ASLR comes up, but that is a different question for a different video.

183

Anyway, thank you for watching, guys.

184

I appreciate it.

185

If you like this stuff, check out my other stuff, and then give me a little kiss on the cheek.

186

Okay, we'll see you later.

187

Goodbye.

शैडोइंग तकनीक क्या है?

शैडोइंग (Shadowing) एक विज्ञान-समर्थित भाषा सीखने की तकनीक है जो मूल रूप से पेशेवर दुभाषिया प्रशिक्षण के लिए विकसित की गई थी। विधि सरल लेकिन शक्तिशाली है: आप मूल अंग्रेज़ी ऑडियो सुनते हैं और तुरंत इसे ज़ोर से दोहराते हैं — जैसे वक्ता की छाया 1-2 सेकंड की देरी से। शोध से पता चलता है कि यह उच्चारण सटीकता, स्वर, लय, जुड़ी हुई ध्वनियाँ, सुनने की समझ और बोलने की प्रवाहशीलता में काफ़ी सुधार करता है।

शैडोइंग अभ्यास: Watch this before you boot up another device - वीडियो के साथ अंग्रेजी बोलना सीखें

संदर्भ और पृष्ठभूमि

दैनिक संवाद के लिए शीर्ष 5 वाक्यांश

कदम-दर-कदम शैडोइंग गाइड

शैडोइंग तकनीक क्या है?