0 00:00:00,000 --> 00:00:30,000 Dear viewer, these subtitles were generated by a machine via the service Trint and therefore are (very) buggy. If you are capable, please help us to create good quality subtitles: https://c3subtitles.de/talk/485 Thanks! 1 00:00:08,840 --> 00:00:10,979 Right. So, yes, I'll be talking 2 00:00:10,980 --> 00:00:13,199 about Windows drivers service, some 3 00:00:13,200 --> 00:00:14,200 new insights. 4 00:00:15,360 --> 00:00:16,799 So my name is Ilya. 5 00:00:16,800 --> 00:00:18,449 I work for a company called Bioactive. 6 00:00:18,450 --> 00:00:20,220 I am the director of penetration testing. 7 00:00:21,330 --> 00:00:23,579 I do Pentax, Waterview basically break 8 00:00:23,580 --> 00:00:24,840 stuff for fun and profit. 9 00:00:25,890 --> 00:00:28,589 And I'm here to talk today about Windows 10 00:00:28,590 --> 00:00:30,479 drivers attack surface. 11 00:00:30,480 --> 00:00:32,129 It's sort of divided up into, you know, I 12 00:00:32,130 --> 00:00:34,019 have a little intro and I've got two 13 00:00:34,020 --> 00:00:36,449 pieces and piece one talks about 14 00:00:36,450 --> 00:00:38,399 gives you some some background and talks 15 00:00:38,400 --> 00:00:39,389 about the where. 16 00:00:39,390 --> 00:00:41,249 And in part two was sort of the guts of 17 00:00:41,250 --> 00:00:43,079 the talk. And it talks about what 18 00:00:44,160 --> 00:00:45,599 I got a lot of ground to cover today. 19 00:00:45,600 --> 00:00:47,849 So I'm going to try and move 20 00:00:47,850 --> 00:00:49,739 my way through part one really fast. 21 00:00:50,970 --> 00:00:52,649 I hope you'll bear with me. 22 00:00:52,650 --> 00:00:54,059 If I don't, I'll run over. 23 00:00:54,060 --> 00:00:55,060 So I kind of have to. 24 00:00:57,220 --> 00:00:58,899 See, I was talking about basically I'm 25 00:00:58,900 --> 00:01:01,179 going to be talking about attack surface 26 00:01:01,180 --> 00:01:03,489 of Windows WDM, which is 27 00:01:03,490 --> 00:01:06,309 Windows driver model drivers, 28 00:01:06,310 --> 00:01:08,009 and specifically about the implementation 29 00:01:08,010 --> 00:01:10,119 of security, I guess the 30 00:01:10,120 --> 00:01:11,859 audience is sort of the you know, if 31 00:01:11,860 --> 00:01:13,539 you're looking for bugs, those drivers 32 00:01:13,540 --> 00:01:15,609 just talk. Might be interesting if 33 00:01:15,610 --> 00:01:16,839 you're a driver, developer, just talk. 34 00:01:16,840 --> 00:01:18,159 Might be interesting. 35 00:01:18,160 --> 00:01:20,259 If you're just curious about this kind of 36 00:01:20,260 --> 00:01:22,239 security stuff, then this talk might be 37 00:01:22,240 --> 00:01:24,579 interesting, too, in terms 38 00:01:24,580 --> 00:01:25,839 of knowledge. 39 00:01:25,840 --> 00:01:27,609 It'd be nice if you have some kind of 40 00:01:27,610 --> 00:01:29,849 general background on, you know, 41 00:01:29,850 --> 00:01:31,929 what an operation is going to look like. 42 00:01:31,930 --> 00:01:33,969 And if you have some specific knowledge 43 00:01:33,970 --> 00:01:36,039 about Windows Kernel and Windows drivers, 44 00:01:36,040 --> 00:01:37,959 that's even better, but not necessarily 45 00:01:37,960 --> 00:01:38,960 required. 46 00:01:40,690 --> 00:01:42,759 Before I talk 47 00:01:42,760 --> 00:01:45,399 about memorization, 48 00:01:45,400 --> 00:01:46,869 it's clear to say that, you know, 49 00:01:46,870 --> 00:01:48,189 standing on the shoulders of giants, 50 00:01:48,190 --> 00:01:50,619 there are have been a number of people 51 00:01:50,620 --> 00:01:52,929 that have done research in these things. 52 00:01:52,930 --> 00:01:54,699 And I would do a disservice if I didn't 53 00:01:54,700 --> 00:01:57,279 at least put their names up there. 54 00:01:57,280 --> 00:01:58,689 If you think I missed someone, please let 55 00:01:58,690 --> 00:02:00,159 me know. I'd I'd like to add your name to 56 00:02:00,160 --> 00:02:02,529 it, but I think this is a fairly 57 00:02:02,530 --> 00:02:03,530 good list. 58 00:02:04,870 --> 00:02:06,939 This this talk is slightly different than 59 00:02:06,940 --> 00:02:08,799 most of those, though. 60 00:02:08,800 --> 00:02:10,689 So if you look at most of the previous 61 00:02:10,690 --> 00:02:12,129 research on Windows called Windows 62 00:02:12,130 --> 00:02:14,569 drivers, it's mostly been focused 63 00:02:14,570 --> 00:02:16,629 on exploitation and 64 00:02:16,630 --> 00:02:18,729 it's usually been focused on the Windows 65 00:02:18,730 --> 00:02:20,709 world, specifically enough so much on the 66 00:02:20,710 --> 00:02:21,729 drivers. 67 00:02:21,730 --> 00:02:23,919 And it's almost always been focused 68 00:02:23,920 --> 00:02:26,079 on like one particular issue. 69 00:02:26,080 --> 00:02:27,729 And so my presentation is different in 70 00:02:27,730 --> 00:02:30,069 the sense that the focus isn't 71 00:02:30,070 --> 00:02:32,379 so much on exploitation, 72 00:02:32,380 --> 00:02:34,899 but it is more on the finding, 73 00:02:34,900 --> 00:02:37,089 identifying of bugs and then giving some 74 00:02:37,090 --> 00:02:39,189 kind of guidance on how to how would 75 00:02:39,190 --> 00:02:41,259 you mitigate or fix these issues. 76 00:02:42,400 --> 00:02:44,259 Also, it isn't so much about we just call 77 00:02:44,260 --> 00:02:46,359 itself as this about specific 78 00:02:46,360 --> 00:02:48,599 drivers, of course, to go ahead and 79 00:02:48,600 --> 00:02:50,079 you can't have one without the other. 80 00:02:50,080 --> 00:02:52,359 So much of this stuff applies 81 00:02:52,360 --> 00:02:54,939 to them just as well and vice versa. 82 00:02:54,940 --> 00:02:56,949 But it's a slight difference, though. 83 00:02:56,950 --> 00:02:58,179 And the other thing is that I'm not 84 00:02:58,180 --> 00:03:01,089 talking about one particular issue. 85 00:03:01,090 --> 00:03:03,189 What I did is I sort of sat down and said 86 00:03:04,540 --> 00:03:06,879 looked at all of the common bugs 87 00:03:06,880 --> 00:03:09,849 you have or you find in most windows 88 00:03:09,850 --> 00:03:12,339 drivers and sort of try to find 89 00:03:12,340 --> 00:03:14,289 the common theme around it in a thread. 90 00:03:14,290 --> 00:03:15,489 And that's basically what I'll be talking 91 00:03:15,490 --> 00:03:16,490 about today. 92 00:03:17,830 --> 00:03:19,769 Right, so the intro is basically 93 00:03:19,770 --> 00:03:21,869 basically the statistics in show 94 00:03:21,870 --> 00:03:24,089 you could easily spend days talking 95 00:03:24,090 --> 00:03:25,229 about all sorts of intricate little 96 00:03:25,230 --> 00:03:27,509 details about windows, driver bugs. 97 00:03:27,510 --> 00:03:28,510 And so I tried to 98 00:03:30,420 --> 00:03:33,389 get it down in the one hour thing 99 00:03:33,390 --> 00:03:35,039 and basically comes down to all of these 100 00:03:35,040 --> 00:03:36,040 little. 101 00:03:37,260 --> 00:03:39,149 Obscure things that very few people seem 102 00:03:39,150 --> 00:03:41,609 to know about and what the consequences 103 00:03:41,610 --> 00:03:44,069 are if you if you if 104 00:03:44,070 --> 00:03:45,809 you know or don't know about certain 105 00:03:45,810 --> 00:03:48,689 things or if you do them wrong or 106 00:03:48,690 --> 00:03:50,309 and whether or not that's documented or 107 00:03:50,310 --> 00:03:52,079 not. And it turns out some of those 108 00:03:52,080 --> 00:03:54,329 things are kind of like 109 00:03:54,330 --> 00:03:56,109 most of it you find anonymous at the end. 110 00:03:56,110 --> 00:03:57,509 But a lot of it is like you have to read 111 00:03:57,510 --> 00:03:59,189 between the lines. 112 00:03:59,190 --> 00:04:02,159 You'll have these subtle hints as to, 113 00:04:02,160 --> 00:04:03,899 you know, what is problematic and what 114 00:04:03,900 --> 00:04:05,879 isn't. But quite often it's not 115 00:04:05,880 --> 00:04:06,910 explicitly mentioned. 116 00:04:08,400 --> 00:04:10,079 And so it makes it very hard for people 117 00:04:10,080 --> 00:04:11,099 to to know these things. 118 00:04:11,100 --> 00:04:13,229 And that includes, unfortunately, most 119 00:04:13,230 --> 00:04:14,230 driver developers. 120 00:04:18,029 --> 00:04:20,099 So with that, let's dove into Part 121 00:04:20,100 --> 00:04:21,689 one series. 122 00:04:21,690 --> 00:04:23,339 The section is by no means to be 123 00:04:23,340 --> 00:04:25,499 exhaustive. It's a quick reminder and 124 00:04:25,500 --> 00:04:26,849 I'm going to try to make my way through 125 00:04:26,850 --> 00:04:29,069 it really fast. 126 00:04:29,070 --> 00:04:31,199 So basically, yeah, start 127 00:04:31,200 --> 00:04:32,459 off with a little bit of architecture. 128 00:04:32,460 --> 00:04:34,679 Basically at a high 129 00:04:34,680 --> 00:04:36,599 level, doing the scroll is divided up 130 00:04:36,600 --> 00:04:38,669 into all of these managers that 131 00:04:38,670 --> 00:04:40,379 have their own tasks to do. 132 00:04:40,380 --> 00:04:42,539 And the idea is that you as a user, if 133 00:04:42,540 --> 00:04:44,219 you want to get to them, you basically 134 00:04:44,220 --> 00:04:46,139 call system cause and you end up in one 135 00:04:46,140 --> 00:04:48,269 of these managers, for example, if you do 136 00:04:48,270 --> 00:04:49,829 at the device your control, you end up in 137 00:04:49,830 --> 00:04:52,049 your manager from 138 00:04:52,050 --> 00:04:54,149 fifty thousand feet view. 139 00:04:54,150 --> 00:04:56,619 This is kind of what it looks like. 140 00:04:56,620 --> 00:04:58,739 So you have I don't know if you know, you 141 00:04:58,740 --> 00:05:01,589 know, OK, basically 142 00:05:01,590 --> 00:05:03,659 from New Zealand, you call 143 00:05:03,660 --> 00:05:05,789 it system calls and then you 144 00:05:05,790 --> 00:05:08,189 go into, you know, your skull table, then 145 00:05:08,190 --> 00:05:10,049 it'll go into one of these managers. 146 00:05:10,050 --> 00:05:11,670 Quite often you end up in jail, a manager 147 00:05:14,280 --> 00:05:16,529 inside, inside 148 00:05:16,530 --> 00:05:17,819 this thing, there's a whole bunch of 149 00:05:17,820 --> 00:05:19,859 frameworks working together. 150 00:05:19,860 --> 00:05:22,979 There's there's over a dozen. 151 00:05:22,980 --> 00:05:24,809 And all of these are worthy of their own 152 00:05:24,810 --> 00:05:26,159 presentation. And I wish I could talk 153 00:05:26,160 --> 00:05:28,379 about all of them, but 154 00:05:28,380 --> 00:05:29,549 due to time constraints, 155 00:05:30,870 --> 00:05:33,269 I'm going to limit myself to 156 00:05:33,270 --> 00:05:35,339 the Windows driver model WDM 157 00:05:35,340 --> 00:05:37,469 and a tiny, tiny little bit about 158 00:05:37,470 --> 00:05:38,470 CDF. 159 00:05:40,110 --> 00:05:41,369 So, yeah, what is WDM? 160 00:05:41,370 --> 00:05:42,659 It's basically the Windows driver model. 161 00:05:42,660 --> 00:05:44,219 It's been around since around Windows 162 00:05:44,220 --> 00:05:45,569 2000. 163 00:05:45,570 --> 00:05:47,639 It sort of extends and updates 164 00:05:47,640 --> 00:05:49,709 the old and T driver model. 165 00:05:49,710 --> 00:05:51,899 It is the standard model for how drivers 166 00:05:51,900 --> 00:05:52,900 are written. 167 00:05:53,620 --> 00:05:54,749 I mean, in recent years there's been a 168 00:05:54,750 --> 00:05:56,879 shift towards Kamdesh, but there's still 169 00:05:56,880 --> 00:05:58,139 a fair amount of WDM. 170 00:06:00,060 --> 00:06:02,309 And so that's why I'll 171 00:06:02,310 --> 00:06:04,109 basic focus on WDM. 172 00:06:04,110 --> 00:06:06,389 So let me now say a few things about 173 00:06:06,390 --> 00:06:09,089 the manager, which is sort of it's 174 00:06:09,090 --> 00:06:10,919 it's this proxy that sits in between the 175 00:06:10,920 --> 00:06:12,179 user and going to drivers. 176 00:06:13,710 --> 00:06:16,139 And depending on what kind of request 177 00:06:16,140 --> 00:06:18,299 you do, it may or may not do some 178 00:06:18,300 --> 00:06:19,410 kind of validation 179 00:06:20,460 --> 00:06:22,799 wants it to. And so it takes your request 180 00:06:22,800 --> 00:06:23,819 for you to land. 181 00:06:23,820 --> 00:06:25,979 And that sort of packages it up 182 00:06:25,980 --> 00:06:28,229 in this thing called an IO 183 00:06:28,230 --> 00:06:29,759 request packet and URP. 184 00:06:29,760 --> 00:06:30,929 And we'll talk about that in a little 185 00:06:30,930 --> 00:06:31,949 bit. 186 00:06:31,950 --> 00:06:34,049 And that basically it finds your 187 00:06:34,050 --> 00:06:35,639 drivers, especially for whatever thing 188 00:06:35,640 --> 00:06:37,389 you want to do and sort of hands it off 189 00:06:37,390 --> 00:06:38,489 there. 190 00:06:38,490 --> 00:06:40,079 And let me try and illustrate that with 191 00:06:40,080 --> 00:06:41,069 some code. 192 00:06:41,070 --> 00:06:42,929 So basically, if you have like a simple a 193 00:06:42,930 --> 00:06:45,089 very, very simple driver basically has 194 00:06:45,090 --> 00:06:46,469 this thing called a driver entry, which 195 00:06:46,470 --> 00:06:48,509 is basically the main entry point. 196 00:06:48,510 --> 00:06:50,579 And then essentially any driver that 197 00:06:50,580 --> 00:06:52,439 wants to have interaction would usually 198 00:06:53,640 --> 00:06:55,349 goes general manager and says, hey, 199 00:06:55,350 --> 00:06:56,969 create this device. 200 00:06:56,970 --> 00:06:58,319 They call your device. 201 00:06:58,320 --> 00:06:59,969 And then they say, OK, now that device 202 00:06:59,970 --> 00:07:01,169 created. 203 00:07:01,170 --> 00:07:03,329 I want usually to be able to talk to it. 204 00:07:03,330 --> 00:07:05,729 And so they go to the manager and say, 205 00:07:05,730 --> 00:07:07,049 I'll create a symbolic link. 206 00:07:07,050 --> 00:07:08,129 And basically what it does, it creates a 207 00:07:08,130 --> 00:07:10,229 symbolic link for you to talk to 208 00:07:10,230 --> 00:07:11,230 that device. 209 00:07:12,150 --> 00:07:14,499 And so basically 210 00:07:14,500 --> 00:07:15,989 just means as you read a bunch of 211 00:07:15,990 --> 00:07:17,939 dispatch calls to our manager and then 212 00:07:17,940 --> 00:07:20,429 you basically 213 00:07:20,430 --> 00:07:22,509 can do axles or fist controls 214 00:07:22,510 --> 00:07:24,789 or open around sofort in code, 215 00:07:24,790 --> 00:07:27,059 just kind of looks like this where 216 00:07:27,060 --> 00:07:28,439 basically, you know, as I mentioned, for 217 00:07:28,440 --> 00:07:30,669 you to create device which will link 218 00:07:30,670 --> 00:07:31,949 and then you do all of these dispatch 219 00:07:31,950 --> 00:07:33,599 functions and then for all of those 220 00:07:33,600 --> 00:07:36,119 functions you basically have 221 00:07:36,120 --> 00:07:37,679 and there's more of these. 222 00:07:40,410 --> 00:07:42,569 But basically for all of these functions, 223 00:07:42,570 --> 00:07:44,699 it kind of looks like this where 224 00:07:44,700 --> 00:07:47,129 there's two arguments 225 00:07:47,130 --> 00:07:48,689 that keep as long as the device object 226 00:07:48,690 --> 00:07:50,329 and the actual urp. 227 00:07:51,930 --> 00:07:54,689 And so the purpose is interesting because 228 00:07:54,690 --> 00:07:57,059 this contains all the data 229 00:07:57,060 --> 00:07:58,679 that's packaged up from user land that 230 00:07:58,680 --> 00:08:01,169 your driver 231 00:08:01,170 --> 00:08:03,059 gets access to. 232 00:08:03,060 --> 00:08:05,759 And it includes things like, you know, 233 00:08:05,760 --> 00:08:08,009 data being passed around your 234 00:08:08,010 --> 00:08:10,109 IO status, what kind of request, 235 00:08:10,110 --> 00:08:11,429 what you are. 236 00:08:11,430 --> 00:08:13,229 And basically it sort of just kind of 237 00:08:13,230 --> 00:08:15,419 nicely completes that where it says, OK, 238 00:08:15,420 --> 00:08:17,549 this is the pointers that are as the 239 00:08:17,550 --> 00:08:19,679 system for a pointer memory 240 00:08:19,680 --> 00:08:22,259 descriptor lists your urp stack. 241 00:08:23,310 --> 00:08:25,709 And so let's talk about your stack. 242 00:08:25,710 --> 00:08:27,959 Basically, for every group that comes 243 00:08:27,960 --> 00:08:29,849 in it associated, there's a stack 244 00:08:29,850 --> 00:08:31,589 associated which is with it, which is 245 00:08:31,590 --> 00:08:34,558 this URP stack, and it contains 246 00:08:34,559 --> 00:08:36,749 very specific information that. 247 00:08:36,750 --> 00:08:38,819 Your driver needs for that particular 248 00:08:38,820 --> 00:08:41,279 operation, and so 249 00:08:41,280 --> 00:08:43,439 it'll say, OK, you 250 00:08:43,440 --> 00:08:45,659 recalled with this major minor function, 251 00:08:45,660 --> 00:08:47,969 no, it's this device object 252 00:08:47,970 --> 00:08:49,379 is this file object. 253 00:08:49,380 --> 00:08:51,719 And then based upon 254 00:08:51,720 --> 00:08:53,069 which major minor function? 255 00:08:53,070 --> 00:08:56,099 No, there's a specific parameter union 256 00:08:56,100 --> 00:08:59,189 and it'll have different sets of 257 00:08:59,190 --> 00:09:01,559 elements inside union based 258 00:09:01,560 --> 00:09:03,559 upon whether it's OK to read or write and 259 00:09:03,560 --> 00:09:04,560 so forth. 260 00:09:05,610 --> 00:09:07,199 But essentially all the specific data you 261 00:09:07,200 --> 00:09:09,359 need, you tend to grab out of Europe 262 00:09:09,360 --> 00:09:10,360 stack. 263 00:09:11,850 --> 00:09:13,219 And then, of course, from New Zealand, 264 00:09:13,220 --> 00:09:14,699 how you get to there? Well, you call 265 00:09:14,700 --> 00:09:16,459 this, you know, a. 266 00:09:16,460 --> 00:09:18,529 device control file 267 00:09:18,530 --> 00:09:20,179 system call. 268 00:09:20,180 --> 00:09:22,459 And then if you look at the last 269 00:09:22,460 --> 00:09:24,409 five arguments sort of ones where there's 270 00:09:24,410 --> 00:09:26,509 there's, you know, potential for four 271 00:09:26,510 --> 00:09:28,819 attack surface and and where the 272 00:09:28,820 --> 00:09:30,949 the entry into driver 273 00:09:30,950 --> 00:09:33,259 happens, which is your 274 00:09:33,260 --> 00:09:35,579 control code input buffer, 275 00:09:35,580 --> 00:09:36,949 buffer like Apple buffer up and buffer 276 00:09:36,950 --> 00:09:37,950 links. 277 00:09:39,710 --> 00:09:40,710 And so, OK, 278 00:09:41,940 --> 00:09:44,149 once that sort of goes through the 279 00:09:44,150 --> 00:09:45,889 manager and it goes to your driver, 280 00:09:45,890 --> 00:09:47,959 driver goes to base, goes to 281 00:09:47,960 --> 00:09:50,099 your device control dispatch 282 00:09:50,100 --> 00:09:52,099 and sort of packs up the surf and hands 283 00:09:52,100 --> 00:09:53,100 it over. 284 00:09:53,840 --> 00:09:55,909 So how depending on 285 00:09:57,140 --> 00:09:59,239 your IO control code, the 286 00:09:59,240 --> 00:10:02,059 way does etiquettes back up 287 00:10:02,060 --> 00:10:03,619 differs. 288 00:10:03,620 --> 00:10:05,569 And so let's look at what the IO control 289 00:10:05,570 --> 00:10:07,669 it looks like, even though 290 00:10:07,670 --> 00:10:10,639 it may look like just a no, it's actually 291 00:10:10,640 --> 00:10:12,409 split up into several different bits and 292 00:10:12,410 --> 00:10:13,729 pieces. 293 00:10:13,730 --> 00:10:15,889 From a security perspective, 294 00:10:15,890 --> 00:10:17,959 we really only care about two pieces of 295 00:10:17,960 --> 00:10:20,299 the required access and the transfer 296 00:10:20,300 --> 00:10:21,300 type. 297 00:10:21,770 --> 00:10:23,749 And so I'll say a little bit about about 298 00:10:23,750 --> 00:10:26,089 transfer type and requite axis. 299 00:10:26,090 --> 00:10:27,529 Right axis basically one of three. 300 00:10:27,530 --> 00:10:29,549 It says file any file data. 301 00:10:29,550 --> 00:10:31,519 And if I write data and what that means 302 00:10:31,520 --> 00:10:33,949 is if you open the handle to a device 303 00:10:33,950 --> 00:10:35,749 and you say, you know, I open it as 304 00:10:35,750 --> 00:10:37,669 Read-Only and then you, you and I are 305 00:10:37,670 --> 00:10:40,189 equal, that requires file. 306 00:10:40,190 --> 00:10:42,289 Right data. For example, Deyo 307 00:10:42,290 --> 00:10:43,519 manager sees all your handles. 308 00:10:43,520 --> 00:10:45,589 Only areto is only Fareed, but 309 00:10:45,590 --> 00:10:47,029 your actual court says file right. 310 00:10:47,030 --> 00:10:49,219 Data that that doesn't match and 311 00:10:49,220 --> 00:10:51,289 so you imagine will kick you out. 312 00:10:51,290 --> 00:10:53,779 And so this, this restricts you to 313 00:10:53,780 --> 00:10:55,639 the access that you need. 314 00:10:58,300 --> 00:10:59,889 And so the other one is the transfer 315 00:10:59,890 --> 00:11:01,449 type, and there's basically four 316 00:11:01,450 --> 00:11:03,909 different kinds of transfer type Bufford 317 00:11:03,910 --> 00:11:05,709 neater, indirect, not direct. 318 00:11:05,710 --> 00:11:08,049 And so let me let me sort of run 319 00:11:08,050 --> 00:11:09,609 through those really quickly. 320 00:11:09,610 --> 00:11:12,039 The first one is Method Bufford. 321 00:11:12,040 --> 00:11:14,199 I met Bufford is sort of the preferred 322 00:11:14,200 --> 00:11:16,569 safe ish way of 323 00:11:16,570 --> 00:11:19,109 it, passing Arktos from from 324 00:11:19,110 --> 00:11:20,949 out to drivers. 325 00:11:20,950 --> 00:11:22,749 What that means is the manager basically 326 00:11:22,750 --> 00:11:25,089 looks at the data that usually 327 00:11:25,090 --> 00:11:27,399 passes in and it says, OK, your input 328 00:11:27,400 --> 00:11:29,109 buffer is, I don't know, let's say 10 329 00:11:29,110 --> 00:11:31,149 bytes big. What I'll do is I'll meet it 330 00:11:31,150 --> 00:11:32,739 all, create a kernel buffer that's 10 331 00:11:32,740 --> 00:11:35,229 bytes, picking up your data over, 332 00:11:35,230 --> 00:11:37,899 and then I'll pass that on to the driver. 333 00:11:37,900 --> 00:11:39,249 And what that means is the driver doesn't 334 00:11:39,250 --> 00:11:41,589 have to worry about, you know, 335 00:11:41,590 --> 00:11:43,989 race conditions or making sure that 336 00:11:43,990 --> 00:11:46,209 the address is within user and 337 00:11:46,210 --> 00:11:47,259 doesn't point a kernel. 338 00:11:47,260 --> 00:11:48,879 And all these tricks, you don't have to 339 00:11:48,880 --> 00:11:50,740 worry about it if using buffer Bufford. 340 00:11:52,390 --> 00:11:54,219 Additionally, when the kernel does all 341 00:11:54,220 --> 00:11:56,889 that copulatory to charge charges, 342 00:11:56,890 --> 00:11:58,299 quarter for your memory. So if you hit 343 00:11:58,300 --> 00:12:00,429 your quota, then that fails and sort 344 00:12:00,430 --> 00:12:02,499 of returns and fails. 345 00:12:02,500 --> 00:12:04,719 So a buffer to sort of the safe 346 00:12:04,720 --> 00:12:06,369 ish way of passing data around. 347 00:12:09,360 --> 00:12:11,459 Midnighters is the exact opposite 348 00:12:11,460 --> 00:12:13,559 it, the manager does nothing, the manager 349 00:12:13,560 --> 00:12:16,109 basically takes the data 350 00:12:16,110 --> 00:12:18,239 given to it as is, and 351 00:12:18,240 --> 00:12:20,339 sort of passed it on 352 00:12:20,340 --> 00:12:22,149 to your driver. So your input buffer, 353 00:12:22,150 --> 00:12:24,599 input buffer, you have a buffer 354 00:12:24,600 --> 00:12:26,489 there, just raw pointers or raw lengths 355 00:12:26,490 --> 00:12:28,739 that have not been validated and 356 00:12:28,740 --> 00:12:30,839 pass along to your driver. 357 00:12:30,840 --> 00:12:33,149 This is the endless source of windows, 358 00:12:33,150 --> 00:12:34,150 driver bugs. 359 00:12:35,190 --> 00:12:37,259 It's in my 360 00:12:37,260 --> 00:12:38,969 view, as a driver writer, you should 361 00:12:38,970 --> 00:12:40,509 avoid them at all costs. 362 00:12:40,510 --> 00:12:42,629 Unfortunately, that doesn't 363 00:12:42,630 --> 00:12:45,149 appear I mean, there's plenty people 364 00:12:45,150 --> 00:12:47,459 pulling drivers to due to stuff. 365 00:12:47,460 --> 00:12:49,559 And I mean, there's a perf benefit, 366 00:12:49,560 --> 00:12:52,170 but it's it's a huge drain on 367 00:12:53,220 --> 00:12:54,869 resources for security because you have 368 00:12:54,870 --> 00:12:56,730 to manually check everything yourself. 369 00:12:58,800 --> 00:13:00,750 So in order to just to sort of 370 00:13:02,220 --> 00:13:03,929 describe an indirect bit abstract, I 371 00:13:03,930 --> 00:13:06,029 first have to say something 372 00:13:06,030 --> 00:13:08,399 about these things called models 373 00:13:08,400 --> 00:13:10,109 and models. Basically, it's called a 374 00:13:10,110 --> 00:13:11,789 memory descriptivist and it's 375 00:13:12,870 --> 00:13:14,999 a data structure in the windows 376 00:13:15,000 --> 00:13:16,979 kernel that represents a buffer by its 377 00:13:16,980 --> 00:13:17,980 physical address. 378 00:13:19,200 --> 00:13:21,029 And I'm not going to discuss that because 379 00:13:21,030 --> 00:13:22,589 the terms are kind of opaque. 380 00:13:22,590 --> 00:13:25,139 But basically when scroll has APIs 381 00:13:25,140 --> 00:13:27,479 to create, modify, delete 382 00:13:27,480 --> 00:13:29,639 and consume these models 383 00:13:29,640 --> 00:13:31,379 so that you can go and say, OK, well, I 384 00:13:31,380 --> 00:13:33,509 have to this model that describes 385 00:13:33,510 --> 00:13:35,609 physical buffer. Now give 386 00:13:35,610 --> 00:13:37,109 me a kernel of virtual address for it, 387 00:13:37,110 --> 00:13:38,309 for example. And 388 00:13:39,480 --> 00:13:41,669 the I think it's 389 00:13:41,670 --> 00:13:43,349 the memory manager will do that for you 390 00:13:43,350 --> 00:13:45,689 and basically hands you back a pointer. 391 00:13:45,690 --> 00:13:47,069 Why is this important? It's important 392 00:13:47,070 --> 00:13:48,789 because in this particular case, where I 393 00:13:48,790 --> 00:13:50,579 go manager, pass the stuff back and 394 00:13:50,580 --> 00:13:52,919 forth, what usually happens is you have 395 00:13:52,920 --> 00:13:54,359 to do a double mapping. 396 00:13:54,360 --> 00:13:55,919 So what happens is the user goes to 397 00:13:55,920 --> 00:13:58,259 kernel to your manager and says, oh, 398 00:13:58,260 --> 00:14:00,449 I have this, this and this 399 00:14:00,450 --> 00:14:01,439 and this length. 400 00:14:01,440 --> 00:14:03,329 And no manager goes to it and says, OK, 401 00:14:03,330 --> 00:14:05,579 I'm going to create a model that 402 00:14:05,580 --> 00:14:07,349 sees what this Juland Pointer is and 403 00:14:07,350 --> 00:14:09,509 figures out what the physical 404 00:14:09,510 --> 00:14:10,649 memory by it is. 405 00:14:10,650 --> 00:14:13,249 And then you know, if it's one page 406 00:14:13,250 --> 00:14:15,329 it finds all the physical memory pages 407 00:14:15,330 --> 00:14:17,759 and sort of packets is up in the MDL 408 00:14:17,760 --> 00:14:20,129 and pass that off to your driver and then 409 00:14:20,130 --> 00:14:22,499 when a driver looks at it it'll come 410 00:14:22,500 --> 00:14:24,809 and say OK, now 411 00:14:24,810 --> 00:14:26,939 get me the kernel for traders 412 00:14:26,940 --> 00:14:28,739 for it. So you get to sort of double 413 00:14:28,740 --> 00:14:30,809 mapping in user and kernel 414 00:14:30,810 --> 00:14:33,419 that boat map to the same physical page. 415 00:14:33,420 --> 00:14:35,219 And the reason why you would do that is 416 00:14:35,220 --> 00:14:37,829 so you get these situations where 417 00:14:37,830 --> 00:14:39,239 you have to copy large amounts of data 418 00:14:39,240 --> 00:14:41,399 around because you're using models. 419 00:14:41,400 --> 00:14:43,499 You now have zero copy as you 420 00:14:43,500 --> 00:14:45,419 get a huge, huge perf increase. 421 00:14:47,700 --> 00:14:49,799 Essentially, that's if you draw them as 422 00:14:49,800 --> 00:14:50,909 paint, that's what it looks like. 423 00:14:54,090 --> 00:14:56,219 Yeah, and so this is done 424 00:14:56,220 --> 00:14:58,379 for for Perth and you get zero copy. 425 00:14:58,380 --> 00:15:00,089 Additionally, you know, you have no pain 426 00:15:00,090 --> 00:15:01,289 of probing and try except 427 00:15:02,400 --> 00:15:04,799 and so there are definitely upsides 428 00:15:04,800 --> 00:15:06,869 stem there's also downsides to it. 429 00:15:06,870 --> 00:15:08,279 And I'll get to that later. 430 00:15:09,660 --> 00:15:11,549 But essentially, now that I've you have 431 00:15:11,550 --> 00:15:13,659 an idea when ideals are basically about 432 00:15:13,660 --> 00:15:15,449 indirect metal objects or these things 433 00:15:15,450 --> 00:15:16,919 where that indirect sort of the 434 00:15:18,000 --> 00:15:19,619 the input is going to be Namgyal. 435 00:15:19,620 --> 00:15:21,689 And so when 436 00:15:21,690 --> 00:15:22,799 your driver takes input and starts 437 00:15:22,800 --> 00:15:24,839 reading from it, it'll come from MDL. 438 00:15:24,840 --> 00:15:26,399 And when you spit out, it's going to be 439 00:15:26,400 --> 00:15:28,379 the exact opposite, where it's like once 440 00:15:28,380 --> 00:15:29,699 you drive, it generates output. 441 00:15:29,700 --> 00:15:32,069 You just put it to an MDL and then 442 00:15:32,070 --> 00:15:33,769 user automatically basically gets it. 443 00:15:34,890 --> 00:15:36,359 In short, that's what these things are. 444 00:15:38,040 --> 00:15:40,319 OK, so this sort of my last slide 445 00:15:40,320 --> 00:15:42,419 four part one. So I hope I 446 00:15:42,420 --> 00:15:43,679 wasn't too confusing. You know, I ran 447 00:15:43,680 --> 00:15:45,569 through it really fast, but it's because 448 00:15:45,570 --> 00:15:47,219 the next section is really where all the 449 00:15:47,220 --> 00:15:48,220 cool stuff is. 450 00:15:49,050 --> 00:15:51,529 But so most of the stuff 451 00:15:51,530 --> 00:15:53,969 I talked about or we'll talk about is 452 00:15:53,970 --> 00:15:56,069 WDM model, which is older 453 00:15:56,070 --> 00:15:58,019 and so came the F is this new COL old 454 00:15:58,020 --> 00:15:59,020 driver framework. 455 00:16:00,060 --> 00:16:02,459 And it's part of what's called a WDEF, 456 00:16:02,460 --> 00:16:04,769 which is something 457 00:16:04,770 --> 00:16:06,449 drive a framework. 458 00:16:06,450 --> 00:16:08,609 And basically this thing was made 459 00:16:08,610 --> 00:16:10,739 sort of it was designed based 460 00:16:10,740 --> 00:16:12,929 upon learning mistakes from 461 00:16:12,930 --> 00:16:15,079 the WDM world. 462 00:16:15,080 --> 00:16:16,469 A lot of that has to do with power 463 00:16:16,470 --> 00:16:19,079 management and things like that, but 464 00:16:19,080 --> 00:16:20,699 also for security. 465 00:16:20,700 --> 00:16:23,189 A few things became apparent 466 00:16:23,190 --> 00:16:26,099 and that sort of made easier to 467 00:16:26,100 --> 00:16:28,499 do and using CDV 468 00:16:28,500 --> 00:16:30,569 and so in general can make it easier to 469 00:16:30,570 --> 00:16:32,759 write, write drivers and less 470 00:16:32,760 --> 00:16:34,710 likely to introduce bugs. 471 00:16:35,850 --> 00:16:37,949 But it is layered over the 472 00:16:37,950 --> 00:16:40,679 same infrastructure that's WDM Soyuzes. 473 00:16:40,680 --> 00:16:42,899 That is to say, if you don't understand 474 00:16:42,900 --> 00:16:44,999 the old model, you're still 475 00:16:45,000 --> 00:16:47,189 going to have sort of these implicit CDV 476 00:16:47,190 --> 00:16:48,190 bugs. 477 00:16:49,620 --> 00:16:51,539 But in general, it does make it harder to 478 00:16:51,540 --> 00:16:52,889 have bugs. 479 00:16:52,890 --> 00:16:54,869 And so what example, security wise is a 480 00:16:54,870 --> 00:16:55,870 great one is where 481 00:16:57,240 --> 00:16:59,099 it strongly discourages the use of 482 00:16:59,100 --> 00:17:00,779 passing, usually pointed directly to 483 00:17:00,780 --> 00:17:02,849 kernel. And in fact, so they have this 484 00:17:02,850 --> 00:17:05,098 set of APIs to sort of extract data 485 00:17:05,099 --> 00:17:06,099 out of the requests. 486 00:17:07,170 --> 00:17:08,939 So one of them is IDF 487 00:17:10,240 --> 00:17:12,659 request, retrieve input buffer. 488 00:17:12,660 --> 00:17:14,969 And if you have met with Bufford or 489 00:17:14,970 --> 00:17:17,219 Indirect Directorate out direct, 490 00:17:17,220 --> 00:17:19,019 that API will just go grab the pointers 491 00:17:19,020 --> 00:17:19,979 for you. 492 00:17:19,980 --> 00:17:21,779 But if using neither, that API will 493 00:17:21,780 --> 00:17:23,009 totally fail. 494 00:17:23,010 --> 00:17:25,019 And if you must use Midnighter, then you 495 00:17:25,020 --> 00:17:27,318 have to call this new API called 496 00:17:27,319 --> 00:17:29,939 Davydov request retrieve unsafe 497 00:17:29,940 --> 00:17:31,739 user input buffer. 498 00:17:31,740 --> 00:17:33,869 And that, I mean pretty explicitly tells 499 00:17:33,870 --> 00:17:34,920 you that it's unsafe 500 00:17:36,210 --> 00:17:37,710 and and so 501 00:17:38,760 --> 00:17:40,739 that's what these things were. You know, 502 00:17:40,740 --> 00:17:43,229 they really knew that using these 503 00:17:43,230 --> 00:17:45,719 methods, Niederer things are horrible. 504 00:17:45,720 --> 00:17:47,159 And so they made it really hard for you 505 00:17:47,160 --> 00:17:48,389 to use it. 506 00:17:48,390 --> 00:17:50,009 And so if you do use it, you know, the 507 00:17:50,010 --> 00:17:51,239 names very explicitly tell you that 508 00:17:51,240 --> 00:17:52,240 things are unsafe. 509 00:17:53,760 --> 00:17:55,619 So and generally as a private developer, 510 00:17:55,620 --> 00:17:58,200 you're encouraged to use KDAF over WDM. 511 00:17:59,340 --> 00:18:00,569 And the cool thing about Kim, you have 512 00:18:00,570 --> 00:18:02,999 said, is actually open source. 513 00:18:03,000 --> 00:18:04,799 Earlier this year, Microsoft slapped an 514 00:18:04,800 --> 00:18:06,689 MIT license on it and put it on GitHub 515 00:18:07,800 --> 00:18:09,899 and about 90 percent of code 516 00:18:09,900 --> 00:18:11,159 is there. 517 00:18:11,160 --> 00:18:12,479 There's tiny bits and pieces still 518 00:18:12,480 --> 00:18:14,969 missing. The reader isn't there yet, 519 00:18:14,970 --> 00:18:17,129 but by and large, the guts 520 00:18:17,130 --> 00:18:19,739 of Kamdar for totally available 521 00:18:19,740 --> 00:18:22,499 under a 522 00:18:22,500 --> 00:18:24,059 free software license, I guess. 523 00:18:25,770 --> 00:18:27,269 And if you want, you can totally take a 524 00:18:27,270 --> 00:18:29,459 look at them. OK, so we get 525 00:18:29,460 --> 00:18:31,559 out of the way. Let's dove 526 00:18:31,560 --> 00:18:34,379 into these lots of 527 00:18:34,380 --> 00:18:35,959 windows. Drivers attack surface. 528 00:18:37,470 --> 00:18:39,599 So basically, pilots, 529 00:18:39,600 --> 00:18:41,699 when you look at the 530 00:18:41,700 --> 00:18:43,769 sort of bugs you have in a 531 00:18:43,770 --> 00:18:45,059 driver, there's sort of three things that 532 00:18:45,060 --> 00:18:46,349 come up right. 533 00:18:46,350 --> 00:18:47,879 They can be elevation of privilege, bugs, 534 00:18:47,880 --> 00:18:49,049 you know, like a buffer overflow or 535 00:18:49,050 --> 00:18:50,219 something like it. 536 00:18:50,220 --> 00:18:52,169 They can be the service right, where you 537 00:18:52,170 --> 00:18:54,569 get a kernel panic 538 00:18:54,570 --> 00:18:57,419 or a deadlock or, 539 00:18:57,420 --> 00:18:59,519 you know, resource starvation type of 540 00:18:59,520 --> 00:19:00,869 attacks. 541 00:19:00,870 --> 00:19:02,309 And the third one is where you get 542 00:19:02,310 --> 00:19:03,809 information leaks. Right. By and large, 543 00:19:03,810 --> 00:19:05,669 those are the ones you would see when you 544 00:19:05,670 --> 00:19:07,919 look for security, implementation, bugs 545 00:19:07,920 --> 00:19:10,169 in drivers. 546 00:19:10,170 --> 00:19:12,629 And so that's sort of the bylaws, 547 00:19:12,630 --> 00:19:15,659 the kind of things that I'll talk about 548 00:19:15,660 --> 00:19:17,429 specifically things that I'm not covering 549 00:19:17,430 --> 00:19:19,949 are exploitation or bypassing 550 00:19:19,950 --> 00:19:21,689 of mitigations. 551 00:19:21,690 --> 00:19:23,189 For the most part, there's bits and 552 00:19:23,190 --> 00:19:24,929 pieces where I'll sort of mentioned some 553 00:19:24,930 --> 00:19:27,089 of that. But by and large, I'm 554 00:19:27,090 --> 00:19:28,769 working from the assumption that bugs are 555 00:19:28,770 --> 00:19:29,770 going to be exportable, 556 00:19:31,260 --> 00:19:32,729 if that's what we're looking for. 557 00:19:32,730 --> 00:19:34,469 I mean, this is an exploitation talk, 558 00:19:34,470 --> 00:19:35,939 which is what I pretty much start off 559 00:19:35,940 --> 00:19:37,379 with saying. 560 00:19:37,380 --> 00:19:39,449 So I won't be focusing on 561 00:19:39,450 --> 00:19:41,369 exploitation. I will instead be focusing 562 00:19:41,370 --> 00:19:43,829 on sort of finding identifying 563 00:19:43,830 --> 00:19:45,959 these type of bugs and sort 564 00:19:45,960 --> 00:19:48,299 of developer guidance on how to fix 565 00:19:48,300 --> 00:19:49,300 those kind of issues. 566 00:19:51,060 --> 00:19:52,399 The other thing is that I. I'm assuming 567 00:19:52,400 --> 00:19:54,589 that you guys have a basic understanding 568 00:19:54,590 --> 00:19:56,749 of, you know, native code security, 569 00:19:56,750 --> 00:19:58,819 so I, I won't discuss, you 570 00:19:58,820 --> 00:20:00,949 know, the standard buffer overflow 571 00:20:00,950 --> 00:20:03,139 or integer overflow or, you know, 572 00:20:03,140 --> 00:20:04,599 what it means if you haven't unveiled it. 573 00:20:04,600 --> 00:20:06,319 Lynnfield, I'm assuming those things are 574 00:20:06,320 --> 00:20:07,759 understood. 575 00:20:07,760 --> 00:20:09,259 Same thing for, you know, C++ type of 576 00:20:09,260 --> 00:20:10,809 bugs or those kinds of things. 577 00:20:12,500 --> 00:20:14,479 So just because I said I was going to 578 00:20:14,480 --> 00:20:16,549 cover intro flows, I lied. 579 00:20:16,550 --> 00:20:17,689 I am actually going to say something 580 00:20:17,690 --> 00:20:20,989 about them specifically because 581 00:20:20,990 --> 00:20:22,519 in the Windows kernel, you actually have 582 00:20:22,520 --> 00:20:24,709 these APIs to help you 583 00:20:24,710 --> 00:20:26,569 not have of those, they'll they'll have a 584 00:20:26,570 --> 00:20:28,699 set of APIs you can use. 585 00:20:28,700 --> 00:20:30,799 And if you are driver developers, 586 00:20:30,800 --> 00:20:32,449 you are encouraged to use them, even 587 00:20:32,450 --> 00:20:34,039 though I haven't seen them all that often 588 00:20:34,040 --> 00:20:35,249 and you should in fact use them. 589 00:20:35,250 --> 00:20:38,119 But when you use these APIs, 590 00:20:38,120 --> 00:20:40,189 you should sort of there is 591 00:20:40,190 --> 00:20:42,019 still potential for misuse. 592 00:20:42,020 --> 00:20:44,409 And basically when you use the APIs, 593 00:20:44,410 --> 00:20:45,529 there's sort of the three things you 594 00:20:45,530 --> 00:20:47,659 should always or never do 595 00:20:47,660 --> 00:20:49,579 is always take your term value, always 596 00:20:49,580 --> 00:20:51,799 passing the exact type and 597 00:20:51,800 --> 00:20:53,899 always you never 598 00:20:53,900 --> 00:20:55,829 do it when path parameters, because when 599 00:20:55,830 --> 00:20:57,109 you do any of those three things, you're 600 00:20:57,110 --> 00:20:58,639 basically sort of reintroducing your 601 00:20:58,640 --> 00:21:00,799 initial issues when you're trying 602 00:21:00,800 --> 00:21:03,289 to use these new APIs and have examples 603 00:21:03,290 --> 00:21:04,639 of this stuff. 604 00:21:04,640 --> 00:21:06,079 But for in the interest of time, I'm sort 605 00:21:06,080 --> 00:21:07,879 of just going to return really fast 606 00:21:07,880 --> 00:21:09,949 basically to stuff on the left is wrong 607 00:21:09,950 --> 00:21:12,109 and the stuff on the right is correct. 608 00:21:13,130 --> 00:21:14,749 So there's nothing left to sort of see. 609 00:21:14,750 --> 00:21:16,249 Here's how to use the API is wrong and 610 00:21:16,250 --> 00:21:17,809 here's how to use the correct use of the 611 00:21:17,810 --> 00:21:18,810 APIs. 612 00:21:20,850 --> 00:21:22,559 OK, so basically now I come down to sort 613 00:21:22,560 --> 00:21:24,689 of what it it is, I sort of 614 00:21:24,690 --> 00:21:26,759 sat down and sort of, you 615 00:21:26,760 --> 00:21:28,949 know, looked over, you know, what most 616 00:21:28,950 --> 00:21:31,199 common screwy bugs are in drivers 617 00:21:31,200 --> 00:21:33,749 and sort of try to figure out 618 00:21:33,750 --> 00:21:35,999 if, like, what's the common 619 00:21:36,000 --> 00:21:37,349 theme around all this? And they came up 620 00:21:37,350 --> 00:21:39,959 with this idea where there's five 621 00:21:39,960 --> 00:21:42,359 things that almost that most drivers 622 00:21:42,360 --> 00:21:44,429 will do if they're 623 00:21:44,430 --> 00:21:46,829 talking to use land where there's 624 00:21:46,830 --> 00:21:49,109 potential for attack surface and 625 00:21:49,110 --> 00:21:51,449 we have some kind of entry point. 626 00:21:51,450 --> 00:21:53,579 And basically it comes down to 627 00:21:53,580 --> 00:21:55,709 when you create a device, when 628 00:21:55,710 --> 00:21:57,419 you talk to your manager, when you handle 629 00:21:57,420 --> 00:21:59,579 data, when you 630 00:21:59,580 --> 00:22:00,929 interact with the memory manager, and 631 00:22:00,930 --> 00:22:02,519 when you interact with the object 632 00:22:02,520 --> 00:22:04,919 manager. By and large, those 633 00:22:04,920 --> 00:22:05,920 five areas, 634 00:22:07,680 --> 00:22:09,809 a driver will if they talk to 635 00:22:09,810 --> 00:22:12,089 user, those are the five big areas 636 00:22:12,090 --> 00:22:14,189 where you have attack surface. 637 00:22:14,190 --> 00:22:16,259 I mean, there's it's not you know, I 638 00:22:16,260 --> 00:22:17,489 mean, there can be other ways to. 639 00:22:17,490 --> 00:22:19,889 But by large, it's my 640 00:22:19,890 --> 00:22:22,089 view it's it's those five. 641 00:22:22,090 --> 00:22:23,279 And so basically I sort of 642 00:22:24,690 --> 00:22:26,639 structured my next set of slides around 643 00:22:26,640 --> 00:22:28,139 these five areas. And for each one of 644 00:22:28,140 --> 00:22:30,329 these five, basically, 645 00:22:30,330 --> 00:22:32,039 I'll discuss a few things that I've seen 646 00:22:32,040 --> 00:22:33,329 gone wrong and do. 647 00:22:33,330 --> 00:22:35,159 And so all of the first set of slides and 648 00:22:35,160 --> 00:22:37,349 a cute little icon on the left top 649 00:22:37,350 --> 00:22:39,329 that indicates this is a bug and then a 650 00:22:39,330 --> 00:22:40,859 cute little icon with some tools that 651 00:22:40,860 --> 00:22:42,989 says this is a fix, but 652 00:22:42,990 --> 00:22:44,399 biological by these five. 653 00:22:44,400 --> 00:22:45,959 And if three twenty five, there's a 654 00:22:45,960 --> 00:22:48,029 couple of cases that I cover. 655 00:22:48,030 --> 00:22:49,379 So with that, let's start with device 656 00:22:49,380 --> 00:22:50,759 creation. Right. 657 00:22:50,760 --> 00:22:52,740 As I showed earlier in the. 658 00:22:54,210 --> 00:22:56,279 And the sample driver 659 00:22:56,280 --> 00:22:58,229 is when you create a device, you 660 00:22:58,230 --> 00:23:00,669 basically have to API calls, 661 00:23:00,670 --> 00:23:02,339 which is IO create device or you create a 662 00:23:02,340 --> 00:23:04,379 device secure and your driver basically 663 00:23:04,380 --> 00:23:06,569 goes to jail and says, please create 664 00:23:06,570 --> 00:23:07,570 a device for me. 665 00:23:08,400 --> 00:23:11,219 And when you do that, 666 00:23:11,220 --> 00:23:12,689 you can pass. 667 00:23:12,690 --> 00:23:14,309 You can say, OK, these are the access 668 00:23:14,310 --> 00:23:16,259 controls that I want on it. 669 00:23:16,260 --> 00:23:17,879 And there's two ways of doing that. 670 00:23:17,880 --> 00:23:19,919 Right? One is you call, I'll create 671 00:23:19,920 --> 00:23:22,019 device secure and you 672 00:23:22,020 --> 00:23:24,299 can passerelle what's called 673 00:23:24,300 --> 00:23:25,410 Eskdale String, which is 674 00:23:27,130 --> 00:23:28,649 a string representation of a security 675 00:23:28,650 --> 00:23:30,869 descriptor, which basically says who 676 00:23:30,870 --> 00:23:32,669 can and can't access the device under 677 00:23:32,670 --> 00:23:33,670 what conditions? 678 00:23:34,600 --> 00:23:36,269 If you don't call, you create device the 679 00:23:36,270 --> 00:23:38,369 other way, do it is the you 680 00:23:38,370 --> 00:23:40,469 specify the SDL string 681 00:23:40,470 --> 00:23:41,759 and design file that comes with your 682 00:23:41,760 --> 00:23:43,859 driver and 683 00:23:43,860 --> 00:23:45,690 then that will be applied 684 00:23:47,190 --> 00:23:49,349 by your manager when when 685 00:23:49,350 --> 00:23:50,700 somebody tries to connect your device. 686 00:23:52,950 --> 00:23:54,179 Commonly, though, these things are 687 00:23:54,180 --> 00:23:56,549 missing, you'll see a lot of drivers 688 00:23:56,550 --> 00:23:57,550 that they'll call 689 00:23:59,100 --> 00:24:01,379 just AOK device and they won't 690 00:24:01,380 --> 00:24:02,439 specify. 691 00:24:02,440 --> 00:24:04,649 That's the also, you know, if you fall 692 00:24:04,650 --> 00:24:07,379 back to ETRE, you know, default 693 00:24:07,380 --> 00:24:08,380 or sort of 694 00:24:09,660 --> 00:24:11,400 an actual that's too wide. 695 00:24:14,040 --> 00:24:16,499 This is just a common sort of simple 696 00:24:16,500 --> 00:24:18,869 design problem that you see with drivers 697 00:24:18,870 --> 00:24:20,939 that are thrown together too fast. 698 00:24:23,250 --> 00:24:25,349 Basically, the IDs that you just sit 699 00:24:25,350 --> 00:24:27,479 down to sort of try to figure out who 700 00:24:27,480 --> 00:24:29,489 needs to device and under what 701 00:24:29,490 --> 00:24:30,989 circumstances. 702 00:24:30,990 --> 00:24:33,089 And I mean, it it has value 703 00:24:33,090 --> 00:24:35,309 to sit down and really think about this, 704 00:24:35,310 --> 00:24:37,379 because what you're doing is you're you 705 00:24:37,380 --> 00:24:39,359 can try to reduce cruel tax surface. 706 00:24:39,360 --> 00:24:40,349 Right. 707 00:24:40,350 --> 00:24:42,479 And so one good, you know, 708 00:24:42,480 --> 00:24:44,639 proper engineering example would be to 709 00:24:44,640 --> 00:24:46,919 sort of sit down and say, OK, well, 710 00:24:46,920 --> 00:24:48,599 we have to set up high schools that 711 00:24:48,600 --> 00:24:50,069 really an admin should only ever need to 712 00:24:50,070 --> 00:24:51,449 do. So we're going to do is we will 713 00:24:51,450 --> 00:24:53,459 create it will create a driver that is 714 00:24:53,460 --> 00:24:54,929 only accessible by admin. 715 00:24:54,930 --> 00:24:56,099 And then what we'll do is we'll create a 716 00:24:56,100 --> 00:24:57,869 service on top of that that you can and 717 00:24:57,870 --> 00:24:59,969 talk to through UDP 718 00:24:59,970 --> 00:25:01,139 or whatever. 719 00:25:01,140 --> 00:25:02,729 And then they have the service sort of 720 00:25:02,730 --> 00:25:04,829 reroute things to tell 721 00:25:04,830 --> 00:25:05,830 you what it needs to. 722 00:25:07,050 --> 00:25:08,850 So in that example, you know, the 723 00:25:11,520 --> 00:25:12,749 the downside of that is that, you know, 724 00:25:12,750 --> 00:25:14,759 you have to write more code and you may 725 00:25:14,760 --> 00:25:16,709 get some performance degradation. 726 00:25:16,710 --> 00:25:18,779 But the upside is you get, you 727 00:25:18,780 --> 00:25:21,029 know, extra security and probably, 728 00:25:21,030 --> 00:25:22,700 you know, better reliability as well. 729 00:25:23,760 --> 00:25:25,139 So that that that's one solution. 730 00:25:25,140 --> 00:25:26,400 But the idea is basically that 731 00:25:27,810 --> 00:25:30,299 this is this is usually a design 732 00:25:30,300 --> 00:25:32,429 question was like, OK, who really needs 733 00:25:32,430 --> 00:25:34,769 access to our device and then and 734 00:25:34,770 --> 00:25:35,770 why write? 735 00:25:37,200 --> 00:25:39,389 OK, so with that said, let's move 736 00:25:39,390 --> 00:25:40,799 on to some more important stuff for 737 00:25:40,800 --> 00:25:41,800 device creation. 738 00:25:44,130 --> 00:25:46,079 When you create this device, you call 739 00:25:46,080 --> 00:25:48,239 this AOK device API, and 740 00:25:48,240 --> 00:25:49,829 basically you're allowed to pass these 741 00:25:49,830 --> 00:25:51,329 device characteristics into it. 742 00:25:52,470 --> 00:25:54,659 And it basically there's one bit in 743 00:25:54,660 --> 00:25:56,879 there, which is this thing called Phyll 744 00:25:56,880 --> 00:25:59,189 Device, Secure, Open and 745 00:25:59,190 --> 00:26:00,629 has very special meaning. 746 00:26:00,630 --> 00:26:03,269 So basically, when you create a device in 747 00:26:03,270 --> 00:26:05,519 the windows call by default, your 748 00:26:05,520 --> 00:26:07,469 manager will always assume that it is 749 00:26:07,470 --> 00:26:09,449 filesystem device. 750 00:26:09,450 --> 00:26:11,549 And what that means is that, you know, 751 00:26:11,550 --> 00:26:14,099 when you open the device, the 752 00:26:14,100 --> 00:26:15,449 manager basically assumes that it has, 753 00:26:15,450 --> 00:26:17,069 you know, directories and files. 754 00:26:18,090 --> 00:26:20,039 And so if you do, instead of you open the 755 00:26:20,040 --> 00:26:22,049 files, you say device file, 756 00:26:23,130 --> 00:26:24,749 I imagine looks at it and says, oh, I 757 00:26:24,750 --> 00:26:25,679 don't have to apply. 758 00:26:25,680 --> 00:26:27,839 The ackles here to filesystem has to do 759 00:26:27,840 --> 00:26:29,789 it. I'll just go to the custom device and 760 00:26:29,790 --> 00:26:31,409 let the first device handle it. 761 00:26:31,410 --> 00:26:32,759 And that works really well if you're a 762 00:26:32,760 --> 00:26:34,439 filesystem driver. 763 00:26:34,440 --> 00:26:35,999 But if you're not a fast driver, which 764 00:26:36,000 --> 00:26:37,130 most drivers are, 765 00:26:38,520 --> 00:26:40,589 so if you're not a fast driver, all 766 00:26:40,590 --> 00:26:42,899 of a sudden you have this problem where 767 00:26:42,900 --> 00:26:44,369 your manager thinks you are and it 768 00:26:44,370 --> 00:26:46,499 doesn't it won't apply your ackles 769 00:26:46,500 --> 00:26:47,969 and the hands it off to you, but you're 770 00:26:47,970 --> 00:26:49,379 not checking your meter. 771 00:26:49,380 --> 00:26:51,509 And so all of a sudden, if you 772 00:26:51,510 --> 00:26:52,949 don't set this particular flag and you're 773 00:26:52,950 --> 00:26:55,019 not a filesystem driver, 774 00:26:55,020 --> 00:26:57,329 you have to sort of bydesign automatic 775 00:26:57,330 --> 00:26:59,489 echo acall, bypass problem. 776 00:27:00,800 --> 00:27:03,059 And so that's why pretty much 777 00:27:03,060 --> 00:27:05,429 every time you create a driver 778 00:27:05,430 --> 00:27:07,559 and you're not a fast and driver, you 779 00:27:07,560 --> 00:27:09,599 should really, really set this flag. 780 00:27:10,860 --> 00:27:12,719 And it's bizarre because it's actually 781 00:27:12,720 --> 00:27:14,849 documented and there's a lot of a lot 782 00:27:14,850 --> 00:27:16,280 of drivers that are not doing this. 783 00:27:17,670 --> 00:27:19,889 And what's really funny is that this bug 784 00:27:19,890 --> 00:27:22,859 is incredibly, incredibly easy to find. 785 00:27:22,860 --> 00:27:24,269 There's a tool out there called Device 786 00:27:24,270 --> 00:27:26,369 Tree, and it enumerates all of your 787 00:27:26,370 --> 00:27:28,439 devices. And you click on it and 788 00:27:28,440 --> 00:27:30,299 you basically it allows you it's kind of 789 00:27:30,300 --> 00:27:31,799 hard to see there, but you can basically 790 00:27:31,800 --> 00:27:33,869 see who see what the Ackles are. 791 00:27:33,870 --> 00:27:36,359 And then it also says, what are this? 792 00:27:36,360 --> 00:27:38,039 Files of obscure flag is set. 793 00:27:38,040 --> 00:27:40,079 And so if the flag isn't set 794 00:27:41,160 --> 00:27:42,749 and Ackles basically say, oh, this all 795 00:27:42,750 --> 00:27:44,969 the admin, then, 796 00:27:44,970 --> 00:27:47,069 you know, you most likely 797 00:27:47,070 --> 00:27:48,209 have a security bug right there. 798 00:27:48,210 --> 00:27:49,709 And it's like it's one click away. 799 00:27:49,710 --> 00:27:50,710 It's easy to find. 800 00:27:51,810 --> 00:27:53,699 So what's the fix for this one? 801 00:27:53,700 --> 00:27:56,159 Basically always used the flag. 802 00:27:56,160 --> 00:27:58,499 Unless you are very specifically 803 00:27:58,500 --> 00:28:00,869 building a some driver, 804 00:28:00,870 --> 00:28:02,640 you should always, always set this flag. 805 00:28:03,870 --> 00:28:05,879 That's the general rule. 806 00:28:05,880 --> 00:28:07,769 Now, some people go, well, you know, you 807 00:28:07,770 --> 00:28:09,209 don't have this flag. 808 00:28:09,210 --> 00:28:11,639 You can sort of make your own 809 00:28:11,640 --> 00:28:13,709 create dispatch, call back and 810 00:28:13,710 --> 00:28:15,839 sort of do it in there. And and, yes, you 811 00:28:15,840 --> 00:28:16,840 absolutely can. 812 00:28:17,880 --> 00:28:20,069 You probably shouldn't because, A, 813 00:28:20,070 --> 00:28:21,689 you're now adding more attacks surface, 814 00:28:21,690 --> 00:28:23,369 even though this functionality is already 815 00:28:23,370 --> 00:28:25,469 there. And Windows Squirtle just 816 00:28:25,470 --> 00:28:28,109 set that one bit and you get it for free 817 00:28:28,110 --> 00:28:30,419 too is if you do 818 00:28:30,420 --> 00:28:32,609 do it yourself there there's 819 00:28:32,610 --> 00:28:35,069 a few intricate sort of little things 820 00:28:35,070 --> 00:28:37,409 that you want to try and mimic 821 00:28:37,410 --> 00:28:38,849 exactly what your manager does in that 822 00:28:38,850 --> 00:28:39,989 case. 823 00:28:39,990 --> 00:28:41,069 Otherwise, you know, you get these sort 824 00:28:41,070 --> 00:28:44,549 of, you know, sort of discrepancies. 825 00:28:44,550 --> 00:28:46,529 So, yes, you can't do that. 826 00:28:46,530 --> 00:28:48,569 But unless you're doing a fast driver, 827 00:28:48,570 --> 00:28:49,680 probably shouldn't. 828 00:28:51,790 --> 00:28:54,129 Yes, that's one of five, so the second 829 00:28:54,130 --> 00:28:56,889 second of the five I had is basically 830 00:28:56,890 --> 00:28:59,109 so working with your 831 00:28:59,110 --> 00:29:01,059 manager and the first case I had is sort 832 00:29:01,060 --> 00:29:03,159 of a simple one. But this is this 833 00:29:03,160 --> 00:29:04,479 is a pretty common one. 834 00:29:04,480 --> 00:29:06,519 I've seen in a bunch of drivers where 835 00:29:06,520 --> 00:29:08,799 basically you'll have some like 836 00:29:08,800 --> 00:29:11,949 I will call back and it will be 837 00:29:11,950 --> 00:29:14,349 out direct and 838 00:29:14,350 --> 00:29:16,659 it'll say, OK, well, we'll use the 839 00:29:16,660 --> 00:29:17,529 MDL address. 840 00:29:17,530 --> 00:29:19,749 So we'll sort of get our 841 00:29:20,890 --> 00:29:23,349 due to get systematize from the safe 842 00:29:23,350 --> 00:29:25,659 and we get our kernel pointer out of it 843 00:29:25,660 --> 00:29:27,309 all without ever checking if that pointer 844 00:29:27,310 --> 00:29:29,469 can be no, it can be null 845 00:29:29,470 --> 00:29:31,869 by, you know, by sheer 846 00:29:31,870 --> 00:29:33,339 the fact that the way it works is that 847 00:29:33,340 --> 00:29:35,229 that pointer can absolutely be null. 848 00:29:35,230 --> 00:29:37,459 And so before you ever touch and address, 849 00:29:37,460 --> 00:29:40,389 you should check it for being an opener 850 00:29:40,390 --> 00:29:41,709 at this one in a case where it could 851 00:29:41,710 --> 00:29:44,140 happen as if it's a zero sized buffer. 852 00:29:45,700 --> 00:29:48,129 If you're not doing that, 853 00:29:48,130 --> 00:29:50,679 then you may very well have 854 00:29:50,680 --> 00:29:53,299 a bug check or or worse. 855 00:29:53,300 --> 00:29:55,539 And I'll talk about that later. 856 00:29:55,540 --> 00:29:57,849 But the idea is that if 857 00:29:57,850 --> 00:30:00,039 you're doing Adric, 858 00:30:00,040 --> 00:30:01,779 check your embryologists before you use 859 00:30:01,780 --> 00:30:03,849 it, which is to 860 00:30:03,850 --> 00:30:06,189 fix great sort of second 861 00:30:06,190 --> 00:30:07,809 sort of problem. 862 00:30:07,810 --> 00:30:10,029 Yeshe in the manager 863 00:30:10,030 --> 00:30:11,030 class is 864 00:30:12,100 --> 00:30:13,509 using that Bufford. 865 00:30:13,510 --> 00:30:15,819 I discussed Method Bufford before 866 00:30:15,820 --> 00:30:18,309 and I said it is the sort of safer option 867 00:30:18,310 --> 00:30:19,420 and it is. 868 00:30:20,500 --> 00:30:22,449 But there's still something you should 869 00:30:22,450 --> 00:30:24,669 know is a is similar with the 870 00:30:24,670 --> 00:30:27,039 email address. Is that the pointer 871 00:30:27,040 --> 00:30:29,209 you are given from the driver 872 00:30:29,210 --> 00:30:30,400 spectrum in Europe 873 00:30:31,570 --> 00:30:33,769 for Bufford is this 874 00:30:33,770 --> 00:30:36,429 social system buffer 875 00:30:36,430 --> 00:30:38,529 and the problem is similar to the email 876 00:30:38,530 --> 00:30:40,689 address where that point can also 877 00:30:40,690 --> 00:30:41,079 be null. 878 00:30:41,080 --> 00:30:42,129 So the first thing you should do is 879 00:30:42,130 --> 00:30:43,929 always, always check, make sure it's not 880 00:30:43,930 --> 00:30:44,859 know. 881 00:30:44,860 --> 00:30:47,679 The other thing, Whitmont, a Bufford, is 882 00:30:47,680 --> 00:30:49,839 that even though it is the safer 883 00:30:49,840 --> 00:30:52,299 or I guess the safest method 884 00:30:52,300 --> 00:30:54,789 of 04 is that 885 00:30:54,790 --> 00:30:56,559 because it's seen that way, you get the 886 00:30:56,560 --> 00:30:58,929 sort of false sense of security 887 00:30:58,930 --> 00:31:01,239 in that while, you know, Proby 888 00:31:01,240 --> 00:31:03,519 and capturing of the whole buffer happens 889 00:31:03,520 --> 00:31:04,899 for you. 890 00:31:04,900 --> 00:31:06,819 Any and all of the content inside of that 891 00:31:06,820 --> 00:31:08,919 buffer still needs, depending on what it 892 00:31:08,920 --> 00:31:11,169 is, still needs any kind of validation. 893 00:31:11,170 --> 00:31:13,149 Right. And so there's a set of developers 894 00:31:13,150 --> 00:31:14,769 that'll say, oh, I'm at a Bufford, cool, 895 00:31:14,770 --> 00:31:16,179 we're good. We don't need to end security 896 00:31:16,180 --> 00:31:17,319 checking. 897 00:31:17,320 --> 00:31:18,339 And then, you know, they'll have some 898 00:31:18,340 --> 00:31:20,049 kind of a better Lynnfield that are never 899 00:31:20,050 --> 00:31:21,999 validated and used to copy stuff around. 900 00:31:22,000 --> 00:31:23,439 And, you know, all of sudden you get 901 00:31:23,440 --> 00:31:24,689 memory. Corruption's left and right. 902 00:31:26,110 --> 00:31:27,310 So, yeah, the idea would 903 00:31:30,470 --> 00:31:32,829 buffer is that a validate for null 904 00:31:32,830 --> 00:31:35,379 and B, all the embedded content 905 00:31:35,380 --> 00:31:36,820 still has to be validated. 906 00:31:38,900 --> 00:31:40,819 One of my one of my all time sort of pet 907 00:31:40,820 --> 00:31:43,639 peeves or criddle bugs, is this 908 00:31:43,640 --> 00:31:45,949 basically once let's 909 00:31:45,950 --> 00:31:46,950 say you get octal. 910 00:31:48,160 --> 00:31:49,779 And you do all the work and everything 911 00:31:49,780 --> 00:31:51,609 and you're successful in the actual was 912 00:31:51,610 --> 00:31:53,679 completed correctly and you're about to 913 00:31:53,680 --> 00:31:55,959 sort of return and you you 914 00:31:55,960 --> 00:31:57,579 basically there's a field in the in 915 00:31:57,580 --> 00:31:59,709 Europe that says your status and 916 00:31:59,710 --> 00:32:01,119 you basically say, OK, I had status 917 00:32:01,120 --> 00:32:02,049 success. 918 00:32:02,050 --> 00:32:03,449 And then there's a single I use that 919 00:32:03,450 --> 00:32:04,899 information and information. 920 00:32:04,900 --> 00:32:06,249 It's basically an integer. 921 00:32:06,250 --> 00:32:08,229 And in the case of success, what that 922 00:32:08,230 --> 00:32:11,049 means is I have completed successfully 923 00:32:11,050 --> 00:32:12,849 and these are the amount of bytes that I 924 00:32:12,850 --> 00:32:14,039 give to U.S. output. 925 00:32:15,580 --> 00:32:18,219 And basically 926 00:32:18,220 --> 00:32:20,469 the quite often what people will do 927 00:32:20,470 --> 00:32:22,839 is they'll go to 928 00:32:22,840 --> 00:32:24,519 I old status, that information, they'll 929 00:32:24,520 --> 00:32:27,729 say, OK, whatever 930 00:32:27,730 --> 00:32:30,009 output buffer linked that the user gave 931 00:32:30,010 --> 00:32:32,289 me, that's that that's 932 00:32:32,290 --> 00:32:33,909 the number I give you. 933 00:32:33,910 --> 00:32:35,859 And sure enough, you work, you do that 934 00:32:35,860 --> 00:32:37,809 and everything works. Nothing crashes. 935 00:32:37,810 --> 00:32:39,219 You get old data you need and everything 936 00:32:39,220 --> 00:32:40,629 works perfectly. 937 00:32:40,630 --> 00:32:43,239 But there's this very subtle thing where 938 00:32:43,240 --> 00:32:45,099 basically all of a sudden you have this 939 00:32:45,100 --> 00:32:46,100 information leak. 940 00:32:46,930 --> 00:32:48,969 So basically what happens is when you do 941 00:32:48,970 --> 00:32:50,679 when I octal and you go to your manager 942 00:32:50,680 --> 00:32:52,419 and you have better Bufford, the manager 943 00:32:52,420 --> 00:32:54,819 looks at your input length 944 00:32:54,820 --> 00:32:56,829 and you output length and it says, OK, 945 00:32:56,830 --> 00:32:59,319 which one of these two is the maximum? 946 00:32:59,320 --> 00:33:01,389 And it says, OK, let's say the 947 00:33:01,390 --> 00:33:03,729 output length is is the bigger one. 948 00:33:03,730 --> 00:33:05,859 It goes and says, OK, 949 00:33:05,860 --> 00:33:08,439 mallock of kernel buffer of 950 00:33:08,440 --> 00:33:10,240 that amount of data. And then it sees 951 00:33:11,380 --> 00:33:13,209 what is the length of the input buffer 952 00:33:13,210 --> 00:33:15,639 and it says, oh it was X, great. 953 00:33:15,640 --> 00:33:16,839 We'll take them with Bufferin, we'll use 954 00:33:16,840 --> 00:33:18,099 that length and we'll copy it into this 955 00:33:18,100 --> 00:33:19,509 buffer. I just locate it. 956 00:33:19,510 --> 00:33:21,039 So if you have an input buffer that is 957 00:33:21,040 --> 00:33:23,019 smaller than the output buffer that the 958 00:33:23,020 --> 00:33:24,669 delta between input and output is 959 00:33:24,670 --> 00:33:25,670 initialized memory. 960 00:33:26,890 --> 00:33:28,959 And if you now have this bug where at 961 00:33:28,960 --> 00:33:30,969 the end of the day you're done all the 962 00:33:30,970 --> 00:33:32,949 way to the end and what you've copied 963 00:33:32,950 --> 00:33:35,199 into the output buffer is smaller 964 00:33:35,200 --> 00:33:37,509 than the total allocated 965 00:33:37,510 --> 00:33:40,209 space that is available, 966 00:33:40,210 --> 00:33:42,099 then that that Delta all the way at the 967 00:33:42,100 --> 00:33:44,049 end is just like memory. 968 00:33:44,050 --> 00:33:46,149 And so if you then go and say, 969 00:33:46,150 --> 00:33:47,309 you know, IO status, 970 00:33:48,550 --> 00:33:50,919 that information is, you know, the full 971 00:33:50,920 --> 00:33:53,349 buffer length, then that includes that 972 00:33:53,350 --> 00:33:54,819 piece of uninsulated all the way at the 973 00:33:54,820 --> 00:33:56,589 end. And that gets copied back to 974 00:33:56,590 --> 00:33:57,939 usually. And and then when you it gets 975 00:33:57,940 --> 00:33:59,949 the buffer, they can just read that 976 00:33:59,950 --> 00:34:00,950 stuff. 977 00:34:01,420 --> 00:34:03,639 It's kind of subtle because stuff 978 00:34:03,640 --> 00:34:05,559 doesn't crash, stuff doesn't break. 979 00:34:05,560 --> 00:34:07,629 You have to really look for it. 980 00:34:07,630 --> 00:34:09,129 But quite often when you have these kind 981 00:34:09,130 --> 00:34:10,928 of bugs is you can you can rig this so 982 00:34:10,929 --> 00:34:12,218 you get really large buffers. 983 00:34:12,219 --> 00:34:14,198 You can say, I want a one or two gig 984 00:34:14,199 --> 00:34:16,029 buffer and all of a sudden you get just 985 00:34:16,030 --> 00:34:18,099 piles and piles and piles of unrealized 986 00:34:18,100 --> 00:34:20,259 data that comes out of Kerlin contains 987 00:34:20,260 --> 00:34:21,699 all sorts of interesting things. 988 00:34:24,250 --> 00:34:26,379 And so this is I reverse out of 989 00:34:26,380 --> 00:34:28,509 a driver, but it's it's a fairly common 990 00:34:28,510 --> 00:34:30,669 bug to see because you can test 991 00:34:30,670 --> 00:34:31,959 all you want. This thing will never 992 00:34:31,960 --> 00:34:34,029 crash. It's it's kind of subtle. 993 00:34:34,030 --> 00:34:36,609 So unless you know about this explicitly, 994 00:34:36,610 --> 00:34:38,468 you people don't find it either in 995 00:34:38,469 --> 00:34:40,599 testing or for looking 996 00:34:40,600 --> 00:34:42,009 for security bugs. 997 00:34:42,010 --> 00:34:43,928 But it's basically the common case where 998 00:34:43,929 --> 00:34:46,198 you you start your your 999 00:34:46,199 --> 00:34:48,369 dispatcher and you say, OK, this 1000 00:34:48,370 --> 00:34:50,138 is the flight user gave me, and then you 1001 00:34:50,139 --> 00:34:52,149 do all the work and then all the way at 1002 00:34:52,150 --> 00:34:53,289 the end when you're done, you say, OK, I 1003 00:34:53,290 --> 00:34:55,388 was that information is we start off 1004 00:34:55,389 --> 00:34:57,309 with the apple before linked and bouffe 1005 00:34:57,310 --> 00:34:58,269 off we go. 1006 00:34:58,270 --> 00:35:00,579 I have an old son, Distin just leaked 1007 00:35:00,580 --> 00:35:01,580 information. 1008 00:35:04,000 --> 00:35:05,049 What's the other thing that's really 1009 00:35:05,050 --> 00:35:06,429 interesting about this one is. 1010 00:35:08,540 --> 00:35:10,969 Even though this is a WDM thing, 1011 00:35:10,970 --> 00:35:12,259 and even though, Kim, you have to sort of 1012 00:35:12,260 --> 00:35:14,629 build on top of this in 1013 00:35:14,630 --> 00:35:16,729 Cambodia, if you still 1014 00:35:16,730 --> 00:35:18,679 you can still have this particular 1015 00:35:18,680 --> 00:35:21,859 mistake, you don't actually 1016 00:35:21,860 --> 00:35:23,689 manually fill out the members of the 1017 00:35:23,690 --> 00:35:25,789 group. But Kim 1018 00:35:25,790 --> 00:35:27,739 gives you a set of opacity where you 1019 00:35:27,740 --> 00:35:29,269 basically just pass parameters. 1020 00:35:29,270 --> 00:35:31,129 So it's WDEF request, complete with 1021 00:35:31,130 --> 00:35:33,769 information, request information. 1022 00:35:33,770 --> 00:35:35,449 Both of you fill out just IO status 1023 00:35:35,450 --> 00:35:36,450 field. 1024 00:35:37,520 --> 00:35:39,739 And, you know, if it's too 1025 00:35:39,740 --> 00:35:41,689 large, you have the same problem. 1026 00:35:41,690 --> 00:35:43,849 And because Kim, you have is open 1027 00:35:43,850 --> 00:35:45,649 source, you can just go look at source 1028 00:35:45,650 --> 00:35:46,789 and see what these functions do. 1029 00:35:46,790 --> 00:35:48,889 And indeed, if you look it up and you see 1030 00:35:48,890 --> 00:35:51,469 what these functions do, you'll see that 1031 00:35:51,470 --> 00:35:53,119 internally they still look up to Europe 1032 00:35:53,120 --> 00:35:55,819 and they go and say biostatistician 1033 00:35:55,820 --> 00:35:57,530 information and the links you give it. 1034 00:36:00,220 --> 00:36:02,319 The fix here is is simple, I 1035 00:36:02,320 --> 00:36:03,699 mean, it's a little bit 1036 00:36:06,250 --> 00:36:08,050 hard to figure out initially because 1037 00:36:09,870 --> 00:36:11,499 the bug itself is so subtle that, you 1038 00:36:11,500 --> 00:36:13,479 know, because nothing crashes, nothing 1039 00:36:13,480 --> 00:36:14,480 ever misbehaves. 1040 00:36:15,550 --> 00:36:17,889 It's kind of sold that way. 1041 00:36:17,890 --> 00:36:19,569 But once you're aware of it, the bugs are 1042 00:36:19,570 --> 00:36:21,039 really easy and it's incredibly easy to 1043 00:36:21,040 --> 00:36:23,139 fix. Basically, you know, any 1044 00:36:23,140 --> 00:36:25,329 time you get the information, you 1045 00:36:25,330 --> 00:36:27,129 should just be exact. 1046 00:36:27,130 --> 00:36:29,259 If you copy five bytes there, then 1047 00:36:29,260 --> 00:36:30,339 say that, right. 1048 00:36:30,340 --> 00:36:31,569 Always recorded about a batch put in 1049 00:36:31,570 --> 00:36:33,839 there and then just make that your ISIS 1050 00:36:33,840 --> 00:36:35,289 on information and you never have that 1051 00:36:35,290 --> 00:36:36,290 bug again. 1052 00:36:38,080 --> 00:36:40,269 The thing is, though, you 1053 00:36:40,270 --> 00:36:41,229 have to be consistent about it. 1054 00:36:41,230 --> 00:36:43,749 And that can be pretty hard, 1055 00:36:43,750 --> 00:36:46,030 especially if you're reviewing old code. 1056 00:36:47,110 --> 00:36:48,519 And so it's really easy to miss one or 1057 00:36:48,520 --> 00:36:50,379 two cases. 1058 00:36:50,380 --> 00:36:51,909 That is, you know, that is still lying 1059 00:36:51,910 --> 00:36:53,829 around code that was written 20 years 1060 00:36:53,830 --> 00:36:54,830 ago. 1061 00:36:56,800 --> 00:36:57,910 OK, so 1062 00:36:59,230 --> 00:37:01,059 the last part about your manager that I 1063 00:37:01,060 --> 00:37:02,979 want to talk about, and this is sort of 1064 00:37:02,980 --> 00:37:05,139 in broad strokes, is about her 1065 00:37:05,140 --> 00:37:07,379 cancelation and the reason why 1066 00:37:07,380 --> 00:37:09,579 it is I 1067 00:37:09,580 --> 00:37:11,679 talk about it broadly, not specifically 1068 00:37:11,680 --> 00:37:13,839 because it's incredibly complex stuff. 1069 00:37:13,840 --> 00:37:16,029 And I could easily feel, you know, a one 1070 00:37:16,030 --> 00:37:17,359 hour lecture, just about Earth 1071 00:37:17,360 --> 00:37:18,400 cancelation stuff. 1072 00:37:19,540 --> 00:37:21,909 So basically what happens is 1073 00:37:21,910 --> 00:37:23,709 when, you know, usually it doesn't. 1074 00:37:23,710 --> 00:37:25,419 I actually think it comes to the driver 1075 00:37:25,420 --> 00:37:27,489 and the driver says, OK, well, this is 1076 00:37:27,490 --> 00:37:29,649 a told that I can't complete right 1077 00:37:29,650 --> 00:37:31,389 away. And so what I'm going to do is I'm 1078 00:37:31,390 --> 00:37:33,129 going to go take this URP and spend it 1079 00:37:33,130 --> 00:37:34,149 and I'm going to go back a year later and 1080 00:37:34,150 --> 00:37:36,399 say, hey, come back later. 1081 00:37:36,400 --> 00:37:37,509 I'll give you a signal later. 1082 00:37:37,510 --> 00:37:39,639 Once I'm done, you can go do something 1083 00:37:39,640 --> 00:37:40,539 else now. 1084 00:37:40,540 --> 00:37:42,609 And then once the driver is done that 1085 00:37:42,610 --> 00:37:44,859 says, OK, well, this is now completed 1086 00:37:44,860 --> 00:37:46,899 and then, you know, signals user lands 1087 00:37:46,900 --> 00:37:48,849 and says, hey, I'm done. 1088 00:37:48,850 --> 00:37:51,249 That time in between is undefined. 1089 00:37:51,250 --> 00:37:53,079 Depending on what the driver does 1090 00:37:53,080 --> 00:37:55,449 supposed to do can possibly 1091 00:37:55,450 --> 00:37:57,549 be a long time, for example, something 1092 00:37:57,550 --> 00:37:58,599 that's disc based. 1093 00:38:00,430 --> 00:38:02,529 And so basically, at any point 1094 00:38:02,530 --> 00:38:04,829 after the to 1095 00:38:04,830 --> 00:38:06,369 suspended and usually knows that the 1096 00:38:06,370 --> 00:38:07,899 kernel sort of pended it and is working 1097 00:38:07,900 --> 00:38:09,849 on it, usually it can go back to the 1098 00:38:09,850 --> 00:38:12,069 kernel and say, oh, hey, 1099 00:38:12,070 --> 00:38:13,629 you know that driver that's holding my 1100 00:38:13,630 --> 00:38:15,759 URP, I'm done 1101 00:38:15,760 --> 00:38:18,579 waiting. You've taken way too long. 1102 00:38:18,580 --> 00:38:19,920 Just cancel the damn urp. 1103 00:38:20,950 --> 00:38:22,389 And then basically the driver sort of 1104 00:38:22,390 --> 00:38:24,279 gets woken up again, finds Europe and 1105 00:38:24,280 --> 00:38:25,280 cancels it. 1106 00:38:25,930 --> 00:38:27,499 And the problem with this is that there's 1107 00:38:27,500 --> 00:38:29,109 this potential for all these, like, race 1108 00:38:29,110 --> 00:38:30,759 conditions, right. Where you have one 1109 00:38:30,760 --> 00:38:32,349 thread that's still trying to work on the 1110 00:38:32,350 --> 00:38:33,969 European. You have another thread that 1111 00:38:33,970 --> 00:38:35,289 has been instructed to cancel it. 1112 00:38:35,290 --> 00:38:36,729 And so you have one guy working on one 1113 00:38:36,730 --> 00:38:37,959 guy canceling it. 1114 00:38:37,960 --> 00:38:40,299 And if they're not in perfect sync, 1115 00:38:40,300 --> 00:38:42,069 you have all sort of these weird race 1116 00:38:42,070 --> 00:38:43,070 conditions. 1117 00:38:44,870 --> 00:38:47,389 And so that stuff gets incredibly 1118 00:38:47,390 --> 00:38:49,859 complicated, and so 1119 00:38:49,860 --> 00:38:51,379 there are literally dozens and dozens of 1120 00:38:51,380 --> 00:38:52,759 examples of what this stuff looks like, 1121 00:38:52,760 --> 00:38:54,679 and I wish I could get into it, but I 1122 00:38:54,680 --> 00:38:56,839 can't. But I will say, though, 1123 00:38:56,840 --> 00:38:58,949 that reconciliation routines 1124 00:38:58,950 --> 00:39:00,829 that have segregation issues often lead 1125 00:39:00,830 --> 00:39:02,899 to deadlocks, memory leaks, race 1126 00:39:02,900 --> 00:39:04,549 conditions, double freeze, muzaffer 1127 00:39:04,550 --> 00:39:06,439 freeze. So all the stuff that, you know, 1128 00:39:06,440 --> 00:39:07,759 if you're a security guy looking for 1129 00:39:07,760 --> 00:39:09,859 bugs, that you start drooling when 1130 00:39:09,860 --> 00:39:11,779 you hear those things, they're all in 1131 00:39:11,780 --> 00:39:12,780 there. 1132 00:39:13,160 --> 00:39:14,569 And I really wish I could get into 1133 00:39:14,570 --> 00:39:15,570 detail. 1134 00:39:16,340 --> 00:39:17,340 And so 1135 00:39:18,620 --> 00:39:20,929 fix wise, it's kind of there's 1136 00:39:20,930 --> 00:39:22,249 no easy advice to give. 1137 00:39:22,250 --> 00:39:24,799 The stuff is just extremely complex, 1138 00:39:24,800 --> 00:39:26,789 and especially when you do or 1139 00:39:26,790 --> 00:39:27,790 cancelation. 1140 00:39:29,030 --> 00:39:30,829 Be very careful, be extremely 1141 00:39:30,830 --> 00:39:31,830 conservative. 1142 00:39:32,690 --> 00:39:35,059 Implement would care, 1143 00:39:35,060 --> 00:39:37,249 you know, double check, triple check, 1144 00:39:37,250 --> 00:39:38,870 have it. Peer review, check again. 1145 00:39:40,700 --> 00:39:43,009 You know, try to use 1146 00:39:43,010 --> 00:39:45,290 Cassol safe urp cuz 1147 00:39:47,810 --> 00:39:48,709 that's pretty much it. 1148 00:39:48,710 --> 00:39:50,869 Unfortunately there's no better 1149 00:39:50,870 --> 00:39:51,870 advice. 1150 00:39:52,700 --> 00:39:55,729 OK, so now we've got those two down. 1151 00:39:55,730 --> 00:39:58,259 Let's move on to use 1152 00:39:58,260 --> 00:39:59,959 land and data pointers. 1153 00:39:59,960 --> 00:40:01,789 And so I guess we should first talk about 1154 00:40:01,790 --> 00:40:02,810 the elephant in the room, 1155 00:40:03,950 --> 00:40:06,079 which is basically, you know what if 1156 00:40:06,080 --> 00:40:07,459 a driver takes, you know, 1157 00:40:09,710 --> 00:40:11,179 direct pointers from user lands, 1158 00:40:12,190 --> 00:40:14,149 what you're supposed to do these things 1159 00:40:14,150 --> 00:40:16,129 called, you know, probing, which is 1160 00:40:16,130 --> 00:40:19,009 basically a fancy word for 1161 00:40:19,010 --> 00:40:20,729 is this pointer within the range that 1162 00:40:20,730 --> 00:40:23,809 usually is allowed to be 1163 00:40:23,810 --> 00:40:25,869 and including the length and 1164 00:40:25,870 --> 00:40:27,559 then the end pointer does not overflow at 1165 00:40:27,560 --> 00:40:29,029 all those things. And that's basically 1166 00:40:29,030 --> 00:40:30,259 what the pro free and appropriate 1167 00:40:30,260 --> 00:40:31,929 functions do. 1168 00:40:31,930 --> 00:40:33,869 Mm hmm. 1169 00:40:35,990 --> 00:40:37,999 OK, there you go. 1170 00:40:38,000 --> 00:40:39,019 So basically, you know 1171 00:40:40,150 --> 00:40:42,379 it if you take someone's 1172 00:40:42,380 --> 00:40:43,699 land, you're supposed to do this kind of 1173 00:40:43,700 --> 00:40:45,649 probing if you don't probe. 1174 00:40:45,650 --> 00:40:47,869 So let's say you take a pointer from New 1175 00:40:47,870 --> 00:40:50,209 Zealand and you forget the probe 1176 00:40:50,210 --> 00:40:52,189 and you read from it. 1177 00:40:52,190 --> 00:40:54,029 Basically, that's potentially information 1178 00:40:54,030 --> 00:40:55,039 leak. 1179 00:40:55,040 --> 00:40:57,199 You could be reading from anywhere and 1180 00:40:57,200 --> 00:40:58,429 you could definitely crash. 1181 00:40:58,430 --> 00:40:59,699 And depending if that information gets 1182 00:40:59,700 --> 00:41:01,369 sent back to you land, you could 1183 00:41:01,370 --> 00:41:03,020 potentially info leak. 1184 00:41:04,790 --> 00:41:06,109 So that's bad. 1185 00:41:06,110 --> 00:41:07,969 But if you get a point of Friesland and 1186 00:41:07,970 --> 00:41:09,799 you don't probe and you write from it, 1187 00:41:09,800 --> 00:41:11,599 you basically get this sort of right. 1188 00:41:11,600 --> 00:41:13,309 Anything, anywhere primitive and colonel. 1189 00:41:13,310 --> 00:41:15,589 And that is extremely bad. 1190 00:41:15,590 --> 00:41:17,669 You basically just want to curl. 1191 00:41:17,670 --> 00:41:18,919 You do that. 1192 00:41:18,920 --> 00:41:20,569 And so basically to try to prevent these 1193 00:41:20,570 --> 00:41:22,849 cases, you do 1194 00:41:22,850 --> 00:41:24,439 probing and use appropriate approach for 1195 00:41:24,440 --> 00:41:25,440 IDP's. 1196 00:41:27,880 --> 00:41:29,679 And so this is this is one example, I 1197 00:41:29,680 --> 00:41:31,809 think this is some Intel driver 1198 00:41:31,810 --> 00:41:34,179 where basically, you know, that 1199 00:41:34,180 --> 00:41:36,039 you take an input buffer and then 1200 00:41:36,040 --> 00:41:38,379 basically you 1201 00:41:38,380 --> 00:41:40,119 there's no probing anywhere in between 1202 00:41:40,120 --> 00:41:41,559 and you just sort of reading right from 1203 00:41:41,560 --> 00:41:42,560 it. 1204 00:41:43,820 --> 00:41:45,619 But suffice to say, these bugs, 1205 00:41:45,620 --> 00:41:47,089 unfortunately, are extremely, extremely 1206 00:41:47,090 --> 00:41:48,090 common. 1207 00:41:51,240 --> 00:41:53,789 Another interesting sort of nugget 1208 00:41:53,790 --> 00:41:55,889 with this stuff is that and 1209 00:41:55,890 --> 00:41:57,479 this I think this was noted a few years 1210 00:41:57,480 --> 00:41:59,759 ago, is that so these is basically 1211 00:41:59,760 --> 00:42:02,009 the way they work is you say, OK, here's 1212 00:42:02,010 --> 00:42:03,659 why I use land pointer. 1213 00:42:03,660 --> 00:42:05,279 Here's the thing they want to throw for 1214 00:42:05,280 --> 00:42:07,139 and here's the alignment. 1215 00:42:07,140 --> 00:42:08,579 And you can have these very subtle bugs 1216 00:42:08,580 --> 00:42:10,169 where people do probe. 1217 00:42:10,170 --> 00:42:12,569 But for whatever reason, the links 1218 00:42:12,570 --> 00:42:15,269 given to the probing is zero. 1219 00:42:15,270 --> 00:42:17,519 And when the APIs basically go, 1220 00:42:17,520 --> 00:42:19,769 those processes basically say, OK, 1221 00:42:19,770 --> 00:42:21,479 we'll have the link to zero short circuit 1222 00:42:21,480 --> 00:42:23,460 logic return success. 1223 00:42:24,660 --> 00:42:26,129 And that is perfectly valid. 1224 00:42:26,130 --> 00:42:28,229 You know, if I say a probe of a 1225 00:42:28,230 --> 00:42:30,029 probe of zero, then I mean, you know, 1226 00:42:30,030 --> 00:42:31,030 clearly that zero. 1227 00:42:32,280 --> 00:42:33,779 The thing is that there's a little bit of 1228 00:42:33,780 --> 00:42:35,729 risk here when you when that's being 1229 00:42:35,730 --> 00:42:37,919 done. Basically, the idea that if 1230 00:42:37,920 --> 00:42:40,139 you probe with a link to zero and 1231 00:42:40,140 --> 00:42:42,569 then later on you basically 1232 00:42:42,570 --> 00:42:44,159 use that address, but then you read or 1233 00:42:44,160 --> 00:42:45,929 write one byte. 1234 00:42:45,930 --> 00:42:47,669 Obviously the bug there is that you have 1235 00:42:47,670 --> 00:42:50,609 a link discrepancy between zero and one. 1236 00:42:50,610 --> 00:42:53,039 But the difference is that because 1237 00:42:53,040 --> 00:42:55,409 the way the probes work, this discrepancy 1238 00:42:55,410 --> 00:42:57,479 becomes incredibly exploitable. 1239 00:42:57,480 --> 00:42:59,669 Right. If the API is at work, 1240 00:42:59,670 --> 00:43:01,109 worked away where they said, OK, well, 1241 00:43:01,110 --> 00:43:02,429 the link is zero. What we're going to do 1242 00:43:02,430 --> 00:43:03,649 is we're going to make the link one and 1243 00:43:03,650 --> 00:43:05,969 we'll just probe that particular address. 1244 00:43:05,970 --> 00:43:08,159 It would make these bugs far less 1245 00:43:08,160 --> 00:43:09,160 exploitable. 1246 00:43:10,440 --> 00:43:12,569 And so that's why that's why there's 1247 00:43:12,570 --> 00:43:13,679 risk here. 1248 00:43:13,680 --> 00:43:15,449 The common case for where these kind of 1249 00:43:15,450 --> 00:43:16,529 bugs could happen, where you do have a 1250 00:43:16,530 --> 00:43:19,139 probe would link to zero is a 1251 00:43:19,140 --> 00:43:21,899 you'll you'll see this code where 1252 00:43:21,900 --> 00:43:24,329 they'll take, they'll take they'll 1253 00:43:24,330 --> 00:43:26,729 take like a buffer length 1254 00:43:26,730 --> 00:43:28,889 and it put buffer and they'll just assume 1255 00:43:28,890 --> 00:43:30,149 it's of a certain length. And they never 1256 00:43:30,150 --> 00:43:31,139 actually double check what the link 1257 00:43:31,140 --> 00:43:32,909 really is. But they still passed the 1258 00:43:32,910 --> 00:43:34,409 original input buffer linked to the pro 1259 00:43:34,410 --> 00:43:35,410 functions. 1260 00:43:36,060 --> 00:43:37,439 And so if you forget that kind of link 1261 00:43:37,440 --> 00:43:39,839 check, you end up with these exact 1262 00:43:39,840 --> 00:43:40,840 kind of issues. 1263 00:43:41,700 --> 00:43:43,499 The other one is where if you do link 1264 00:43:43,500 --> 00:43:45,589 checks, is that you may still have like 1265 00:43:45,590 --> 00:43:47,559 little intro flows where the probing link 1266 00:43:47,560 --> 00:43:49,109 just happens, overflow right back to 1267 00:43:49,110 --> 00:43:50,110 zero. 1268 00:43:50,700 --> 00:43:52,050 So so that that could happen to you. 1269 00:43:53,520 --> 00:43:54,809 So the fix basically is 1270 00:43:56,040 --> 00:43:57,869 performed, correct? Consistent, probing. 1271 00:43:57,870 --> 00:43:59,270 Always, always, always probe. 1272 00:44:00,420 --> 00:44:02,259 It's easier than it looks. 1273 00:44:02,260 --> 00:44:05,099 You always forget one somewhere. 1274 00:44:05,100 --> 00:44:06,029 It's where these things were. 1275 00:44:06,030 --> 00:44:08,339 Once you start like if you if it's 1276 00:44:08,340 --> 00:44:10,199 all in one simple function, then that 1277 00:44:10,200 --> 00:44:11,729 tends to be easy. But you'll have these 1278 00:44:11,730 --> 00:44:12,909 things where you have these complex 1279 00:44:12,910 --> 00:44:14,729 drivers, where it calls a function that 1280 00:44:14,730 --> 00:44:16,259 calls function, that calls a function. 1281 00:44:16,260 --> 00:44:17,879 And somewhere down the road you're not 1282 00:44:17,880 --> 00:44:19,619 quite sure if it's user pointer or a 1283 00:44:19,620 --> 00:44:21,029 kernel pointer. 1284 00:44:21,030 --> 00:44:23,249 And then, you know, you end up 1285 00:44:23,250 --> 00:44:24,250 missing a probe. 1286 00:44:26,840 --> 00:44:28,999 So the second sort of variation of this 1287 00:44:29,000 --> 00:44:31,369 is, OK, let's say you take a kernel, 1288 00:44:31,370 --> 00:44:33,739 you take use of water in your driver 1289 00:44:33,740 --> 00:44:35,179 and you've not probed it and then you're 1290 00:44:35,180 --> 00:44:36,180 going to start using it, 1291 00:44:37,370 --> 00:44:39,409 you can still do things that are horribly 1292 00:44:39,410 --> 00:44:41,629 wrong. So every time you use a 1293 00:44:41,630 --> 00:44:44,179 pointer, a usually a splintering kernel, 1294 00:44:44,180 --> 00:44:45,799 even if it's properties that you must 1295 00:44:45,800 --> 00:44:47,690 always wrapped up in a tree, except 1296 00:44:48,860 --> 00:44:50,659 the reason being is that if you don't do 1297 00:44:50,660 --> 00:44:52,819 any try, except is that 1298 00:44:52,820 --> 00:44:54,889 after you after it's been probed, you 1299 00:44:54,890 --> 00:44:56,929 could have a second use land thread that 1300 00:44:56,930 --> 00:44:59,209 takes, you know, your maps address and 1301 00:44:59,210 --> 00:45:00,949 basically changes the page projections or 1302 00:45:00,950 --> 00:45:03,199 unmap stem and then the 1303 00:45:03,200 --> 00:45:04,969 somewhere in critelli after the probing, 1304 00:45:04,970 --> 00:45:06,349 they go, oh, well, we'll just use these 1305 00:45:06,350 --> 00:45:08,209 pointers and all of a sudden they're 1306 00:45:08,210 --> 00:45:11,059 reading or writing to unmap pages, 1307 00:45:11,060 --> 00:45:13,939 which will throw an exception. 1308 00:45:13,940 --> 00:45:15,799 And so that's why you must always do a 1309 00:45:15,800 --> 00:45:16,800 try, except. 1310 00:45:18,410 --> 00:45:20,509 So the obvious key is to forget 1311 00:45:20,510 --> 00:45:21,510 exception handling, 1312 00:45:22,700 --> 00:45:24,769 but in the less obvious case, as 1313 00:45:24,770 --> 00:45:27,409 is, maybe you do have to accept case. 1314 00:45:27,410 --> 00:45:29,779 But the thing is, the you know, except 1315 00:45:29,780 --> 00:45:31,969 cases rarely exercise because, 1316 00:45:31,970 --> 00:45:33,529 you know, it's the exception, right. 1317 00:45:33,530 --> 00:45:35,569 It almost never happens. 1318 00:45:35,570 --> 00:45:37,639 And as such, these bugs 1319 00:45:37,640 --> 00:45:39,859 in accepted handlers 1320 00:45:39,860 --> 00:45:41,689 often don't show up in testing simply 1321 00:45:41,690 --> 00:45:43,969 because it's never been exercised. 1322 00:45:43,970 --> 00:45:46,039 So even if you 1323 00:45:46,040 --> 00:45:48,109 do accept what usually pointers, 1324 00:45:48,110 --> 00:45:49,759 it's still quite often to notice things 1325 00:45:49,760 --> 00:45:51,979 like memory leaks and reference 1326 00:45:51,980 --> 00:45:52,980 leaks 1327 00:45:55,040 --> 00:45:57,109 that sort of fixed here basically is 1328 00:45:57,110 --> 00:45:59,189 a use try except when using 1329 00:45:59,190 --> 00:46:01,430 using Pointer and B is. 1330 00:46:03,370 --> 00:46:05,949 Make sure your exceptional logic is same, 1331 00:46:05,950 --> 00:46:07,929 except your logic can be really tricky, 1332 00:46:07,930 --> 00:46:09,369 and so you want to design implement that 1333 00:46:09,370 --> 00:46:10,370 stuff with care. 1334 00:46:14,090 --> 00:46:16,459 Sort of related to 1335 00:46:16,460 --> 00:46:18,199 you, that point is what they're called 1336 00:46:18,200 --> 00:46:20,509 double features, so the idea basically 1337 00:46:20,510 --> 00:46:22,579 is I'm usually 1338 00:46:22,580 --> 00:46:24,229 and I go call to a driver and say, OK, 1339 00:46:24,230 --> 00:46:25,609 here's usually the pointer and the driver 1340 00:46:25,610 --> 00:46:27,769 takes the pointer and it does the probing 1341 00:46:27,770 --> 00:46:29,209 and it does try, except it does all that 1342 00:46:29,210 --> 00:46:30,679 stuff. Right. 1343 00:46:30,680 --> 00:46:32,869 But we'll take a pointer and he'll say 1344 00:46:32,870 --> 00:46:34,369 let's say it contains an embedded 1345 00:46:34,370 --> 00:46:36,349 Lynnfield and well, to lose, they'll 1346 00:46:36,350 --> 00:46:37,579 dereference usually the pointer and 1347 00:46:37,580 --> 00:46:38,689 they'll make sure that Leitchfield is 1348 00:46:38,690 --> 00:46:40,549 Valot. It's got to be, let's say, I don't 1349 00:46:40,550 --> 00:46:42,349 know, bigger than 10 and smaller than one 1350 00:46:42,350 --> 00:46:43,489 hundred or something. 1351 00:46:43,490 --> 00:46:45,199 And then sure enough, that's true. 1352 00:46:45,200 --> 00:46:46,729 And then right after that they'll drop 1353 00:46:46,730 --> 00:46:47,779 that pointer again. They'll take the 1354 00:46:47,780 --> 00:46:49,039 Lynnfield and they'll use it to do 1355 00:46:49,040 --> 00:46:50,119 something else. 1356 00:46:50,120 --> 00:46:51,439 And the difference is that there's a race 1357 00:46:51,440 --> 00:46:52,440 condition here 1358 00:46:53,750 --> 00:46:55,429 where basically 1359 00:46:56,570 --> 00:46:58,639 between the first check and the 1360 00:46:58,640 --> 00:47:00,859 second check, you know, 1361 00:47:00,860 --> 00:47:02,359 because I could have a second Suzlon 1362 00:47:02,360 --> 00:47:04,579 thread that really overrides that memory 1363 00:47:04,580 --> 00:47:06,499 so that when you check it, it's OK. 1364 00:47:06,500 --> 00:47:08,359 And when you start using it, it's some 1365 00:47:08,360 --> 00:47:09,360 totally different value. 1366 00:47:10,520 --> 00:47:12,289 And this is just a simple example of what 1367 00:47:12,290 --> 00:47:14,329 that could look like, where basically, 1368 00:47:14,330 --> 00:47:16,519 you know, you have some some some 1369 00:47:16,520 --> 00:47:18,709 functioning kernel where you pass it, 1370 00:47:18,710 --> 00:47:19,710 you know, some 1371 00:47:20,780 --> 00:47:21,889 some user pointer 1372 00:47:23,990 --> 00:47:26,359 and use a pointer will 1373 00:47:26,360 --> 00:47:28,639 contain some and better Lynnfield. 1374 00:47:28,640 --> 00:47:30,289 So in this case, it's got to be, you 1375 00:47:30,290 --> 00:47:32,779 know, smaller than hundred. 1376 00:47:32,780 --> 00:47:35,359 And then, you know, they use that 1377 00:47:35,360 --> 00:47:37,399 Lynnfield to copy into a local stock for 1378 00:47:37,400 --> 00:47:38,869 that 100 bytes. 1379 00:47:38,870 --> 00:47:40,909 And so between that check and read the 1380 00:47:40,910 --> 00:47:43,069 first time and the use in the 1381 00:47:43,070 --> 00:47:45,619 in the in the copy memory, 1382 00:47:45,620 --> 00:47:46,759 you can have a second. Usually try to 1383 00:47:46,760 --> 00:47:48,199 overnight's overwrites Stillings. 1384 00:47:51,640 --> 00:47:53,619 And basically, you end up with memory 1385 00:47:53,620 --> 00:47:55,779 corruption and 1386 00:47:55,780 --> 00:47:58,089 this is an example of a bug 1387 00:47:58,090 --> 00:48:00,129 that is a double and triple fach that I 1388 00:48:00,130 --> 00:48:02,289 found in the security program a couple 1389 00:48:02,290 --> 00:48:03,669 of months ago. 1390 00:48:03,670 --> 00:48:06,039 And I have a link to the advisory below, 1391 00:48:06,040 --> 00:48:08,379 if you will. Look at it, the fix for 1392 00:48:08,380 --> 00:48:10,719 this kind of stuff is basically capture 1393 00:48:10,720 --> 00:48:12,999 data, validate and only then do use, 1394 00:48:13,000 --> 00:48:15,459 never fetch again, keep the cap, 1395 00:48:15,460 --> 00:48:17,409 keep the data you captured and validate 1396 00:48:17,410 --> 00:48:18,460 that and use that. 1397 00:48:22,600 --> 00:48:24,069 Similarly, for four years and that stuff 1398 00:48:24,070 --> 00:48:25,090 is basically 1399 00:48:26,470 --> 00:48:28,689 sort of new, the references I 1400 00:48:28,690 --> 00:48:30,669 considered the same class. 1401 00:48:30,670 --> 00:48:32,799 It's not specific to Windows 1402 00:48:32,800 --> 00:48:34,119 drivers. I actually spoke about this 1403 00:48:34,120 --> 00:48:36,549 particular bug NCC conference 1404 00:48:36,550 --> 00:48:39,369 here in 2006. 1405 00:48:39,370 --> 00:48:41,949 I was talking about Lisker all the time, 1406 00:48:41,950 --> 00:48:44,019 but it applies just as well to 1407 00:48:44,020 --> 00:48:45,759 the Windows kernel. 1408 00:48:45,760 --> 00:48:47,889 And basically the only difference in sort 1409 00:48:47,890 --> 00:48:50,169 of the in trying to trigger a mapping 1410 00:48:50,170 --> 00:48:53,089 to the new page is in 1411 00:48:53,090 --> 00:48:54,669 Linux and Unix to basically do a map. 1412 00:48:54,670 --> 00:48:56,829 And you say, you know, you say fix 1413 00:48:56,830 --> 00:48:58,469 and you just give it an A. 1414 00:48:58,470 --> 00:49:00,459 and it'll go map it in windows. 1415 00:49:00,460 --> 00:49:02,409 It's slightly more tricky where basically 1416 00:49:02,410 --> 00:49:04,749 if you try to map the attritional, 1417 00:49:04,750 --> 00:49:06,639 it basically sort of goes like, oh, no 1418 00:49:06,640 --> 00:49:08,189 means you don't mean an address while 1419 00:49:08,190 --> 00:49:09,359 it's looking for you. 1420 00:49:09,360 --> 00:49:10,479 And so the way you're supposed to do it, 1421 00:49:10,480 --> 00:49:12,729 as you say, no, the address is one. 1422 00:49:12,730 --> 00:49:14,349 And then what it does is it roots down to 1423 00:49:14,350 --> 00:49:15,309 one to a zero. 1424 00:49:15,310 --> 00:49:17,559 And then it goes to maps, no page, 1425 00:49:17,560 --> 00:49:18,909 but it's essentially the same thing. 1426 00:49:20,590 --> 00:49:22,659 This used to be a much bigger deal as 1427 00:49:22,660 --> 00:49:24,999 of Windows eight mappings 1428 00:49:25,000 --> 00:49:26,260 of the new page or disallowed, 1429 00:49:27,700 --> 00:49:28,779 which isn't. 1430 00:49:28,780 --> 00:49:30,429 So that's what that's what they'll tell 1431 00:49:30,430 --> 00:49:32,719 you. And it isn't entirely accurate. 1432 00:49:32,720 --> 00:49:34,929 The 64 bit Windows mappings of no page or 1433 00:49:34,930 --> 00:49:37,329 disallowed on thirty bit Windows mappings 1434 00:49:37,330 --> 00:49:40,089 of the new page or disallowed by default. 1435 00:49:40,090 --> 00:49:42,129 But there's this thing called the a.D.A, 1436 00:49:42,130 --> 00:49:43,749 which is the virtual DOS machine. 1437 00:49:43,750 --> 00:49:45,339 So if you want to run all doors cames, 1438 00:49:45,340 --> 00:49:47,679 for example, you have to turn this stuff 1439 00:49:47,680 --> 00:49:49,509 on and all of a sudden you can have no 1440 00:49:49,510 --> 00:49:51,429 pointer references in your old DOS games. 1441 00:49:51,430 --> 00:49:53,959 And those would then allow you to explore 1442 00:49:53,960 --> 00:49:56,109 new point references in Windows 1443 00:49:56,110 --> 00:49:59,289 drivers, essentially. 1444 00:49:59,290 --> 00:50:01,509 But even if in this if this 1445 00:50:01,510 --> 00:50:03,699 sort of little Corta case 1446 00:50:03,700 --> 00:50:05,769 doesn't work and then we take 1447 00:50:05,770 --> 00:50:07,719 the premise that no map, no mappings 1448 00:50:07,720 --> 00:50:09,759 can't aren't allowed in Windows as 1449 00:50:09,760 --> 00:50:11,529 Windows eight, there are still some 1450 00:50:11,530 --> 00:50:13,569 exceptions where no pointers in kernel 1451 00:50:13,570 --> 00:50:15,459 might be exploitable. 1452 00:50:15,460 --> 00:50:17,679 So well as if you have null plus 1453 00:50:17,680 --> 00:50:19,449 a large offset, what you offset basically 1454 00:50:19,450 --> 00:50:20,450 becomes your pointer. 1455 00:50:21,520 --> 00:50:23,530 A common case of this might be where? 1456 00:50:25,880 --> 00:50:27,979 You have a copy of a reverse them 1457 00:50:27,980 --> 00:50:30,319 copy or where you pass to a function 1458 00:50:30,320 --> 00:50:31,320 as special meaning. 1459 00:50:34,430 --> 00:50:35,779 Yeah, the fix is basically defensive 1460 00:50:35,780 --> 00:50:37,219 programing, right? I mean, we all know 1461 00:50:37,220 --> 00:50:39,169 about pointed references there, nothing 1462 00:50:39,170 --> 00:50:40,170 special. 1463 00:50:41,840 --> 00:50:43,369 OK, let me I'm just going to skip this 1464 00:50:43,370 --> 00:50:44,370 because I'm running out of time. 1465 00:50:47,710 --> 00:50:50,019 OK, so memory related bugs. 1466 00:50:50,020 --> 00:50:51,399 This is number four out of the five I 1467 00:50:51,400 --> 00:50:52,449 had. 1468 00:50:52,450 --> 00:50:53,500 Basically, if you're 1469 00:50:54,730 --> 00:50:56,829 a Windows driver, there's two 1470 00:50:56,830 --> 00:50:59,349 sets of APIs you do to look at memory. 1471 00:50:59,350 --> 00:51:01,959 It's the locate pool and locate 1472 00:51:01,960 --> 00:51:02,960 pool with cuota. 1473 00:51:04,330 --> 00:51:06,819 And basically there's a discrepancy 1474 00:51:06,820 --> 00:51:09,219 between the two where one of the APIs, 1475 00:51:09,220 --> 00:51:11,229 when it fails, returns null and the other 1476 00:51:11,230 --> 00:51:14,409 API when it fails, throws an exception. 1477 00:51:14,410 --> 00:51:15,759 So if you mixed up one with the other, 1478 00:51:15,760 --> 00:51:17,259 all of a sudden you're checking for 1479 00:51:17,260 --> 00:51:19,329 value. But you might get an exception 1480 00:51:19,330 --> 00:51:21,229 or you're you have an exception handler. 1481 00:51:21,230 --> 00:51:22,659 But what really happens is you get a no 1482 00:51:22,660 --> 00:51:25,389 pointer back, so 1483 00:51:25,390 --> 00:51:28,119 you have to get those straight. 1484 00:51:28,120 --> 00:51:30,249 And I believe one 1485 00:51:30,250 --> 00:51:32,619 of the the pull would, quote, actually 1486 00:51:32,620 --> 00:51:34,299 allows you it has an option where you 1487 00:51:34,300 --> 00:51:36,399 basically go to it and say, hey, instead 1488 00:51:36,400 --> 00:51:39,159 of throwing give me a null, 1489 00:51:39,160 --> 00:51:41,199 I would recommend using the API that way 1490 00:51:41,200 --> 00:51:42,489 because then you have consistency. 1491 00:51:43,720 --> 00:51:46,059 But that's one of the ways you could say 1492 00:51:46,060 --> 00:51:48,280 you can go wrong using these APIs. 1493 00:51:49,400 --> 00:51:51,669 There are two 1494 00:51:51,670 --> 00:51:53,859 other things. One is basically so 1495 00:51:53,860 --> 00:51:55,959 the allocate pool with Cuota is 1496 00:51:55,960 --> 00:51:58,089 basically done so that any time you do an 1497 00:51:58,090 --> 00:52:00,789 allocation in kernel 1498 00:52:00,790 --> 00:52:02,949 based, driven by user 1499 00:52:02,950 --> 00:52:05,439 land, you're supposed to do allocations 1500 00:52:05,440 --> 00:52:06,849 based on the quarter after you land 1501 00:52:06,850 --> 00:52:08,019 caller. Right. 1502 00:52:08,020 --> 00:52:09,549 So in my view, any time you do an 1503 00:52:09,550 --> 00:52:11,889 analysis based upon 1504 00:52:11,890 --> 00:52:13,929 driven by user land, you should always do 1505 00:52:13,930 --> 00:52:15,099 the quarter ALAC. 1506 00:52:15,100 --> 00:52:16,960 If you don't, I think that's a bug. 1507 00:52:20,290 --> 00:52:22,119 And then, of course, you know, the, ah, 1508 00:52:22,120 --> 00:52:24,069 simple case, right, where obviously, yes, 1509 00:52:24,070 --> 00:52:25,029 you know, if you don't check in for 1510 00:52:25,030 --> 00:52:27,219 value, yes, you may have no references. 1511 00:52:27,220 --> 00:52:28,659 If you don't handle exceptions, yes, you 1512 00:52:28,660 --> 00:52:30,609 may have unhandled exceptions. 1513 00:52:30,610 --> 00:52:32,709 And even if you are, you could have 1514 00:52:32,710 --> 00:52:33,790 faulty exception, logic. 1515 00:52:35,620 --> 00:52:36,849 You know, these are pretty simple. 1516 00:52:36,850 --> 00:52:38,649 You know, fixed wises like. 1517 00:52:38,650 --> 00:52:39,879 Yes, check values. 1518 00:52:39,880 --> 00:52:41,349 Yes. 1519 00:52:41,350 --> 00:52:42,549 Charge quartet when you have to. 1520 00:52:42,550 --> 00:52:43,599 Yes. Cap Buffer's. 1521 00:52:43,600 --> 00:52:45,400 Please don't have unbelted Alaric's. 1522 00:52:47,350 --> 00:52:49,059 So the second sort of related issue, and 1523 00:52:49,060 --> 00:52:51,219 this is again, this is new as of Windows 1524 00:52:51,220 --> 00:52:52,809 eight, and this is mostly a mitigation 1525 00:52:52,810 --> 00:52:54,219 type thing. 1526 00:52:54,220 --> 00:52:56,109 So by default in Windows, when you used 1527 00:52:56,110 --> 00:52:58,419 to do a memory allocation, 1528 00:52:58,420 --> 00:52:59,919 the pages you would get back were 1529 00:52:59,920 --> 00:53:02,049 executable as of Windows 1530 00:53:02,050 --> 00:53:04,419 eight. That is no longer true. 1531 00:53:04,420 --> 00:53:07,029 So there's a possible pool 1532 00:53:07,030 --> 00:53:09,129 for the pool 1533 00:53:09,130 --> 00:53:10,239 by default. 1534 00:53:10,240 --> 00:53:12,489 They are now not suitable for 1535 00:53:12,490 --> 00:53:14,679 an office pool. They still have to be. 1536 00:53:14,680 --> 00:53:16,449 And so they came up with this new thing 1537 00:53:16,450 --> 00:53:19,329 called a nonpaid pool, not executable. 1538 00:53:19,330 --> 00:53:21,639 And the idea is that anytime you do 1539 00:53:21,640 --> 00:53:24,789 nonpublic Alok nowadays 1540 00:53:24,790 --> 00:53:26,439 is that you specify this particular 1541 00:53:26,440 --> 00:53:28,509 pulled it out page an ex, unless 1542 00:53:28,510 --> 00:53:30,699 you really need 1543 00:53:30,700 --> 00:53:33,219 executable, not painful memory, 1544 00:53:33,220 --> 00:53:35,319 which is not impossible, but it's 1545 00:53:35,320 --> 00:53:36,789 pretty rare that you actually need it 1546 00:53:36,790 --> 00:53:38,259 also be executable. 1547 00:53:38,260 --> 00:53:39,979 And in that case, sure, go ahead and use 1548 00:53:39,980 --> 00:53:41,709 the non-paper one. 1549 00:53:41,710 --> 00:53:43,279 But in any other case where you eat not 1550 00:53:43,280 --> 00:53:44,829 painful memory and you don't need to be a 1551 00:53:44,830 --> 00:53:46,959 shootable, you should really use 1552 00:53:46,960 --> 00:53:48,399 this flag. 1553 00:53:48,400 --> 00:53:50,829 It's not a bug per say by itself. 1554 00:53:50,830 --> 00:53:53,589 It's really sort of, you know, 1555 00:53:53,590 --> 00:53:55,989 this this does not 1556 00:53:55,990 --> 00:53:57,599 to let people is really mitigation 1557 00:53:57,600 --> 00:53:58,959 reputation. And so the idea is that if 1558 00:53:58,960 --> 00:54:01,599 you use this incorrectly, you're kind of 1559 00:54:01,600 --> 00:54:02,710 killing in mitigation. 1560 00:54:05,630 --> 00:54:06,630 Um. 1561 00:54:08,240 --> 00:54:10,909 And so basically 1562 00:54:10,910 --> 00:54:12,739 the idea is that, you know. 1563 00:54:14,010 --> 00:54:15,119 Welcome back. 1564 00:54:15,120 --> 00:54:17,579 The idea is that you 1565 00:54:17,580 --> 00:54:19,409 use the numbers baseball, and 1566 00:54:20,910 --> 00:54:23,279 if you're going to do things, if 1567 00:54:23,280 --> 00:54:25,589 you're going to do not be specific 1568 00:54:26,880 --> 00:54:27,880 allocations. 1569 00:54:30,150 --> 00:54:32,219 So the next memory bug 1570 00:54:32,220 --> 00:54:34,319 story, there's a API call that 1571 00:54:34,320 --> 00:54:36,269 gets us at us from Gizelle, which is 1572 00:54:36,270 --> 00:54:37,769 basically if you get Namgyal, how do you 1573 00:54:37,770 --> 00:54:39,399 get it mapped in your refrigerator space 1574 00:54:39,400 --> 00:54:41,429 to curdle this old API? 1575 00:54:41,430 --> 00:54:42,430 Basically, 1576 00:54:44,010 --> 00:54:46,179 if you call it, there's a risk of if 1577 00:54:46,180 --> 00:54:48,749 if it can't map it, what it does is 1578 00:54:48,750 --> 00:54:51,299 it causes a kernel panic. 1579 00:54:51,300 --> 00:54:53,259 And so there's a new API called Get 1580 00:54:53,260 --> 00:54:55,589 Systematized for MDL safe, and 1581 00:54:55,590 --> 00:54:57,689 that one doesn't cause a 1582 00:54:57,690 --> 00:54:58,919 kernel panic. 1583 00:54:58,920 --> 00:55:00,149 And so obviously you use a new one. 1584 00:55:00,150 --> 00:55:01,979 If you see the old one, that's a bug. 1585 00:55:01,980 --> 00:55:03,809 And while this seems easy, there's still 1586 00:55:03,810 --> 00:55:05,399 a fair amount of drivers that use the old 1587 00:55:05,400 --> 00:55:06,299 API. 1588 00:55:06,300 --> 00:55:07,289 And I start thinking about it. 1589 00:55:07,290 --> 00:55:09,449 And I think I mean, there's there's two 1590 00:55:09,450 --> 00:55:11,219 reasons why you would still have that if 1591 00:55:11,220 --> 00:55:12,599 you have an old code base. 1592 00:55:12,600 --> 00:55:14,849 But I think B is if you're 1593 00:55:14,850 --> 00:55:17,309 developing based upon 1594 00:55:17,310 --> 00:55:19,619 driver books and document basically 1595 00:55:19,620 --> 00:55:21,929 books that basically 1596 00:55:21,930 --> 00:55:24,479 tell you to use the old API because 1597 00:55:24,480 --> 00:55:26,069 the book was written before the API 1598 00:55:26,070 --> 00:55:27,719 existed. And there's actually there's 1599 00:55:27,720 --> 00:55:29,219 plenty of most of these kernel driver 1600 00:55:29,220 --> 00:55:30,989 books are relatively old. 1601 00:55:30,990 --> 00:55:33,239 And so they advise using that API. 1602 00:55:33,240 --> 00:55:34,529 And I think that's why these bugs are 1603 00:55:34,530 --> 00:55:35,530 still around. 1604 00:55:36,540 --> 00:55:37,540 Um. 1605 00:55:39,710 --> 00:55:40,939 Yeah, so this is basically what I was 1606 00:55:40,940 --> 00:55:42,319 talking about earlier, right, when you 1607 00:55:42,320 --> 00:55:44,539 have these embryos that are used to 1608 00:55:44,540 --> 00:55:47,089 create a mapping between user and kernel, 1609 00:55:47,090 --> 00:55:48,289 all of a sudden you end up with these 1610 00:55:48,290 --> 00:55:50,449 double features again, right where 1611 00:55:50,450 --> 00:55:52,519 let's say you have like an apple that 1612 00:55:52,520 --> 00:55:55,669 comes in with a method indirects 1613 00:55:55,670 --> 00:55:57,739 and you you take it, you get 1614 00:55:57,740 --> 00:55:59,719 your kernel point out EnerDel and you 1615 00:55:59,720 --> 00:56:00,909 just sort of using like embedded 1616 00:56:00,910 --> 00:56:01,910 Lynnfield 1617 00:56:03,200 --> 00:56:04,200 then. 1618 00:56:05,790 --> 00:56:07,649 Not realizing that that memory can be 1619 00:56:07,650 --> 00:56:10,259 changed any given time by yourself. 1620 00:56:10,260 --> 00:56:11,399 So you end up with all of these sort of 1621 00:56:11,400 --> 00:56:13,379 double bucks again. 1622 00:56:13,380 --> 00:56:14,609 The thing is, they're not quite as 1623 00:56:14,610 --> 00:56:16,440 obvious as the ones that directly from 1624 00:56:18,030 --> 00:56:20,189 the ones I showed earlier, because you're 1625 00:56:20,190 --> 00:56:21,239 dealing with a coral pointer. 1626 00:56:21,240 --> 00:56:23,159 So if you just look at the point, you 1627 00:56:23,160 --> 00:56:24,690 would assume that 1628 00:56:26,370 --> 00:56:27,389 usually doesn't really have 1629 00:56:28,710 --> 00:56:30,089 control over it. 1630 00:56:30,090 --> 00:56:32,339 And so that's why they're not as obvious. 1631 00:56:32,340 --> 00:56:34,469 This is a very simple sort of example of 1632 00:56:34,470 --> 00:56:35,899 what that would look like. Right. 1633 00:56:35,900 --> 00:56:37,469 So you have Namgyal you say, OK, it's 1634 00:56:37,470 --> 00:56:39,599 better safe, and then you get your data 1635 00:56:39,600 --> 00:56:41,069 back and then you say in but at length 1636 00:56:41,070 --> 00:56:43,229 and then you're going to go, OK, we'll 1637 00:56:43,230 --> 00:56:45,299 use we'll use that 1638 00:56:45,300 --> 00:56:46,739 a bit at length. 1639 00:56:46,740 --> 00:56:48,269 But because it comes from Namgyal, you 1640 00:56:48,270 --> 00:56:49,559 can have a second use that thread that 1641 00:56:49,560 --> 00:56:52,049 just changes your embedded length after 1642 00:56:52,050 --> 00:56:53,579 validation, but before you use. 1643 00:56:54,630 --> 00:56:56,669 Oh, did I? 1644 00:56:56,670 --> 00:56:57,670 OK. 1645 00:57:01,500 --> 00:57:03,029 I'm going to skip over this because I'm 1646 00:57:03,030 --> 00:57:04,639 really close to running out of time. 1647 00:57:06,650 --> 00:57:08,839 So I think I have 1648 00:57:08,840 --> 00:57:10,939 two more minutes. Sweet, 1649 00:57:10,940 --> 00:57:13,399 let me get to the first part 1650 00:57:13,400 --> 00:57:15,139 of your calendar, basically. 1651 00:57:15,140 --> 00:57:17,239 So when you talk to 1652 00:57:17,240 --> 00:57:19,369 Colonel and basically says, OK, 1653 00:57:19,370 --> 00:57:21,679 here's some handle to some file, go 1654 00:57:21,680 --> 00:57:24,529 do something with it, the way 1655 00:57:24,530 --> 00:57:26,389 the colonel goes, says, OK, well, I'm 1656 00:57:26,390 --> 00:57:28,459 supposed to how do I how do 1657 00:57:28,460 --> 00:57:30,199 I translate this handle to a colonel 1658 00:57:30,200 --> 00:57:31,759 point I can use? 1659 00:57:31,760 --> 00:57:33,259 You call it a function called a reference 1660 00:57:33,260 --> 00:57:35,479 object by handle, and that basically 1661 00:57:35,480 --> 00:57:37,429 translates one to the other. 1662 00:57:37,430 --> 00:57:39,649 And the API looks like this 1663 00:57:39,650 --> 00:57:41,419 and it has distinct object type and 1664 00:57:41,420 --> 00:57:43,669 access mode and basically object 1665 00:57:43,670 --> 00:57:44,749 type says. 1666 00:57:44,750 --> 00:57:47,119 And for that it is that the object 1667 00:57:47,120 --> 00:57:49,609 that the handlers of this particular type 1668 00:57:49,610 --> 00:57:51,979 and windows has about 40 something 1669 00:57:51,980 --> 00:57:54,679 different types of objects. 1670 00:57:54,680 --> 00:57:56,749 And so you can you if you 1671 00:57:56,750 --> 00:57:58,429 take a handle from user and kernel and 1672 00:57:58,430 --> 00:58:01,459 use this API and you say 1673 00:58:01,460 --> 00:58:03,559 object type is no, there's no type 1674 00:58:03,560 --> 00:58:06,079 and force and you get all these classic 1675 00:58:06,080 --> 00:58:08,059 type confusion bugs. 1676 00:58:08,060 --> 00:58:10,639 So that's one to the second 1677 00:58:10,640 --> 00:58:12,949 bug you can have here is basically where 1678 00:58:12,950 --> 00:58:14,599 if you access mode, you're supposed to 1679 00:58:14,600 --> 00:58:15,529 specify user. 1680 00:58:15,530 --> 00:58:17,389 If you specify, Colonel, that all of a 1681 00:58:17,390 --> 00:58:19,639 sudden use land gets to give you 1682 00:58:19,640 --> 00:58:21,799 handles that are really kernel handles. 1683 00:58:21,800 --> 00:58:24,229 And so because handle numbers are really 1684 00:58:24,230 --> 00:58:26,239 not secrets, they're easy to brute force. 1685 00:58:26,240 --> 00:58:28,279 And all of a sudden, if you say XML as 1686 00:58:28,280 --> 00:58:30,469 kernel mode, user olsun gets 1687 00:58:30,470 --> 00:58:32,449 to tinker with your kernel handles. 1688 00:58:33,870 --> 00:58:35,820 Oh, OK. 1689 00:58:37,190 --> 00:58:38,989 Another thing with this kind of object 1690 00:58:38,990 --> 00:58:40,219 stuff is that once you dereference and 1691 00:58:40,220 --> 00:58:41,719 you're done, you're supposed to 1692 00:58:41,720 --> 00:58:43,549 dereference and then you know, you're 1693 00:58:43,550 --> 00:58:45,379 done with handle. And so quite often 1694 00:58:45,380 --> 00:58:47,389 you'll have these bugs where 1695 00:58:48,800 --> 00:58:50,929 basically like let's say you 1696 00:58:50,930 --> 00:58:52,819 have some kind of exception that gets 1697 00:58:52,820 --> 00:58:54,449 thrown and you forget the leak, you 1698 00:58:54,450 --> 00:58:55,489 forget to do you have a handle 1699 00:58:56,690 --> 00:58:58,909 and also just handle leaks so 1700 00:58:58,910 --> 00:59:00,709 that this is a no sort of accounting 1701 00:59:00,710 --> 00:59:02,799 county bug except a problem with this. 1702 00:59:02,800 --> 00:59:04,879 If this is repeatable 1703 00:59:04,880 --> 00:59:07,429 most like you, let's say you 1704 00:59:07,430 --> 00:59:08,869 through two bits of this, if you can 1705 00:59:08,870 --> 00:59:10,969 repeat, is about four billion times, you 1706 00:59:10,970 --> 00:59:12,379 can overflow to zero. 1707 00:59:12,380 --> 00:59:14,599 And all of a sudden you have a. 1708 00:59:14,600 --> 00:59:15,600 I've got. 1709 00:59:16,590 --> 00:59:17,590 Awesome, perfect. 1710 00:59:19,170 --> 00:59:21,269 So if if you're in all 1711 00:59:21,270 --> 00:59:23,519 of a sudden it goes zero, you object, 1712 00:59:23,520 --> 00:59:24,569 it's freed, but you may still have 1713 00:59:24,570 --> 00:59:26,129 reference to it. And also when you get 1714 00:59:26,130 --> 00:59:28,559 these these use after free cases, 1715 00:59:29,970 --> 00:59:32,309 as of, I think, Windows eight, 1716 00:59:32,310 --> 00:59:34,919 there has been called attitude 1717 00:59:34,920 --> 00:59:37,349 of reference calls where basically 1718 00:59:37,350 --> 00:59:39,389 they the your flow, when an interval 1719 00:59:39,390 --> 00:59:41,819 happens, they cause 1720 00:59:41,820 --> 00:59:43,379 a kernel panic. 1721 00:59:43,380 --> 00:59:44,879 And so all of a sudden these bugs are no 1722 00:59:44,880 --> 00:59:47,609 longer exploitable beyond the leak, 1723 00:59:47,610 --> 00:59:49,949 which is great, but up to one seven. 1724 00:59:49,950 --> 00:59:51,359 That was a little problem. 1725 00:59:51,360 --> 00:59:53,519 Related issues are a double Refco 1726 00:59:53,520 --> 00:59:55,709 increase use after 1727 00:59:55,710 --> 00:59:57,869 reference at a passing of no 1728 00:59:57,870 --> 01:00:00,029 and the fixed basically always 1729 01:00:00,030 --> 01:00:01,929 BALSHAW reference calls. 1730 01:00:01,930 --> 01:00:02,930 Uh. 1731 01:00:05,510 --> 01:00:07,309 And I'm done 1732 01:00:08,840 --> 01:00:09,840 with. 1733 01:00:15,510 --> 01:00:17,699 Well, unfortunately, we do 1734 01:00:17,700 --> 01:00:20,059 not have time for questions.