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/881 Thanks! 1 00:00:15,180 --> 00:00:17,819 Let's have a big hand for 11 2 00:00:17,820 --> 00:00:18,820 spangle. 3 00:00:27,150 --> 00:00:29,609 Also, OK, yes, 4 00:00:29,610 --> 00:00:31,529 so as previously mentioned by terrorists, 5 00:00:31,530 --> 00:00:33,719 are all of these created equally a 6 00:00:33,720 --> 00:00:36,479 survey of Colonel Variabilities 7 00:00:37,500 --> 00:00:38,729 Strafford? Who am I? 8 00:00:38,730 --> 00:00:40,589 My name is Julie Fundamental. 9 00:00:40,590 --> 00:00:42,929 I work for a company called Bioactive. 10 00:00:42,930 --> 00:00:45,059 I did spend the last five years in 11 00:00:45,060 --> 00:00:46,889 America, but I recently moved back to 12 00:00:46,890 --> 00:00:48,059 Belgium a couple of weeks ago. 13 00:00:49,110 --> 00:00:51,179 I am a computer expert and 14 00:00:51,180 --> 00:00:53,429 I do fantastical review I 15 00:00:53,430 --> 00:00:55,139 Brigstock for a profit. 16 00:00:55,140 --> 00:00:56,279 I've been going to this U.S. 17 00:00:56,280 --> 00:00:58,709 Congress since 1983 three. 18 00:00:58,710 --> 00:00:59,819 It's been a while and I've spoken a 19 00:00:59,820 --> 00:01:01,469 couple of times before. 20 00:01:01,470 --> 00:01:03,119 I think this will be my seven or eight 21 00:01:03,120 --> 00:01:05,219 time and let's see 22 00:01:05,220 --> 00:01:06,220 how this goes. 23 00:01:06,960 --> 00:01:09,179 Right. So my meditation is sort of split 24 00:01:09,180 --> 00:01:12,149 into three, four ish pieces. 25 00:01:12,150 --> 00:01:13,109 There's was an intro which will be the 26 00:01:13,110 --> 00:01:15,029 next slide, and then there's a little bit 27 00:01:15,030 --> 00:01:17,159 of data that I'll show and then 28 00:01:17,160 --> 00:01:18,569 there's lack of data. So I want to test a 29 00:01:18,570 --> 00:01:20,399 couple of things. And then once I've 30 00:01:20,400 --> 00:01:22,829 tested that and get some results 31 00:01:22,830 --> 00:01:24,510 to present my results and my conclusions. 32 00:01:25,760 --> 00:01:27,159 Oh, right. 33 00:01:27,160 --> 00:01:28,339 So what did you talk about, because you 34 00:01:28,340 --> 00:01:29,629 couldn't vulnerability's it's a 35 00:01:29,630 --> 00:01:31,789 comparison between the different 36 00:01:31,790 --> 00:01:35,089 current bisdee flavors. 37 00:01:35,090 --> 00:01:37,309 As for what I expect from the audience, 38 00:01:37,310 --> 00:01:39,409 if you really expect 39 00:01:39,410 --> 00:01:41,479 some basic Unix kernel 40 00:01:41,480 --> 00:01:43,759 ish knowledge, not too deep, but some 41 00:01:43,760 --> 00:01:45,859 would be nice people that I 42 00:01:45,860 --> 00:01:47,119 think might appreciate the stock. 43 00:01:47,120 --> 00:01:48,229 Or, you know, if you're a low level 44 00:01:48,230 --> 00:01:49,729 security issues. Yes. 45 00:01:49,730 --> 00:01:51,559 If you're you is the biggest geek and 46 00:01:51,560 --> 00:01:53,389 then if you're Linux guy, you might like 47 00:01:53,390 --> 00:01:54,289 this, too. 48 00:01:54,290 --> 00:01:55,639 And then generally people are curious 49 00:01:55,640 --> 00:01:57,859 about OS internal security, 50 00:01:57,860 --> 00:01:59,419 I think might enjoy this presentation 51 00:02:01,710 --> 00:02:03,049 or move on. I have to mention, you know, 52 00:02:03,050 --> 00:02:05,119 some people that I call just 53 00:02:05,120 --> 00:02:06,109 standing on the shoulders of giants 54 00:02:06,110 --> 00:02:08,209 because you don't do this by yourself, 55 00:02:08,210 --> 00:02:09,589 you build upon work by others. 56 00:02:09,590 --> 00:02:11,959 So there's a number of people that have 57 00:02:11,960 --> 00:02:13,369 done interesting musicale security 58 00:02:13,370 --> 00:02:15,559 research over the last decade 59 00:02:15,560 --> 00:02:17,779 and a half, maybe two decades. 60 00:02:17,780 --> 00:02:19,909 Some of them might even be at a Congress. 61 00:02:19,910 --> 00:02:22,189 So Silvio 62 00:02:22,190 --> 00:02:23,959 Bunch others that did some really 63 00:02:23,960 --> 00:02:24,960 interesting work. 64 00:02:26,420 --> 00:02:28,610 So really, this just sort of started with 65 00:02:30,470 --> 00:02:32,569 a post to a mailing list years and 66 00:02:32,570 --> 00:02:34,669 years ago by Theodorus, 67 00:02:34,670 --> 00:02:37,129 who, if you don't know who he is, is the 68 00:02:37,130 --> 00:02:39,829 the main guy behind OpenBSD. 69 00:02:39,830 --> 00:02:41,509 And I remember reading this 12 years ago, 70 00:02:41,510 --> 00:02:43,729 and it's been sort of stuck in my head 71 00:02:43,730 --> 00:02:45,139 since then. 72 00:02:45,140 --> 00:02:46,759 And it's basically a quote from Theo 73 00:02:46,760 --> 00:02:48,739 where he goes, you know, if the Linux 74 00:02:48,740 --> 00:02:50,629 people actually cared about quality, you 75 00:02:50,630 --> 00:02:52,579 know, as the obviously people do, they 76 00:02:52,580 --> 00:02:54,319 wouldn't they would not have had as many 77 00:02:54,320 --> 00:02:56,629 local root security holes as they had 78 00:02:56,630 --> 00:02:59,089 last year, which is that year, which is 79 00:02:59,090 --> 00:03:01,249 2005. And goes how many is it like 80 00:03:01,250 --> 00:03:02,250 20 or so. 81 00:03:03,980 --> 00:03:06,499 And so I think that was 82 00:03:06,500 --> 00:03:07,969 you know, when you make that sort of, oh, 83 00:03:07,970 --> 00:03:09,259 20 or so, I was like, really? 84 00:03:09,260 --> 00:03:11,029 You know, is that true? Is what's the 85 00:03:11,030 --> 00:03:12,739 data behind that? Can we look at some of 86 00:03:12,740 --> 00:03:13,819 this? 87 00:03:13,820 --> 00:03:16,189 And so I basically started looking at 88 00:03:16,190 --> 00:03:18,379 the last almost 20 89 00:03:18,380 --> 00:03:20,509 years of Linux kernel vulnerabilities and 90 00:03:20,510 --> 00:03:21,769 what the numbers are. 91 00:03:21,770 --> 00:03:23,599 And so I went to KVI details and they 92 00:03:23,600 --> 00:03:25,759 basically keep a record of his stuff. 93 00:03:25,760 --> 00:03:27,830 And it goes back to 1999. 94 00:03:29,690 --> 00:03:30,799 And if you look at it, you know, the 95 00:03:30,800 --> 00:03:32,599 first three or four years, it's, you 96 00:03:32,600 --> 00:03:34,849 know, in the teens and then Sirnak, 97 00:03:34,850 --> 00:03:37,279 2004, 2005, it sort of jumps up, 98 00:03:37,280 --> 00:03:39,229 goes up into the hundreds. 99 00:03:39,230 --> 00:03:41,929 And then this actually is this table is 100 00:03:41,930 --> 00:03:42,889 from July of this year. 101 00:03:42,890 --> 00:03:45,499 So 2070 numbers are correct. 102 00:03:45,500 --> 00:03:47,659 And so in July 103 00:03:47,660 --> 00:03:49,819 2017, it was three hundred 104 00:03:49,820 --> 00:03:51,229 forty six abilities. 105 00:03:51,230 --> 00:03:53,059 But as of today, because I checked 106 00:03:53,060 --> 00:03:56,059 earlier, it was 434 107 00:03:56,060 --> 00:03:58,129 political vulnerabilities. 108 00:03:58,130 --> 00:04:00,499 And so as you see, these numbers 109 00:04:00,500 --> 00:04:01,759 are kind of sort of growing 110 00:04:03,140 --> 00:04:04,579 now. 111 00:04:04,580 --> 00:04:07,429 CVT doesn't have the same numbers for 112 00:04:07,430 --> 00:04:09,379 like BSD kernel issues. 113 00:04:09,380 --> 00:04:10,669 They have like general abused the 114 00:04:10,670 --> 00:04:12,829 numbers, but that that's all encompassing 115 00:04:12,830 --> 00:04:15,559 to OS. And I wanted to specific 116 00:04:15,560 --> 00:04:16,819 because the kernel numbers. 117 00:04:16,820 --> 00:04:18,679 And so what I did is I sort of scraped 118 00:04:18,680 --> 00:04:20,539 off freebees the MusicNet because the 119 00:04:20,540 --> 00:04:22,759 numbers I sort of put them into a nice 120 00:04:22,760 --> 00:04:24,049 little table. 121 00:04:24,050 --> 00:04:25,050 And if you look at the 122 00:04:26,180 --> 00:04:28,249 tables here for the BSD, you'll 123 00:04:28,250 --> 00:04:29,779 see that the first couple of years are 124 00:04:29,780 --> 00:04:31,339 kind of on par with Linux, but then the 125 00:04:31,340 --> 00:04:33,949 links ones kind of explode 126 00:04:33,950 --> 00:04:36,139 and the easy ones will sort of more 127 00:04:36,140 --> 00:04:38,629 or less the same, either single digits 128 00:04:38,630 --> 00:04:39,630 or low teens. 129 00:04:40,490 --> 00:04:41,749 It doesn't really go over 17. 130 00:04:41,750 --> 00:04:44,419 And that's that was only just a 131 00:04:44,420 --> 00:04:45,420 year ago. 132 00:04:46,220 --> 00:04:48,109 So if you look at these numbers, two 133 00:04:48,110 --> 00:04:49,959 observation was pretty, pretty astute 134 00:04:49,960 --> 00:04:51,469 observation. 135 00:04:51,470 --> 00:04:54,289 In fact, 20 was a low estimate. 136 00:04:54,290 --> 00:04:55,730 It turns out it was significantly more. 137 00:04:56,960 --> 00:04:58,849 And so you see that numbers for the 138 00:04:58,850 --> 00:05:00,979 analytics over the years 139 00:05:00,980 --> 00:05:03,139 are not the same or not on the same 140 00:05:03,140 --> 00:05:04,219 level. 141 00:05:04,220 --> 00:05:05,659 And so what I asked is, are they on equal 142 00:05:05,660 --> 00:05:07,849 footing? Like, obviously 143 00:05:07,850 --> 00:05:09,979 there's a really large family 144 00:05:09,980 --> 00:05:11,899 behind Luse. Colonel, if you look at the 145 00:05:11,900 --> 00:05:13,789 BSD, you know, that's a small group of 146 00:05:13,790 --> 00:05:15,859 developers, a small group of users that 147 00:05:15,860 --> 00:05:17,569 are using these things and compiling 148 00:05:17,570 --> 00:05:19,609 themselves and and so forth. 149 00:05:19,610 --> 00:05:21,859 And so I wonder if that is 150 00:05:21,860 --> 00:05:23,299 if that's the reason or if there is a 151 00:05:23,300 --> 00:05:25,399 reason why the numbers aren't the same or 152 00:05:25,400 --> 00:05:27,289 if it really is, as you said, if it's 153 00:05:27,290 --> 00:05:28,249 good quality. 154 00:05:28,250 --> 00:05:29,149 And obviously, one of the things I 155 00:05:29,150 --> 00:05:30,469 consider as well, maybe it's too many 156 00:05:30,470 --> 00:05:32,869 eyeballs thing and I know there's 157 00:05:32,870 --> 00:05:35,029 Meribel thing is, you know, 158 00:05:35,030 --> 00:05:36,619 very convoluted thing, but but there's 159 00:05:36,620 --> 00:05:38,329 some truth to that. 160 00:05:38,330 --> 00:05:39,799 And so I was wondering if there's some 161 00:05:39,800 --> 00:05:40,970 truth to it in this case. 162 00:05:42,280 --> 00:05:43,879 Well, and the only way to really do that 163 00:05:43,880 --> 00:05:46,109 is to to test it, 164 00:05:46,110 --> 00:05:48,589 to go and see what what 165 00:05:48,590 --> 00:05:50,719 what the code is really like. 166 00:05:50,720 --> 00:05:52,879 And sure enough, there's a guy that 167 00:05:52,880 --> 00:05:55,009 did this 15 168 00:05:55,010 --> 00:05:56,329 years ago, Sylvia, 169 00:05:57,500 --> 00:05:59,959 and confrontation about this 170 00:05:59,960 --> 00:06:02,060 2003, 14 years ago. 171 00:06:03,830 --> 00:06:06,229 And basically they 172 00:06:06,230 --> 00:06:08,419 did an audit of the kernel and 173 00:06:08,420 --> 00:06:10,069 sort of drew some clues from that. 174 00:06:10,070 --> 00:06:12,199 And one of the things that he said was he 175 00:06:12,200 --> 00:06:14,299 said, well, 176 00:06:14,300 --> 00:06:15,289 there really isn't much difference 177 00:06:15,290 --> 00:06:17,449 between the colonel and the colonels 178 00:06:17,450 --> 00:06:19,879 in terms of security auditing. 179 00:06:19,880 --> 00:06:21,829 They're equally broken. 180 00:06:21,830 --> 00:06:23,419 It's easy enough to find bugs in both of 181 00:06:23,420 --> 00:06:25,959 them and the same kind of bugs. 182 00:06:25,960 --> 00:06:27,640 Now, that was 15 years ago. 183 00:06:29,590 --> 00:06:31,479 Have things changed since then? 184 00:06:31,480 --> 00:06:33,669 The other thing I said was that he only 185 00:06:33,670 --> 00:06:35,409 spent a couple of days and then three 186 00:06:35,410 --> 00:06:37,119 months on Linux. 187 00:06:37,120 --> 00:06:39,579 And so if you spend longer 188 00:06:39,580 --> 00:06:41,859 on the BSD, would that have 189 00:06:41,860 --> 00:06:43,899 we've got more bugs or would you sort of 190 00:06:43,900 --> 00:06:45,209 hit a limit? Right. 191 00:06:45,210 --> 00:06:46,989 And then third one is if you look at his 192 00:06:46,990 --> 00:06:49,479 presentation and this is 15 years ago, 193 00:06:49,480 --> 00:06:51,699 he mostly looked for a mostly 194 00:06:51,700 --> 00:06:54,189 found Trivellato flows 195 00:06:54,190 --> 00:06:56,349 and Infl and nothing 196 00:06:56,350 --> 00:06:58,419 else. And so the only ahead is what if 197 00:06:58,420 --> 00:07:00,279 I expand the number of bugs that look for 198 00:07:00,280 --> 00:07:01,510 what if you will, look for, you know, 199 00:07:02,980 --> 00:07:04,959 race conditions and things like that. 200 00:07:06,580 --> 00:07:08,709 And so the data is interesting, but it's 201 00:07:08,710 --> 00:07:11,439 kind of a little bit outdated and a 202 00:07:11,440 --> 00:07:13,779 bit too limited at the time. 203 00:07:13,780 --> 00:07:16,119 I think it was perfect for 204 00:07:16,120 --> 00:07:17,799 today's purposes. It's not quite good 205 00:07:17,800 --> 00:07:19,059 enough. 206 00:07:19,060 --> 00:07:21,009 And so the only way to really figure out 207 00:07:21,010 --> 00:07:23,199 if those numbers line up or don't line 208 00:07:23,200 --> 00:07:25,359 up what the reason is, is I have to dig 209 00:07:25,360 --> 00:07:25,989 in myself. 210 00:07:25,990 --> 00:07:28,119 And so I spent April, May, June 211 00:07:28,120 --> 00:07:30,379 and July of this year looking at 212 00:07:30,380 --> 00:07:31,380 the code. 213 00:07:32,110 --> 00:07:33,399 I don't know exactly how much time I 214 00:07:33,400 --> 00:07:35,139 spend on each one of them, but I would 215 00:07:35,140 --> 00:07:36,329 say they're more or less equal. 216 00:07:38,470 --> 00:07:40,059 And so basically what I did is I asked 217 00:07:40,060 --> 00:07:42,399 myself if I was going to look for bugs, 218 00:07:42,400 --> 00:07:43,599 where would the bugs be? 219 00:07:43,600 --> 00:07:44,919 Where do I think they would make 220 00:07:44,920 --> 00:07:45,920 mistakes? 221 00:07:46,760 --> 00:07:48,369 And so I made a list of sort of attack 222 00:07:48,370 --> 00:07:50,769 surfaces that I wanted to go look at. 223 00:07:50,770 --> 00:07:52,629 And none of these are, I think, overly 224 00:07:52,630 --> 00:07:54,789 surprising, obviously, to the 225 00:07:54,790 --> 00:07:56,439 common stuff is like, yeah, obviously, 226 00:07:56,440 --> 00:07:57,459 I'm going to take a look at some of these 227 00:07:57,460 --> 00:07:59,529 calls and I'll take a look at the DSP 228 00:07:59,530 --> 00:08:01,659 stack and then, yeah, I'll take 229 00:08:01,660 --> 00:08:03,469 a look at some drivers and I'll look at 230 00:08:03,470 --> 00:08:05,049 the complete code and a trap handlers in 231 00:08:05,050 --> 00:08:07,269 the filesystems and, you know, other 232 00:08:07,270 --> 00:08:08,789 networking stuff. 233 00:08:08,790 --> 00:08:10,629 And I essentially spend three months 234 00:08:10,630 --> 00:08:11,630 looking at that. 235 00:08:12,370 --> 00:08:14,079 And so when I want to do is I want to 236 00:08:14,080 --> 00:08:16,299 jump over some of the things that in each 237 00:08:16,300 --> 00:08:18,699 of those areas that I found 238 00:08:18,700 --> 00:08:19,809 and as were discussed at 239 00:08:20,830 --> 00:08:23,259 briefly and I have a couple of demos 240 00:08:23,260 --> 00:08:24,260 in here as well. 241 00:08:25,450 --> 00:08:27,249 And then once I've run through that, I'll 242 00:08:27,250 --> 00:08:29,079 sort of run you through my results and my 243 00:08:29,080 --> 00:08:30,609 conclusions. 244 00:08:30,610 --> 00:08:31,959 So, yeah, so let's dove in the system, 245 00:08:31,960 --> 00:08:34,408 cause obviously this is 246 00:08:34,409 --> 00:08:35,409 a attack surface. 247 00:08:36,880 --> 00:08:39,009 I don't think it should be anybody that, 248 00:08:39,010 --> 00:08:40,519 you know, if you're looking for Syria, 249 00:08:40,520 --> 00:08:41,439 because the first thing you want to do is 250 00:08:41,440 --> 00:08:42,788 look at system calls, because that's the 251 00:08:42,789 --> 00:08:44,889 thing where user talks, the 252 00:08:44,890 --> 00:08:46,149 kernel. 253 00:08:46,150 --> 00:08:48,669 And the first thing that that you can see 254 00:08:48,670 --> 00:08:49,780 or can observe is that 255 00:08:51,130 --> 00:08:53,199 among the three big BSD, 256 00:08:53,200 --> 00:08:54,609 there's a difference in the amount of 257 00:08:54,610 --> 00:08:56,079 system calls that are implemented. 258 00:08:56,080 --> 00:08:58,599 Right. VBAC has well over five hundred 259 00:08:58,600 --> 00:09:01,089 net boards, almost five hundred, and 260 00:09:01,090 --> 00:09:03,159 obviously has, you know, about 300 and 261 00:09:03,160 --> 00:09:04,389 change. 262 00:09:04,390 --> 00:09:06,489 So right then and there, there's a 263 00:09:06,490 --> 00:09:08,109 clear difference between attack surface 264 00:09:08,110 --> 00:09:09,249 between three of them. 265 00:09:09,250 --> 00:09:10,449 Right. 266 00:09:10,450 --> 00:09:12,609 But but even sort of regardless of tax, 267 00:09:12,610 --> 00:09:14,949 it was my assumption was, given 268 00:09:14,950 --> 00:09:17,139 that these are so obvious and so well 269 00:09:17,140 --> 00:09:19,239 tested, they're less likely 270 00:09:19,240 --> 00:09:21,129 to contain security bugs. 271 00:09:21,130 --> 00:09:23,229 And so, you know, I go along and I 272 00:09:23,230 --> 00:09:24,489 start looking and I start looking at 273 00:09:24,490 --> 00:09:26,109 system calls. I start playing with them. 274 00:09:26,110 --> 00:09:28,329 And sure enough, this is not system 275 00:09:28,330 --> 00:09:30,429 call and it's the census log. 276 00:09:30,430 --> 00:09:32,079 And you get to give you a number of 277 00:09:32,080 --> 00:09:33,549 bytes. And basically that 278 00:09:34,570 --> 00:09:36,609 gets passed on eventually to Malac. 279 00:09:36,610 --> 00:09:39,279 And I think about 280 00:09:39,280 --> 00:09:40,209 ancient code. 281 00:09:40,210 --> 00:09:41,289 Nobody has this. 282 00:09:41,290 --> 00:09:43,419 If you pass it on to Mallach, you 283 00:09:43,420 --> 00:09:45,189 get an institutional panic. 284 00:09:45,190 --> 00:09:46,419 And sure enough, that's what happens if 285 00:09:46,420 --> 00:09:47,829 you do just log in and give it a real 286 00:09:47,830 --> 00:09:48,849 value. 287 00:09:48,850 --> 00:09:49,850 The thing blows up 288 00:09:50,980 --> 00:09:53,109 and actually have a demo of this. 289 00:09:53,110 --> 00:09:54,129 I don't know how this is going to work on 290 00:09:54,130 --> 00:09:55,209 the screens. Let's see if I can get this 291 00:09:55,210 --> 00:09:56,210 to work. 292 00:10:00,800 --> 00:10:01,800 And. 293 00:10:07,630 --> 00:10:09,759 Yeah, on. 294 00:10:15,290 --> 00:10:16,290 Uh. 295 00:10:21,650 --> 00:10:23,209 Yeah, OK. 296 00:10:23,210 --> 00:10:24,979 Crap, it's not marrying on my screen, so 297 00:10:24,980 --> 00:10:26,509 it's kind of annoying to see this. 298 00:10:26,510 --> 00:10:27,729 Hold on. 299 00:10:27,730 --> 00:10:28,730 OK. 300 00:10:29,620 --> 00:10:31,689 So there's obviously and this is my 301 00:10:31,690 --> 00:10:33,939 example and sure enough, boom, 302 00:10:33,940 --> 00:10:34,990 that caused the kernel panic. 303 00:10:43,550 --> 00:10:44,550 OK, 304 00:10:46,400 --> 00:10:48,199 so that's the Similac and that's the 305 00:10:48,200 --> 00:10:49,459 kernel panic. There you go. 306 00:10:49,460 --> 00:10:50,690 And so what's happening is basically 307 00:10:52,130 --> 00:10:54,709 uses this the this log says call 308 00:10:54,710 --> 00:10:57,019 and you pass it on about value and cause 309 00:10:57,020 --> 00:10:58,549 panic and malac. 310 00:10:58,550 --> 00:11:00,949 This is not me. This is one 311 00:11:00,950 --> 00:11:02,009 I haven't looked at the little ones. 312 00:11:02,010 --> 00:11:04,369 I know it's been fixed since, but it's 313 00:11:04,370 --> 00:11:05,539 been there will be six points here. 314 00:11:05,540 --> 00:11:07,879 So it's a fairly recent 315 00:11:07,880 --> 00:11:08,880 bug. 316 00:11:10,550 --> 00:11:12,169 So and here's the second example. 317 00:11:12,170 --> 00:11:14,299 This is a system call on 318 00:11:14,300 --> 00:11:16,129 previously called Kaldi Stat, which 319 00:11:16,130 --> 00:11:18,109 basically gives you statistics about 320 00:11:18,110 --> 00:11:20,029 kernel drivers. 321 00:11:20,030 --> 00:11:22,279 And this thing basically creates as 322 00:11:22,280 --> 00:11:23,840 this stat bar from the stack 323 00:11:25,070 --> 00:11:26,819 fills it out and then sends it back to 324 00:11:26,820 --> 00:11:28,669 user land, but it doesn't fill out 325 00:11:28,670 --> 00:11:30,589 everything. And so you get initialize 326 00:11:30,590 --> 00:11:31,590 bytes in there. 327 00:11:32,300 --> 00:11:34,169 This has been found. 328 00:11:34,170 --> 00:11:36,349 And if you use the 11 but 329 00:11:36,350 --> 00:11:38,779 it's been in there for over 330 00:11:38,780 --> 00:11:39,830 just over a decade, 331 00:11:40,990 --> 00:11:42,919 doesn't fully initialize a structure and 332 00:11:42,920 --> 00:11:45,549 basically sits back to Ireland. 333 00:11:45,550 --> 00:11:48,019 And then I 334 00:11:48,020 --> 00:11:49,309 let me see if I can show you the name of 335 00:11:49,310 --> 00:11:50,310 this to. 336 00:12:00,900 --> 00:12:03,179 This is KDDI leak and then. 337 00:12:06,410 --> 00:12:07,939 And then basically all these bites are on 338 00:12:07,940 --> 00:12:09,799 his memory that's basically flashing over 339 00:12:09,800 --> 00:12:10,800 the screen. 340 00:12:18,720 --> 00:12:20,699 So that's that's basically bag number 341 00:12:20,700 --> 00:12:22,529 two, where you get to basically lead a 342 00:12:22,530 --> 00:12:23,530 whole bunch of 343 00:12:24,720 --> 00:12:25,720 initialized Crameri. 344 00:12:27,660 --> 00:12:29,339 So basically my previous assumption was 345 00:12:29,340 --> 00:12:31,469 wrong, right? When I said that, 346 00:12:31,470 --> 00:12:33,419 I assumed that because the system calls 347 00:12:33,420 --> 00:12:35,599 so well tested that it's like less 348 00:12:35,600 --> 00:12:36,959 like bugs in them. Well, that turns out 349 00:12:36,960 --> 00:12:38,879 to be entirely wrong. 350 00:12:38,880 --> 00:12:41,159 You can find bugs in the system causing 351 00:12:41,160 --> 00:12:43,349 the BSD within, 352 00:12:43,350 --> 00:12:46,169 you know, fairly quickly, fairly easily. 353 00:12:46,170 --> 00:12:48,779 Bugs that aren't too esoteric 354 00:12:48,780 --> 00:12:51,119 or too too weird, fairly straight, 355 00:12:51,120 --> 00:12:53,229 straightforward bugs, especially 356 00:12:53,230 --> 00:12:54,869 in newly assistant calls. 357 00:12:54,870 --> 00:12:56,939 But even the older stuff, as you 358 00:12:56,940 --> 00:12:58,709 can see, a 10 year old system called in 359 00:12:58,710 --> 00:13:01,559 previously still had a trivial 360 00:13:01,560 --> 00:13:03,380 info leak. So those things do occur. 361 00:13:06,440 --> 00:13:08,569 Right, so now that we know there are bugs 362 00:13:08,570 --> 00:13:10,119 in system calls and they're fairly 363 00:13:10,120 --> 00:13:12,200 defined, let's move on to Giuseppe Stack. 364 00:13:13,730 --> 00:13:15,319 This one again. My assumption is it's 365 00:13:15,320 --> 00:13:16,579 very well tested and less likely to have 366 00:13:16,580 --> 00:13:18,919 bugs because we all know the 367 00:13:18,920 --> 00:13:21,259 risk has been around for ages since 368 00:13:21,260 --> 00:13:23,329 the 80s at least, and it's incredibly 369 00:13:23,330 --> 00:13:25,639 well tested and highly 370 00:13:25,640 --> 00:13:27,529 unlikely to find bugs in there. 371 00:13:27,530 --> 00:13:29,569 And for those who know what this is, all 372 00:13:29,570 --> 00:13:31,179 things like before and every 600 373 00:13:32,210 --> 00:13:34,599 ICMP, IP, SEC, 374 00:13:34,600 --> 00:13:35,809 Internet and things like that, 375 00:13:36,890 --> 00:13:38,389 it's been around forever. 376 00:13:38,390 --> 00:13:40,609 And so my assumption is unlikely 377 00:13:40,610 --> 00:13:42,199 to have bugs in there. 378 00:13:42,200 --> 00:13:44,329 So I start looking around and I found 379 00:13:44,330 --> 00:13:45,859 something which is restack, which 380 00:13:45,860 --> 00:13:46,860 basically 381 00:13:48,100 --> 00:13:49,100 passes, parses 382 00:13:50,360 --> 00:13:52,549 packets. And then it's a little 383 00:13:52,550 --> 00:13:55,489 bit convoluted, I guess. 384 00:13:55,490 --> 00:13:57,769 But basically the idea is that you take 385 00:13:57,770 --> 00:13:59,179 it back and you start parsing it. 386 00:13:59,180 --> 00:14:01,339 And then if it contains 387 00:14:01,340 --> 00:14:03,859 the exact right tag and 388 00:14:03,860 --> 00:14:06,949 the right error message, basically it 389 00:14:06,950 --> 00:14:08,989 actually does this thing. 390 00:14:08,990 --> 00:14:12,109 We're so into BSD, 391 00:14:12,110 --> 00:14:13,519 the way these Biersack works, they have 392 00:14:13,520 --> 00:14:15,319 this thing called EMBOSS and it's 393 00:14:15,320 --> 00:14:17,119 basically it's for management around data 394 00:14:17,120 --> 00:14:19,669 that you send in and out. 395 00:14:19,670 --> 00:14:20,779 And so there's a whole bunch of APIs 396 00:14:20,780 --> 00:14:22,849 around it. Right. And the idea is that if 397 00:14:22,850 --> 00:14:24,859 you don't use the API correctly, things 398 00:14:24,860 --> 00:14:26,239 go really wrong. 399 00:14:26,240 --> 00:14:28,219 And so in this case, you see this thing 400 00:14:28,220 --> 00:14:29,899 called and pull down. 401 00:14:29,900 --> 00:14:33,529 And basically, if Pull-down fails, 402 00:14:33,530 --> 00:14:35,719 it will freedom. But you passed it. 403 00:14:35,720 --> 00:14:37,299 And in this case, you'll see over of my 404 00:14:37,300 --> 00:14:39,139 fields there's error code where basically 405 00:14:39,140 --> 00:14:41,209 to do what you done and then in done, 406 00:14:41,210 --> 00:14:43,489 they're basically free, except if 407 00:14:43,490 --> 00:14:45,720 the thing failed, DMSO retreat. 408 00:14:46,940 --> 00:14:48,889 So this is even though the code to live 409 00:14:48,890 --> 00:14:50,959 the read, it's a relatively easy 410 00:14:50,960 --> 00:14:53,309 bug you trigger it affects 411 00:14:53,310 --> 00:14:54,559 is the six point one. 412 00:14:54,560 --> 00:14:56,449 But it has been there since 2004, so it's 413 00:14:56,450 --> 00:14:57,529 been around for over a decade. 414 00:14:58,970 --> 00:15:00,079 It turns out when I was looking at this 415 00:15:00,080 --> 00:15:02,429 and I found a bug, I checked Stuxnet 416 00:15:02,430 --> 00:15:04,519 because it turns out that these guys have 417 00:15:04,520 --> 00:15:07,069 the same bug, but they fixed it, 418 00:15:07,070 --> 00:15:08,089 but they never release any kind of 419 00:15:08,090 --> 00:15:09,090 advisory for it. 420 00:15:10,430 --> 00:15:12,319 And so clearly, I had never told you guys 421 00:15:12,320 --> 00:15:12,679 about it. 422 00:15:12,680 --> 00:15:15,189 And so they fixed 423 00:15:15,190 --> 00:15:16,129 it means you guys won't fix it. 424 00:15:16,130 --> 00:15:17,130 But I emailed him about it. 425 00:15:18,320 --> 00:15:20,429 And so this bug was, you know, 426 00:15:20,430 --> 00:15:22,489 look for this work was relatively 427 00:15:22,490 --> 00:15:24,049 easy to find. And so, again, my previous 428 00:15:24,050 --> 00:15:25,190 assumption was wrong. 429 00:15:26,570 --> 00:15:28,789 Bugs and Giuseppe's attack do occur 430 00:15:28,790 --> 00:15:30,949 with some frequency in particular 431 00:15:30,950 --> 00:15:33,409 new record. But also, it turns out 432 00:15:33,410 --> 00:15:35,479 and buffs are hard, very 433 00:15:35,480 --> 00:15:37,489 complicated, and it's error prone. 434 00:15:37,490 --> 00:15:39,829 The APIs aren't overly consistent, 435 00:15:39,830 --> 00:15:41,299 about half of them sort of when they fail 436 00:15:41,300 --> 00:15:42,709 the freedom of the other half. 437 00:15:42,710 --> 00:15:44,329 When they fail, they don't forget about 438 00:15:44,330 --> 00:15:47,149 things like that where it turns out 439 00:15:47,150 --> 00:15:49,429 if you have to use them barfs, it's 440 00:15:49,430 --> 00:15:50,389 not quite that easy. 441 00:15:50,390 --> 00:15:51,859 You have to know what you're doing. 442 00:15:51,860 --> 00:15:53,749 And there's a number of cases that I 443 00:15:53,750 --> 00:15:56,659 found where that doesn't happen 444 00:15:56,660 --> 00:15:58,340 and all sort of circle back to 445 00:15:59,780 --> 00:16:02,089 AmBev misuse later 446 00:16:02,090 --> 00:16:04,729 on when I talk about the wi fi stack. 447 00:16:04,730 --> 00:16:06,799 But anyway, it turns out 448 00:16:06,800 --> 00:16:07,800 Habsburgs, 449 00:16:09,090 --> 00:16:11,299 right? So moving on, I 450 00:16:11,300 --> 00:16:13,069 looked at some of the drivers, obviously, 451 00:16:13,070 --> 00:16:15,259 because it turns out that there 452 00:16:15,260 --> 00:16:17,270 is a whole lot of drivers among the uses 453 00:16:18,530 --> 00:16:20,359 for all sorts of things, really. 454 00:16:20,360 --> 00:16:22,009 And given that Unix testing where 455 00:16:22,010 --> 00:16:23,689 everything is a file, the way you find 456 00:16:23,690 --> 00:16:25,069 your drivers, you go to Dev and then 457 00:16:25,070 --> 00:16:26,839 Endeavor will have some kind of name and 458 00:16:26,840 --> 00:16:28,279 then you can do file you open them and 459 00:16:28,280 --> 00:16:30,229 then you can file operations on that 460 00:16:30,230 --> 00:16:31,879 thing. Right. So open read right. 461 00:16:31,880 --> 00:16:33,499 Close and so forth. 462 00:16:33,500 --> 00:16:35,629 But obviously I octal is the 463 00:16:35,630 --> 00:16:37,819 one that you want to look at because 464 00:16:37,820 --> 00:16:40,069 that's generally where most of the 465 00:16:40,070 --> 00:16:41,330 interesting attack surface will be. 466 00:16:42,710 --> 00:16:44,779 So this is this is the 467 00:16:44,780 --> 00:16:47,299 dev krypto on that BSD, 468 00:16:47,300 --> 00:16:48,589 which has this thing where you 469 00:16:49,670 --> 00:16:51,979 basically have this very, 470 00:16:51,980 --> 00:16:54,079 very trivial indro flow and then here 471 00:16:54,080 --> 00:16:55,080 you get memory corruption. 472 00:16:55,940 --> 00:16:57,859 And it's that this is just one snippet. 473 00:16:57,860 --> 00:16:59,239 But if you look at the actual driver, 474 00:16:59,240 --> 00:17:01,969 it's like an octal command 475 00:17:01,970 --> 00:17:03,829 bug. I have to command Sanberg Command 476 00:17:03,830 --> 00:17:05,659 Sanberg seven or eight times the same 477 00:17:05,660 --> 00:17:06,890 trivial 04 shows up 478 00:17:08,450 --> 00:17:10,189 and then sure enough, you trigger it. 479 00:17:10,190 --> 00:17:12,949 So the one I showed was this desire, 480 00:17:12,950 --> 00:17:13,969 but there are seven or eight others. 481 00:17:13,970 --> 00:17:16,338 And then again, let me see 482 00:17:16,339 --> 00:17:17,339 if I can. 483 00:17:18,520 --> 00:17:19,630 If I can demo this. 484 00:17:23,020 --> 00:17:24,129 Yeah, I think so running. 485 00:17:24,130 --> 00:17:26,348 No, I mean, it'll be commemorated in 486 00:17:26,349 --> 00:17:28,539 Philly in a time it won't actually crash 487 00:17:28,540 --> 00:17:29,919 because the memories guaranteed to be 488 00:17:29,920 --> 00:17:31,089 there, it's just an unrealized. 489 00:17:37,010 --> 00:17:39,319 So this is an episode 490 00:17:39,320 --> 00:17:41,569 and then quickdraw flow and then 491 00:17:41,570 --> 00:17:43,009 boom, sure, at the moment, Hatice, you 492 00:17:43,010 --> 00:17:45,080 get memory corruption when I was. 493 00:17:52,380 --> 00:17:54,749 Yeah, so this is a classic control flow 494 00:17:54,750 --> 00:17:56,129 leading to memory corruption. This is 495 00:17:56,130 --> 00:17:57,130 definitely explainable. 496 00:17:59,050 --> 00:18:01,199 And then this is a similar driver 497 00:18:01,200 --> 00:18:02,669 on the street because this is a driver 498 00:18:02,670 --> 00:18:05,399 called Kasim, which basically 499 00:18:05,400 --> 00:18:06,629 gives you access. 500 00:18:06,630 --> 00:18:08,309 It shows you, Colonel, symbols for 501 00:18:08,310 --> 00:18:09,509 freebasing. 502 00:18:09,510 --> 00:18:11,609 It's an official driver you can load. 503 00:18:11,610 --> 00:18:12,749 And they have this interesting thing 504 00:18:12,750 --> 00:18:15,079 where they do they implement 505 00:18:15,080 --> 00:18:16,559 that car. When they do open, they 506 00:18:16,560 --> 00:18:18,869 basically in the to the 507 00:18:18,870 --> 00:18:21,029 driver of driver 508 00:18:21,030 --> 00:18:23,529 files, specific data, 509 00:18:23,530 --> 00:18:26,759 they basically take a copy of a pointer 510 00:18:26,760 --> 00:18:29,040 that's very specific to your process. 511 00:18:30,150 --> 00:18:32,099 And then when you do unmap, they find 512 00:18:32,100 --> 00:18:33,900 that pointer and they basically use it. 513 00:18:35,790 --> 00:18:38,099 There is an interesting issue here 514 00:18:38,100 --> 00:18:40,319 with expired pointers where if you if 515 00:18:40,320 --> 00:18:42,449 I open the device and then 516 00:18:42,450 --> 00:18:44,159 I pass that file scripter along to a 517 00:18:44,160 --> 00:18:46,109 different process and I kill the original 518 00:18:46,110 --> 00:18:48,269 process and then that process 519 00:18:48,270 --> 00:18:50,339 doesn't EMAP, it's basically using 520 00:18:50,340 --> 00:18:51,779 that original pointer to the actual 521 00:18:51,780 --> 00:18:53,639 process, but the original process is 522 00:18:53,640 --> 00:18:55,379 dead. So you have this wild pointed. 523 00:18:55,380 --> 00:18:57,029 It's being used. 524 00:18:57,030 --> 00:18:58,769 This is essentially an expired pointer. 525 00:18:59,880 --> 00:19:01,739 And this is very problematic, it turns 526 00:19:01,740 --> 00:19:04,019 out, because you basically 527 00:19:04,020 --> 00:19:05,219 you're using a weapon I can point 528 00:19:05,220 --> 00:19:06,580 anywhere to read and write to. 529 00:19:09,000 --> 00:19:11,029 And and I wanted to I can't 530 00:19:12,290 --> 00:19:14,399 live because my export kind of sucks. 531 00:19:14,400 --> 00:19:15,659 And it takes three or four days to 532 00:19:15,660 --> 00:19:17,219 actually hit the bug. 533 00:19:17,220 --> 00:19:18,449 I could probably optimize it. 534 00:19:18,450 --> 00:19:19,649 I just haven't. 535 00:19:19,650 --> 00:19:22,169 And so you have to do with a screenshot. 536 00:19:22,170 --> 00:19:24,239 But this is essentially what happens if 537 00:19:24,240 --> 00:19:26,189 you hit the bug and then sure enough, 538 00:19:26,190 --> 00:19:27,420 yeah. If you look at this here, up to 539 00:19:28,560 --> 00:19:30,629 nine days, 540 00:19:30,630 --> 00:19:31,889 one hour. So it took nine days to 541 00:19:31,890 --> 00:19:34,019 actually hit the bug, but I did hit 542 00:19:34,020 --> 00:19:35,020 it. 543 00:19:42,060 --> 00:19:44,169 So that's it for the driver stuff, 544 00:19:44,170 --> 00:19:45,219 and there are many, many, many more 545 00:19:45,220 --> 00:19:46,569 driver examples, but I figure two's 546 00:19:46,570 --> 00:19:49,089 enough so compact 547 00:19:49,090 --> 00:19:51,969 coexisting in the BSD where basically 548 00:19:51,970 --> 00:19:54,099 they allow the US to sort of 549 00:19:54,100 --> 00:19:55,419 emulate a different OS. 550 00:19:55,420 --> 00:19:57,489 So if you have a binary that you can file 551 00:19:57,490 --> 00:19:58,689 for Linux and you're running on 552 00:19:58,690 --> 00:20:01,239 previously and you turn on the previously 553 00:20:01,240 --> 00:20:03,399 compatibility layer and 554 00:20:03,400 --> 00:20:04,989 you make sure that you have the right 555 00:20:04,990 --> 00:20:06,999 libraries and stuff installed, then your 556 00:20:07,000 --> 00:20:09,219 Linux binary will run perfectly or more 557 00:20:09,220 --> 00:20:11,379 or less perfectly on 558 00:20:11,380 --> 00:20:14,229 on your free Musea or Net BSD. 559 00:20:14,230 --> 00:20:15,579 And so you have these kind of the FDA and 560 00:20:15,580 --> 00:20:17,829 the FDA waivers for different operating 561 00:20:17,830 --> 00:20:18,909 systems. 562 00:20:18,910 --> 00:20:21,039 And so especially NEPI, as he has quite 563 00:20:21,040 --> 00:20:22,040 a few of them 564 00:20:23,380 --> 00:20:24,999 free because he has less of them and 565 00:20:25,000 --> 00:20:26,439 Otomi as he pretty much killed most of 566 00:20:26,440 --> 00:20:27,440 them. 567 00:20:27,700 --> 00:20:28,959 But it's essentially their free to 568 00:20:28,960 --> 00:20:30,909 different OS or older version of us. 569 00:20:30,910 --> 00:20:33,039 Or you know, you have 64 bit 570 00:20:33,040 --> 00:20:34,980 and you're supporting 32 bit for to do 571 00:20:36,040 --> 00:20:37,420 all that stuff goes through combat layer 572 00:20:38,740 --> 00:20:40,929 and basically that's basically 573 00:20:40,930 --> 00:20:41,979 has to eliminate a whole bunch of system 574 00:20:41,980 --> 00:20:43,029 costs. 575 00:20:43,030 --> 00:20:45,099 And when you I found a really 576 00:20:45,100 --> 00:20:47,379 nice quote by Tío about combat layers 577 00:20:47,380 --> 00:20:49,209 where it says, well, you know, the people 578 00:20:49,210 --> 00:20:50,889 that rely on the that layers don't care 579 00:20:50,890 --> 00:20:53,139 enough to maintain it. And the people who 580 00:20:53,140 --> 00:20:55,239 work on Moelis don't care about combat 581 00:20:55,240 --> 00:20:56,799 layers because they don't use them. 582 00:20:56,800 --> 00:20:58,419 And the cultures are aligned in the same 583 00:20:58,420 --> 00:21:00,729 direction and basically 584 00:21:00,730 --> 00:21:02,889 says compactly is rot very quickly 585 00:21:02,890 --> 00:21:04,119 and then it's absolutely true. 586 00:21:04,120 --> 00:21:06,249 And so an example of this is 587 00:21:06,250 --> 00:21:08,709 this is SVR for Campath 588 00:21:08,710 --> 00:21:10,989 code on Nepsa. 589 00:21:10,990 --> 00:21:12,459 That's your is ancient. 590 00:21:12,460 --> 00:21:14,289 Nobody nobody's use that in probably 20 591 00:21:14,290 --> 00:21:16,389 years, but it's there and they 592 00:21:16,390 --> 00:21:18,339 support it. And this is the thing called 593 00:21:18,340 --> 00:21:19,340 streams, which is 594 00:21:20,440 --> 00:21:22,569 it's kind of like sockets, but 595 00:21:22,570 --> 00:21:24,759 not and streams have been dead 596 00:21:24,760 --> 00:21:26,379 for a long time. 597 00:21:26,380 --> 00:21:28,629 But that vessel supports it in a server 598 00:21:28,630 --> 00:21:29,630 for combat. 599 00:21:30,670 --> 00:21:32,649 And they have this thing where basically 600 00:21:32,650 --> 00:21:33,650 the 601 00:21:37,660 --> 00:21:38,859 dysfunction that 602 00:21:39,910 --> 00:21:42,109 gets called, which is 603 00:21:42,110 --> 00:21:44,979 a pointer and basically 604 00:21:44,980 --> 00:21:46,000 the content of which 605 00:21:47,080 --> 00:21:48,849 is defined by Juland. 606 00:21:48,850 --> 00:21:50,509 And what they do is they basically grab 607 00:21:50,510 --> 00:21:52,899 the value off of it, uses an offset 608 00:21:52,900 --> 00:21:54,109 and then basically sort of dereference 609 00:21:54,110 --> 00:21:55,959 the thing and read data out of it. 610 00:21:55,960 --> 00:21:58,299 So this is basically arbitrary, you know, 611 00:21:58,300 --> 00:21:59,979 read anything from memory out of 612 00:21:59,980 --> 00:22:00,980 boundary's 613 00:22:02,140 --> 00:22:03,820 that obviously can cause 614 00:22:05,110 --> 00:22:07,629 a kernel crash or potentially in Fleak. 615 00:22:07,630 --> 00:22:08,829 But the really interesting thing about 616 00:22:08,830 --> 00:22:10,569 this code is if you throw all the way up 617 00:22:10,570 --> 00:22:12,069 and you look at the comments, it says, 618 00:22:12,070 --> 00:22:13,119 yes, this is gross. 619 00:22:14,620 --> 00:22:16,899 So they know their code sucks. 620 00:22:16,900 --> 00:22:18,939 This code has been around since 1996, 621 00:22:21,850 --> 00:22:23,379 so it's been there for 20 years. 622 00:22:23,380 --> 00:22:24,669 I mean, there may be people in the room. 623 00:22:24,670 --> 00:22:25,839 They're younger than this bug. 624 00:22:28,480 --> 00:22:30,789 But, yeah, this is this really crappy 625 00:22:30,790 --> 00:22:31,809 code. And this is what you meant when you 626 00:22:31,810 --> 00:22:34,029 said rats really quickly. 627 00:22:34,030 --> 00:22:35,019 They were 21 years ago. 628 00:22:35,020 --> 00:22:37,119 They never look back. It's there probably 629 00:22:37,120 --> 00:22:38,679 hasn't been used in 1996 to. 630 00:22:39,730 --> 00:22:41,199 And then so when I told him about it and 631 00:22:41,200 --> 00:22:42,909 they fixed it, the long message basically 632 00:22:42,910 --> 00:22:44,979 said, well, we fixed a multitude of 633 00:22:44,980 --> 00:22:47,049 holes in our stream code. 634 00:22:47,050 --> 00:22:48,159 And then they said we should have never 635 00:22:48,160 --> 00:22:49,299 enabled us by default. 636 00:22:49,300 --> 00:22:50,619 And then it's a minefield. 637 00:22:50,620 --> 00:22:52,869 And so what I do is 638 00:22:52,870 --> 00:22:54,039 when I fix this thing, they also change 639 00:22:54,040 --> 00:22:55,899 their kernel config and it turn to shit 640 00:22:55,900 --> 00:22:58,089 off by default, which, 641 00:22:58,090 --> 00:22:59,090 you know. 642 00:23:04,890 --> 00:23:07,289 Right, so next year, that or 643 00:23:07,290 --> 00:23:08,819 trap handlers and think about trap 644 00:23:08,820 --> 00:23:11,099 handlers is that trap handlers 645 00:23:11,100 --> 00:23:12,299 basically do this thing where they handle 646 00:23:12,300 --> 00:23:14,849 any kind of sort of exception or false, 647 00:23:14,850 --> 00:23:16,379 which can be division by zero or a system 648 00:23:16,380 --> 00:23:18,239 call or break point or envelopment access 649 00:23:18,240 --> 00:23:20,979 or a very, very long list of things. 650 00:23:20,980 --> 00:23:22,829 And this is essentially mostly this is 651 00:23:22,830 --> 00:23:24,959 sort of hardware sort of coming to us 652 00:23:24,960 --> 00:23:26,729 and saying, hey, this kind of fall 653 00:23:26,730 --> 00:23:28,649 happened and you have to deal with it. 654 00:23:28,650 --> 00:23:30,329 Some can be triggered by your some can 655 00:23:30,330 --> 00:23:31,469 only be triggered by HeartWare, something 656 00:23:31,470 --> 00:23:32,470 only be triggered by kernel. 657 00:23:33,510 --> 00:23:35,429 The code to handle this and this is 658 00:23:35,430 --> 00:23:37,919 usually incredibly, incredibly nasty. 659 00:23:37,920 --> 00:23:39,989 It's terrifying to just read this code. 660 00:23:39,990 --> 00:23:41,039 I can't imagine writing it. 661 00:23:42,360 --> 00:23:43,829 And it's very specific. 662 00:23:43,830 --> 00:23:45,629 Like the intel ones are different from 663 00:23:45,630 --> 00:23:46,639 the yard, which is very different from 664 00:23:46,640 --> 00:23:49,019 MIPS and so on. And even among 665 00:23:49,020 --> 00:23:51,329 the intel 666 00:23:51,330 --> 00:23:53,399 earlier to leaders, there's many changes 667 00:23:53,400 --> 00:23:54,400 in between. 668 00:23:54,990 --> 00:23:57,479 And so I didn't really feel 669 00:23:57,480 --> 00:23:59,689 like orange is code because 670 00:23:59,690 --> 00:24:01,919 I like my sanity. 671 00:24:01,920 --> 00:24:04,049 And so I was like, OK, how about I just 672 00:24:04,050 --> 00:24:06,089 fuzz it well and then it comes out. 673 00:24:06,090 --> 00:24:08,759 OK, well how do you fuzz exceptions? 674 00:24:08,760 --> 00:24:10,829 And I'm like, well I don't really 675 00:24:10,830 --> 00:24:12,929 know how to for specific exceptions, 676 00:24:12,930 --> 00:24:14,399 but what if I just execute random 677 00:24:14,400 --> 00:24:15,599 instructions? Surely 678 00:24:16,770 --> 00:24:18,089 those things will hit some kind of 679 00:24:18,090 --> 00:24:19,109 exception. 680 00:24:19,110 --> 00:24:20,339 And when I say random structures, I mean 681 00:24:20,340 --> 00:24:22,479 like super random, like I don't even know 682 00:24:22,480 --> 00:24:23,699 what the structures are. Basically what I 683 00:24:23,700 --> 00:24:26,309 do is I read from the random 684 00:24:26,310 --> 00:24:28,109 and then I and that page I make 685 00:24:28,110 --> 00:24:30,299 executable Falkoff a process 686 00:24:30,300 --> 00:24:32,309 basically put into it. 687 00:24:32,310 --> 00:24:33,509 Let the process do its thing. 688 00:24:33,510 --> 00:24:35,699 It will die usually 689 00:24:35,700 --> 00:24:36,629 after section two or three. 690 00:24:36,630 --> 00:24:38,549 The thing is dead, but you just keep 691 00:24:38,550 --> 00:24:40,799 doing that and loop in loop and loop 692 00:24:40,800 --> 00:24:43,259 and it generates all sorts of weird 693 00:24:43,260 --> 00:24:44,900 traps that the kernel now has to handle. 694 00:24:46,980 --> 00:24:49,169 And sure enough, if you do this on that 695 00:24:49,170 --> 00:24:51,269 freebie is the you you hit a couple of 696 00:24:51,270 --> 00:24:53,379 bugs. There's a Z 697 00:24:53,380 --> 00:24:55,109 in there, even though I wasn't using then 698 00:24:55,110 --> 00:24:56,309 there's some send signal bug. 699 00:24:56,310 --> 00:24:57,299 There's all sorts of weird things that 700 00:24:57,300 --> 00:24:59,399 happen. So this is one of them. 701 00:24:59,400 --> 00:25:01,169 This is not a one of them. 702 00:25:01,170 --> 00:25:03,269 And I could but 703 00:25:03,270 --> 00:25:04,529 I don't know. The thing is, because it's 704 00:25:04,530 --> 00:25:06,509 so random, you never know when when it 705 00:25:06,510 --> 00:25:07,529 hits. 706 00:25:07,530 --> 00:25:09,779 But essentially this is all the code 707 00:25:09,780 --> 00:25:11,639 it takes. I mean, I have more advanced 708 00:25:11,640 --> 00:25:12,989 versions of this, but this is really all 709 00:25:12,990 --> 00:25:14,549 it takes to cause it. 710 00:25:14,550 --> 00:25:16,499 So if you write something like this and 711 00:25:16,500 --> 00:25:18,929 you run it on the BSD and 712 00:25:18,930 --> 00:25:20,279 it will hit kernel bugs. 713 00:25:23,470 --> 00:25:25,569 Anyway, that's a wrap and happy with 714 00:25:25,570 --> 00:25:27,669 that, because I don't want to talk 715 00:25:27,670 --> 00:25:28,670 about Rafaela's, 716 00:25:29,950 --> 00:25:31,419 so, yeah, the next thing I was looking at 717 00:25:31,420 --> 00:25:32,420 are 718 00:25:34,210 --> 00:25:36,069 filesystems. 719 00:25:36,070 --> 00:25:37,779 And so the attacks festoons. 720 00:25:37,780 --> 00:25:39,849 Obviously, the easy part of the 721 00:25:39,850 --> 00:25:42,069 attack surface is sort of the, 722 00:25:42,070 --> 00:25:44,409 oh, you know, you mount the USB 723 00:25:44,410 --> 00:25:45,699 stick or whatever, and then it has to 724 00:25:45,700 --> 00:25:47,259 pass the filesystem. And that's true, I 725 00:25:47,260 --> 00:25:48,879 believe, in my view that's attack 726 00:25:48,880 --> 00:25:51,099 surface. But it turns out in recent 727 00:25:51,100 --> 00:25:53,409 years there's significantly new 728 00:25:53,410 --> 00:25:55,449 attack servers to filesystems. 729 00:25:55,450 --> 00:25:57,909 And this comes in the form of Few's. 730 00:25:57,910 --> 00:25:58,839 I don't know if you guys know what Fuze 731 00:25:58,840 --> 00:26:00,949 is essentially usually 732 00:26:00,950 --> 00:26:01,950 on file systems. 733 00:26:02,650 --> 00:26:03,969 And so what that means is all of a 734 00:26:03,970 --> 00:26:06,219 sudden, all these Unix 735 00:26:06,220 --> 00:26:07,449 layers that have been around for many, 736 00:26:07,450 --> 00:26:09,669 many years that in previous years only 737 00:26:09,670 --> 00:26:11,799 took data from trusted 738 00:26:11,800 --> 00:26:13,959 drivers and kernel data structures 739 00:26:13,960 --> 00:26:16,209 were, you know, more 740 00:26:16,210 --> 00:26:18,069 or less trusted, like the data in there 741 00:26:18,070 --> 00:26:19,899 you figured was more or less accurate 742 00:26:19,900 --> 00:26:21,669 because it was given to you by kernel. 743 00:26:21,670 --> 00:26:23,409 All of a sudden all that data is handed 744 00:26:23,410 --> 00:26:26,269 to the fifth layer by a useless process 745 00:26:26,270 --> 00:26:27,699 and the assumption that the data in there 746 00:26:27,700 --> 00:26:29,529 is trusted is no longer valid. 747 00:26:31,160 --> 00:26:32,529 And so if you start looking at the future 748 00:26:32,530 --> 00:26:34,269 implications for the BSD, the first thing 749 00:26:34,270 --> 00:26:35,889 I thought was like, oh well, it's Fuze. 750 00:26:35,890 --> 00:26:37,899 It's pretty sure it's what inflation. 751 00:26:37,900 --> 00:26:39,689 And they all do the same thing. 752 00:26:39,690 --> 00:26:40,579 That isn't true. 753 00:26:40,580 --> 00:26:42,999 Turns out all three Busey's, 754 00:26:43,000 --> 00:26:45,159 they're entirely different future 755 00:26:45,160 --> 00:26:46,599 implications. 756 00:26:46,600 --> 00:26:47,979 There is no cochaired read, all three of 757 00:26:47,980 --> 00:26:49,230 them totally different. 758 00:26:50,350 --> 00:26:52,419 My understanding is my view of from 759 00:26:52,420 --> 00:26:54,129 looking at the code is that the deposition 760 00:26:54,130 --> 00:26:55,299 is the most complete in terms of 761 00:26:55,300 --> 00:26:56,769 features. 762 00:26:56,770 --> 00:26:58,539 The freebees you one seems to be the one 763 00:26:58,540 --> 00:27:00,789 where the arguments are the most 764 00:27:00,790 --> 00:27:03,069 controlled and constraint in terms 765 00:27:03,070 --> 00:27:05,169 of the amount of validation being done. 766 00:27:05,170 --> 00:27:07,509 And then the ones basically the 767 00:27:07,510 --> 00:27:08,980 has the most minimal amount of 768 00:27:11,950 --> 00:27:13,929 data or features implemented compared to 769 00:27:13,930 --> 00:27:14,930 the other two. 770 00:27:16,300 --> 00:27:17,559 If you look at Fuze, it actually 771 00:27:17,560 --> 00:27:20,049 supported. But all three 772 00:27:20,050 --> 00:27:22,179 of these do not when they are equal, but 773 00:27:22,180 --> 00:27:23,649 they implement pretty much any other 774 00:27:23,650 --> 00:27:24,759 facet of operation read. 775 00:27:24,760 --> 00:27:27,189 Right, to get attributes. 776 00:27:27,190 --> 00:27:28,359 It attributes that type of stuff. 777 00:27:30,470 --> 00:27:32,539 And so, for example, this 778 00:27:32,540 --> 00:27:34,879 is this is the OMB as the 779 00:27:34,880 --> 00:27:35,880 get get Getsy 780 00:27:37,730 --> 00:27:39,799 system gets called by to call 781 00:27:39,800 --> 00:27:40,999 and basically they'll do this thing where 782 00:27:41,000 --> 00:27:43,129 they go to the VFW later and say get 783 00:27:43,130 --> 00:27:43,639 attribute. 784 00:27:43,640 --> 00:27:44,689 And then they fill out this 785 00:27:45,950 --> 00:27:47,389 feature structure 786 00:27:48,530 --> 00:27:50,659 and they assume everything in the VAT 787 00:27:50,660 --> 00:27:52,879 structure is more or less sane 788 00:27:52,880 --> 00:27:55,189 because it came from a kernel driver. 789 00:27:55,190 --> 00:27:57,289 But given that Use Fuze all 790 00:27:57,290 --> 00:27:59,749 data in VA is no longer trusted, it 791 00:27:59,750 --> 00:28:01,399 should be considered tainted and you 792 00:28:01,400 --> 00:28:02,449 should validate it. 793 00:28:02,450 --> 00:28:03,519 And of course, they don't. 794 00:28:03,520 --> 00:28:05,689 And so you take this massive linked 795 00:28:05,690 --> 00:28:07,159 value from it. And the fact that the 796 00:28:07,160 --> 00:28:09,409 mallock and as I mentioned before, 797 00:28:09,410 --> 00:28:10,819 don't miss email when it sees a very 798 00:28:10,820 --> 00:28:13,069 large value kernel panic. 799 00:28:13,070 --> 00:28:14,749 So this right here was a bug. 800 00:28:14,750 --> 00:28:16,609 And then if you look a little bit further 801 00:28:16,610 --> 00:28:18,799 gets W.D., 802 00:28:18,800 --> 00:28:20,719 they'll do another call to vacillator. 803 00:28:20,720 --> 00:28:22,639 Just stop right there. 804 00:28:22,640 --> 00:28:24,709 And basically they get 805 00:28:24,710 --> 00:28:26,809 to the studio structure 806 00:28:26,810 --> 00:28:28,039 back. 807 00:28:28,040 --> 00:28:30,229 And previously, when you need that kind 808 00:28:30,230 --> 00:28:32,359 of return again, it was it 809 00:28:32,360 --> 00:28:34,459 was Farson data, but it was headed 810 00:28:34,460 --> 00:28:36,619 back from I think some 811 00:28:36,620 --> 00:28:38,779 driver saw the structure was more 812 00:28:38,780 --> 00:28:39,780 or less trusted. 813 00:28:40,880 --> 00:28:42,199 And in this case, it's really just a 814 00:28:42,200 --> 00:28:44,009 Bufferin in length. 815 00:28:44,010 --> 00:28:46,249 And so the content, because it now comes 816 00:28:46,250 --> 00:28:48,439 from usually the process is no longer 817 00:28:48,440 --> 00:28:50,179 trusted. And so if you look at what it 818 00:28:50,180 --> 00:28:52,369 starts parsing the name length 819 00:28:52,370 --> 00:28:54,439 of an entry in a directory, it sort of 820 00:28:54,440 --> 00:28:56,479 just assumes that it's more or less 821 00:28:56,480 --> 00:28:57,619 valid. 822 00:28:57,620 --> 00:29:00,469 And then it uses that for a move 823 00:29:00,470 --> 00:29:02,629 and that can cause another boundary. 824 00:29:02,630 --> 00:29:04,819 So basically, the problem with Fuze and I 825 00:29:04,820 --> 00:29:06,109 would imagine you see this in Linux, too, 826 00:29:06,110 --> 00:29:07,159 but I haven't looked yet. 827 00:29:07,160 --> 00:29:09,379 Is that your view that you have? 828 00:29:09,380 --> 00:29:11,689 If you if you do if you like Fuze, 829 00:29:11,690 --> 00:29:13,249 you have to modify your vacillator 830 00:29:13,250 --> 00:29:15,379 because you're vacillator has 831 00:29:15,380 --> 00:29:17,119 all these assumptions where it assumes 832 00:29:17,120 --> 00:29:18,679 the data gets from your file system is 833 00:29:18,680 --> 00:29:20,369 valid and it's no longer true. 834 00:29:22,250 --> 00:29:24,419 So that was a sample of adoption's. 835 00:29:24,420 --> 00:29:25,849 But you got to be as easy as asimilar 836 00:29:25,850 --> 00:29:26,949 bugs. 837 00:29:26,950 --> 00:29:29,329 Just this particular bug. 838 00:29:29,330 --> 00:29:31,789 The bug was there since 2006, but I 839 00:29:31,790 --> 00:29:33,799 think Fuze is not quite at all. 840 00:29:33,800 --> 00:29:36,169 And so this has only recently been 841 00:29:36,170 --> 00:29:37,170 a real issue. 842 00:29:38,690 --> 00:29:39,769 And then obviously, if you look at the 843 00:29:39,770 --> 00:29:41,730 actual fast handler, when you give it a 844 00:29:42,920 --> 00:29:44,359 a blob of data that amounts. 845 00:29:44,360 --> 00:29:46,699 So this is the X2 parser 846 00:29:46,700 --> 00:29:47,719 for privacy. 847 00:29:47,720 --> 00:29:49,659 And this is a brief, very brief look at 848 00:29:49,660 --> 00:29:52,069 this. I did not do an exhaustive search, 849 00:29:52,070 --> 00:29:53,599 but I was like, you know, grep for this 850 00:29:53,600 --> 00:29:54,739 thing called berried. 851 00:29:54,740 --> 00:29:56,149 And I'm like, oh, well, you're looking 852 00:29:56,150 --> 00:29:57,499 for some kind of string and the string 853 00:29:57,500 --> 00:29:59,039 isn't there. You just panic. 854 00:29:59,040 --> 00:30:00,389 Well, that's pretty bad. 855 00:30:00,390 --> 00:30:02,659 Basically, I can give you a 856 00:30:02,660 --> 00:30:04,609 malicious explanation and then this thing 857 00:30:04,610 --> 00:30:05,610 will cause a panic. 858 00:30:06,770 --> 00:30:09,169 So obviously the 859 00:30:09,170 --> 00:30:11,329 the Faslane partners in 860 00:30:11,330 --> 00:30:14,029 the BSD are not what they should be. 861 00:30:14,030 --> 00:30:15,919 I suspect if you throw a simple fast and 862 00:30:15,920 --> 00:30:17,539 further against these things, it'll blow 863 00:30:17,540 --> 00:30:19,129 up in all sorts of bizarre and weird 864 00:30:19,130 --> 00:30:20,449 ways. 865 00:30:20,450 --> 00:30:22,069 I just spent five minutes on this nose. 866 00:30:22,070 --> 00:30:24,529 Like, this is very, very broken 867 00:30:24,530 --> 00:30:26,419 because clearly you're assuming falt 868 00:30:26,420 --> 00:30:27,420 filesystems. 869 00:30:28,550 --> 00:30:30,499 Again, this this book's been there for 870 00:30:30,500 --> 00:30:32,629 seven or eight years or so, but I suspect 871 00:30:32,630 --> 00:30:34,279 when you start hammering on the Folsom's, 872 00:30:34,280 --> 00:30:35,299 you'll find more bugs. 873 00:30:38,040 --> 00:30:39,040 Right. 874 00:30:39,570 --> 00:30:41,879 So, yeah, networking beyond these VIP 875 00:30:41,880 --> 00:30:44,099 stack and I sort 876 00:30:44,100 --> 00:30:46,229 of mentioned Wi-Fi, 877 00:30:46,230 --> 00:30:48,539 but I really only have Wi-Fi 878 00:30:48,540 --> 00:30:49,439 in my slides. 879 00:30:49,440 --> 00:30:51,629 I kind of threw out because I didn't get 880 00:30:51,630 --> 00:30:52,630 to it. 881 00:30:52,980 --> 00:30:54,299 But when you look at your Wi-Fi attack 882 00:30:54,300 --> 00:30:57,089 surface, there are 883 00:30:57,090 --> 00:30:59,189 sort of two things you have to 884 00:30:59,190 --> 00:31:01,169 look at. Right? One is the stack itself 885 00:31:01,170 --> 00:31:02,789 and then one are to the actual Wi-Fi 886 00:31:02,790 --> 00:31:03,719 drivers. Right. 887 00:31:03,720 --> 00:31:05,009 And ideally, you would have this thing 888 00:31:05,010 --> 00:31:06,659 where you have only one stack and then 889 00:31:06,660 --> 00:31:07,979 all the drivers are according to it, 890 00:31:07,980 --> 00:31:09,269 which ought to be as these did. 891 00:31:09,270 --> 00:31:10,559 Analytics has this too. 892 00:31:10,560 --> 00:31:12,719 But enormities of Wi-Fi, sort of every 893 00:31:12,720 --> 00:31:15,029 driver came in so full stack. 894 00:31:15,030 --> 00:31:16,469 But luckily we sort of passed out and 895 00:31:16,470 --> 00:31:18,059 there's only there's one stack for four 896 00:31:18,060 --> 00:31:19,060 older drivers. 897 00:31:21,210 --> 00:31:23,309 So, yeah, the stack is sort of 898 00:31:23,310 --> 00:31:25,499 it looks like stack, I mean, 899 00:31:25,500 --> 00:31:26,579 it's obviously partially different 900 00:31:26,580 --> 00:31:28,439 protocols, but it's all in buffs. 901 00:31:28,440 --> 00:31:29,549 It's in and out. 902 00:31:29,550 --> 00:31:30,569 It's stuff that gets passed 903 00:31:31,980 --> 00:31:33,419 back and forth. 904 00:31:33,420 --> 00:31:35,659 The main input functions is 905 00:31:35,660 --> 00:31:38,609 Tripoli. Eight or two underscore input. 906 00:31:38,610 --> 00:31:40,019 And once you start reading that, you sort 907 00:31:40,020 --> 00:31:42,269 of find the entire eight or two, 11 908 00:31:42,270 --> 00:31:43,469 passing stack. 909 00:31:43,470 --> 00:31:45,629 And that function is called from all 910 00:31:45,630 --> 00:31:47,429 the Wi-Fi drivers. 911 00:31:47,430 --> 00:31:48,719 And so, sure enough, we start reading 912 00:31:48,720 --> 00:31:49,859 that eventually you find this function 913 00:31:49,860 --> 00:31:52,019 called Tripoli eight or two 914 00:31:52,020 --> 00:31:53,909 eleven underscore equal and square key, 915 00:31:53,910 --> 00:31:54,839 underscore input. 916 00:31:54,840 --> 00:31:56,429 And it's basically deals with people 917 00:31:56,430 --> 00:31:57,479 keys. 918 00:31:57,480 --> 00:31:58,619 And it turns out if you look at the 919 00:31:58,620 --> 00:32:00,149 structure for this thing, it actually has 920 00:32:00,150 --> 00:32:01,259 two different lengths. 921 00:32:01,260 --> 00:32:03,479 One is length and one is payload length. 922 00:32:03,480 --> 00:32:06,119 And it's this this particular function 923 00:32:06,120 --> 00:32:07,889 does validate length and Paillot lengths, 924 00:32:07,890 --> 00:32:09,659 but then it has to do this thing called 925 00:32:09,660 --> 00:32:11,939 an ember pull up to that is to say 926 00:32:11,940 --> 00:32:13,919 that's to actually pull up enough 927 00:32:13,920 --> 00:32:15,509 continuous buffers to make sure there's 928 00:32:15,510 --> 00:32:17,219 that much length. And it does this for 929 00:32:17,220 --> 00:32:18,809 the payload length, but not for the 930 00:32:18,810 --> 00:32:20,729 actual the other Lingfield. 931 00:32:20,730 --> 00:32:22,920 And so it turns out that 932 00:32:24,060 --> 00:32:25,439 the actual airfields used to actually 933 00:32:25,440 --> 00:32:27,569 read beyond the thing to 934 00:32:27,570 --> 00:32:28,529 read the buffer. 935 00:32:28,530 --> 00:32:30,749 And so because the pull up isn't done 936 00:32:30,750 --> 00:32:31,919 for the length, but for the payload 937 00:32:31,920 --> 00:32:33,989 length instead, if your length is bigger 938 00:32:33,990 --> 00:32:35,699 than your payload length, then you can 939 00:32:35,700 --> 00:32:37,949 end up having outer boundaries and 940 00:32:37,950 --> 00:32:40,199 this can be triggered by remote 941 00:32:40,200 --> 00:32:41,200 wi fi frames. 942 00:32:43,290 --> 00:32:45,599 So, again, this goes back to AmBev 943 00:32:45,600 --> 00:32:47,999 mishandling, as I said previously, in 944 00:32:48,000 --> 00:32:50,309 stacked part and buffs 945 00:32:50,310 --> 00:32:51,310 or heart. 946 00:32:54,280 --> 00:32:56,439 This wasn't six 947 00:32:56,440 --> 00:32:58,419 point one when I was ordered, it turns 948 00:32:58,420 --> 00:33:00,369 out the bug has been around for about 949 00:33:00,370 --> 00:33:01,370 nine years. 950 00:33:03,130 --> 00:33:05,589 The drivers, the like for drivers, 951 00:33:05,590 --> 00:33:07,449 this is the interesting part. 952 00:33:07,450 --> 00:33:10,059 The Wi-Fi drivers are either so worried 953 00:33:10,060 --> 00:33:11,749 because these are either PCI or USB. 954 00:33:11,750 --> 00:33:13,389 Right species. 955 00:33:13,390 --> 00:33:14,949 You know, when you put the card in, the 956 00:33:14,950 --> 00:33:16,899 sky's the limit access, but USB is 957 00:33:16,900 --> 00:33:18,409 different, USB packet based. 958 00:33:18,410 --> 00:33:20,769 Right. And so it comes out the question 959 00:33:20,770 --> 00:33:22,989 where it's like, do you trust 960 00:33:22,990 --> 00:33:24,189 your Wi-Fi radio? 961 00:33:24,190 --> 00:33:25,629 Right. What if somebody compromised the 962 00:33:25,630 --> 00:33:27,789 Wi-Fi radio and then from there on 963 00:33:27,790 --> 00:33:29,109 tries to own your OS? 964 00:33:31,750 --> 00:33:33,699 And so for the PCI one, I was like, OK, 965 00:33:33,700 --> 00:33:36,189 well, if your PCI 966 00:33:36,190 --> 00:33:37,299 OK, it's kind of game over because they 967 00:33:37,300 --> 00:33:39,379 can do TMY and that's I mean, 968 00:33:39,380 --> 00:33:41,499 that's no longer true when you use things 969 00:33:41,500 --> 00:33:43,449 like Mumu. 970 00:33:43,450 --> 00:33:45,579 But let's just assume that if it's PCI 971 00:33:45,580 --> 00:33:47,949 and you handle it wrong, OK, fine. 972 00:33:47,950 --> 00:33:50,109 But when it comes down to the USB 973 00:33:50,110 --> 00:33:52,299 drive, three to two or 11 duty 974 00:33:52,300 --> 00:33:54,279 protocol is essentially packet based. 975 00:33:54,280 --> 00:33:56,409 And so your host 976 00:33:56,410 --> 00:33:58,449 really should be able to, you know, pass 977 00:33:58,450 --> 00:34:00,339 the packets correctly and not blow up. 978 00:34:00,340 --> 00:34:03,129 If you get bizarre USB packets 979 00:34:03,130 --> 00:34:04,910 from your Wi-Fi radio, 980 00:34:06,110 --> 00:34:08,049 it turns out they're currently not really 981 00:34:08,050 --> 00:34:09,129 doing that. 982 00:34:09,130 --> 00:34:10,959 And this leads to very, very trivial 983 00:34:10,960 --> 00:34:11,979 smashers. 984 00:34:11,980 --> 00:34:14,019 And I have I wanted to have one example, 985 00:34:14,020 --> 00:34:15,638 but I really give you five examples of, 986 00:34:15,639 --> 00:34:16,639 like, the same thing. 987 00:34:17,409 --> 00:34:19,209 So this is one driver where they go like, 988 00:34:19,210 --> 00:34:21,309 OK, here's a Lynnfield that can be 989 00:34:21,310 --> 00:34:23,948 up to a page long and then, 990 00:34:23,949 --> 00:34:26,079 OK, we'll go do we'll create a number 991 00:34:26,080 --> 00:34:28,599 of cluster, which can be 20 bytes long, 992 00:34:28,600 --> 00:34:30,069 and then we'll just do a copy with that 993 00:34:30,070 --> 00:34:32,019 length into that cluster without ever 994 00:34:32,020 --> 00:34:33,369 felt any of that length is bigger than a 995 00:34:33,370 --> 00:34:34,059 cluster. 996 00:34:34,060 --> 00:34:36,009 And obviously that means you get trivial 997 00:34:36,010 --> 00:34:37,269 memory corruption. 998 00:34:37,270 --> 00:34:39,279 And then this is a different Wi-Fi driver 999 00:34:39,280 --> 00:34:40,809 and they say, OK, let's grab this linked 1000 00:34:40,810 --> 00:34:43,029 field out of the out of the 1001 00:34:43,030 --> 00:34:45,339 USB packet and then we'll basically 1002 00:34:45,340 --> 00:34:47,399 use that and copy into 1003 00:34:47,400 --> 00:34:49,539 an app that can be up to to 1004 00:34:49,540 --> 00:34:51,669 two thousand bytes. And again, very 1005 00:34:51,670 --> 00:34:52,658 similar encryption book. 1006 00:34:52,659 --> 00:34:54,738 And then this is not a driver and it's 1007 00:34:54,739 --> 00:34:56,809 very similar thing with a computer 1008 00:34:56,810 --> 00:34:58,899 linked and then it's another driver, 1009 00:34:58,900 --> 00:35:00,819 very similar thing where you take a link. 1010 00:35:00,820 --> 00:35:04,179 They do an IBM copy and it causes an 1011 00:35:04,180 --> 00:35:06,759 admin heap corruption bug. 1012 00:35:06,760 --> 00:35:08,349 And there's more of these. 1013 00:35:08,350 --> 00:35:09,489 But those are the ones that were very 1014 00:35:09,490 --> 00:35:10,599 trivial. 1015 00:35:10,600 --> 00:35:12,279 So this is basically wide open attack 1016 00:35:12,280 --> 00:35:14,409 surface across all of these, 1017 00:35:14,410 --> 00:35:16,849 across various different 1018 00:35:16,850 --> 00:35:18,589 I mean, there's an ATM, there's a real 1019 00:35:18,590 --> 00:35:20,409 taxers, a whole bunch of these 1020 00:35:22,090 --> 00:35:23,090 like drivers 1021 00:35:24,670 --> 00:35:25,599 did. 1022 00:35:25,600 --> 00:35:27,699 This code is very trusting 1023 00:35:27,700 --> 00:35:29,709 of the USB packets. It just assumes 1024 00:35:29,710 --> 00:35:31,509 everything is done right. 1025 00:35:31,510 --> 00:35:32,759 I think when when these crimes were 1026 00:35:32,760 --> 00:35:34,179 committed, nobody thought about the 1027 00:35:34,180 --> 00:35:35,260 attack surface on this one. 1028 00:35:37,690 --> 00:35:39,789 And then so that's more or less it 1029 00:35:39,790 --> 00:35:42,099 for the for to attack surface. 1030 00:35:42,100 --> 00:35:43,100 I had 1031 00:35:44,380 --> 00:35:46,269 there's a few more things I looked at and 1032 00:35:46,270 --> 00:35:47,440 I kind of want to talk about, 1033 00:35:48,670 --> 00:35:49,869 like I didn't really have much detail 1034 00:35:49,870 --> 00:35:52,399 about it, but two things that I showed up 1035 00:35:52,400 --> 00:35:54,749 that I sort of had that that 1036 00:35:54,750 --> 00:35:56,979 that seemed like there were many bugs 1037 00:35:56,980 --> 00:35:58,120 in there. So one is 1038 00:35:59,170 --> 00:36:01,569 there appear to be a certain 1039 00:36:01,570 --> 00:36:03,669 amount of easily detectable 1040 00:36:03,670 --> 00:36:05,979 giraffe's in the BSD. 1041 00:36:05,980 --> 00:36:07,449 I spent some time looking at it in 1042 00:36:07,450 --> 00:36:08,569 FreeBSD. 1043 00:36:08,570 --> 00:36:11,039 I did a very quick rap on 1044 00:36:11,040 --> 00:36:13,149 the on that because I 1045 00:36:13,150 --> 00:36:15,609 suspect there's a similar amount 1046 00:36:15,610 --> 00:36:17,709 on that because we're basically. 1047 00:36:17,710 --> 00:36:19,599 So the way you call mallock on the BSD 1048 00:36:19,600 --> 00:36:21,729 basically is you pass the flag and 1049 00:36:21,730 --> 00:36:24,129 the flag is either basically says 1050 00:36:24,130 --> 00:36:25,989 no weight or 1051 00:36:27,910 --> 00:36:29,049 default behaviors. 1052 00:36:29,050 --> 00:36:31,119 That default behavior is that the mail 1053 00:36:31,120 --> 00:36:33,189 always waits. And when it succeeds, when 1054 00:36:33,190 --> 00:36:35,049 it returns, it always succeeds. 1055 00:36:35,050 --> 00:36:36,050 It never fails. 1056 00:36:37,430 --> 00:36:38,949 And there's a way you can pass the flag, 1057 00:36:38,950 --> 00:36:40,599 which is no way or can fail. 1058 00:36:40,600 --> 00:36:41,860 And what that means is if it can't 1059 00:36:43,510 --> 00:36:45,729 fulfill the requests within a certain 1060 00:36:45,730 --> 00:36:47,559 amount of time, it returns and feels the 1061 00:36:47,560 --> 00:36:48,699 request. Right. 1062 00:36:48,700 --> 00:36:49,959 And so what you can do is you basically 1063 00:36:49,960 --> 00:36:51,819 graffitis flags and you see any time 1064 00:36:51,820 --> 00:36:53,589 where there's Amalek done and return 1065 00:36:53,590 --> 00:36:54,799 values and checked and you get a new 1066 00:36:54,800 --> 00:36:55,869 address. 1067 00:36:55,870 --> 00:36:57,129 And the reason these things show up is 1068 00:36:57,130 --> 00:36:58,270 because by default, 1069 00:36:59,470 --> 00:37:01,689 the pattern is Malacañang for value. 1070 00:37:01,690 --> 00:37:03,399 And you would think, OK, well, that's an 1071 00:37:03,400 --> 00:37:05,529 easy pattern. And no, if 1072 00:37:05,530 --> 00:37:06,549 you write in Kirkcaldy, you'll never make 1073 00:37:06,550 --> 00:37:08,619 that kind of mistake except because the 1074 00:37:08,620 --> 00:37:10,779 general way calls where 1075 00:37:10,780 --> 00:37:12,219 it could never fail. 1076 00:37:12,220 --> 00:37:14,149 And so there's almost never Amalek servo 1077 00:37:14,150 --> 00:37:16,269 check, except you have to do this 1078 00:37:16,270 --> 00:37:18,939 when you're doing no way to Cadfael. 1079 00:37:18,940 --> 00:37:20,309 And it turns out there is. 1080 00:37:20,310 --> 00:37:21,669 Thank you. 1081 00:37:21,670 --> 00:37:24,069 Turns out there are quite a few cases 1082 00:37:24,070 --> 00:37:26,499 where when you do mellark, 1083 00:37:26,500 --> 00:37:27,399 no way to fail. 1084 00:37:27,400 --> 00:37:28,809 People don't return value. 1085 00:37:28,810 --> 00:37:29,829 And so I think these are pretty 1086 00:37:29,830 --> 00:37:32,139 graspable. The second elsewise 1087 00:37:32,140 --> 00:37:33,699 and I don't know why people haven't done 1088 00:37:33,700 --> 00:37:35,989 this yet, but there's quite 1089 00:37:35,990 --> 00:37:37,719 a I brief. 1090 00:37:37,720 --> 00:37:39,849 So when are you getting at like 1091 00:37:39,850 --> 00:37:41,019 15 or 20? 1092 00:37:41,020 --> 00:37:43,229 I can't remember how long the list was on 1093 00:37:43,230 --> 00:37:44,620 on a frequency. 1094 00:37:46,030 --> 00:37:47,589 And I think that was interesting to see 1095 00:37:47,590 --> 00:37:50,139 that the videos 1096 00:37:50,140 --> 00:37:51,789 have, you know, just direct. 1097 00:37:51,790 --> 00:37:54,159 Interesting stuff in Colonel 1098 00:37:54,160 --> 00:37:55,510 Right track ranging management 1099 00:37:56,980 --> 00:37:58,729 infrastructure for those who don't know, 1100 00:37:58,730 --> 00:38:00,039 these are basically the graphics drivers 1101 00:38:00,040 --> 00:38:02,109 that are in Colonel and so when X1 1102 00:38:02,110 --> 00:38:03,879 runs, it sort of talks to these graphics 1103 00:38:03,880 --> 00:38:05,709 drivers and colonel and that the whole 1104 00:38:05,710 --> 00:38:07,790 thing around it is called DRAM or dry. 1105 00:38:08,920 --> 00:38:11,019 And so this sort of because this sort of 1106 00:38:11,020 --> 00:38:13,059 came from the open desktop people and it 1107 00:38:13,060 --> 00:38:14,619 was initially developed separate. 1108 00:38:14,620 --> 00:38:16,659 And then a couple of years ago it was 1109 00:38:16,660 --> 00:38:18,789 moved into the Linux kernel. 1110 00:38:18,790 --> 00:38:20,319 And then what to be as easy as they kind 1111 00:38:20,320 --> 00:38:22,299 of forked it. But it's essentially more 1112 00:38:22,300 --> 00:38:23,739 or less the same code base. 1113 00:38:25,060 --> 00:38:26,919 And so to be but the PC guys kind of have 1114 00:38:26,920 --> 00:38:28,539 to have it. Otherwise it doesn't really 1115 00:38:28,540 --> 00:38:29,590 do much anymore these days. 1116 00:38:30,610 --> 00:38:32,739 And so it's interesting when you 1117 00:38:32,740 --> 00:38:34,779 see the struggles they have with this. 1118 00:38:34,780 --> 00:38:36,639 And if you look at the the the main 1119 00:38:36,640 --> 00:38:38,649 oatmeal's, the developer was responsible 1120 00:38:38,650 --> 00:38:40,809 for maintaining the AMD urine in 1121 00:38:40,810 --> 00:38:42,879 Otomi as the he said, well he goes 1122 00:38:42,880 --> 00:38:43,989 all this loose code that we are 1123 00:38:43,990 --> 00:38:45,819 importing, it's not going to be reviewed 1124 00:38:45,820 --> 00:38:46,809 by any means. 1125 00:38:46,810 --> 00:38:48,189 The kernel developers, because they 1126 00:38:48,190 --> 00:38:49,449 refuse to read any code that is not 1127 00:38:49,450 --> 00:38:51,939 conform to the basic standard. 1128 00:38:51,940 --> 00:38:54,489 And so you have all of these rigorous 1129 00:38:54,490 --> 00:38:57,369 review standard practices and OBC 1130 00:38:57,370 --> 00:38:59,679 except the zero zero stuff, 1131 00:38:59,680 --> 00:39:01,149 they will not touch it. 1132 00:39:01,150 --> 00:39:02,949 And so all the bad antecedent Linux 1133 00:39:02,950 --> 00:39:05,019 kernel, all that stuff is pretty 1134 00:39:05,020 --> 00:39:07,209 much between abusing free PC as well. 1135 00:39:09,290 --> 00:39:11,349 OK, so that was sort of it for 1136 00:39:13,270 --> 00:39:14,270 running through 1137 00:39:15,490 --> 00:39:17,409 the sort of the types of bugs I was 1138 00:39:17,410 --> 00:39:19,389 looking for and the things I found. 1139 00:39:19,390 --> 00:39:20,739 I mean, I could have spent I could have 1140 00:39:20,740 --> 00:39:22,389 done two or three hours running through a 1141 00:39:22,390 --> 00:39:24,009 bunch of bugs, but it'd get pretty 1142 00:39:24,010 --> 00:39:25,010 boring. 1143 00:39:25,490 --> 00:39:27,849 So so what was my result? 1144 00:39:27,850 --> 00:39:29,949 After I was done about three 1145 00:39:29,950 --> 00:39:32,559 months, I about 115 1146 00:39:32,560 --> 00:39:33,560 bugs in total, 1147 00:39:35,080 --> 00:39:37,179 30 bugs in previously, about twenty five 1148 00:39:37,180 --> 00:39:39,309 bugs in obesity. 1149 00:39:39,310 --> 00:39:41,359 And the lion's share was in jeopardy. 1150 00:39:41,360 --> 00:39:43,639 So about 60 or so. 1151 00:39:43,640 --> 00:39:44,640 And that 1152 00:39:45,700 --> 00:39:47,829 it was a very wide spectrum 1153 00:39:47,830 --> 00:39:49,389 of bugs, pretty much everything under the 1154 00:39:49,390 --> 00:39:50,209 sun that you can expect. 1155 00:39:50,210 --> 00:39:52,509 Right. A straight up SAC smashers, 1156 00:39:52,510 --> 00:39:55,299 race conditions, expired pointers, 1157 00:39:55,300 --> 00:39:57,399 double freeze, integer issues 1158 00:39:57,400 --> 00:39:59,499 on the or flaws in as bugs logic 1159 00:39:59,500 --> 00:40:01,479 bugs. I had a typo somewhere where the 1160 00:40:01,480 --> 00:40:03,369 wrong variable was used, but it turns out 1161 00:40:03,370 --> 00:40:04,359 that one existed two. 1162 00:40:04,360 --> 00:40:06,369 And then you get these weird things where 1163 00:40:06,370 --> 00:40:07,599 the wrong thing was happening on the 1164 00:40:07,600 --> 00:40:09,070 wrong structure because there was a typo 1165 00:40:10,570 --> 00:40:11,529 division by zero. 1166 00:40:11,530 --> 00:40:12,699 I had some logic books in there. 1167 00:40:12,700 --> 00:40:15,009 I mean, you can imagine it's in there. 1168 00:40:15,010 --> 00:40:17,139 It turns out it's not written by gods 1169 00:40:17,140 --> 00:40:19,299 and they to make mistakes and they make 1170 00:40:19,300 --> 00:40:20,409 plenty mistakes, actually. 1171 00:40:22,270 --> 00:40:24,459 So I found basically 1172 00:40:24,460 --> 00:40:26,619 bugs among all three of these 1173 00:40:26,620 --> 00:40:28,269 among all of the attacks, as I mentioned, 1174 00:40:28,270 --> 00:40:31,269 and within that entire spectrum. 1175 00:40:31,270 --> 00:40:33,339 But it is interesting, once I sort of got 1176 00:40:33,340 --> 00:40:34,719 a grasp for all three of them and what 1177 00:40:34,720 --> 00:40:37,039 was where and how it was done, 1178 00:40:37,040 --> 00:40:39,249 it's interesting that I think 1179 00:40:39,250 --> 00:40:40,809 I can make some observations about the 1180 00:40:40,810 --> 00:40:42,879 quality and just looking 1181 00:40:42,880 --> 00:40:44,379 at the bugs, like just a numbers of the 1182 00:40:44,380 --> 00:40:45,759 bugs. Right. You can you can you can see 1183 00:40:45,760 --> 00:40:47,289 the same thing. Right. 1184 00:40:47,290 --> 00:40:49,539 And so there's sort of a I 1185 00:40:49,540 --> 00:40:51,339 think obviously when it comes to code, 1186 00:40:51,340 --> 00:40:53,529 quality in their kernel is 1187 00:40:53,530 --> 00:40:54,639 the clear winner. 1188 00:40:54,640 --> 00:40:56,919 Right. And it comes 1189 00:40:56,920 --> 00:40:59,229 the quote that I had from 1190 00:40:59,230 --> 00:41:00,969 the originally where it says, oh, it's 1191 00:41:00,970 --> 00:41:02,509 code quality. 1192 00:41:02,510 --> 00:41:03,849 That's part of it. 1193 00:41:03,850 --> 00:41:05,979 I think it's it 1194 00:41:05,980 --> 00:41:08,019 became obvious to me that it's code 1195 00:41:08,020 --> 00:41:10,179 quality, but also a tax rate reduction. 1196 00:41:10,180 --> 00:41:11,799 It's a combination of those two that 1197 00:41:12,940 --> 00:41:15,759 seems to be a winning formula. 1198 00:41:15,760 --> 00:41:17,529 And it won't be easy. There is enormous 1199 00:41:17,530 --> 00:41:19,629 tax reduction. If you compare it with 1200 00:41:19,630 --> 00:41:21,099 the other BSD, there are many things they 1201 00:41:21,100 --> 00:41:22,149 do not have. 1202 00:41:22,150 --> 00:41:23,559 They don't have a little kernel modules. 1203 00:41:23,560 --> 00:41:25,269 They have relatively few devices. 1204 00:41:25,270 --> 00:41:27,369 They have virtually no combat code. 1205 00:41:27,370 --> 00:41:28,599 They remove the combat code. 1206 00:41:28,600 --> 00:41:30,459 A couple of years ago, they removed her 1207 00:41:30,460 --> 00:41:32,019 entire Bluetooth stack because they 1208 00:41:32,020 --> 00:41:33,189 thought the code sucked and they just 1209 00:41:33,190 --> 00:41:34,989 deleted it. So no Bluetooth support. 1210 00:41:34,990 --> 00:41:37,599 Obviously, they have significantly 1211 00:41:37,600 --> 00:41:38,979 less system calls. They have more than 1212 00:41:38,980 --> 00:41:40,749 two hundred thousand calls, less than 1213 00:41:40,750 --> 00:41:42,939 FreeBSD, and 1214 00:41:42,940 --> 00:41:44,769 they cut support for a whole bunch of old 1215 00:41:44,770 --> 00:41:46,359 architectures. Right. 1216 00:41:46,360 --> 00:41:48,639 And that in combination with code 1217 00:41:48,640 --> 00:41:49,640 quality, 1218 00:41:51,070 --> 00:41:52,749 I think is a winning formula. 1219 00:41:52,750 --> 00:41:54,339 The quality is interesting because it 1220 00:41:54,340 --> 00:41:55,839 really does show if you look at the code, 1221 00:41:55,840 --> 00:41:58,389 right, the trivial low hanging fruit 1222 00:41:58,390 --> 00:42:00,549 stuff is almost 1223 00:42:00,550 --> 00:42:01,479 entirely gone. 1224 00:42:01,480 --> 00:42:04,059 The integer overflows, sinus 1225 00:42:04,060 --> 00:42:06,489 bugs are virtually 1226 00:42:06,490 --> 00:42:07,490 gone. 1227 00:42:08,320 --> 00:42:10,219 Like the Wi-Fi driver stuff is something 1228 00:42:10,220 --> 00:42:11,499 where I still found it because it was a 1229 00:42:11,500 --> 00:42:13,299 taxi service they never thought about. 1230 00:42:13,300 --> 00:42:14,409 But I don't think that they know is 1231 00:42:14,410 --> 00:42:15,410 attack surface. 1232 00:42:17,080 --> 00:42:19,519 It's highly likely financial flows or 1233 00:42:19,520 --> 00:42:21,819 bugs simply because they know about 1234 00:42:21,820 --> 00:42:23,110 them. They 1235 00:42:24,420 --> 00:42:26,589 they inform their developers 1236 00:42:26,590 --> 00:42:28,239 about what that looks like. 1237 00:42:28,240 --> 00:42:30,309 And they have this every 1238 00:42:30,310 --> 00:42:32,379 every commit gets reviewed 1239 00:42:32,380 --> 00:42:33,909 by at least one or two people. 1240 00:42:33,910 --> 00:42:35,259 And these people know exactly what his 1241 00:42:35,260 --> 00:42:36,789 patterns look like. And it turns out when 1242 00:42:36,790 --> 00:42:39,279 you have a process like that in 1243 00:42:39,280 --> 00:42:40,989 flows simply don't occur in attack 1244 00:42:40,990 --> 00:42:42,339 surface. 1245 00:42:42,340 --> 00:42:43,969 The other thing is that they had fewer 1246 00:42:43,970 --> 00:42:45,010 leaks than the other abuses 1247 00:42:46,540 --> 00:42:47,649 in terms of the clear loser. 1248 00:42:47,650 --> 00:42:49,749 Yeah, that was what I 1249 00:42:49,750 --> 00:42:50,949 think you can see that in these bugs. 1250 00:42:50,950 --> 00:42:52,499 I mean, they have. The other two combined 1251 00:42:52,500 --> 00:42:54,599 is less so, yeah, it was 1252 00:42:54,600 --> 00:42:56,879 it wasn't that busy, tons of legacy code, 1253 00:42:56,880 --> 00:42:58,499 tons of combat code. 1254 00:42:58,500 --> 00:43:00,839 Yeah, it turns out when you have Lexing 1255 00:43:00,840 --> 00:43:02,939 evacuate when you have 96 and you 1256 00:43:02,940 --> 00:43:04,199 haven't looked at it since. 1257 00:43:04,200 --> 00:43:06,119 Yeah. You're going to have bugs. 1258 00:43:06,120 --> 00:43:07,739 They have these ISO protocols there, 1259 00:43:07,740 --> 00:43:09,599 which I don't know if anybody actually 1260 00:43:09,600 --> 00:43:10,979 uses those these days. 1261 00:43:10,980 --> 00:43:12,689 It's really ancient code from the 80s, 1262 00:43:12,690 --> 00:43:13,859 which is written by IBM. 1263 00:43:13,860 --> 00:43:15,719 And then it was important that bisdee and 1264 00:43:15,720 --> 00:43:17,129 it's been there ever since and nobody 1265 00:43:17,130 --> 00:43:18,480 knows what it does, but it's there 1266 00:43:19,740 --> 00:43:21,209 and a whole bunch of this really, really 1267 00:43:21,210 --> 00:43:22,210 old code. 1268 00:43:23,880 --> 00:43:26,309 The other thing is that there seems to be 1269 00:43:26,310 --> 00:43:28,529 less consistent with 1270 00:43:28,530 --> 00:43:30,239 security called security code quality 1271 00:43:30,240 --> 00:43:31,439 compared to the other BSD, 1272 00:43:32,940 --> 00:43:34,919 unlike obviously they have tons and tons 1273 00:43:34,920 --> 00:43:37,049 and tons of issues and 1274 00:43:37,050 --> 00:43:38,959 Satanas bugs there. 1275 00:43:38,960 --> 00:43:40,619 I mean, just I want to show that, you 1276 00:43:40,620 --> 00:43:43,049 know, of those right there. 1277 00:43:43,050 --> 00:43:44,579 So so there is definitely that sort of 1278 00:43:44,580 --> 00:43:46,439 code quality difference. 1279 00:43:46,440 --> 00:43:47,909 And I don't mean that as a dis. 1280 00:43:47,910 --> 00:43:49,019 I mean, I understand that. 1281 00:43:49,020 --> 00:43:51,269 I mean, building, maintaining, improving 1282 00:43:51,270 --> 00:43:52,469 OS is really, really hard. 1283 00:43:52,470 --> 00:43:54,299 And if you think it's easy, you know, try 1284 00:43:54,300 --> 00:43:56,489 it. So I understand that it's very hard 1285 00:43:56,490 --> 00:43:58,709 to analyze, but there is a clear 1286 00:43:58,710 --> 00:44:00,479 difference between if you if you look at 1287 00:44:00,480 --> 00:44:02,619 one or the other, you can see there's 1288 00:44:02,620 --> 00:44:04,949 there's a difference in code quality 1289 00:44:04,950 --> 00:44:07,079 when you look at the attack surface 1290 00:44:07,080 --> 00:44:09,299 and then FreeBSD is somewhere 1291 00:44:09,300 --> 00:44:10,300 in between. Really, 1292 00:44:11,490 --> 00:44:13,799 it's hard to place it, but it's 1293 00:44:13,800 --> 00:44:16,169 it's not it's not the code quality isn't 1294 00:44:16,170 --> 00:44:18,269 as bad as Nepsa, 1295 00:44:18,270 --> 00:44:19,679 but it's not as good as open BSD. 1296 00:44:20,950 --> 00:44:22,979 So, OK, so obviously when I found these 1297 00:44:22,980 --> 00:44:25,169 bugs, I, I talked 1298 00:44:25,170 --> 00:44:26,519 to the teams that are sending e-mails and 1299 00:44:26,520 --> 00:44:28,139 I said, hey, here's a list of bugs. 1300 00:44:28,140 --> 00:44:29,309 Have you guys should probably go and find 1301 00:44:29,310 --> 00:44:31,199 this, fix this. 1302 00:44:31,200 --> 00:44:32,939 So e-mail your music, guys. 1303 00:44:32,940 --> 00:44:34,919 And you know, T.O. gets back to me and 1304 00:44:34,920 --> 00:44:36,569 about a week or so later and first thing 1305 00:44:36,570 --> 00:44:37,739 he does, he says, Oh, I'm sorry, it took 1306 00:44:37,740 --> 00:44:38,939 me a week. Get back to you. 1307 00:44:38,940 --> 00:44:40,529 I was on vacation. 1308 00:44:40,530 --> 00:44:42,719 And he says all these bugs look good, is 1309 00:44:42,720 --> 00:44:43,919 definitely problematic. 1310 00:44:43,920 --> 00:44:45,149 We should go and fix these things. 1311 00:44:45,150 --> 00:44:47,279 And then he says emails back and says 1312 00:44:47,280 --> 00:44:48,719 the next two or three days you should see 1313 00:44:48,720 --> 00:44:50,819 fixes sort of 1314 00:44:50,820 --> 00:44:51,899 coming in our CVS. 1315 00:44:51,900 --> 00:44:52,900 And sure enough. 1316 00:44:54,210 --> 00:44:56,309 Twenty five bucks. I reported 1317 00:44:56,310 --> 00:44:57,839 less than a week and they fixed it, 1318 00:44:57,840 --> 00:44:58,840 right? 1319 00:44:59,730 --> 00:45:00,730 Yeah, I think that's good. 1320 00:45:06,550 --> 00:45:08,739 And then a couple of weeks later, the 1321 00:45:08,740 --> 00:45:10,809 abusive guys basically made 1322 00:45:10,810 --> 00:45:12,189 individual patches and advisories and 1323 00:45:12,190 --> 00:45:14,139 said, OK, if you have if you haven't, 1324 00:45:14,140 --> 00:45:15,579 please don't be easy and you want to fix 1325 00:45:15,580 --> 00:45:16,729 these bugs, here's the patches. 1326 00:45:16,730 --> 00:45:18,369 Here's how to do it. 1327 00:45:18,370 --> 00:45:19,809 So I think that was great. 1328 00:45:19,810 --> 00:45:20,889 I think that's perfect. I think that's 1329 00:45:20,890 --> 00:45:21,910 the way it's supposed to be. Right. 1330 00:45:23,470 --> 00:45:25,059 You know, within a week, responds a few 1331 00:45:25,060 --> 00:45:27,219 days later or fixes the 1332 00:45:27,220 --> 00:45:28,809 fixed in place and then like a week or 1333 00:45:28,810 --> 00:45:30,699 two after that, all the patches are 1334 00:45:30,700 --> 00:45:32,379 publicly available. 1335 00:45:32,380 --> 00:45:33,499 There's advisories. 1336 00:45:33,500 --> 00:45:35,769 This is exactly the way 1337 00:45:35,770 --> 00:45:37,809 a security process should work. 1338 00:45:37,810 --> 00:45:39,489 It means you guys have done everything 1339 00:45:39,490 --> 00:45:40,870 right as far as I'm concerned. 1340 00:45:42,460 --> 00:45:44,499 So Freebie is the hardcore. 1341 00:45:44,500 --> 00:45:46,929 Well, it sort of started off similarly 1342 00:45:46,930 --> 00:45:48,639 where I got a response within a couple of 1343 00:45:48,640 --> 00:45:50,739 days, maybe a week, and I got a 1344 00:45:50,740 --> 00:45:52,149 bug back from these guys and said, OK, 1345 00:45:52,150 --> 00:45:53,679 well, we've seen all your bugs and we 1346 00:45:53,680 --> 00:45:55,959 filed the internal bug database. 1347 00:45:55,960 --> 00:45:57,219 And this was July 14th. 1348 00:45:57,220 --> 00:45:59,469 And sure enough, this is from the email 1349 00:45:59,470 --> 00:46:00,369 and have blacked out. 1350 00:46:00,370 --> 00:46:01,719 What hasn't been fixed yet or what. 1351 00:46:01,720 --> 00:46:03,819 I'm not quite sure of just three negative 1352 00:46:03,820 --> 00:46:05,469 and fixed rate. 1353 00:46:05,470 --> 00:46:07,629 So since that 1354 00:46:07,630 --> 00:46:09,759 email, not all 1355 00:46:09,760 --> 00:46:10,969 that much has happened. Right. 1356 00:46:10,970 --> 00:46:13,089 It's five months later, 1357 00:46:13,090 --> 00:46:14,409 two devices have been released. 1358 00:46:15,520 --> 00:46:16,809 And so obviously those two books have 1359 00:46:16,810 --> 00:46:17,859 been fixed. And then there's the third 1360 00:46:17,860 --> 00:46:20,709 one is Akie Incap. 1361 00:46:20,710 --> 00:46:22,959 I saw 1362 00:46:22,960 --> 00:46:24,399 I saw civs commit for that. 1363 00:46:24,400 --> 00:46:25,659 So I know that was fixed. 1364 00:46:25,660 --> 00:46:27,759 All the others I it's 1365 00:46:27,760 --> 00:46:29,049 up in the air. I don't think they're 1366 00:46:29,050 --> 00:46:31,479 fixed. I, I quickly checked CBS 1367 00:46:31,480 --> 00:46:33,009 right before I came here. 1368 00:46:33,010 --> 00:46:34,719 They look like they're still in limbo 1369 00:46:34,720 --> 00:46:35,720 somewhere. 1370 00:46:36,460 --> 00:46:38,559 So, you know, this is this 1371 00:46:38,560 --> 00:46:39,790 is where freebees the 1372 00:46:42,350 --> 00:46:44,529 NEPI is the first of all 1373 00:46:44,530 --> 00:46:45,699 when I e-mailed news bugs, 1374 00:46:46,720 --> 00:46:48,879 a list of sixty bugs to 1375 00:46:48,880 --> 00:46:50,439 shit got fixed overnight. 1376 00:46:51,700 --> 00:46:53,170 Seriously. Seriously. 1377 00:47:01,880 --> 00:47:03,349 This is obviously unbelievably 1378 00:47:03,350 --> 00:47:04,879 impressive, right? 1379 00:47:04,880 --> 00:47:06,799 I don't know how you can do that, but 1380 00:47:06,800 --> 00:47:07,939 clearly there were two developers that 1381 00:47:07,940 --> 00:47:09,259 were like, oh, let's fix this shit, let's 1382 00:47:09,260 --> 00:47:10,260 fix it right now. 1383 00:47:11,060 --> 00:47:13,309 So that was that was very impressive. 1384 00:47:13,310 --> 00:47:14,569 And then, as I mentioned, it also turned 1385 00:47:14,570 --> 00:47:17,179 off your last year for 1386 00:47:17,180 --> 00:47:18,829 Campath subsystem. 1387 00:47:18,830 --> 00:47:20,649 And if you look at the commitments, you 1388 00:47:20,650 --> 00:47:21,619 know, the email they sent me said 1389 00:47:21,620 --> 00:47:23,539 basically it disappeared in the messages 1390 00:47:23,540 --> 00:47:25,519 that we've just able to ask for by 1391 00:47:25,520 --> 00:47:27,229 default, something that should have been 1392 00:47:27,230 --> 00:47:28,230 done a long time ago. 1393 00:47:29,270 --> 00:47:31,219 So that isn't really impressive. 1394 00:47:31,220 --> 00:47:34,369 That was late July 2013, 1395 00:47:34,370 --> 00:47:36,429 five months ago. 1396 00:47:36,430 --> 00:47:37,609 Let me let me tell you what's happened 1397 00:47:37,610 --> 00:47:39,769 since absolutely 1398 00:47:39,770 --> 00:47:43,189 nothing bugs are fixed and CBS, 1399 00:47:43,190 --> 00:47:44,509 there are no patches for current. 1400 00:47:44,510 --> 00:47:46,249 There are no advisories. 1401 00:47:46,250 --> 00:47:47,959 What this effectively means is if you're 1402 00:47:47,960 --> 00:47:50,329 running that busy today 1403 00:47:50,330 --> 00:47:52,409 or 60 bugs are there and you can 1404 00:47:52,410 --> 00:47:54,709 go us and 1405 00:47:54,710 --> 00:47:55,969 see exactly what the bug is. 1406 00:47:56,990 --> 00:47:58,819 So I wish they had followed up with some 1407 00:47:58,820 --> 00:48:00,409 patches and advisories. 1408 00:48:00,410 --> 00:48:02,329 So that kind of it started off really, 1409 00:48:02,330 --> 00:48:03,649 really, really well. And then they kind 1410 00:48:03,650 --> 00:48:04,650 of dropped the ball. 1411 00:48:07,640 --> 00:48:09,350 OK, so coming back to my sort of 1412 00:48:11,480 --> 00:48:13,789 the earlier where I began 1413 00:48:13,790 --> 00:48:15,529 my presentation, the sort of New York, 1414 00:48:15,530 --> 00:48:16,849 are things on equal footing? 1415 00:48:18,740 --> 00:48:20,899 Well, I think bugs are still 1416 00:48:20,900 --> 00:48:22,969 very to defined in the physical's, 1417 00:48:22,970 --> 00:48:24,849 probably about as easy as Colonel, 1418 00:48:26,000 --> 00:48:27,979 even open, because he wasn't I mean, 1419 00:48:27,980 --> 00:48:29,219 there were certain things I didn't see, 1420 00:48:29,220 --> 00:48:30,949 obviously, but it wasn't like it was hard 1421 00:48:30,950 --> 00:48:31,950 to find bugs in there. 1422 00:48:33,050 --> 00:48:35,479 There's certainly very little quality 1423 00:48:35,480 --> 00:48:37,639 between the two or 1424 00:48:37,640 --> 00:48:39,499 three of them and depends on the agent 1425 00:48:39,500 --> 00:48:40,489 who wrote it and under what 1426 00:48:40,490 --> 00:48:42,079 circumstances. 1427 00:48:42,080 --> 00:48:43,819 The most consistent set of quality I 1428 00:48:43,820 --> 00:48:46,009 found by far was open because again, 1429 00:48:46,010 --> 00:48:48,229 this comes back to their rigorous review 1430 00:48:48,230 --> 00:48:49,159 process, right? 1431 00:48:49,160 --> 00:48:51,589 Every every check in gets 1432 00:48:51,590 --> 00:48:52,669 reviewed. 1433 00:48:52,670 --> 00:48:54,349 I think that's a process that simply just 1434 00:48:54,350 --> 00:48:55,309 works. 1435 00:48:55,310 --> 00:48:57,739 With the exception to the idea of 1436 00:48:57,740 --> 00:48:59,929 the ABC. Guys have the same shitty code 1437 00:48:59,930 --> 00:49:01,789 everybody else is, and a fairly busy 1438 00:49:01,790 --> 00:49:03,199 developers refused to touch it. 1439 00:49:05,610 --> 00:49:08,599 Another thing I have that I 1440 00:49:08,600 --> 00:49:10,459 think should happen because I found a 1441 00:49:10,460 --> 00:49:12,439 couple of bugs where I was like, OK, this 1442 00:49:12,440 --> 00:49:14,089 bugs me, but it was fixing it. 1443 00:49:14,090 --> 00:49:15,499 BSD or and the other thing around where 1444 00:49:15,500 --> 00:49:17,569 I'm like, oh, this is Nepsa, but 1445 00:49:17,570 --> 00:49:19,729 you obviously got to fix it 15 years 1446 00:49:19,730 --> 00:49:21,739 ago. Right? So those things from time to 1447 00:49:21,740 --> 00:49:24,889 time did happen with some frequency. 1448 00:49:24,890 --> 00:49:27,169 And so ideally, 1449 00:49:27,170 --> 00:49:28,429 I think to maintain it, to be as we 1450 00:49:28,430 --> 00:49:30,889 should talk more among each other. 1451 00:49:30,890 --> 00:49:32,899 Now, understand, that's easier said than 1452 00:49:32,900 --> 00:49:34,879 done, because in the last two, three or 1453 00:49:34,880 --> 00:49:36,349 four years, they have diverged and 1454 00:49:36,350 --> 00:49:38,599 there's different philosophies and ideas 1455 00:49:38,600 --> 00:49:39,889 on where the music is supposed to go. 1456 00:49:39,890 --> 00:49:42,229 And obviously, you know, there's big egos 1457 00:49:42,230 --> 00:49:43,339 involved as well. 1458 00:49:43,340 --> 00:49:44,839 And so getting these guys to talk isn't 1459 00:49:44,840 --> 00:49:46,729 always very easy and it doesn't always 1460 00:49:46,730 --> 00:49:47,719 make sense. 1461 00:49:47,720 --> 00:49:49,159 But by and large, I think there's enough 1462 00:49:49,160 --> 00:49:51,259 commonality still between all the boards 1463 00:49:51,260 --> 00:49:53,509 that it would make sense that when 1464 00:49:53,510 --> 00:49:54,649 it comes to things that are attack 1465 00:49:54,650 --> 00:49:56,989 surface and fixes, it 1466 00:49:56,990 --> 00:49:58,669 would probably make sense of these guys 1467 00:49:58,670 --> 00:50:00,800 talked more with each other. 1468 00:50:03,790 --> 00:50:05,199 The other thing is that obviously, when 1469 00:50:05,200 --> 00:50:06,789 it comes to things, you know, if you look 1470 00:50:06,790 --> 00:50:08,649 at countries alone, that tells you 1471 00:50:08,650 --> 00:50:09,549 something about your tax. 1472 00:50:09,550 --> 00:50:11,739 If it's right, can as kernel is about 1473 00:50:11,740 --> 00:50:14,199 two point eight millions of code net BSD 1474 00:50:14,200 --> 00:50:16,119 is about seven point three million in 1475 00:50:16,120 --> 00:50:17,239 that business. 1476 00:50:17,240 --> 00:50:19,299 And this is 10 this was 11 1477 00:50:19,300 --> 00:50:20,289 points or I don't know what the latest 1478 00:50:20,290 --> 00:50:22,299 one is. The freezy was about nine 1479 00:50:22,300 --> 00:50:24,489 million. Right. So that alone tells 1480 00:50:24,490 --> 00:50:26,289 you that it is going to have less bugs 1481 00:50:26,290 --> 00:50:27,339 because they have less code. 1482 00:50:27,340 --> 00:50:28,340 Right. It's that easy. 1483 00:50:29,470 --> 00:50:30,649 So obviously, this plays a part, right. 1484 00:50:30,650 --> 00:50:31,989 You can't have a bug in code that you 1485 00:50:31,990 --> 00:50:33,759 don't have. Right. 1486 00:50:33,760 --> 00:50:34,840 And the other thing is obviously 1487 00:50:36,280 --> 00:50:38,559 sort of accidental versus planned where 1488 00:50:38,560 --> 00:50:40,749 if I haven't gotten if 1489 00:50:40,750 --> 00:50:41,769 I haven't done something yet, then you 1490 00:50:41,770 --> 00:50:42,770 can't have it yet. Right. 1491 00:50:44,200 --> 00:50:45,459 But the other thing is, obviously, is 1492 00:50:45,460 --> 00:50:47,859 that the plan was choices to make 1493 00:50:47,860 --> 00:50:49,669 the delete code on purpose. 1494 00:50:49,670 --> 00:50:51,879 And this is something we saw in OBC 1495 00:50:51,880 --> 00:50:53,919 where, you know, they chose to delete the 1496 00:50:53,920 --> 00:50:55,869 Bluetooth stack. They chose to delete 1497 00:50:55,870 --> 00:50:58,089 their letters, come back later. 1498 00:50:58,090 --> 00:50:59,799 And obviously it's a double edged sword. 1499 00:50:59,800 --> 00:51:01,389 You lose functionality, but you gain 1500 00:51:01,390 --> 00:51:04,059 security and try to find that balance 1501 00:51:04,060 --> 00:51:05,529 to obviously, you know, cutting code. 1502 00:51:05,530 --> 00:51:07,599 You know, that generally, you know, 1503 00:51:07,600 --> 00:51:09,189 it cuts to service and generally means 1504 00:51:09,190 --> 00:51:10,190 you have less bugs. 1505 00:51:12,640 --> 00:51:14,759 Right, so, yeah, 1506 00:51:14,760 --> 00:51:17,789 my conclusions basically 1507 00:51:17,790 --> 00:51:18,929 going back to what I 1508 00:51:19,950 --> 00:51:21,209 was dealing with, that, which was the 1509 00:51:21,210 --> 00:51:22,210 many eyeballs thing. 1510 00:51:23,070 --> 00:51:24,069 Yeah, I think that's a factor. 1511 00:51:24,070 --> 00:51:25,519 I think it really does matter. 1512 00:51:25,520 --> 00:51:27,629 Right. I think if you have more people 1513 00:51:27,630 --> 00:51:29,219 looking at something, more books are 1514 00:51:29,220 --> 00:51:30,179 going to be found. 1515 00:51:30,180 --> 00:51:31,799 And so I think one of the big reasons why 1516 00:51:31,800 --> 00:51:33,629 the numbers are off when you compare 1517 00:51:33,630 --> 00:51:35,789 those tables initially, I think 1518 00:51:35,790 --> 00:51:37,889 a large part of it is 1519 00:51:37,890 --> 00:51:39,749 more people are looking at a girl and so 1520 00:51:39,750 --> 00:51:41,459 they're going to find more bugs. 1521 00:51:41,460 --> 00:51:43,799 Coach quality can't explain 1522 00:51:43,800 --> 00:51:44,800 everything. 1523 00:51:49,070 --> 00:51:51,259 And right, I mean, 1524 00:51:51,260 --> 00:51:52,609 you can say what you want about people, 1525 00:51:52,610 --> 00:51:54,489 ratlines colonel, but, you know, there 1526 00:51:54,490 --> 00:51:56,179 are just orders of magnitude people. 1527 00:51:56,180 --> 00:51:57,979 More people looking at that quote are 1528 00:51:57,980 --> 00:51:59,689 just going to find more bucks. 1529 00:51:59,690 --> 00:52:00,849 And it shows in numbers, 1530 00:52:02,060 --> 00:52:03,770 and that's pretty much it. 1531 00:52:15,040 --> 00:52:16,929 That was frightfully awesome. 1532 00:52:20,080 --> 00:52:22,239 OK, I'm quite convinced people 1533 00:52:22,240 --> 00:52:24,309 want to ask a bunch of questions, 1534 00:52:24,310 --> 00:52:26,139 we got about nine minutes. 1535 00:52:27,340 --> 00:52:29,559 Let's start with 1536 00:52:29,560 --> 00:52:30,849 you over there. 1537 00:52:30,850 --> 00:52:32,880 One sentence, one question mark, 1538 00:52:35,260 --> 00:52:37,449 but thank you for your awesome 1539 00:52:37,450 --> 00:52:40,479 work and nice presentation. 1540 00:52:40,480 --> 00:52:42,669 And the question is, 1541 00:52:42,670 --> 00:52:44,769 are you interested in 1542 00:52:44,770 --> 00:52:45,770 exploiting 1543 00:52:47,080 --> 00:52:49,569 so you had a crush crush 1544 00:52:49,570 --> 00:52:51,789 us? And how about making 1545 00:52:51,790 --> 00:52:53,859 a proof of concept legal privileges 1546 00:52:53,860 --> 00:52:56,079 coalition or RC 1547 00:52:56,080 --> 00:52:57,699 and what is execution? 1548 00:52:57,700 --> 00:52:59,769 Yeah, given that my plan was 1549 00:52:59,770 --> 00:53:01,869 to report all the bugs I saw 1550 00:53:01,870 --> 00:53:03,789 really no point in running football next 1551 00:53:03,790 --> 00:53:05,859 points because it's wasted effort, right? 1552 00:53:05,860 --> 00:53:07,929 The only to me, the only way I mean if 1553 00:53:07,930 --> 00:53:10,059 I go to my next point, I don't 1554 00:53:10,060 --> 00:53:11,749 like I don't, I don't want to next one 1555 00:53:11,750 --> 00:53:12,939 for a bug. I know it's going to get killed. 1556 00:53:12,940 --> 00:53:15,159 Right. So I didn't see I mean, 1557 00:53:15,160 --> 00:53:16,509 some of these bugs would have taken me 1558 00:53:16,510 --> 00:53:18,369 weeks or months to sit down and write 1559 00:53:18,370 --> 00:53:19,370 code for. 1560 00:53:20,080 --> 00:53:21,669 And so I didn't I don't think it would 1561 00:53:21,670 --> 00:53:22,839 have been very useful for me to write 1562 00:53:22,840 --> 00:53:23,840 full-blown exploits. 1563 00:53:24,880 --> 00:53:26,619 I know there's a shock and awe factor to 1564 00:53:26,620 --> 00:53:29,589 exploit. And at times they can be useful, 1565 00:53:29,590 --> 00:53:31,959 given my understanding or my assumption 1566 00:53:31,960 --> 00:53:33,639 that the people on the other end, I was 1567 00:53:33,640 --> 00:53:35,799 talking to people like Dō 1568 00:53:35,800 --> 00:53:37,629 that are very knowledgeable in this area. 1569 00:53:37,630 --> 00:53:39,039 I didn't feel there was any need to write 1570 00:53:39,040 --> 00:53:41,229 the write next board, and so I didn't. 1571 00:53:41,230 --> 00:53:42,769 Does that answer your question? 1572 00:53:42,770 --> 00:53:43,219 Things. 1573 00:53:43,220 --> 00:53:44,220 But 1574 00:53:45,760 --> 00:53:48,309 showing exploits usually 1575 00:53:48,310 --> 00:53:50,049 helps to convince people in 1576 00:53:50,050 --> 00:53:52,119 self-protection technique technologies 1577 00:53:52,120 --> 00:53:54,579 like we have our security and. 1578 00:53:54,580 --> 00:53:56,049 Oh, yes, absolutely no. 1579 00:53:56,050 --> 00:53:57,669 I mean in mitigation obviously got a good 1580 00:53:57,670 --> 00:53:59,859 thing. And we should we should keep 1581 00:53:59,860 --> 00:54:02,679 innovating in scoring new medications. 1582 00:54:02,680 --> 00:54:04,179 It's just that I don't think this would 1583 00:54:04,180 --> 00:54:06,009 have contributed much to it. 1584 00:54:06,010 --> 00:54:07,629 OK, thank you. 1585 00:54:07,630 --> 00:54:09,339 There's a question from the Internet. 1586 00:54:09,340 --> 00:54:11,649 Please listen to the dark side. 1587 00:54:11,650 --> 00:54:13,330 Yes, I think the dark side. 1588 00:54:14,350 --> 00:54:17,229 How would you suggest to improve 1589 00:54:17,230 --> 00:54:20,399 cooperating between the different BSD? 1590 00:54:20,400 --> 00:54:21,489 That's a good question. 1591 00:54:21,490 --> 00:54:22,389 I mean, I don't know. 1592 00:54:22,390 --> 00:54:24,579 I understand because I know I 1593 00:54:24,580 --> 00:54:25,809 know what you said a few things about. 1594 00:54:25,810 --> 00:54:27,049 Well, you know, it's not easy to talk to 1595 00:54:27,050 --> 00:54:30,249 other people because so and so and so 1596 00:54:30,250 --> 00:54:32,499 I don't know how to you know, either they 1597 00:54:32,500 --> 00:54:33,759 get these guys in a room and get them to 1598 00:54:33,760 --> 00:54:34,760 talk or something. 1599 00:54:36,490 --> 00:54:37,719 Obviously, there's 1600 00:54:40,150 --> 00:54:41,619 there are some difference between the two 1601 00:54:41,620 --> 00:54:43,599 and they're not there. 1602 00:54:43,600 --> 00:54:45,669 Certain things, obviously, that, 1603 00:54:45,670 --> 00:54:47,109 you know, where there's differences, they 1604 00:54:47,110 --> 00:54:48,249 don't necessarily have to talk to each 1605 00:54:48,250 --> 00:54:49,250 other. 1606 00:54:49,660 --> 00:54:51,729 But I can't I don't really 1607 00:54:51,730 --> 00:54:53,469 know of any specific way to try to 1608 00:54:53,470 --> 00:54:54,969 massage them, to talk to them, to each 1609 00:54:54,970 --> 00:54:57,189 other. All I can say is find 1610 00:54:57,190 --> 00:54:58,119 the right containers for the right 1611 00:54:58,120 --> 00:55:00,489 subsystems. And if some guy fixes 1612 00:55:00,490 --> 00:55:01,659 a bug, it's something where they go, this 1613 00:55:01,660 --> 00:55:03,249 is a tax surface. 1614 00:55:03,250 --> 00:55:05,529 You know, reach out to the guy on 1615 00:55:05,530 --> 00:55:07,659 the other you know, the other 1616 00:55:07,660 --> 00:55:09,609 BSD, Amela, and just drop. 1617 00:55:09,610 --> 00:55:11,709 And it will be like, hey, guys, maybe you 1618 00:55:11,710 --> 00:55:13,569 should look at this to be all that. 1619 00:55:13,570 --> 00:55:15,130 I have no good answer, really. 1620 00:55:17,330 --> 00:55:18,469 OK, thank you. 1621 00:55:18,470 --> 00:55:20,179 Is there another question from the 1622 00:55:20,180 --> 00:55:21,559 Internet? 1623 00:55:21,560 --> 00:55:22,579 Not yet. 1624 00:55:22,580 --> 00:55:23,580 Not yet. 1625 00:55:24,350 --> 00:55:25,729 How about one last question? 1626 00:55:25,730 --> 00:55:27,030 We got five more minutes. 1627 00:55:28,070 --> 00:55:30,199 Anybody at the microphone who. 1628 00:55:30,200 --> 00:55:31,969 I'm not really seeing anything out there. 1629 00:55:33,800 --> 00:55:35,929 OK, over 1630 00:55:35,930 --> 00:55:37,369 there on the left. Excuse me. 1631 00:55:39,210 --> 00:55:41,719 My question was about methodology. 1632 00:55:41,720 --> 00:55:43,909 Did you use any automated tool or did 1633 00:55:43,910 --> 00:55:45,289 you do everything by hand 1634 00:55:46,420 --> 00:55:47,479 where you come from? 1635 00:55:47,480 --> 00:55:49,999 Anywhere on the left side, 1636 00:55:50,000 --> 00:55:51,319 your neighbors are in the back. 1637 00:55:51,320 --> 00:55:52,339 Oh, OK. 1638 00:55:52,340 --> 00:55:54,709 Yeah, well, I didn't 1639 00:55:54,710 --> 00:55:56,869 I nine out 1640 00:55:56,870 --> 00:55:58,429 of this thing was like straight up 1641 00:55:58,430 --> 00:55:59,749 reading code. 1642 00:55:59,750 --> 00:56:02,209 Just, you know, I open up in 1643 00:56:02,210 --> 00:56:04,639 an idea and I was reading it. 1644 00:56:04,640 --> 00:56:05,899 There were a couple of times when I used 1645 00:56:05,900 --> 00:56:08,719 some grep to look for some patterns. 1646 00:56:08,720 --> 00:56:10,369 But beyond that, no, it was just me 1647 00:56:10,370 --> 00:56:12,559 reading code that 1648 00:56:12,560 --> 00:56:13,819 was pretty much there were no other tools 1649 00:56:13,820 --> 00:56:14,820 involved. 1650 00:56:21,880 --> 00:56:24,029 I think we'll take one more, one more? 1651 00:56:24,030 --> 00:56:24,999 Sure, yeah. 1652 00:56:25,000 --> 00:56:27,219 One more here 1653 00:56:27,220 --> 00:56:28,220 than you want to. 1654 00:56:29,380 --> 00:56:31,119 Now's your big chance. 1655 00:56:31,120 --> 00:56:33,279 Could you describe your motivation 1656 00:56:33,280 --> 00:56:35,349 of spending three months 1657 00:56:35,350 --> 00:56:36,350 on that work? 1658 00:56:37,330 --> 00:56:39,399 Yeah, I know CAVU isn't 1659 00:56:39,400 --> 00:56:41,499 for everyone. I think I once heard it 1660 00:56:41,500 --> 00:56:43,749 described being more boring than watching 1661 00:56:43,750 --> 00:56:44,750 paint dry. 1662 00:56:45,580 --> 00:56:46,809 I disagree with that. 1663 00:56:46,810 --> 00:56:48,909 I actually I enjoy reading code. 1664 00:56:49,930 --> 00:56:51,129 I think it's fun. 1665 00:56:51,130 --> 00:56:52,509 I think there's a number of things you 1666 00:56:52,510 --> 00:56:54,070 can learn from reading code 1667 00:56:55,240 --> 00:56:57,399 and it's sort of interesting 1668 00:56:57,400 --> 00:56:59,079 sort of kick from writing. Like if I find 1669 00:56:59,080 --> 00:57:00,939 a bug in pieces like sometimes used to be 1670 00:57:00,940 --> 00:57:03,069 the code and I'm like, oh 1671 00:57:03,070 --> 00:57:04,539 like, oh, they screw this up. 1672 00:57:04,540 --> 00:57:05,949 Like, I noticed this and they didn't. 1673 00:57:05,950 --> 00:57:08,079 So there's a little bit of that. 1674 00:57:08,080 --> 00:57:09,080 But generally, 1675 00:57:10,510 --> 00:57:12,699 yeah, I, I generally enjoy it and 1676 00:57:12,700 --> 00:57:14,949 I know some people don't, but for me 1677 00:57:14,950 --> 00:57:16,569 it was, it wasn't a death march, it 1678 00:57:16,570 --> 00:57:20,019 wasn't a stretch. I was I had no problem. 1679 00:57:20,020 --> 00:57:21,879 And when I say three, three, four months, 1680 00:57:21,880 --> 00:57:23,499 I mean on and off because obviously I've 1681 00:57:23,500 --> 00:57:25,119 worked and things. So it's like evenings 1682 00:57:25,120 --> 00:57:26,319 and weekends. 1683 00:57:26,320 --> 00:57:27,759 But it wasn't it wasn't hard. 1684 00:57:27,760 --> 00:57:29,199 It was difficult. I was just like, OK, 1685 00:57:29,200 --> 00:57:31,449 let's open up my laptop and I'll spend 1686 00:57:31,450 --> 00:57:32,889 the next three or four hours looking at 1687 00:57:32,890 --> 00:57:34,030 the system or something. 1688 00:57:35,110 --> 00:57:36,399 I didn't think it was hard. 1689 00:57:36,400 --> 00:57:38,499 I understand there's not for everyone, 1690 00:57:38,500 --> 00:57:39,609 but I. 1691 00:57:39,610 --> 00:57:42,459 I tend to enjoy that view. 1692 00:57:42,460 --> 00:57:44,059 Thanks again for your work. 1693 00:57:44,060 --> 00:57:45,060 I'll see. 1694 00:57:45,670 --> 00:57:47,710 OK, thank you very much. 1695 00:57:50,440 --> 00:57:52,929 Am I overseeing a question somewhere? 1696 00:57:54,340 --> 00:57:56,769 No, now's 1697 00:57:56,770 --> 00:57:58,119 your chance. 1698 00:57:58,120 --> 00:57:59,799 The Internet, yes. 1699 00:57:59,800 --> 00:58:01,269 There's one final question from the 1700 00:58:01,270 --> 00:58:02,589 Internet. 1701 00:58:02,590 --> 00:58:05,229 Why the BSD may not be cooperating? 1702 00:58:05,230 --> 00:58:06,909 Is there at least a common mission 1703 00:58:06,910 --> 00:58:09,059 statement or any high level thing that 1704 00:58:09,060 --> 00:58:11,119 they could at least agree on? 1705 00:58:13,390 --> 00:58:15,759 This is a non security BSD 1706 00:58:15,760 --> 00:58:17,329 question. I have no idea. 1707 00:58:17,330 --> 00:58:18,849 I think there are people here that are 1708 00:58:18,850 --> 00:58:20,949 probably a much better 1709 00:58:20,950 --> 00:58:22,929 place than I am to answer these kind of 1710 00:58:22,930 --> 00:58:23,930 questions. 1711 00:58:25,010 --> 00:58:26,010 I have no idea. 1712 00:58:27,110 --> 00:58:29,079 OK, if that's it. 1713 00:58:29,080 --> 00:58:30,940 Thank you. But let's have a final hand.