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/94 Thanks! 1 00:00:09,730 --> 00:00:12,129 OK, now now we're going to start, 2 00:00:12,130 --> 00:00:14,889 so on that three next speakers 3 00:00:14,890 --> 00:00:17,229 are Sergei Brutus 4 00:00:17,230 --> 00:00:19,449 is a research assistant professor at 5 00:00:19,450 --> 00:00:20,450 Dartmouth College. 6 00:00:22,150 --> 00:00:24,459 Next is backs. 7 00:00:25,580 --> 00:00:27,169 She's a Ph.D. 8 00:00:27,170 --> 00:00:29,419 student, also at Dartmouth College, 9 00:00:29,420 --> 00:00:31,519 and to the right is Julian 10 00:00:31,520 --> 00:00:34,459 Baggett. He's a student at MIT. 11 00:00:34,460 --> 00:00:36,649 And they all specialize in finding 12 00:00:36,650 --> 00:00:38,329 machines where there shouldn't be any 13 00:00:38,330 --> 00:00:40,159 machines. And sometimes sometimes these 14 00:00:40,160 --> 00:00:42,559 machines turn out to be Turing complete, 15 00:00:42,560 --> 00:00:44,749 and they're now going to show us 16 00:00:44,750 --> 00:00:45,889 their latest work. 17 00:00:45,890 --> 00:00:48,079 Please give it up for trusting 18 00:00:48,080 --> 00:00:49,580 trust for binary tool. 19 00:00:55,610 --> 00:00:58,579 Hello. It's great to be here. 20 00:00:58,580 --> 00:01:00,979 We're going to build on 21 00:01:00,980 --> 00:01:03,079 our previous series talk, which 22 00:01:03,080 --> 00:01:04,488 some of you may have caught. 23 00:01:04,489 --> 00:01:07,209 If not, we'll catch you up. 24 00:01:07,210 --> 00:01:09,319 And I 25 00:01:09,320 --> 00:01:11,659 am Sergei. We're from Dartmouth. 26 00:01:11,660 --> 00:01:13,789 Julian was from Dartmouth as well, but 27 00:01:13,790 --> 00:01:15,139 he defected. 28 00:01:15,140 --> 00:01:16,140 Traitor. 29 00:01:19,130 --> 00:01:22,039 OK, so 30 00:01:22,040 --> 00:01:24,469 this is what we're going to talk about. 31 00:01:24,470 --> 00:01:26,689 Imagine, if you will, that we 32 00:01:26,690 --> 00:01:29,209 could make bugs disappear 33 00:01:29,210 --> 00:01:31,279 magically for some definition 34 00:01:31,280 --> 00:01:33,019 of disappear, for some definition of 35 00:01:33,020 --> 00:01:35,419 bugs. Would we still be able 36 00:01:35,420 --> 00:01:37,609 to or will we be able to build chains 37 00:01:37,610 --> 00:01:39,799 of trust that wouldn't suck so much as 38 00:01:39,800 --> 00:01:41,119 they do now? 39 00:01:41,120 --> 00:01:43,579 And we're going to explain why not 40 00:01:43,580 --> 00:01:46,009 and why the standard 41 00:01:46,010 --> 00:01:48,049 practices of constructing chains of trust 42 00:01:48,050 --> 00:01:50,149 these days have to change before we 43 00:01:50,150 --> 00:01:52,219 can actually trust 44 00:01:52,220 --> 00:01:54,409 them. And if you want 45 00:01:54,410 --> 00:01:56,099 a tongue twister to go with this as a 46 00:01:56,100 --> 00:01:58,459 take home and bagless, Babel breaks 47 00:01:58,460 --> 00:01:59,929 badly. 48 00:01:59,930 --> 00:02:01,879 Right. Because this is going to be about 49 00:02:01,880 --> 00:02:04,280 the Tower of Babel and 50 00:02:05,720 --> 00:02:08,000 the problems that you get when you have 51 00:02:09,110 --> 00:02:11,179 things disagreeing on components of 52 00:02:11,180 --> 00:02:12,379 your trust chain, disagreeing on 53 00:02:12,380 --> 00:02:13,489 dialects. 54 00:02:13,490 --> 00:02:14,869 And we're going to show you some case 55 00:02:14,870 --> 00:02:16,939 studies, in 56 00:02:16,940 --> 00:02:19,099 particular el signing and 57 00:02:19,100 --> 00:02:20,299 a bit about. 58 00:02:20,300 --> 00:02:22,489 And then we're going to show you how 59 00:02:22,490 --> 00:02:24,589 the Linux kernel disagrees with the 60 00:02:24,590 --> 00:02:26,659 Linux loader about 61 00:02:26,660 --> 00:02:28,969 what is where in the loaded image. 62 00:02:28,970 --> 00:02:29,970 Isn't that fun? 63 00:02:31,760 --> 00:02:34,369 I'll start with theory and then handed 64 00:02:34,370 --> 00:02:36,259 to books, and then she'll handle to 65 00:02:36,260 --> 00:02:37,549 Julian. 66 00:02:37,550 --> 00:02:39,889 So 1984 67 00:02:39,890 --> 00:02:42,049 Ken Thompson in his famous reflections 68 00:02:42,050 --> 00:02:43,099 on trusting trust. 69 00:02:44,210 --> 00:02:46,339 Almost 30 years ago, you know, 70 00:02:46,340 --> 00:02:48,050 29 that Watson of Buy One 71 00:02:49,190 --> 00:02:51,649 came up with this maxim 72 00:02:51,650 --> 00:02:53,749 that you can't trust code that 73 00:02:53,750 --> 00:02:56,689 you didn't completely write yourself. 74 00:02:56,690 --> 00:02:59,839 And he planted the bug in the compiler 75 00:02:59,840 --> 00:03:02,299 and the compiler, 76 00:03:02,300 --> 00:03:04,429 having compiled whatever was built 77 00:03:04,430 --> 00:03:06,379 with that trust chain, propagated the 78 00:03:06,380 --> 00:03:09,109 backdoor into everything and compiled. 79 00:03:09,110 --> 00:03:10,909 And so you shouldn't really trust your 80 00:03:10,910 --> 00:03:11,910 compiler. 81 00:03:12,980 --> 00:03:15,439 He went on to predict the future. 82 00:03:15,440 --> 00:03:18,169 And by now, everything 83 00:03:18,170 --> 00:03:19,550 that he predicted came true, 84 00:03:20,780 --> 00:03:22,879 including well-placed 85 00:03:22,880 --> 00:03:24,139 microcode bugs. 86 00:03:24,140 --> 00:03:25,550 And really, these days, 87 00:03:26,570 --> 00:03:28,519 when you look at software, you wonder, 88 00:03:28,520 --> 00:03:30,589 well, which software doesn't have planted 89 00:03:30,590 --> 00:03:31,590 bugs right 90 00:03:32,900 --> 00:03:34,999 of certain organizations has something 91 00:03:35,000 --> 00:03:37,069 to do with it. But honestly, 92 00:03:37,070 --> 00:03:39,589 50 years ago, I never imagined 93 00:03:39,590 --> 00:03:42,799 that I would ever encounter 94 00:03:42,800 --> 00:03:44,879 a deliberately planted bug. 95 00:03:44,880 --> 00:03:45,919 And yet here we go. 96 00:03:47,320 --> 00:03:49,479 But what if 97 00:03:49,480 --> 00:03:51,609 we could wave a magic wand and make it 98 00:03:51,610 --> 00:03:53,139 all go away? 99 00:03:53,140 --> 00:03:55,059 What if we could completely trust the 100 00:03:55,060 --> 00:03:56,379 author? 101 00:03:56,380 --> 00:03:59,679 And what if the author could completely 102 00:03:59,680 --> 00:04:02,379 trust him or herself 103 00:04:02,380 --> 00:04:04,689 to have the code do 104 00:04:04,690 --> 00:04:07,030 exactly what the author intended? 105 00:04:08,350 --> 00:04:10,779 Would we solve trusting trust them? 106 00:04:12,130 --> 00:04:14,289 And the answer is 107 00:04:14,290 --> 00:04:15,290 Hell, no. 108 00:04:17,450 --> 00:04:19,889 And the reason is that 109 00:04:19,890 --> 00:04:22,969 our trust chains are 110 00:04:22,970 --> 00:04:25,639 built up and up and up, 111 00:04:25,640 --> 00:04:27,979 and all of the components of those trust 112 00:04:27,980 --> 00:04:30,049 chains must talk to each 113 00:04:30,050 --> 00:04:32,839 other and agree on what they're saying 114 00:04:32,840 --> 00:04:35,359 and agree on what they're interpreting. 115 00:04:35,360 --> 00:04:37,939 This is what software engineering 116 00:04:37,940 --> 00:04:40,279 pretty much looks today, 117 00:04:40,280 --> 00:04:41,280 right? 118 00:04:41,750 --> 00:04:43,399 If you need the 119 00:04:44,420 --> 00:04:46,009 narrative biblical narrative 120 00:04:47,150 --> 00:04:49,489 reminder, people 121 00:04:49,490 --> 00:04:51,679 decided to build a tower to reach 122 00:04:51,680 --> 00:04:53,089 the sky. 123 00:04:53,090 --> 00:04:55,519 They, the 124 00:04:55,520 --> 00:04:57,469 powers that be did not like that. 125 00:04:57,470 --> 00:04:59,779 So they made 126 00:04:59,780 --> 00:05:02,809 the dialects of the builders diverge. 127 00:05:02,810 --> 00:05:04,969 And suddenly, if 128 00:05:04,970 --> 00:05:07,789 one builder asked for a rope, 129 00:05:07,790 --> 00:05:10,369 he was instead handed the sole 130 00:05:10,370 --> 00:05:12,679 or the, 131 00:05:12,680 --> 00:05:14,689 you know, somebody said, Give me a sword. 132 00:05:14,690 --> 00:05:16,249 And the other person heard. 133 00:05:16,250 --> 00:05:17,540 Well, your father is a donkey. 134 00:05:19,250 --> 00:05:21,649 And as you can imagine, the construction 135 00:05:21,650 --> 00:05:24,349 didn't go well afterwards. 136 00:05:24,350 --> 00:05:26,809 So if we're to explain it with cats, 137 00:05:26,810 --> 00:05:28,939 right? The components of the 138 00:05:28,940 --> 00:05:30,769 trust chain must 139 00:05:32,720 --> 00:05:35,629 speak precisely the same dialect 140 00:05:35,630 --> 00:05:36,739 of the inputs 141 00:05:38,000 --> 00:05:40,969 or else you are going to have. 142 00:05:40,970 --> 00:05:43,219 Well, we're 143 00:05:43,220 --> 00:05:44,989 going to call this the Babel cat. 144 00:05:44,990 --> 00:05:46,310 You know, the ceiling cat, 145 00:05:47,630 --> 00:05:49,609 which is of your moral health. 146 00:05:49,610 --> 00:05:51,709 The Babel cat 147 00:05:51,710 --> 00:05:52,759 isn't your trust chance. 148 00:05:54,770 --> 00:05:57,049 Well, let's make 149 00:05:57,050 --> 00:05:58,999 this a bit more theoretical before we get 150 00:05:59,000 --> 00:06:00,000 to the practice. 151 00:06:00,950 --> 00:06:02,629 What is a chain of trust? 152 00:06:02,630 --> 00:06:04,699 A chain of trust is really a chain 153 00:06:04,700 --> 00:06:06,799 of execution environments 154 00:06:06,800 --> 00:06:08,149 of increasing power. 155 00:06:08,150 --> 00:06:10,519 You start at, but you execute 156 00:06:10,520 --> 00:06:12,769 some code, you load your OS, 157 00:06:12,770 --> 00:06:15,139 you execute some code and 158 00:06:15,140 --> 00:06:17,809 eventually you want to get to the 159 00:06:17,810 --> 00:06:19,549 executable that you want to run, 160 00:06:19,550 --> 00:06:21,859 construct a process out of it and 161 00:06:21,860 --> 00:06:24,109 run it. And hopefully throughout 162 00:06:24,110 --> 00:06:26,389 that entire process, no 163 00:06:26,390 --> 00:06:28,489 unexpected computation 164 00:06:28,490 --> 00:06:30,919 otherwise known as personnage occurs. 165 00:06:32,410 --> 00:06:33,819 It's the same code. 166 00:06:33,820 --> 00:06:36,039 It's the same bytes that are being 167 00:06:36,040 --> 00:06:38,619 interpreted by a chain of passers 168 00:06:38,620 --> 00:06:41,109 and handled by a chain of loaders. 169 00:06:41,110 --> 00:06:43,299 And so the meaning of those bytes 170 00:06:43,300 --> 00:06:45,579 has to be completely agreed upon 171 00:06:45,580 --> 00:06:47,889 between all of those truss 172 00:06:47,890 --> 00:06:48,890 links. 173 00:06:50,200 --> 00:06:52,269 Now, when I say trust, 174 00:06:52,270 --> 00:06:54,189 what exactly do I mean, right? 175 00:06:54,190 --> 00:06:55,149 How do we trust? 176 00:06:55,150 --> 00:06:56,479 Why do we trust things? 177 00:06:56,480 --> 00:06:58,569 Why do we trust bikes 178 00:06:58,570 --> 00:06:59,649 to run them? 179 00:06:59,650 --> 00:07:01,569 Well, you know, there are two approaches 180 00:07:01,570 --> 00:07:02,709 to this. 181 00:07:02,710 --> 00:07:05,319 You can't analyze 182 00:07:05,320 --> 00:07:07,809 Turing complete binary code, 183 00:07:07,810 --> 00:07:09,549 which is, of course, what you compile 184 00:07:09,550 --> 00:07:10,569 down to. 185 00:07:10,570 --> 00:07:12,729 And so instead, you 186 00:07:12,730 --> 00:07:13,959 sign it. 187 00:07:13,960 --> 00:07:16,239 You trust the process of 188 00:07:16,240 --> 00:07:17,919 your developers, you trust their good 189 00:07:17,920 --> 00:07:20,679 intentions, you trust their 190 00:07:20,680 --> 00:07:23,349 scopes and so on. 191 00:07:23,350 --> 00:07:25,509 And so you get this frozen bit of 192 00:07:25,510 --> 00:07:27,759 code and you hope 193 00:07:27,760 --> 00:07:28,870 that it will be immutable. 194 00:07:30,890 --> 00:07:33,529 Or there is another way 195 00:07:33,530 --> 00:07:36,499 you can actually check the code 196 00:07:36,500 --> 00:07:38,659 do static on the list is of it. 197 00:07:38,660 --> 00:07:40,759 Convince yourself that the 198 00:07:40,760 --> 00:07:42,739 execution of it will be exactly as 199 00:07:42,740 --> 00:07:43,759 intended. 200 00:07:43,760 --> 00:07:45,319 It can do that as well. 201 00:07:45,320 --> 00:07:47,509 And then 202 00:07:47,510 --> 00:07:49,099 you can trust it because you've analyzed 203 00:07:49,100 --> 00:07:51,559 it. It doesn't work with General 204 00:07:51,560 --> 00:07:53,839 Code. No matter what, NATO 205 00:07:53,840 --> 00:07:56,059 virus vendors will tell you how many 206 00:07:56,060 --> 00:07:57,979 times a day they sold the halting 207 00:07:57,980 --> 00:07:59,269 problem, you know, 208 00:08:02,690 --> 00:08:03,690 so. 209 00:08:04,620 --> 00:08:06,719 Let's see which kinds of trust 210 00:08:06,720 --> 00:08:08,219 are are interested in, and the answer is 211 00:08:08,220 --> 00:08:09,809 both. Right? 212 00:08:09,810 --> 00:08:12,149 You freeze some bits 213 00:08:12,150 --> 00:08:14,219 in your binary, but you also 214 00:08:14,220 --> 00:08:15,929 want to do composition. 215 00:08:15,930 --> 00:08:17,519 You also want to have libraries. 216 00:08:17,520 --> 00:08:19,919 Laudable modules combine 217 00:08:19,920 --> 00:08:22,589 sign code from different sources. 218 00:08:22,590 --> 00:08:25,019 So in the end, you were 219 00:08:25,020 --> 00:08:27,239 trusted. Binary ends up being 220 00:08:27,240 --> 00:08:29,819 this kind of a sausage thing with 221 00:08:29,820 --> 00:08:32,339 some bits of frozen and hard 222 00:08:32,340 --> 00:08:34,619 and some other bits telling you 223 00:08:34,620 --> 00:08:36,959 where in that sausage, 224 00:08:36,960 --> 00:08:39,089 the trusted bits the frozen 225 00:08:39,090 --> 00:08:40,408 bits are. 226 00:08:40,409 --> 00:08:42,749 So enter 227 00:08:42,750 --> 00:08:44,939 stage right or stage 228 00:08:44,940 --> 00:08:47,279 left tables, 229 00:08:47,280 --> 00:08:49,499 tables that describe whether 230 00:08:49,500 --> 00:08:51,689 the sign pieces are and 231 00:08:51,690 --> 00:08:54,209 where those signatures are. 232 00:08:54,210 --> 00:08:56,129 And you know, a table is a table, right? 233 00:08:56,130 --> 00:08:57,329 The table is very simple. 234 00:08:58,680 --> 00:09:00,509 You can 235 00:09:02,280 --> 00:09:04,230 put the stuff at full of offsets, right? 236 00:09:05,340 --> 00:09:07,619 Or you can even put some data 237 00:09:07,620 --> 00:09:09,689 in there about how you replicate 238 00:09:09,690 --> 00:09:11,759 the code, how to patch the 239 00:09:11,760 --> 00:09:12,689 code. 240 00:09:12,690 --> 00:09:14,429 It's still a table, right? 241 00:09:14,430 --> 00:09:16,529 So that makes it asla 242 00:09:16,530 --> 00:09:17,969 possible. 243 00:09:17,970 --> 00:09:20,039 But really, if you don't, if 244 00:09:20,040 --> 00:09:22,259 you do composition, you can't avoid 245 00:09:22,260 --> 00:09:23,819 having tables. 246 00:09:23,820 --> 00:09:26,339 But in fact, any input 247 00:09:26,340 --> 00:09:28,649 is a program and any 248 00:09:28,650 --> 00:09:30,869 table is a program as 249 00:09:30,870 --> 00:09:31,949 well. 250 00:09:31,950 --> 00:09:34,229 So what happens there is here's 251 00:09:34,230 --> 00:09:36,359 your table, you know, periodic 252 00:09:36,360 --> 00:09:37,360 table. 253 00:09:38,970 --> 00:09:41,249 This is probably the the top 254 00:09:41,250 --> 00:09:43,619 of my graphics abilities, so 255 00:09:43,620 --> 00:09:44,620 please bear with me. 256 00:09:45,810 --> 00:09:47,969 Right? So it's a table 257 00:09:47,970 --> 00:09:50,219 that describes the elements of 258 00:09:50,220 --> 00:09:52,949 the sausage or the trusted sausage 259 00:09:52,950 --> 00:09:55,589 of the composition 260 00:09:55,590 --> 00:09:57,239 of the binary file. 261 00:09:57,240 --> 00:09:59,399 Well, I could I could be saying API 262 00:09:59,400 --> 00:10:01,589 application binder interface. 263 00:10:01,590 --> 00:10:03,719 But what happens is 264 00:10:03,720 --> 00:10:05,789 there are pieces of code. 265 00:10:05,790 --> 00:10:08,009 You can think of them as pieces 266 00:10:08,010 --> 00:10:11,039 of logic that are 267 00:10:11,040 --> 00:10:12,629 baked into the processor. 268 00:10:12,630 --> 00:10:13,919 Well, except they aren't. 269 00:10:13,920 --> 00:10:15,959 They are in your loader. 270 00:10:15,960 --> 00:10:17,699 They are in your kernel. 271 00:10:17,700 --> 00:10:18,999 They are in your RTL. 272 00:10:20,670 --> 00:10:22,919 And these 273 00:10:22,920 --> 00:10:26,129 pieces of code consume the tables 274 00:10:26,130 --> 00:10:28,409 just as 275 00:10:28,410 --> 00:10:30,629 your processor consumes its 276 00:10:30,630 --> 00:10:31,559 inputs. 277 00:10:31,560 --> 00:10:33,959 Now, hopefully, that logic is simple 278 00:10:33,960 --> 00:10:36,179 enough so that your computation 279 00:10:36,180 --> 00:10:37,859 doesn't get in the way. 280 00:10:37,860 --> 00:10:40,649 But tables drive computation 281 00:10:40,650 --> 00:10:43,289 just like anything else. 282 00:10:43,290 --> 00:10:45,359 Tables are, in fact, something of a 283 00:10:45,360 --> 00:10:46,739 bytecode. 284 00:10:46,740 --> 00:10:48,869 If you think of how you 285 00:10:48,870 --> 00:10:50,999 compute those offsets and 286 00:10:51,000 --> 00:10:53,129 locate the signed pieces and 287 00:10:53,130 --> 00:10:55,259 their signatures, well, you're doing 288 00:10:55,260 --> 00:10:57,509 arithmetic, you're doing branches, 289 00:10:57,510 --> 00:10:59,189 you're doing loops. 290 00:10:59,190 --> 00:11:01,529 Are all of these things are known 291 00:11:01,530 --> 00:11:02,789 if you are unlucky. 292 00:11:02,790 --> 00:11:04,979 To give you a Turing machine 293 00:11:04,980 --> 00:11:07,019 and Becks showed such a touring machine 294 00:11:07,020 --> 00:11:08,309 on relocation tables 295 00:11:09,480 --> 00:11:10,710 last season, you see. 296 00:11:12,000 --> 00:11:14,279 So in fact, 297 00:11:14,280 --> 00:11:16,559 any input is a program that's just 298 00:11:16,560 --> 00:11:18,479 a matter of principle. 299 00:11:18,480 --> 00:11:20,489 This is what we stand on. 300 00:11:20,490 --> 00:11:23,009 Any sufficiently complex input data 301 00:11:23,010 --> 00:11:25,799 is indistinguishable from bytecode 302 00:11:25,800 --> 00:11:28,199 driving some virtual machine. 303 00:11:28,200 --> 00:11:29,939 Oh, if you see that, do this. 304 00:11:29,940 --> 00:11:31,409 If you see this, do that. 305 00:11:32,550 --> 00:11:33,990 That's how you write a VM. 306 00:11:36,010 --> 00:11:38,649 A partial code for any sufficiently 307 00:11:38,650 --> 00:11:40,779 complex input is indistinguishable 308 00:11:40,780 --> 00:11:42,669 from a virtual machine running its 309 00:11:42,670 --> 00:11:43,929 inputs. 310 00:11:43,930 --> 00:11:46,059 So what happens there is that what 311 00:11:46,060 --> 00:11:48,759 you think of as input validation 312 00:11:48,760 --> 00:11:51,099 is this table valid 313 00:11:51,100 --> 00:11:53,409 is actually something of 314 00:11:53,410 --> 00:11:56,129 runtime verification 315 00:11:56,130 --> 00:11:58,419 of the core of the bytecode that 316 00:11:58,420 --> 00:12:00,519 are your tables, that are your metadata. 317 00:12:01,630 --> 00:12:03,579 So what can go wrong? 318 00:12:03,580 --> 00:12:06,249 And of course, your partner may be buggy. 319 00:12:06,250 --> 00:12:08,799 Your partner may overflow memory 320 00:12:08,800 --> 00:12:09,849 corrupted. 321 00:12:09,850 --> 00:12:12,069 And then 322 00:12:12,070 --> 00:12:14,229 some other piece of logic will take 323 00:12:14,230 --> 00:12:15,699 the corruption and run with it and run 324 00:12:15,700 --> 00:12:18,039 away with it and with your 325 00:12:18,040 --> 00:12:20,349 trustworthy system as such. 326 00:12:20,350 --> 00:12:22,689 But the input can be completely 327 00:12:22,690 --> 00:12:23,690 well-formed. 328 00:12:24,470 --> 00:12:27,319 But as a matter of software engineering, 329 00:12:27,320 --> 00:12:29,869 so complex that there is no predicting 330 00:12:29,870 --> 00:12:31,219 what it would do. 331 00:12:31,220 --> 00:12:33,949 Whole thing problem, Turing completeness, 332 00:12:33,950 --> 00:12:35,839 it turns out that even there were 333 00:12:35,840 --> 00:12:38,089 locations and symbols. 334 00:12:38,090 --> 00:12:40,909 Tables have that 335 00:12:40,910 --> 00:12:43,369 or the input could be seen differently. 336 00:12:43,370 --> 00:12:45,649 The Babel effect and 337 00:12:45,650 --> 00:12:47,209 different pieces of the trust chain would 338 00:12:47,210 --> 00:12:49,489 disagree, and the trust will be lost. 339 00:12:49,490 --> 00:12:51,829 And we'll show you both examples. 340 00:12:51,830 --> 00:12:52,879 So just. 341 00:12:52,880 --> 00:12:54,379 And oh, by the way, these are the three 342 00:12:54,380 --> 00:12:55,519 cats of the apocalypse. 343 00:12:57,810 --> 00:12:58,810 Right. 344 00:12:59,310 --> 00:13:01,499 You know, and we're going to 345 00:13:01,500 --> 00:13:03,659 be looking at the two cats, you know, who 346 00:13:03,660 --> 00:13:05,939 get the gold star and the 347 00:13:05,940 --> 00:13:08,219 red star, the well-formed input 348 00:13:08,220 --> 00:13:10,079 that's so complex and the parts of 349 00:13:10,080 --> 00:13:11,339 differentials. 350 00:13:11,340 --> 00:13:13,529 And so, you know, you think you're doing 351 00:13:13,530 --> 00:13:15,389 software engineering, you think you're 352 00:13:15,390 --> 00:13:17,579 doing code reviews and things like that. 353 00:13:17,580 --> 00:13:19,799 What you're in fact doing is you're 354 00:13:19,800 --> 00:13:22,289 getting the Turing cat out of the bag. 355 00:13:22,290 --> 00:13:23,290 Right? 356 00:13:23,780 --> 00:13:25,909 And the cat then turns 357 00:13:25,910 --> 00:13:28,279 out to be quite an impressive 358 00:13:28,280 --> 00:13:29,280 cat. 359 00:13:30,230 --> 00:13:32,869 You know, medieval bestiary 360 00:13:32,870 --> 00:13:35,030 writers knew their cats well. 361 00:13:37,130 --> 00:13:39,830 So here is your runtime 362 00:13:40,940 --> 00:13:41,940 after boot. 363 00:13:43,040 --> 00:13:45,139 Boot process has the same issues, 364 00:13:45,140 --> 00:13:47,479 but here is the original Ken 365 00:13:47,480 --> 00:13:50,329 Thompson Ken Thompson's planted bug. 366 00:13:50,330 --> 00:13:51,829 It was on the compiler. 367 00:13:51,830 --> 00:13:54,559 Then, of course, comes the linker and 368 00:13:54,560 --> 00:13:57,259 then the loader and then 369 00:13:57,260 --> 00:13:58,609 the dynamic linker. 370 00:13:58,610 --> 00:14:00,769 If you are for code reuse and 371 00:14:00,770 --> 00:14:02,929 the array locator, 372 00:14:02,930 --> 00:14:04,819 the dynamic here locator machine. 373 00:14:04,820 --> 00:14:06,439 And then of course, there is memory 374 00:14:06,440 --> 00:14:08,539 management and 375 00:14:08,540 --> 00:14:10,819 pitch faults and double faults 376 00:14:10,820 --> 00:14:13,639 if you're unlucky and exception handling. 377 00:14:13,640 --> 00:14:16,159 So this is sort of your process from 378 00:14:16,160 --> 00:14:17,160 birth to grave. 379 00:14:18,020 --> 00:14:19,020 And 380 00:14:20,420 --> 00:14:22,789 just to remind you, we found that 381 00:14:22,790 --> 00:14:24,889 these pieces that have the 382 00:14:24,890 --> 00:14:27,199 gold stars are actually Turing 383 00:14:27,200 --> 00:14:28,820 complete on their inputs. 384 00:14:29,970 --> 00:14:32,519 So if you feel them crafted 385 00:14:32,520 --> 00:14:35,069 tables that are complex enough, 386 00:14:35,070 --> 00:14:37,739 you can actually compile any computation, 387 00:14:37,740 --> 00:14:40,229 any program into those crafted tables. 388 00:14:41,490 --> 00:14:43,679 The favorite of 389 00:14:44,760 --> 00:14:47,189 especially favorite of mine is 390 00:14:47,190 --> 00:14:49,619 the weird machine 391 00:14:49,620 --> 00:14:50,970 in the 392 00:14:53,160 --> 00:14:54,870 peaceful tunneling logic, 393 00:14:55,890 --> 00:14:57,719 because people handling logic actually 394 00:14:57,720 --> 00:14:59,729 not only reads from memory and is 395 00:14:59,730 --> 00:15:01,979 triggered by read from memory or a right, 396 00:15:01,980 --> 00:15:04,649 it also writes to memory itself. 397 00:15:04,650 --> 00:15:07,349 She can close the loop and 398 00:15:07,350 --> 00:15:09,569 keep your processor doing 399 00:15:09,570 --> 00:15:11,699 whatever it's doing to kindle a page 400 00:15:11,700 --> 00:15:13,859 fold alternating between the page 401 00:15:13,860 --> 00:15:15,989 fold and the double fold as a tick 402 00:15:15,990 --> 00:15:17,699 of the machine. 403 00:15:17,700 --> 00:15:19,859 And while no 404 00:15:19,860 --> 00:15:21,989 execution instruction, no instruction is 405 00:15:21,990 --> 00:15:24,089 getting fixed successfully, 406 00:15:24,090 --> 00:15:25,979 you're continually getting the illegal 407 00:15:25,980 --> 00:15:28,079 instruction and the 408 00:15:28,080 --> 00:15:29,820 oh sorry, the page fold. 409 00:15:31,020 --> 00:15:33,149 You can still compute anything 410 00:15:33,150 --> 00:15:35,219 you like and write 411 00:15:35,220 --> 00:15:36,720 interesting patterns into memory. 412 00:15:37,960 --> 00:15:39,150 Julian, take a bath! 413 00:15:41,250 --> 00:15:43,259 Julian wrote the compiler for that sort 414 00:15:43,260 --> 00:15:44,260 of thing. 415 00:15:46,230 --> 00:15:47,230 The 416 00:15:50,040 --> 00:15:52,109 the dynamic 417 00:15:52,110 --> 00:15:54,209 curve locater right byxe 418 00:15:54,210 --> 00:15:55,210 take of all 419 00:15:56,430 --> 00:15:57,719 the checks are implemented. 420 00:15:57,720 --> 00:16:00,839 The language called brain fuck 421 00:16:00,840 --> 00:16:03,899 and the compiler into that language, 422 00:16:03,900 --> 00:16:05,589 which is known to be Turing complete. 423 00:16:05,590 --> 00:16:07,799 You know, some academic has had 424 00:16:07,800 --> 00:16:09,359 an unerring sense of taste. 425 00:16:09,360 --> 00:16:10,360 Probably 426 00:16:11,790 --> 00:16:13,949 so. But you know, term, can 427 00:16:13,950 --> 00:16:15,149 you do? 428 00:16:15,150 --> 00:16:17,609 The real accounting engine 429 00:16:17,610 --> 00:16:20,129 that builds up your program and memory 430 00:16:20,130 --> 00:16:22,229 is actually can be convinced is 431 00:16:22,230 --> 00:16:23,729 actually Turing complete can be convinced 432 00:16:23,730 --> 00:16:25,259 to compute anything? 433 00:16:25,260 --> 00:16:26,489 Here's a new thing that we're going to 434 00:16:26,490 --> 00:16:27,490 show you. 435 00:16:28,050 --> 00:16:30,179 The RTL Rd 436 00:16:30,180 --> 00:16:32,279 and the loader can be made 437 00:16:32,280 --> 00:16:34,469 to disagree about what 438 00:16:34,470 --> 00:16:35,639 is in the program. 439 00:16:35,640 --> 00:16:37,169 They can see completely different 440 00:16:37,170 --> 00:16:39,449 pictures of memory that they are 441 00:16:39,450 --> 00:16:42,149 constructing or have constructed 442 00:16:42,150 --> 00:16:43,559 for the runtime. 443 00:16:43,560 --> 00:16:45,659 And that's, you know, a second 444 00:16:45,660 --> 00:16:47,639 kind of cat of Do 445 00:16:48,900 --> 00:16:50,959 you will find. We finally wrote this up. 446 00:16:50,960 --> 00:16:52,679 I mean, the first we gave it at hacker 447 00:16:52,680 --> 00:16:54,869 conferences because hacker conferences 448 00:16:54,870 --> 00:16:56,699 are just about the only place where this 449 00:16:56,700 --> 00:16:59,189 kind of thing is appreciated. 450 00:16:59,190 --> 00:17:01,199 Because why would you really want to know 451 00:17:01,200 --> 00:17:03,539 what's in your machine and how to 452 00:17:03,540 --> 00:17:05,639 you know what sorts of extra 453 00:17:05,640 --> 00:17:07,949 logic can you squeeze out of it 454 00:17:07,950 --> 00:17:10,379 when you know you can so 455 00:17:10,380 --> 00:17:12,929 much more interesting problems, such as 456 00:17:12,930 --> 00:17:14,789 how to have graphs that look like. 457 00:17:18,410 --> 00:17:19,410 Yeah. 458 00:17:21,900 --> 00:17:22,900 Anyhow. 459 00:17:24,020 --> 00:17:26,269 Anyhow, so what finally, 460 00:17:26,270 --> 00:17:28,338 we published those papers 461 00:17:28,339 --> 00:17:29,339 in court. 462 00:17:30,590 --> 00:17:32,809 After having been rejected from 463 00:17:32,810 --> 00:17:34,879 some high and mighty 464 00:17:34,880 --> 00:17:35,880 other avenues. 465 00:17:39,400 --> 00:17:41,469 And there will been more coming. 466 00:17:41,470 --> 00:17:42,819 So with this mind. 467 00:17:45,360 --> 00:17:48,239 Tables are programs 468 00:17:48,240 --> 00:17:50,159 they run on the pieces of logic that 469 00:17:50,160 --> 00:17:51,359 interpret them. 470 00:17:51,360 --> 00:17:54,119 So when you are 471 00:17:54,120 --> 00:17:56,429 validating your inputs, 472 00:17:56,430 --> 00:17:58,169 I mean, God forbid you sanitize your 473 00:17:58,170 --> 00:18:00,119 inputs. This is an anti pattern. 474 00:18:00,120 --> 00:18:01,619 This is absolutely the worst thing you 475 00:18:01,620 --> 00:18:02,639 can do. 476 00:18:02,640 --> 00:18:04,439 You know, the idea that, oh, there are 477 00:18:04,440 --> 00:18:06,629 bad things in the input, but 478 00:18:06,630 --> 00:18:08,519 you can suppress them by checking for 479 00:18:08,520 --> 00:18:09,689 them piecemeal. 480 00:18:09,690 --> 00:18:11,860 Oh, you know, this is this is just poat. 481 00:18:12,930 --> 00:18:13,859 This is this is wrong. 482 00:18:13,860 --> 00:18:15,059 This is poll. 483 00:18:15,060 --> 00:18:16,060 But 484 00:18:17,430 --> 00:18:20,099 validation is actually 485 00:18:20,100 --> 00:18:22,229 the same as verification 486 00:18:22,230 --> 00:18:24,329 because that data 487 00:18:24,330 --> 00:18:25,769 causes computation. 488 00:18:27,720 --> 00:18:29,819 And you don't think of it 489 00:18:29,820 --> 00:18:31,619 that way. You don't think of it as 490 00:18:31,620 --> 00:18:32,939 program verification. 491 00:18:32,940 --> 00:18:34,469 You know, there have been talks here 492 00:18:34,470 --> 00:18:36,539 about for millennia Alsace, but in 493 00:18:36,540 --> 00:18:39,149 fact, it is, and the validation 494 00:18:39,150 --> 00:18:41,429 of tables is in fact 495 00:18:41,430 --> 00:18:43,859 static analysis of the computation 496 00:18:43,860 --> 00:18:45,869 that they induce. 497 00:18:45,870 --> 00:18:49,319 And even in the absence of bugs, 498 00:18:49,320 --> 00:18:51,419 you can have a rather 499 00:18:51,420 --> 00:18:54,119 complex analysis or impossible 500 00:18:54,120 --> 00:18:56,279 analysis to perform so that 501 00:18:56,280 --> 00:18:58,769 you will be trusting your tables when 502 00:18:58,770 --> 00:19:00,869 they shouldn't be trusted and 503 00:19:00,870 --> 00:19:03,029 you will be solving the antivirus 504 00:19:03,030 --> 00:19:04,200 vendors holding problem 505 00:19:05,610 --> 00:19:07,739 when you are and you 506 00:19:07,740 --> 00:19:09,989 know whether the the 507 00:19:09,990 --> 00:19:12,369 result is somewhat predictable. 508 00:19:12,370 --> 00:19:15,609 So with that, let's look at the specifics 509 00:19:15,610 --> 00:19:18,160 of the machines that execute tables. 510 00:19:22,110 --> 00:19:23,110 Yes. 511 00:19:24,370 --> 00:19:26,229 Yes, there. There we go. 512 00:19:26,230 --> 00:19:29,169 So with this little hiccup, 513 00:19:29,170 --> 00:19:30,939 I try, I have a microphone. 514 00:19:30,940 --> 00:19:31,149 Oh, you 515 00:19:31,150 --> 00:19:32,469 have a microphone? Excellent. 516 00:19:32,470 --> 00:19:33,669 Go ahead. Now we can talk at the same 517 00:19:33,670 --> 00:19:33,969 time. 518 00:19:33,970 --> 00:19:34,970 Prepared students. 519 00:19:38,290 --> 00:19:40,809 Code signing is 520 00:19:40,810 --> 00:19:42,549 definitely being worked into the trust 521 00:19:42,550 --> 00:19:44,469 train more and more, and we're seeing it 522 00:19:44,470 --> 00:19:46,539 and say in certain environments are 523 00:19:46,540 --> 00:19:48,939 becoming what walled gardens? 524 00:19:48,940 --> 00:19:51,969 But we're also seeing it popping up 525 00:19:51,970 --> 00:19:54,939 more and more, and it's open source 526 00:19:54,940 --> 00:19:57,999 Linux for kernel modules, 527 00:19:58,000 --> 00:20:00,189 drivers signing and Windows, et 528 00:20:00,190 --> 00:20:02,719 cetera. And it's 529 00:20:02,720 --> 00:20:05,139 it's use being used to provide 530 00:20:05,140 --> 00:20:07,359 trust evidence and that this particular 531 00:20:07,360 --> 00:20:09,849 binaries not only 532 00:20:09,850 --> 00:20:11,769 has some sort of integrity and it hasn't 533 00:20:11,770 --> 00:20:14,409 been changed since, you know, signed 534 00:20:14,410 --> 00:20:16,539 since the developer distributed handed 535 00:20:16,540 --> 00:20:18,669 to you. But we also are able 536 00:20:18,670 --> 00:20:21,219 to have some sort of attribution 537 00:20:21,220 --> 00:20:23,289 so that this binary really came from 538 00:20:23,290 --> 00:20:24,369 these people. 539 00:20:24,370 --> 00:20:26,439 And it's, you know, those are two 540 00:20:26,440 --> 00:20:28,719 good things to know about a given 541 00:20:28,720 --> 00:20:29,720 binary. 542 00:20:31,620 --> 00:20:33,689 It's easy to implement poorly 543 00:20:33,690 --> 00:20:35,819 because code signing, it's not 544 00:20:35,820 --> 00:20:37,619 just an algorithm, it's not just finding 545 00:20:37,620 --> 00:20:40,139 the right way to hash the ET, 546 00:20:40,140 --> 00:20:42,059 it's a lifestyle. 547 00:20:42,060 --> 00:20:44,699 There are so many components 548 00:20:44,700 --> 00:20:46,769 involved in code signing and to have it 549 00:20:46,770 --> 00:20:48,869 done well and to really 550 00:20:48,870 --> 00:20:51,599 be able to have a good amount of trust 551 00:20:51,600 --> 00:20:53,759 and evidence from code 552 00:20:53,760 --> 00:20:56,429 signing. You know, something verifying 553 00:20:56,430 --> 00:20:58,529 we need to maintain 554 00:20:58,530 --> 00:21:01,289 we have to have a proper key management. 555 00:21:01,290 --> 00:21:03,869 And there's other things the program 556 00:21:03,870 --> 00:21:05,969 that is is loaded in memory that 557 00:21:05,970 --> 00:21:08,509 we really want to know is trustful 558 00:21:08,510 --> 00:21:10,619 and trustworthy is not the 559 00:21:10,620 --> 00:21:13,379 same as the one on disk because 560 00:21:13,380 --> 00:21:15,779 we like to write things 561 00:21:15,780 --> 00:21:17,549 that are portable to different 562 00:21:17,550 --> 00:21:20,159 architectures or randomize 563 00:21:20,160 --> 00:21:22,349 able to help with other types of attacks. 564 00:21:22,350 --> 00:21:24,419 And really, the program that's in 565 00:21:24,420 --> 00:21:26,519 memory is merely influenced by 566 00:21:26,520 --> 00:21:28,829 that which is on disk. 567 00:21:28,830 --> 00:21:31,079 And then so we have to ask the question, 568 00:21:31,080 --> 00:21:32,969 does code signing really give us what we 569 00:21:32,970 --> 00:21:33,989 want it to give us? 570 00:21:33,990 --> 00:21:36,059 That this which was handed 571 00:21:36,060 --> 00:21:38,369 to us is what we'll 572 00:21:38,370 --> 00:21:40,559 be running and we are feeling 573 00:21:40,560 --> 00:21:42,419 trust. We feel like we can trust it 574 00:21:42,420 --> 00:21:44,549 because we know who 575 00:21:44,550 --> 00:21:46,679 gave it to us and we know there's 576 00:21:46,680 --> 00:21:48,779 some sort of integrity to the 577 00:21:48,780 --> 00:21:50,369 binary. 578 00:21:50,370 --> 00:21:53,099 But there's many machines involved 579 00:21:53,100 --> 00:21:55,319 in verification of 580 00:21:55,320 --> 00:21:57,189 a particular binary code signing. 581 00:21:57,190 --> 00:21:59,189 We have to worry about passers, 582 00:21:59,190 --> 00:22:01,889 interpreters, slash translators, 583 00:22:01,890 --> 00:22:03,359 validators. There's all these things that 584 00:22:03,360 --> 00:22:05,429 we bring together and 585 00:22:05,430 --> 00:22:07,289 we end up with some sort of like Rube 586 00:22:07,290 --> 00:22:09,719 Goldberg machine that we 587 00:22:09,720 --> 00:22:11,909 it's not even though it's different 588 00:22:11,910 --> 00:22:14,189 components of the machine will 589 00:22:14,190 --> 00:22:16,739 of a good sign will actually 590 00:22:16,740 --> 00:22:18,539 put together pieces of data. 591 00:22:18,540 --> 00:22:20,079 The two hands the next one. 592 00:22:20,080 --> 00:22:21,689 And so there's many different components 593 00:22:21,690 --> 00:22:22,949 working together. 594 00:22:22,950 --> 00:22:25,769 And we we have to think about how this 595 00:22:25,770 --> 00:22:27,689 how this really fits and how we can trust 596 00:22:27,690 --> 00:22:29,039 the different components and trust 597 00:22:29,040 --> 00:22:31,379 composition because different 598 00:22:31,380 --> 00:22:33,059 security doesn't compose particularly 599 00:22:33,060 --> 00:22:34,319 well. 600 00:22:34,320 --> 00:22:36,239 We have to think about it. 601 00:22:36,240 --> 00:22:38,369 So when we are considering 602 00:22:38,370 --> 00:22:40,109 code signing, there's a bunch of 603 00:22:40,110 --> 00:22:41,939 questions that come to my mind when I 604 00:22:41,940 --> 00:22:43,020 want to look at a system. 605 00:22:44,220 --> 00:22:46,079 Are these machines that implement code 606 00:22:46,080 --> 00:22:48,509 signing correctly implemented 607 00:22:48,510 --> 00:22:49,529 bug free? 608 00:22:49,530 --> 00:22:52,109 But even if they're not, do we understand 609 00:22:52,110 --> 00:22:53,849 what these different machines are capable 610 00:22:53,850 --> 00:22:56,279 of? We've shown that metadata 611 00:22:56,280 --> 00:22:58,499 for elves in the last year's 612 00:22:58,500 --> 00:23:00,779 talk that I did is capable 613 00:23:00,780 --> 00:23:03,089 of of running Turing 614 00:23:03,090 --> 00:23:05,219 complete or pushing Turing complete 615 00:23:05,220 --> 00:23:07,829 processes, making the loader do something 616 00:23:07,830 --> 00:23:11,189 that we really don't expect, necessarily 617 00:23:11,190 --> 00:23:13,499 if we have two different machines 618 00:23:13,500 --> 00:23:15,149 operating on the same data. 619 00:23:15,150 --> 00:23:17,249 Do they agree on how it's passed 620 00:23:17,250 --> 00:23:19,699 in and how to interpret it? 621 00:23:19,700 --> 00:23:21,779 Do do the tables that we are 622 00:23:21,780 --> 00:23:23,789 basing these computations off of. 623 00:23:23,790 --> 00:23:25,369 Are they correct or are they complete? 624 00:23:25,370 --> 00:23:27,449 They really portray what we 625 00:23:27,450 --> 00:23:29,699 need to know in order to trust 626 00:23:29,700 --> 00:23:32,399 the code the signature. 627 00:23:32,400 --> 00:23:34,529 Can we trust the transformations that are 628 00:23:34,530 --> 00:23:36,449 done to the to the process once it's 629 00:23:36,450 --> 00:23:37,679 loaded into memory? 630 00:23:37,680 --> 00:23:39,749 After we do this sort of static analysis 631 00:23:39,750 --> 00:23:41,579 and look at these frozen bits and, you 632 00:23:41,580 --> 00:23:43,679 know, pray that these like squishy 633 00:23:43,680 --> 00:23:46,169 bits that we can change or 634 00:23:46,170 --> 00:23:48,329 change it in in the right 635 00:23:48,330 --> 00:23:50,429 way. And then another big question is 636 00:23:50,430 --> 00:23:52,679 enforcement, which I won't cover 637 00:23:52,680 --> 00:23:54,689 at all, because that's that's a whole 638 00:23:54,690 --> 00:23:56,579 thing. What how do we want to enforce 639 00:23:56,580 --> 00:23:58,079 enforce validation? 640 00:23:59,310 --> 00:24:01,499 I looked at a bunch of different 641 00:24:01,500 --> 00:24:03,749 elf code signing mechanisms, many that 642 00:24:03,750 --> 00:24:06,209 seem kind of obsolete, but this is a case 643 00:24:06,210 --> 00:24:07,949 study and I hope we can learn a little 644 00:24:07,950 --> 00:24:09,929 from what has been done. 645 00:24:09,930 --> 00:24:12,059 And in thinking about 646 00:24:12,060 --> 00:24:14,159 the code signing and elf, we we 647 00:24:14,160 --> 00:24:16,229 have a bunch of components machines that 648 00:24:16,230 --> 00:24:18,239 are working together. We have partners 649 00:24:18,240 --> 00:24:20,339 that pass out this signature metadata and 650 00:24:20,340 --> 00:24:22,829 other data and the file. 651 00:24:22,830 --> 00:24:25,319 We have interpreters and translators such 652 00:24:25,320 --> 00:24:27,419 ones that maybe may look at 653 00:24:27,420 --> 00:24:29,249 the binary and produce a bunch of hashes 654 00:24:29,250 --> 00:24:31,499 based on that so that we can start 655 00:24:31,500 --> 00:24:33,029 looking at signatures. 656 00:24:33,030 --> 00:24:35,039 And we have validator machines part of 657 00:24:35,040 --> 00:24:37,139 this whole code siting process that look 658 00:24:37,140 --> 00:24:39,839 at certificates and signatures hashes. 659 00:24:39,840 --> 00:24:42,299 There's a lot working together 660 00:24:42,300 --> 00:24:44,070 and there's Rube Goldberg machine. 661 00:24:45,090 --> 00:24:46,709 So I started looking at different 662 00:24:46,710 --> 00:24:49,379 implementations of code signing and elf 663 00:24:49,380 --> 00:24:52,319 for both executable user line binaries 664 00:24:52,320 --> 00:24:54,719 and kernel modules. 665 00:24:54,720 --> 00:24:56,939 And I must say those they have 666 00:24:56,940 --> 00:24:59,069 very creative names 667 00:24:59,070 --> 00:25:01,439 for their code site. 668 00:25:01,440 --> 00:25:03,569 I actually had trouble telling a lot 669 00:25:03,570 --> 00:25:05,909 of them apart and figuring out which 670 00:25:05,910 --> 00:25:07,979 were different, and a lot of 671 00:25:07,980 --> 00:25:09,779 these were actually written in 2003, 672 00:25:09,780 --> 00:25:12,339 2004, 2005 are pretty obsolete. 673 00:25:12,340 --> 00:25:14,639 I'm seeing I started seeing 674 00:25:14,640 --> 00:25:16,829 a resurgence of work and especially more 675 00:25:16,830 --> 00:25:18,630 in the kernel module area. 676 00:25:21,140 --> 00:25:23,059 But, yeah, so a lot of what I looked at 677 00:25:23,060 --> 00:25:24,739 was is kind of obsolete, but it is 678 00:25:24,740 --> 00:25:26,929 interesting. So questions that 679 00:25:26,930 --> 00:25:28,969 I asked before I'm going to revise it 680 00:25:28,970 --> 00:25:31,159 right now are the machines 681 00:25:31,160 --> 00:25:33,169 involved with this code signing correctly 682 00:25:33,170 --> 00:25:34,170 implemented 683 00:25:35,960 --> 00:25:37,099 in Marco. 684 00:25:37,100 --> 00:25:39,169 There's actually XML embedded 685 00:25:39,170 --> 00:25:40,909 into their code signature. 686 00:25:40,910 --> 00:25:43,249 And we know how how 687 00:25:43,250 --> 00:25:45,439 easy it is to parse XML and 688 00:25:45,440 --> 00:25:47,869 how well implemented XML passers 689 00:25:47,870 --> 00:25:48,870 are 690 00:25:50,210 --> 00:25:52,369 certificates and 691 00:25:52,370 --> 00:25:54,469 anything that's signed as often 692 00:25:54,470 --> 00:25:57,499 encoded in s and one BR 693 00:25:57,500 --> 00:25:59,809 format. And those are, 694 00:25:59,810 --> 00:26:02,209 yeah, those those are easy to pass and 695 00:26:02,210 --> 00:26:03,949 everyone will agree on the correct 696 00:26:03,950 --> 00:26:06,639 parsing of a particular certificate. 697 00:26:06,640 --> 00:26:08,869 There is no problem there. 698 00:26:08,870 --> 00:26:11,269 And in Elf, I saw 699 00:26:11,270 --> 00:26:13,519 that everything was written 700 00:26:13,520 --> 00:26:15,469 in either c actually everything. 701 00:26:15,470 --> 00:26:17,469 But one thing I looked at was written in 702 00:26:17,470 --> 00:26:19,729 C was one thing written 703 00:26:19,730 --> 00:26:22,499 in C++ and those are safe languages. 704 00:26:22,500 --> 00:26:24,979 I'm sure there won't be any other bugs 705 00:26:24,980 --> 00:26:27,019 that are exploitable because of that. 706 00:26:29,260 --> 00:26:31,659 How powerful are machines that 707 00:26:31,660 --> 00:26:33,879 take part in this, the signing 708 00:26:33,880 --> 00:26:35,079 process? 709 00:26:35,080 --> 00:26:36,669 I think there's a work that we need to 710 00:26:36,670 --> 00:26:38,949 really do in this and just thinking about 711 00:26:38,950 --> 00:26:41,019 it old at our old work, 712 00:26:41,020 --> 00:26:43,179 things that just look like tables like 713 00:26:43,180 --> 00:26:45,909 relocation metadata we found to be 714 00:26:45,910 --> 00:26:48,409 to drive this unexpected computation. 715 00:26:48,410 --> 00:26:50,769 So if we're able, we 716 00:26:50,770 --> 00:26:53,089 want to make sure we understand 717 00:26:53,090 --> 00:26:55,209 what the components of code signing 718 00:26:55,210 --> 00:26:57,490 are able to do because 719 00:26:59,050 --> 00:27:01,719 we, this is old, work in 720 00:27:01,720 --> 00:27:03,849 putting backdoor into 721 00:27:03,850 --> 00:27:05,979 ping that drops a root shell and on 722 00:27:05,980 --> 00:27:08,410 the top itself and the green is 723 00:27:09,490 --> 00:27:11,049 data that was added to the file. 724 00:27:11,050 --> 00:27:12,309 And there is a couple of other changes 725 00:27:12,310 --> 00:27:13,719 made to the file. 726 00:27:13,720 --> 00:27:15,849 The bottom is the same exact 727 00:27:15,850 --> 00:27:18,309 backdoor in Moscow and the red bytes. 728 00:27:18,310 --> 00:27:20,169 Those were changed. 729 00:27:20,170 --> 00:27:21,279 Now, no other changes. 730 00:27:21,280 --> 00:27:22,989 Nothing else was added or removed from 731 00:27:22,990 --> 00:27:23,889 the file. 732 00:27:23,890 --> 00:27:24,939 So it's actually 733 00:27:27,820 --> 00:27:30,009 I I would I would argue 734 00:27:30,010 --> 00:27:32,349 that it hiding computation and 735 00:27:32,350 --> 00:27:34,059 metadata. 736 00:27:34,060 --> 00:27:36,279 It can be so you can see 737 00:27:36,280 --> 00:27:38,529 it. But it's also it can be 738 00:27:38,530 --> 00:27:40,239 hard to see, especially if two different 739 00:27:40,240 --> 00:27:42,639 interpreters pass the metadata 740 00:27:42,640 --> 00:27:43,599 differently. 741 00:27:43,600 --> 00:27:45,189 And we so that's something we need to be 742 00:27:45,190 --> 00:27:47,349 careful with and code signing. 743 00:27:47,350 --> 00:27:49,659 So I also started looking 744 00:27:49,660 --> 00:27:51,940 this is code from various different 745 00:27:53,230 --> 00:27:55,359 code signing for Elf 746 00:27:55,360 --> 00:27:57,249 implementations I looked at. 747 00:27:57,250 --> 00:28:00,209 So the question is, can 748 00:28:00,210 --> 00:28:01,539 can what we're looking at, can the 749 00:28:01,540 --> 00:28:03,129 metadata that we're looking at that's 750 00:28:03,130 --> 00:28:04,929 involved with designing the tables that 751 00:28:04,930 --> 00:28:06,849 are driving our computation? 752 00:28:06,850 --> 00:28:08,019 How much do we need to trust? 753 00:28:10,300 --> 00:28:12,459 In this particular example, this is from 754 00:28:12,460 --> 00:28:14,109 be signed. 755 00:28:14,110 --> 00:28:16,029 It's doing a lot of checks, but I love 756 00:28:16,030 --> 00:28:17,619 this comment right here. 757 00:28:17,620 --> 00:28:19,749 It's like, I don't recall why we need 758 00:28:19,750 --> 00:28:21,999 to check more than just the elf header, 759 00:28:22,000 --> 00:28:24,279 and the author goes 760 00:28:24,280 --> 00:28:26,709 on to check different headers as well. 761 00:28:26,710 --> 00:28:28,899 But the interesting part is, the author 762 00:28:28,900 --> 00:28:31,089 thought I could stop here and I think 763 00:28:31,090 --> 00:28:33,699 we'll be OK. But there 764 00:28:33,700 --> 00:28:35,769 there's more to be considered and how 765 00:28:35,770 --> 00:28:37,389 much data the check. 766 00:28:37,390 --> 00:28:39,519 And I am a see this as a red flag. 767 00:28:39,520 --> 00:28:41,289 We need to think a little more while 768 00:28:41,290 --> 00:28:43,359 we're developing code signing 769 00:28:43,360 --> 00:28:45,519 if we want to actually be able to 770 00:28:45,520 --> 00:28:46,810 trust what comes from it 771 00:28:48,040 --> 00:28:49,719 in passer differential. 772 00:28:49,720 --> 00:28:52,329 So having two different dialects, 773 00:28:52,330 --> 00:28:54,730 two different passers for the same data. 774 00:28:55,780 --> 00:28:58,989 So in these particular 775 00:28:58,990 --> 00:29:01,329 and one in PR and coded 776 00:29:01,330 --> 00:29:03,459 messages for it 777 00:29:03,460 --> 00:29:05,529 or for signing 778 00:29:05,530 --> 00:29:08,949 can be a little difficult to decode. 779 00:29:08,950 --> 00:29:12,519 Elf has multiple ways to interpret, 780 00:29:12,520 --> 00:29:14,379 and Julian will actually get into this. 781 00:29:14,380 --> 00:29:16,179 So I will just say that there's multiple 782 00:29:16,180 --> 00:29:18,309 ways to load an elf 783 00:29:18,310 --> 00:29:19,659 and there's multiple ways to locate a 784 00:29:19,660 --> 00:29:21,729 section. So if your signature is 785 00:29:21,730 --> 00:29:23,859 in a single section, 786 00:29:23,860 --> 00:29:25,269 you need to be sure that everything 787 00:29:25,270 --> 00:29:26,889 that's looking up the signature is 788 00:29:26,890 --> 00:29:28,659 looking up the same signature because 789 00:29:28,660 --> 00:29:30,549 it's possible to put in two sections with 790 00:29:30,550 --> 00:29:31,659 the same name. 791 00:29:31,660 --> 00:29:34,089 And this particular piece of code 792 00:29:34,090 --> 00:29:35,709 was a. 793 00:29:35,710 --> 00:29:37,839 It was a proposed patch to the kernel 794 00:29:37,840 --> 00:29:39,969 for module assigning, and 795 00:29:39,970 --> 00:29:41,739 it's just looking for the signature 796 00:29:41,740 --> 00:29:43,629 section by looping through all the 797 00:29:43,630 --> 00:29:45,459 segments and stopping at the first one 798 00:29:45,460 --> 00:29:47,589 that has the correct name and breaking 799 00:29:47,590 --> 00:29:49,089 out of that loop. And I've seen other 800 00:29:49,090 --> 00:29:50,979 implementations that will loop through 801 00:29:50,980 --> 00:29:53,259 all the signature sections and remember 802 00:29:53,260 --> 00:29:55,329 the last one, and we need 803 00:29:55,330 --> 00:29:57,130 to be careful with these differentials. 804 00:29:58,230 --> 00:30:00,299 We need to think about completeness 805 00:30:00,300 --> 00:30:02,549 and correctness of record signing. 806 00:30:02,550 --> 00:30:05,609 This is an example from Elf GPG 807 00:30:05,610 --> 00:30:07,799 and his comments only look 808 00:30:07,800 --> 00:30:09,929 at the interesting section, so it's 809 00:30:09,930 --> 00:30:13,319 just if it has, 810 00:30:13,320 --> 00:30:15,539 let's see if it's of type know, 811 00:30:15,540 --> 00:30:17,639 then perhaps it won't get loaded. 812 00:30:17,640 --> 00:30:19,899 And then let's see skip over the sign 813 00:30:19,900 --> 00:30:21,989 sections. OK, well, I can name 814 00:30:21,990 --> 00:30:23,309 other sections. 815 00:30:23,310 --> 00:30:25,019 I can give other sections the same name. 816 00:30:25,020 --> 00:30:27,119 So is there something else in the code 817 00:30:27,120 --> 00:30:28,979 signing that's preventing me from 818 00:30:28,980 --> 00:30:31,019 inserting new sections? 819 00:30:31,020 --> 00:30:32,489 So there's a larger picture we need to 820 00:30:32,490 --> 00:30:34,679 look at and with more with 821 00:30:34,680 --> 00:30:36,319 correctness and completeness. 822 00:30:37,500 --> 00:30:39,299 Signing the signatures who watches the 823 00:30:39,300 --> 00:30:40,439 watchers there? 824 00:30:40,440 --> 00:30:42,179 But these signatures are still loaded in 825 00:30:42,180 --> 00:30:43,109 memory. 826 00:30:43,110 --> 00:30:44,729 And this particular example from Elf 827 00:30:44,730 --> 00:30:46,979 Sign, it just assumes that the last 828 00:30:46,980 --> 00:30:49,079 segment in the file is 829 00:30:49,080 --> 00:30:51,179 the signature, and it won't try to hash 830 00:30:51,180 --> 00:30:53,249 that and for the signature at 831 00:30:53,250 --> 00:30:55,589 all. So does that leave us 832 00:30:55,590 --> 00:30:57,449 an interesting way to sneak in more data 833 00:30:57,450 --> 00:30:58,670 that gets mapped to memory? 834 00:30:59,860 --> 00:31:01,989 So a little bit about 835 00:31:01,990 --> 00:31:04,359 Marco, could I am so lucky 836 00:31:04,360 --> 00:31:06,429 to get our graphic designer 837 00:31:06,430 --> 00:31:08,499 to to draw up a 838 00:31:08,500 --> 00:31:09,500 nice 839 00:31:10,570 --> 00:31:12,639 sketch sketch up what a code is Blob 840 00:31:12,640 --> 00:31:14,529 looked like that that are embedded at the 841 00:31:14,530 --> 00:31:16,299 end of Marco files that you could 842 00:31:16,300 --> 00:31:17,300 signing. 843 00:31:18,250 --> 00:31:20,439 It's slightly complicated, so I 844 00:31:20,440 --> 00:31:22,869 simplified it a lot 845 00:31:22,870 --> 00:31:25,029 to give you an idea of all the passers 846 00:31:25,030 --> 00:31:27,519 and interpreters that are required 847 00:31:27,520 --> 00:31:29,589 for this. So in Marco code signing 848 00:31:29,590 --> 00:31:32,079 Blob, there's a bunch of metadata. 849 00:31:32,080 --> 00:31:34,359 There are something called internal 850 00:31:34,360 --> 00:31:36,639 requirements, which is actually encoded 851 00:31:36,640 --> 00:31:37,689 in this bytecode. 852 00:31:37,690 --> 00:31:39,939 And what I wrote here is a 853 00:31:39,940 --> 00:31:42,309 text representation of it, of 854 00:31:42,310 --> 00:31:45,489 what might need a sign, the interpreter 855 00:31:45,490 --> 00:31:47,709 if it's a Perl program and what 856 00:31:47,710 --> 00:31:49,089 needs to sign the certificate. 857 00:31:49,090 --> 00:31:51,219 But these are encoded until by 858 00:31:51,220 --> 00:31:54,069 code with strings and et cetera. 859 00:31:54,070 --> 00:31:56,259 And it's a hand-rolled interpreter 860 00:31:56,260 --> 00:31:57,189 entitlements. 861 00:31:57,190 --> 00:31:59,319 Our next email and I noted that before 862 00:31:59,320 --> 00:32:01,519 that, we all perfectly know how to pass 863 00:32:01,520 --> 00:32:03,519 XML and there's no problems with that. 864 00:32:03,520 --> 00:32:05,799 But yeah, and 865 00:32:05,800 --> 00:32:07,869 so there's also a bunch of hashes, and so 866 00:32:07,870 --> 00:32:08,979 those need to be passed out. 867 00:32:08,980 --> 00:32:10,389 That's another table. 868 00:32:10,390 --> 00:32:12,519 And finally, a nice encoding 869 00:32:12,520 --> 00:32:14,169 of a signature. So there's all these 870 00:32:14,170 --> 00:32:15,669 different components that are working 871 00:32:15,670 --> 00:32:17,889 together that we must must trust. 872 00:32:17,890 --> 00:32:19,989 And yet there is so much room for persons 873 00:32:19,990 --> 00:32:20,990 that disagree. 874 00:32:22,460 --> 00:32:24,739 So to take away from what I am thinking 875 00:32:24,740 --> 00:32:26,929 is you can't trust 876 00:32:26,930 --> 00:32:28,609 her that you did not totally create 877 00:32:28,610 --> 00:32:29,610 yourself. 878 00:32:30,590 --> 00:32:32,029 But you also have to think the 879 00:32:32,030 --> 00:32:33,469 environment in which loaded it all 880 00:32:33,470 --> 00:32:34,939 everything that signing all the 881 00:32:34,940 --> 00:32:36,979 relocations and everything because that 882 00:32:36,980 --> 00:32:39,139 which is on desk doesn't match that 883 00:32:39,140 --> 00:32:40,639 well, that's loaded in memory. 884 00:32:40,640 --> 00:32:42,739 So the corollary is you cannot 885 00:32:42,740 --> 00:32:44,599 trust Canada. You did not totally load 886 00:32:44,600 --> 00:32:46,159 yourself. 887 00:32:46,160 --> 00:32:48,499 And with that, I will let Julianne 888 00:32:48,500 --> 00:32:50,119 continue. 889 00:32:50,120 --> 00:32:51,859 OK. Hello. 890 00:32:51,860 --> 00:32:53,449 Now, for the third part of the talk, we 891 00:32:53,450 --> 00:32:55,339 bring out the third cat of the 892 00:32:55,340 --> 00:32:57,259 apocalypse, which takes the form of an 893 00:32:57,260 --> 00:32:59,179 elephant that stomping all over our trust 894 00:32:59,180 --> 00:33:00,829 chains and also our trusted China. 895 00:33:02,240 --> 00:33:05,539 And that Elephant Pass differentials 896 00:33:05,540 --> 00:33:07,639 a differentials break, chains of trust, 897 00:33:07,640 --> 00:33:09,109 chains of trust and multiple elements 898 00:33:09,110 --> 00:33:10,969 that have that implicitly trust each 899 00:33:10,970 --> 00:33:13,189 other. Now, if various parts 900 00:33:13,190 --> 00:33:14,779 in the binary tool chain see different 901 00:33:14,780 --> 00:33:17,239 things, that implicit trust is violated 902 00:33:17,240 --> 00:33:19,249 and can or can be made to interpret the 903 00:33:19,250 --> 00:33:21,589 same data differently, and the trust 904 00:33:21,590 --> 00:33:22,820 is implicitly violated. 905 00:33:23,990 --> 00:33:25,789 Historically, there have been issues such 906 00:33:25,790 --> 00:33:27,689 as with X five or nine SSL certificate 907 00:33:27,690 --> 00:33:29,749 suspects already mentioned that I 908 00:33:29,750 --> 00:33:31,609 might get the Certificate of Authority to 909 00:33:31,610 --> 00:33:33,649 see a subdomain of Julian Bango dot com 910 00:33:33,650 --> 00:33:35,119 being signed. But when your browser looks 911 00:33:35,120 --> 00:33:37,189 at the same certificate, it actually 912 00:33:37,190 --> 00:33:38,919 sees a certificate for PayPal dot com and 913 00:33:38,920 --> 00:33:40,879 then you might run into an issue. 914 00:33:40,880 --> 00:33:43,069 More recently, there have been issues 915 00:33:43,070 --> 00:33:45,469 with Android's code signing our Android 916 00:33:45,470 --> 00:33:47,749 Master key vulnerability, where you have 917 00:33:47,750 --> 00:33:49,909 two separate policies for the 918 00:33:49,910 --> 00:33:52,069 same zip file that contains an Android 919 00:33:52,070 --> 00:33:53,629 application, one of them implemented in 920 00:33:53,630 --> 00:33:55,759 C, one of them implemented in Java, 921 00:33:55,760 --> 00:33:57,859 and the designers of Java did not believe 922 00:33:57,860 --> 00:34:00,139 in unsigned integers, whereas the various 923 00:34:00,140 --> 00:34:01,669 the C implementation uses unsigned 924 00:34:01,670 --> 00:34:02,779 integers. 925 00:34:02,780 --> 00:34:04,909 Then suddenly, well, the the 926 00:34:04,910 --> 00:34:06,379 signature matches when it's installed. 927 00:34:06,380 --> 00:34:07,819 But hey, you can run something completely 928 00:34:07,820 --> 00:34:08,839 differently when you're actually 929 00:34:08,840 --> 00:34:09,840 executing the thing. 930 00:34:12,090 --> 00:34:14,638 The same also happens on Apple iOS 931 00:34:14,639 --> 00:34:16,499 as the invaders demonstrated in the iOS 932 00:34:16,500 --> 00:34:17,639 six jailbreak. 933 00:34:18,810 --> 00:34:20,369 Different components within the tool 934 00:34:20,370 --> 00:34:22,649 chain can see the same binary 935 00:34:22,650 --> 00:34:24,629 differently and therefore you can get you 936 00:34:24,630 --> 00:34:26,309 can sneak past the code signature scheme 937 00:34:26,310 --> 00:34:28,169 in that case. And as specs demonstrate 938 00:34:28,170 --> 00:34:29,968 it, the same happens for the Linux kernel 939 00:34:29,969 --> 00:34:32,069 with their kernel mode's module signing 940 00:34:32,070 --> 00:34:33,479 schemes. 941 00:34:33,480 --> 00:34:35,609 And what I'm going to talk about is it 942 00:34:35,610 --> 00:34:37,049 also happens in user space. 943 00:34:37,050 --> 00:34:38,879 We found a positive differential between 944 00:34:38,880 --> 00:34:40,948 the in kernel positives 945 00:34:40,949 --> 00:34:43,138 part of the exact system call and 946 00:34:43,139 --> 00:34:44,879 the user space dynamic loaded. 947 00:34:44,880 --> 00:34:46,439 It handles things like actually setting 948 00:34:46,440 --> 00:34:47,908 up your address space and loading in all 949 00:34:47,909 --> 00:34:49,589 the various dynamic libraries you have. 950 00:34:53,219 --> 00:34:55,529 And little quick question the audience 951 00:34:55,530 --> 00:34:57,329 into the audience, how many health passes 952 00:34:57,330 --> 00:34:59,099 are involved in your typical program 953 00:34:59,100 --> 00:35:00,509 execution? 954 00:35:00,510 --> 00:35:01,510 Does anyone know? 955 00:35:03,090 --> 00:35:05,159 Indeed, well, that tends to be at least 956 00:35:05,160 --> 00:35:06,539 two, depending on what your system, while 957 00:35:06,540 --> 00:35:08,159 you might have a lot more, there's all 958 00:35:08,160 --> 00:35:09,569 sorts of things from kernel modules 959 00:35:09,570 --> 00:35:11,189 onwards, but the two that we are going to 960 00:35:11,190 --> 00:35:13,559 focus on is the elf loading 961 00:35:13,560 --> 00:35:15,809 the kernel in bin form, former elf 962 00:35:15,810 --> 00:35:17,909 and the user land LDA so 963 00:35:17,910 --> 00:35:20,039 loaded. That's part of the new C library. 964 00:35:21,240 --> 00:35:23,249 And in order for there to be any sort of 965 00:35:23,250 --> 00:35:25,529 trust and in any 966 00:35:25,530 --> 00:35:27,659 code signing schemes, all of these elf 967 00:35:27,660 --> 00:35:29,759 pulses have to see the same few of 968 00:35:29,760 --> 00:35:31,229 the sections in the segments and have to 969 00:35:31,230 --> 00:35:32,849 interpret all of the metadata that they 970 00:35:32,850 --> 00:35:35,039 rely on to enforce their trust. 971 00:35:35,040 --> 00:35:36,179 Exactly the same way. 972 00:35:37,920 --> 00:35:39,209 And now, when these two policies 973 00:35:39,210 --> 00:35:41,339 implemented by two totally 974 00:35:41,340 --> 00:35:43,349 separate entities and don't share any 975 00:35:43,350 --> 00:35:45,419 code or don't share any 976 00:35:45,420 --> 00:35:47,279 formal grammar that can be used to prove 977 00:35:47,280 --> 00:35:48,280 the equivalence. 978 00:35:49,080 --> 00:35:50,999 It's pretty unlikely that they'll 979 00:35:51,000 --> 00:35:53,249 actually see the same information in that 980 00:35:53,250 --> 00:35:55,139 sequence in just the right sequence of 981 00:35:55,140 --> 00:35:56,140 bytes. 982 00:35:57,390 --> 00:35:58,679 The particular example we're going to 983 00:35:58,680 --> 00:36:00,779 look at today is about the 984 00:36:00,780 --> 00:36:02,669 Elf program header table. 985 00:36:02,670 --> 00:36:04,979 In particular, the Peachey Load Entries 986 00:36:04,980 --> 00:36:07,049 50 Load is there to map a 987 00:36:07,050 --> 00:36:09,449 range of bytes from the file into 988 00:36:09,450 --> 00:36:10,919 the address range of the program you just 989 00:36:10,920 --> 00:36:11,909 want to execute. 990 00:36:11,910 --> 00:36:13,619 It describes the various code and data 991 00:36:13,620 --> 00:36:14,999 segments in your program. 992 00:36:16,440 --> 00:36:18,929 Internally, the implementation of 993 00:36:18,930 --> 00:36:21,299 the exact system called just converts 994 00:36:21,300 --> 00:36:23,399 every load entry in that table into a 995 00:36:23,400 --> 00:36:24,509 map system called. 996 00:36:24,510 --> 00:36:26,249 That's what the invaders noted as part of 997 00:36:26,250 --> 00:36:28,409 the iOS jailbreak that 998 00:36:28,410 --> 00:36:30,839 a memory map at a fixed address replaces 999 00:36:30,840 --> 00:36:32,909 any previous mappings at that particular 1000 00:36:32,910 --> 00:36:35,399 address, which means they could remap 1001 00:36:35,400 --> 00:36:36,509 an address that had already been 1002 00:36:36,510 --> 00:36:38,789 validated and certain other 1003 00:36:38,790 --> 00:36:40,139 parts of the tool chain would just look 1004 00:36:40,140 --> 00:36:41,369 for the first entry mapping. 1005 00:36:41,370 --> 00:36:43,139 That was really the kernel, which was the 1006 00:36:43,140 --> 00:36:45,329 last one, which is, if 1007 00:36:45,330 --> 00:36:46,379 you're looking at the past, is not 1008 00:36:46,380 --> 00:36:48,659 immediately obvious because 1009 00:36:48,660 --> 00:36:50,489 they actually are impulses for a table, 1010 00:36:50,490 --> 00:36:52,229 the automaton that are executing on the 1011 00:36:52,230 --> 00:36:53,699 data that's present in that table. 1012 00:36:53,700 --> 00:36:55,499 And unless you're thinking of them as 1013 00:36:55,500 --> 00:36:57,600 automata that have mutable state, 1014 00:36:59,280 --> 00:37:00,719 it's unlikely that you'll catch all of 1015 00:37:00,720 --> 00:37:02,879 these bugs because the spec 1016 00:37:02,880 --> 00:37:04,589 note mentions no way that the order of 1017 00:37:04,590 --> 00:37:06,149 these entries is in fact important. 1018 00:37:08,210 --> 00:37:10,169 In order to drive home the point, this is 1019 00:37:10,170 --> 00:37:11,639 the actual politics, the Linux kernel 1020 00:37:11,640 --> 00:37:13,769 source code as of three point four that 1021 00:37:13,770 --> 00:37:15,989 actually processes peachy 1022 00:37:15,990 --> 00:37:18,029 load entries in an L Files program hit a 1023 00:37:18,030 --> 00:37:20,039 table. And this is not really look like a 1024 00:37:20,040 --> 00:37:21,599 parser. There is no grammar. 1025 00:37:21,600 --> 00:37:22,979 There's no BNF. 1026 00:37:22,980 --> 00:37:25,079 There's just randomly casting 1027 00:37:25,080 --> 00:37:27,719 around pointers and having stuff. 1028 00:37:27,720 --> 00:37:29,579 And a particularly interesting bit that 1029 00:37:29,580 --> 00:37:31,649 I'll get to in a second is this 1030 00:37:31,650 --> 00:37:32,670 is this line here. 1031 00:37:34,680 --> 00:37:36,929 So the the typical layout 1032 00:37:36,930 --> 00:37:38,789 of an L file is that there's the elf 1033 00:37:38,790 --> 00:37:40,979 headed at Pax already described, followed 1034 00:37:40,980 --> 00:37:42,179 immediately by this program. 1035 00:37:42,180 --> 00:37:44,069 Head to table In the program head a table 1036 00:37:44,070 --> 00:37:46,199 describes how the alpha is supposed to be 1037 00:37:46,200 --> 00:37:47,200 mapped into memory. 1038 00:37:50,570 --> 00:37:52,429 And in order to execute the program, the 1039 00:37:52,430 --> 00:37:53,839 colonel first reads this program at a 1040 00:37:53,840 --> 00:37:55,819 table into an buy into a buffet, 1041 00:37:55,820 --> 00:37:57,979 allocates performs one memory map for 1042 00:37:57,980 --> 00:38:00,199 each payload with the awesome pulsing 1043 00:38:00,200 --> 00:38:01,459 source code that we just saw. 1044 00:38:02,510 --> 00:38:04,789 It then finds out if that program 1045 00:38:04,790 --> 00:38:06,409 is dynamically linked, which nowadays is 1046 00:38:06,410 --> 00:38:08,509 true for just about any binary and loads 1047 00:38:08,510 --> 00:38:10,669 the dynamic loader from 1048 00:38:10,670 --> 00:38:12,739 the file name the present in 1049 00:38:12,740 --> 00:38:13,820 a special section. 1050 00:38:15,230 --> 00:38:17,509 And then in order to tell the dynamic 1051 00:38:17,510 --> 00:38:19,609 loader where from where it's supposed 1052 00:38:19,610 --> 00:38:21,739 to start parsing the file, it has to 1053 00:38:21,740 --> 00:38:24,199 give it the virtual address where the. 1054 00:38:25,590 --> 00:38:27,419 Where the program hit a table resides 1055 00:38:27,420 --> 00:38:29,069 because the Linux kernel has access to 1056 00:38:29,070 --> 00:38:30,689 the acceptable file as a file, it can 1057 00:38:30,690 --> 00:38:32,429 read the bytes there is the user space 1058 00:38:32,430 --> 00:38:34,229 loader is actually already mapped into 1059 00:38:34,230 --> 00:38:35,969 the address space and therefore can only 1060 00:38:35,970 --> 00:38:37,589 access to virtual addresses. 1061 00:38:37,590 --> 00:38:39,239 So the kernel has to bootstrap the 1062 00:38:39,240 --> 00:38:41,549 translation between virtual 1063 00:38:41,550 --> 00:38:43,859 addresses and ranges of bytes. 1064 00:38:43,860 --> 00:38:45,959 And it does that by looking at 1065 00:38:45,960 --> 00:38:48,059 the address where the first party 1066 00:38:48,060 --> 00:38:49,409 load was mapped 1067 00:38:50,460 --> 00:38:53,189 and adding the file offset in bytes 1068 00:38:53,190 --> 00:38:54,149 to that address. 1069 00:38:54,150 --> 00:38:55,979 And it ends writes it into a special data 1070 00:38:55,980 --> 00:38:58,319 structure called an ox vector, where 1071 00:38:58,320 --> 00:39:00,509 the user space loader will then look and 1072 00:39:00,510 --> 00:39:01,860 begin passing the file. 1073 00:39:05,840 --> 00:39:06,840 If. 1074 00:39:07,470 --> 00:39:09,569 The post had been written in the same 1075 00:39:09,570 --> 00:39:11,699 war type, safe language that would 1076 00:39:11,700 --> 00:39:13,379 probably not have compiled because it 1077 00:39:13,380 --> 00:39:15,389 turns out you're adding a file offset to 1078 00:39:15,390 --> 00:39:17,669 a memory pointer in the 1079 00:39:17,670 --> 00:39:19,439 usual case of any binary that comes out 1080 00:39:19,440 --> 00:39:21,629 of CC or clang, or whatever your compiler 1081 00:39:21,630 --> 00:39:23,909 is, which always places the program 1082 00:39:23,910 --> 00:39:25,169 in a table in the first segment. 1083 00:39:25,170 --> 00:39:27,509 That works perfectly fine because 1084 00:39:27,510 --> 00:39:29,909 really the mapping is perfectly linear, 1085 00:39:29,910 --> 00:39:31,559 so you can add file offsets to virtual 1086 00:39:31,560 --> 00:39:33,269 memory addresses as you please. 1087 00:39:35,190 --> 00:39:37,259 However, if someone were to be 1088 00:39:37,260 --> 00:39:39,419 a little less nice and a little 1089 00:39:39,420 --> 00:39:41,249 less orderly and place, the program had a 1090 00:39:41,250 --> 00:39:42,959 table somewhere else in memory, the 1091 00:39:42,960 --> 00:39:44,339 kernel which is reading it as a sequence 1092 00:39:44,340 --> 00:39:46,469 of bytes. Oh, well, so the offset 1093 00:39:46,470 --> 00:39:48,149 in the file is a bit larger, so we have 1094 00:39:48,150 --> 00:39:49,949 to speak to a different sector and disk. 1095 00:39:49,950 --> 00:39:51,509 No big deal. 1096 00:39:51,510 --> 00:39:54,179 However, then when it adds that suddenly 1097 00:39:54,180 --> 00:39:56,279 the pointer in the X Factor is pointing 1098 00:39:56,280 --> 00:39:57,809 to some other garbage. 1099 00:39:57,810 --> 00:39:59,669 If you craft things just right and you 1100 00:39:59,670 --> 00:40:01,019 can, because if you're controlling the 1101 00:40:01,020 --> 00:40:03,419 program at a table, you can point. 1102 00:40:03,420 --> 00:40:05,099 You can map arbitrary memory at arbitrary 1103 00:40:05,100 --> 00:40:06,100 addresses. 1104 00:40:07,080 --> 00:40:08,189 Really, something else will be 1105 00:40:08,190 --> 00:40:09,479 interpreted as a program head a table 1106 00:40:09,480 --> 00:40:11,789 that no other tool will 1107 00:40:11,790 --> 00:40:13,949 see as such, which 1108 00:40:13,950 --> 00:40:16,109 of course, is quite a nice thing 1109 00:40:16,110 --> 00:40:17,699 if you want to hide a binary or hide some 1110 00:40:17,700 --> 00:40:19,499 other things from reverse engineers who 1111 00:40:19,500 --> 00:40:21,449 tend to poke into your code. 1112 00:40:21,450 --> 00:40:23,039 So if instead of having the normal 1113 00:40:23,040 --> 00:40:24,150 layout, you have 1114 00:40:25,470 --> 00:40:26,999 this particular there where you place the 1115 00:40:27,000 --> 00:40:28,619 program at a table at the very end of the 1116 00:40:28,620 --> 00:40:30,719 file and you craft 1117 00:40:30,720 --> 00:40:32,879 things just right and you make the memory 1118 00:40:32,880 --> 00:40:33,869 layout just right. 1119 00:40:33,870 --> 00:40:35,969 You can make sure that the user 1120 00:40:35,970 --> 00:40:37,739 space loader will actually see a program 1121 00:40:37,740 --> 00:40:39,119 at a table somewhere in the middle of the 1122 00:40:39,120 --> 00:40:40,859 data segment that could have previously 1123 00:40:40,860 --> 00:40:42,449 been some unused padding. 1124 00:40:42,450 --> 00:40:43,949 Or you could even make a new segment with 1125 00:40:43,950 --> 00:40:46,079 it. If you still want to, or 1126 00:40:46,080 --> 00:40:48,209 if you have one of Max's code signing 1127 00:40:48,210 --> 00:40:49,379 schemes, you could point it to the middle 1128 00:40:49,380 --> 00:40:50,610 of a BGP signature. 1129 00:40:51,840 --> 00:40:54,059 Oh, and it was should. 1130 00:40:54,060 --> 00:40:56,039 And in order to demonstrate this, we 1131 00:40:56,040 --> 00:40:57,629 cooked up a little demo. 1132 00:40:57,630 --> 00:40:58,769 A fun fact for assigned it. 1133 00:40:58,770 --> 00:40:59,999 We're going to use and this is that in 1134 00:41:00,000 --> 00:41:01,589 Linux, you can actually execute a 1135 00:41:01,590 --> 00:41:02,590 library. 1136 00:41:03,720 --> 00:41:05,999 I don't really understand why, but if 1137 00:41:06,000 --> 00:41:07,829 you have the next term, you can try 1138 00:41:07,830 --> 00:41:09,689 executing, see an intellectually print 1139 00:41:09,690 --> 00:41:12,209 out. It's compiled data and a few options 1140 00:41:12,210 --> 00:41:13,589 and give you an email address where you 1141 00:41:13,590 --> 00:41:14,730 can bug them about bugs. 1142 00:41:16,480 --> 00:41:18,599 Oh, and if you do 1143 00:41:18,600 --> 00:41:20,489 that well, it goes through the normal 1144 00:41:20,490 --> 00:41:22,589 kernel policy for Exec. 1145 00:41:22,590 --> 00:41:24,269 and then passive of control to the 1146 00:41:24,270 --> 00:41:26,489 separate Tulsa that's also living as part 1147 00:41:26,490 --> 00:41:28,829 of Lipsey for the 1148 00:41:28,830 --> 00:41:29,830 user space loader. 1149 00:41:30,990 --> 00:41:32,819 However, when you're loading that same 1150 00:41:32,820 --> 00:41:34,829 file as a shared library from another 1151 00:41:34,830 --> 00:41:36,479 process, the kernel never gets to touch 1152 00:41:36,480 --> 00:41:38,759 it. The kernel never runs for shared 1153 00:41:38,760 --> 00:41:40,919 library, and it 1154 00:41:40,920 --> 00:41:42,509 will only be loaded by LDA. 1155 00:41:42,510 --> 00:41:43,889 So which in this case will get a 1156 00:41:43,890 --> 00:41:46,199 consistent view, which might, which 1157 00:41:46,200 --> 00:41:47,310 will be completely different? 1158 00:41:51,180 --> 00:41:52,619 And now I hope that the demo works 1159 00:41:52,620 --> 00:41:53,620 properly. 1160 00:41:54,680 --> 00:41:55,680 Demigods. 1161 00:41:56,700 --> 00:41:57,469 Pray. 1162 00:41:57,470 --> 00:41:59,669 Yeah, OK. 1163 00:41:59,670 --> 00:42:01,769 I was someplace we first have our shared 1164 00:42:01,770 --> 00:42:02,939 library. 1165 00:42:02,940 --> 00:42:04,139 It's relatively straightforward. 1166 00:42:04,140 --> 00:42:05,369 It just calls another function. 1167 00:42:05,370 --> 00:42:06,659 I'll explain in a second why, 1168 00:42:07,710 --> 00:42:09,989 and that other function normally comes 1169 00:42:09,990 --> 00:42:12,149 from a file lib good dot 1170 00:42:12,150 --> 00:42:14,249 c, which does nothing but print Hello 1171 00:42:14,250 --> 00:42:15,250 world. 1172 00:42:16,810 --> 00:42:19,179 And in order to demonstrate this awesome 1173 00:42:19,180 --> 00:42:21,459 asset library that link licenses 1174 00:42:21,460 --> 00:42:23,109 for for something that I can't disclose 1175 00:42:23,110 --> 00:42:24,110 except under NDA. 1176 00:42:26,730 --> 00:42:28,350 And apparently that's a type anymore. 1177 00:42:29,550 --> 00:42:31,289 We just have a little sample program that 1178 00:42:31,290 --> 00:42:32,789 will invoke that function. 1179 00:42:32,790 --> 00:42:34,679 And if we do it, indeed everything as 1180 00:42:34,680 --> 00:42:35,680 well. 1181 00:42:36,120 --> 00:42:37,799 We have Helloworld, we can even trace the 1182 00:42:37,800 --> 00:42:39,839 execution we see, OK? 1183 00:42:39,840 --> 00:42:40,840 It's loading 1184 00:42:42,810 --> 00:42:44,459 lib good acid when it's loading lib 1185 00:42:44,460 --> 00:42:47,369 pocket, so everything is perfectly fine. 1186 00:42:47,370 --> 00:42:49,509 However, now when we're executing Lib 1187 00:42:49,510 --> 00:42:50,699 Pak'nSave directly, 1188 00:42:52,200 --> 00:42:53,849 we tend to get this nasty little bugger, 1189 00:42:53,850 --> 00:42:55,979 which is a shell which people might not 1190 00:42:55,980 --> 00:42:57,659 have expected, because maybe your device 1191 00:42:57,660 --> 00:42:59,039 isn't supposed to have a shell binary 1192 00:42:59,040 --> 00:43:00,569 running on it, but some nasty engineer 1193 00:43:00,570 --> 00:43:02,250 compiled stuff and we weird way. 1194 00:43:03,300 --> 00:43:04,979 And actually, if you're running on 1195 00:43:04,980 --> 00:43:07,019 Debian, you again might want to figure 1196 00:43:07,020 --> 00:43:08,579 out what is going on. 1197 00:43:08,580 --> 00:43:10,469 And you see, OK, what binaries, what 1198 00:43:10,470 --> 00:43:13,079 libraries and linked into lib POCSO? 1199 00:43:13,080 --> 00:43:14,849 Oh, it's just lib good. 1200 00:43:14,850 --> 00:43:16,919 And seeing that you 1201 00:43:16,920 --> 00:43:18,479 can then load everything up pro and 1202 00:43:18,480 --> 00:43:20,159 you'll see, OK, it's just going to move 1203 00:43:20,160 --> 00:43:22,599 good and that's looking to look good. 1204 00:43:22,600 --> 00:43:24,659 So it doesn't even 1205 00:43:24,660 --> 00:43:25,749 mention a bin shell. 1206 00:43:25,750 --> 00:43:27,839 So how the hell does it fork something? 1207 00:43:27,840 --> 00:43:29,999 Well, it turns out that because it uses 1208 00:43:30,000 --> 00:43:32,679 these crafted headers and the source code 1209 00:43:32,680 --> 00:43:34,379 for the alpha manipulation is available 1210 00:43:34,380 --> 00:43:35,689 in the good Pesta manual. 1211 00:43:35,690 --> 00:43:37,389 The Frog's International Journal of 1212 00:43:37,390 --> 00:43:39,000 P.O.S. would get the fuck out 1213 00:43:40,080 --> 00:43:42,389 um, which is available at your local 1214 00:43:42,390 --> 00:43:43,390 samizdat retailer. 1215 00:43:46,450 --> 00:43:48,159 You'll notice that, in fact, and you can 1216 00:43:48,160 --> 00:43:49,899 do this if you actually take the pain of 1217 00:43:49,900 --> 00:43:51,399 debugging the thing and then looking at 1218 00:43:51,400 --> 00:43:53,739 maps, it will actually link to evil 1219 00:43:53,740 --> 00:43:56,619 S0, which contains the shell drop. 1220 00:43:56,620 --> 00:43:58,239 Because the user space lotus is a 1221 00:43:58,240 --> 00:43:59,529 completely different program, head a 1222 00:43:59,530 --> 00:44:01,419 table from which on I can point it to a 1223 00:44:01,420 --> 00:44:03,099 completely different dynamic table, which 1224 00:44:03,100 --> 00:44:04,809 allows me to completely manipulate what 1225 00:44:04,810 --> 00:44:06,069 the binary is doing. 1226 00:44:06,070 --> 00:44:07,659 If I wouldn't want to load another shared 1227 00:44:07,660 --> 00:44:09,639 library, I could also use the tricks that 1228 00:44:09,640 --> 00:44:11,229 Bax has demonstrated and many other 1229 00:44:11,230 --> 00:44:13,299 people say escapes lo 1230 00:44:13,300 --> 00:44:15,729 create to completely rewrite 1231 00:44:15,730 --> 00:44:17,799 my binary at runtime 1232 00:44:17,800 --> 00:44:19,779 and just embed the code directly into it. 1233 00:44:19,780 --> 00:44:21,349 But for the purposes of having a clear 1234 00:44:21,350 --> 00:44:23,079 and understandable PC loading a different 1235 00:44:23,080 --> 00:44:25,149 shared library is 1236 00:44:25,150 --> 00:44:27,519 just as easily as a side note. 1237 00:44:27,520 --> 00:44:29,259 If you happen to run this on a more sane 1238 00:44:29,260 --> 00:44:31,299 system and not Debien 1239 00:44:32,350 --> 00:44:34,629 led will actually say on arch 1240 00:44:34,630 --> 00:44:36,039 led will actually tell you that it's 1241 00:44:36,040 --> 00:44:38,769 linking to enslave evil because 1242 00:44:38,770 --> 00:44:40,839 as some side effect of, I think 1243 00:44:40,840 --> 00:44:42,460 and say, Linux implementation 1244 00:44:44,020 --> 00:44:46,689 it actually invokes, 1245 00:44:46,690 --> 00:44:48,759 the shed actually invokes the user space 1246 00:44:48,760 --> 00:44:50,709 loader as an executable, which is an 1247 00:44:50,710 --> 00:44:52,779 alternative way of executing a 1248 00:44:52,780 --> 00:44:54,829 binary without having access to an exact 1249 00:44:54,830 --> 00:44:57,429 system call, which 1250 00:44:57,430 --> 00:44:59,079 means that the debugging tool actually 1251 00:44:59,080 --> 00:45:00,309 does not debug what would happen 1252 00:45:00,310 --> 00:45:01,310 normally. 1253 00:45:01,810 --> 00:45:04,119 So in this way, you can quietly hide code 1254 00:45:04,120 --> 00:45:05,120 in a shared library. 1255 00:45:06,490 --> 00:45:07,959 And feel free to play around with it as a 1256 00:45:07,960 --> 00:45:09,789 few others, I'm sure there's many other 1257 00:45:09,790 --> 00:45:12,399 passing ambiguities in Elf. 1258 00:45:12,400 --> 00:45:14,229 And with that, I'll hand it back to see. 1259 00:45:25,280 --> 00:45:27,379 And as I mentioned, the idea of 1260 00:45:27,380 --> 00:45:29,329 loading a shared library is really just a 1261 00:45:29,330 --> 00:45:30,979 trick for privacy. 1262 00:45:30,980 --> 00:45:32,749 If you want to, you can use the various 1263 00:45:32,750 --> 00:45:34,339 tables that you now have control over and 1264 00:45:34,340 --> 00:45:35,719 that you now have successfully hidden 1265 00:45:35,720 --> 00:45:38,629 from all those pesky IRA wielding is 1266 00:45:38,630 --> 00:45:40,639 to rewrite your binary at will. 1267 00:45:41,660 --> 00:45:42,739 Well, so 1268 00:45:44,000 --> 00:45:46,339 just to cover the last point. 1269 00:45:46,340 --> 00:45:49,039 Imagine, I mean, so OK, we've 1270 00:45:49,040 --> 00:45:51,679 used relocation entries to completely 1271 00:45:51,680 --> 00:45:53,839 rewrite an image 1272 00:45:53,840 --> 00:45:56,629 that is loading, and whatever 1273 00:45:56,630 --> 00:45:58,339 you think you're getting is absolutely 1274 00:45:58,340 --> 00:46:00,019 not what is in your runtime. 1275 00:46:00,020 --> 00:46:02,629 However, relocation entries are powerful. 1276 00:46:02,630 --> 00:46:05,329 They are there for editing 1277 00:46:05,330 --> 00:46:07,459 the loaded code for 1278 00:46:07,460 --> 00:46:09,379 patching the road load of code for 1279 00:46:09,380 --> 00:46:11,090 rewriting addresses. 1280 00:46:12,200 --> 00:46:14,179 So that's cheating, right? 1281 00:46:14,180 --> 00:46:16,699 How about just symbols? 1282 00:46:16,700 --> 00:46:19,129 Just dynamic symbols? 1283 00:46:19,130 --> 00:46:20,599 Just a dynamic symbol table. 1284 00:46:20,600 --> 00:46:23,089 Turns out with this trick, we can't 1285 00:46:23,090 --> 00:46:25,789 because I can pretend 1286 00:46:25,790 --> 00:46:28,489 that all of your program 1287 00:46:28,490 --> 00:46:30,200 is the global offset table. 1288 00:46:31,800 --> 00:46:34,079 A global also table is something 1289 00:46:34,080 --> 00:46:36,209 that the dynamic linker writes 1290 00:46:36,210 --> 00:46:38,489 into, because 1291 00:46:38,490 --> 00:46:41,189 this is how this is where the address 1292 00:46:41,190 --> 00:46:44,099 of the resolved function by name. 1293 00:46:44,100 --> 00:46:46,349 Say you want to print, OK, are 1294 00:46:46,350 --> 00:46:48,419 you? Your first jump will 1295 00:46:48,420 --> 00:46:51,389 be into the stub 1296 00:46:51,390 --> 00:46:53,969 through the global or sub table, 1297 00:46:53,970 --> 00:46:56,039 which will be pointing at that 1298 00:46:56,040 --> 00:46:58,109 stub. And then the stub 1299 00:46:58,110 --> 00:47:00,389 will bring you into the dynamic loader, 1300 00:47:00,390 --> 00:47:03,029 which will resolve print by name. 1301 00:47:03,030 --> 00:47:05,459 Load the library well, 1302 00:47:05,460 --> 00:47:08,099 you know Lipsy, and then 1303 00:47:08,100 --> 00:47:09,809 it will overwrite the global. 1304 00:47:09,810 --> 00:47:12,059 Also table entry pointing 1305 00:47:12,060 --> 00:47:14,639 there. And so your next 1306 00:47:14,640 --> 00:47:16,949 jump. Your next call to Prince 1307 00:47:16,950 --> 00:47:19,499 will go straight to the 1308 00:47:19,500 --> 00:47:22,289 library to the resolved symbol. 1309 00:47:22,290 --> 00:47:24,479 So now I can pretend that 1310 00:47:24,480 --> 00:47:26,579 my entire program is 1311 00:47:26,580 --> 00:47:27,479 got. 1312 00:47:27,480 --> 00:47:29,549 And yes, that will take a rather large 1313 00:47:29,550 --> 00:47:30,749 assemble tables. 1314 00:47:30,750 --> 00:47:32,819 But you 1315 00:47:32,820 --> 00:47:35,069 know, we can fingerprint pimpin memory 1316 00:47:35,070 --> 00:47:36,070 this way. 1317 00:47:36,600 --> 00:47:37,600 So to conclude? 1318 00:47:40,750 --> 00:47:42,969 Channels of trust are something 1319 00:47:42,970 --> 00:47:44,889 that we absolutely want to have. 1320 00:47:46,420 --> 00:47:48,489 All those little steps, 1321 00:47:48,490 --> 00:47:50,649 little links in them, such 1322 00:47:50,650 --> 00:47:53,109 as loading, 1323 00:47:53,110 --> 00:47:55,629 signing, checking 1324 00:47:55,630 --> 00:47:56,859 signatures. 1325 00:47:56,860 --> 00:47:59,289 Anything that involves finding 1326 00:47:59,290 --> 00:48:00,820 the pieces that we trust 1327 00:48:01,990 --> 00:48:03,789 and we are the pieces that we trust, 1328 00:48:03,790 --> 00:48:05,949 other pieces to go 1329 00:48:05,950 --> 00:48:08,049 by and 1330 00:48:08,050 --> 00:48:10,149 contain evidence, 1331 00:48:10,150 --> 00:48:12,759 say cryptographic evidence that 1332 00:48:12,760 --> 00:48:13,809 they have not changed. 1333 00:48:13,810 --> 00:48:15,399 They have not been tampered with. 1334 00:48:15,400 --> 00:48:17,769 All those steps are as important 1335 00:48:17,770 --> 00:48:20,499 computationally as 1336 00:48:20,500 --> 00:48:23,079 the original as the 1337 00:48:23,080 --> 00:48:25,389 original development process. 1338 00:48:25,390 --> 00:48:27,819 And even though you may have no bugs 1339 00:48:27,820 --> 00:48:29,079 there whatsoever. 1340 00:48:30,510 --> 00:48:32,729 You will nevertheless 1341 00:48:32,730 --> 00:48:35,129 likely have disagreements between 1342 00:48:35,130 --> 00:48:37,379 the links in the chain of trust, and 1343 00:48:37,380 --> 00:48:39,659 you will likely also have 1344 00:48:39,660 --> 00:48:42,899 a rather powerful 1345 00:48:42,900 --> 00:48:44,100 software engineering 1346 00:48:45,150 --> 00:48:47,819 hacks like 1347 00:48:47,820 --> 00:48:49,919 relocation that 1348 00:48:49,920 --> 00:48:50,920 in fact. 1349 00:48:51,690 --> 00:48:54,239 Can rewrite your program and 1350 00:48:54,240 --> 00:48:57,299 will deprive you of the ability 1351 00:48:57,300 --> 00:48:59,369 to try to apply the first kind of 1352 00:48:59,370 --> 00:49:01,499 trust. I analyzed it. 1353 00:49:01,500 --> 00:49:03,119 Therefore, I trust it. 1354 00:49:03,120 --> 00:49:05,879 And of course, you can start trusting 1355 00:49:05,880 --> 00:49:07,709 starts signing everything. 1356 00:49:07,710 --> 00:49:10,169 But you know. 1357 00:49:11,380 --> 00:49:14,439 Composition is the soul of 1358 00:49:14,440 --> 00:49:16,809 software engineering, so 1359 00:49:16,810 --> 00:49:19,209 you will at some point face 1360 00:49:19,210 --> 00:49:21,399 the necessity to combine 1361 00:49:21,400 --> 00:49:23,499 things programs out of pieces 1362 00:49:23,500 --> 00:49:24,579 of code. 1363 00:49:24,580 --> 00:49:27,219 So let's come back 1364 00:49:27,220 --> 00:49:28,989 to trusting trust, reflections on trust 1365 00:49:28,990 --> 00:49:30,129 and trust. 1366 00:49:30,130 --> 00:49:32,409 Even though there may be no 1367 00:49:32,410 --> 00:49:34,899 bugs, the bugs it was never 1368 00:49:34,900 --> 00:49:37,089 all about the bugs 1369 00:49:37,090 --> 00:49:38,979 are sure. 1370 00:49:38,980 --> 00:49:40,959 Memory corruption is fun. 1371 00:49:40,960 --> 00:49:43,149 Sure, you know 1372 00:49:43,150 --> 00:49:45,309 shellcode is lovely, 1373 00:49:45,310 --> 00:49:48,219 but partial differentials 1374 00:49:48,220 --> 00:49:50,859 are equally important. 1375 00:49:50,860 --> 00:49:53,349 Agreement in the dialects 1376 00:49:53,350 --> 00:49:55,989 of the parsers that are 1377 00:49:55,990 --> 00:49:58,749 the partners in the chain of trust 1378 00:49:58,750 --> 00:50:00,879 is equally important. 1379 00:50:00,880 --> 00:50:02,979 Complex data formats that 1380 00:50:02,980 --> 00:50:05,799 do not allow you to check things 1381 00:50:05,800 --> 00:50:08,199 out for the first order of trust. 1382 00:50:08,200 --> 00:50:10,179 I have analyzed it fully. 1383 00:50:10,180 --> 00:50:12,339 I know what kind of a program 1384 00:50:12,340 --> 00:50:13,689 that table is. 1385 00:50:15,040 --> 00:50:16,040 They kill trust. 1386 00:50:17,430 --> 00:50:19,709 Diversion of dialects 1387 00:50:19,710 --> 00:50:21,059 kills trust. 1388 00:50:21,060 --> 00:50:23,189 There can be no chain of trust in 1389 00:50:23,190 --> 00:50:24,190 Babel. 1390 00:50:24,990 --> 00:50:27,359 You are, you know, all your cats 1391 00:50:27,360 --> 00:50:30,279 building up that Babel Tower. 1392 00:50:30,280 --> 00:50:32,809 And yeah, not 1393 00:50:32,810 --> 00:50:35,429 not a good software engineering practice. 1394 00:50:35,430 --> 00:50:36,430 So what could we do? 1395 00:50:39,120 --> 00:50:40,019 We should be. 1396 00:50:40,020 --> 00:50:41,100 I mean, what do we want? 1397 00:50:42,160 --> 00:50:43,899 Chains of trust. 1398 00:50:43,900 --> 00:50:45,040 When do we want them 1399 00:50:46,060 --> 00:50:47,799 now, right? 1400 00:50:47,800 --> 00:50:50,439 What do I want? Simple formats. 1401 00:50:50,440 --> 00:50:52,389 Simple formats that. 1402 00:50:53,490 --> 00:50:56,339 Take away the computational 1403 00:50:56,340 --> 00:50:58,529 power from the tables 1404 00:50:58,530 --> 00:51:00,629 so that you can actually 1405 00:51:00,630 --> 00:51:03,479 statically analyze the computation 1406 00:51:03,480 --> 00:51:05,009 that they will cause. 1407 00:51:05,010 --> 00:51:07,139 Squeeze complexity out of data. 1408 00:51:07,140 --> 00:51:08,659 We want simple formats 1409 00:51:10,230 --> 00:51:12,479 now starting with 1410 00:51:12,480 --> 00:51:13,379 a boot. 1411 00:51:13,380 --> 00:51:15,029 You know, we've looked at the top of the 1412 00:51:15,030 --> 00:51:16,829 trust chain. What about the beginning, 1413 00:51:16,830 --> 00:51:18,599 the bottom unify? 1414 00:51:18,600 --> 00:51:19,649 How simple is that? 1415 00:51:21,470 --> 00:51:22,669 OK. 1416 00:51:22,670 --> 00:51:24,799 Software package formats 1417 00:51:24,800 --> 00:51:26,989 zipped crypto, 1418 00:51:26,990 --> 00:51:29,419 I mean, Android Master key bugs were 1419 00:51:29,420 --> 00:51:32,089 just brilliant, you know, oh, 1420 00:51:32,090 --> 00:51:33,829 you shouldn't roll your own crypto. 1421 00:51:33,830 --> 00:51:36,439 Therefore, we will use the JavaScript 1422 00:51:36,440 --> 00:51:38,599 library because that's 1423 00:51:38,600 --> 00:51:41,090 great code on one problem 1424 00:51:42,260 --> 00:51:44,389 the installer is a Linux 1425 00:51:44,390 --> 00:51:46,759 installer, and 1426 00:51:46,760 --> 00:51:48,859 what it is is not what the 1427 00:51:48,860 --> 00:51:51,589 JavaScript of their fire sees. 1428 00:51:51,590 --> 00:51:53,749 And with my best impression of Agent 1429 00:51:53,750 --> 00:51:55,129 Smith, you know what? 1430 00:51:55,130 --> 00:51:57,649 Good is a signature, Mr. Anderson. 1431 00:51:57,650 --> 00:51:59,749 If you can't even see the document, 1432 00:52:02,300 --> 00:52:03,300 it's. 1433 00:52:07,710 --> 00:52:09,659 But it goes deeper than that. 1434 00:52:09,660 --> 00:52:11,669 It's all about computation, it's all 1435 00:52:11,670 --> 00:52:13,799 about input being programs and 1436 00:52:13,800 --> 00:52:16,619 tables being programs in particular. 1437 00:52:16,620 --> 00:52:18,779 So you have to hobble the 1438 00:52:18,780 --> 00:52:21,569 power that these can induce 1439 00:52:21,570 --> 00:52:23,009 in your code. 1440 00:52:23,010 --> 00:52:25,319 So we have a few 1441 00:52:25,320 --> 00:52:27,539 of the modest engineering 1442 00:52:27,540 --> 00:52:29,399 proposals. One of them is called ealth 1443 00:52:29,400 --> 00:52:30,540 back. You will see the 1444 00:52:31,950 --> 00:52:33,209 TR. 1445 00:52:33,210 --> 00:52:36,089 We will be releasing code eventually 1446 00:52:36,090 --> 00:52:37,090 next year. 1447 00:52:38,250 --> 00:52:39,689 Julian is the 1448 00:52:41,040 --> 00:52:42,040 main developer. 1449 00:52:43,560 --> 00:52:46,319 And that thing actually breaks 1450 00:52:46,320 --> 00:52:48,599 because this weird machine, 1451 00:52:48,600 --> 00:52:50,699 because it deprives 1452 00:52:50,700 --> 00:52:52,799 the replicator automaton 1453 00:52:52,800 --> 00:52:54,629 of some of the implicit flows that she 1454 00:52:54,630 --> 00:52:55,829 has used. 1455 00:52:55,830 --> 00:52:58,679 And it breaks other techniques 1456 00:52:58,680 --> 00:53:00,299 as well. 1457 00:53:00,300 --> 00:53:02,399 And of course, everyone 1458 00:53:02,400 --> 00:53:05,249 wants new hardware that would contain 1459 00:53:05,250 --> 00:53:07,469 parsers and 1460 00:53:07,470 --> 00:53:09,359 not allow them to run the way with the 1461 00:53:09,360 --> 00:53:11,249 rest of your program, even if they 1462 00:53:11,250 --> 00:53:12,239 contain the bug. 1463 00:53:12,240 --> 00:53:14,339 But as we have seen, the bugs are 1464 00:53:14,340 --> 00:53:16,289 not a necessity for getting potent. 1465 00:53:16,290 --> 00:53:18,539 It's a little disagreement between what 1466 00:53:18,540 --> 00:53:20,639 the dialects of your 1467 00:53:20,640 --> 00:53:22,829 input the parsers, 1468 00:53:22,830 --> 00:53:24,810 the pastors defect or accept 1469 00:53:25,860 --> 00:53:27,359 they will not see the same thing. 1470 00:53:28,380 --> 00:53:31,139 And so we're going to hold an academic 1471 00:53:31,140 --> 00:53:32,550 workshop in this. 1472 00:53:33,660 --> 00:53:36,239 The inventor 1473 00:53:36,240 --> 00:53:38,429 of the inventors of the language 1474 00:53:38,430 --> 00:53:40,829 theoretic approach to security, which 1475 00:53:40,830 --> 00:53:43,139 is what I've been sneaking in 1476 00:53:43,140 --> 00:53:46,439 during the entire introduction, 1477 00:53:46,440 --> 00:53:47,440 is 1478 00:53:50,520 --> 00:53:52,649 finally, you know, finally, we're 1479 00:53:52,650 --> 00:53:54,749 going to have a workshop 1480 00:53:54,750 --> 00:53:56,879 where these topics 1481 00:53:56,880 --> 00:53:59,339 will be considered and 1482 00:53:59,340 --> 00:54:01,589 it's co-located with the 1483 00:54:01,590 --> 00:54:05,429 Police Security Enterprise Symposium 2014 1484 00:54:05,430 --> 00:54:08,099 May 18th, you will find the 1485 00:54:08,100 --> 00:54:10,379 CFP and the Program Committee lists 1486 00:54:10,380 --> 00:54:12,509 and instructions and 1487 00:54:12,510 --> 00:54:15,899 whatnot at the CRL. 1488 00:54:15,900 --> 00:54:18,149 It will be dedicated to the memory of 1489 00:54:18,150 --> 00:54:20,609 Len Sassaman, who, together 1490 00:54:20,610 --> 00:54:22,559 with his wife Meredith Patterson, 1491 00:54:22,560 --> 00:54:23,760 invented the topic. 1492 00:54:30,600 --> 00:54:32,669 So consider 1493 00:54:32,670 --> 00:54:34,949 submitting case 1494 00:54:34,950 --> 00:54:37,529 studies, theory papers, 1495 00:54:37,530 --> 00:54:39,329 exploits that 1496 00:54:41,580 --> 00:54:43,709 use these ideas of 1497 00:54:43,710 --> 00:54:45,479 language theoretic security parser 1498 00:54:45,480 --> 00:54:48,119 differentials and 1499 00:54:48,120 --> 00:54:50,219 weird machines that 1500 00:54:50,220 --> 00:54:52,289 run away on 1501 00:54:52,290 --> 00:54:54,719 their input by being way too powerful 1502 00:54:54,720 --> 00:54:57,059 and by solving by enforcing 1503 00:54:57,060 --> 00:54:59,579 the defender to solve the thing problem, 1504 00:54:59,580 --> 00:55:01,139 which of course, cannot be solved 1505 00:55:03,090 --> 00:55:04,199 with it. 1506 00:55:04,200 --> 00:55:05,200 I think you. 1507 00:55:10,180 --> 00:55:11,180 He ended up. 1508 00:55:13,620 --> 00:55:14,620 It's great to be here. 1509 00:55:15,900 --> 00:55:18,119 OK, so we have very little 1510 00:55:18,120 --> 00:55:19,799 time for Q&A. 1511 00:55:19,800 --> 00:55:22,049 So if you have a question, please sign 1512 00:55:22,050 --> 00:55:24,149 a line up at one of the eight microphones 1513 00:55:24,150 --> 00:55:26,250 that we have in this room. 1514 00:55:29,220 --> 00:55:31,229 If you leave, please take your trash with 1515 00:55:31,230 --> 00:55:32,789 you and 1516 00:55:34,380 --> 00:55:36,509 please put all the bottles 1517 00:55:36,510 --> 00:55:38,789 in one of the crates located at each 1518 00:55:38,790 --> 00:55:41,319 exit. So do we have a question? 1519 00:55:41,320 --> 00:55:44,039 So we have a question from the internet. 1520 00:55:44,040 --> 00:55:46,229 So the internet would like to know 1521 00:55:46,230 --> 00:55:48,359 if you if you could implement 1522 00:55:48,360 --> 00:55:50,639 relocation without a 1523 00:55:50,640 --> 00:55:52,200 Turing complete semantics. 1524 00:55:53,820 --> 00:55:54,749 I have 1525 00:55:54,750 --> 00:55:56,159 not understood. Please repeat the 1526 00:55:56,160 --> 00:55:56,789 question. 1527 00:55:56,790 --> 00:55:58,919 So the question is, can you 1528 00:55:58,920 --> 00:56:01,019 implement relocation without 1529 00:56:01,020 --> 00:56:02,879 Turing? Complete semantics? 1530 00:56:04,470 --> 00:56:06,569 Well, yes, and 1531 00:56:06,570 --> 00:56:07,570 you should. 1532 00:56:08,190 --> 00:56:10,589 Moreover, you should implement 1533 00:56:10,590 --> 00:56:12,929 linking and every 1534 00:56:12,930 --> 00:56:15,839 other step in the API 1535 00:56:15,840 --> 00:56:18,119 without Turing completeness, because 1536 00:56:18,120 --> 00:56:19,769 if you actually do have Turing 1537 00:56:19,770 --> 00:56:22,109 completeness accidentally or 1538 00:56:22,110 --> 00:56:25,079 by design, 1539 00:56:25,080 --> 00:56:27,539 you are completely 1540 00:56:27,540 --> 00:56:29,879 depriving yourself of the ability 1541 00:56:29,880 --> 00:56:33,059 to check what the actual 1542 00:56:33,060 --> 00:56:35,219 result would look like other 1543 00:56:35,220 --> 00:56:37,349 than by renting it otherwise, you 1544 00:56:37,350 --> 00:56:38,699 know, known as halting. 1545 00:56:41,820 --> 00:56:43,949 This will probably be a 1546 00:56:43,950 --> 00:56:45,440 part of the thesis. 1547 00:56:49,860 --> 00:56:51,959 But I mean, this is a very good 1548 00:56:51,960 --> 00:56:52,960 question. 1549 00:56:53,910 --> 00:56:56,189 We see Turing 1550 00:56:56,190 --> 00:56:58,379 completeness being shown 1551 00:56:58,380 --> 00:57:00,479 everywhere, you know, in 1552 00:57:00,480 --> 00:57:02,999 order to download a file 1553 00:57:03,000 --> 00:57:05,369 from, Oh, Dropbox, 1554 00:57:05,370 --> 00:57:07,020 I need to run JavaScript. 1555 00:57:08,640 --> 00:57:11,009 Right. What is so Turing complete 1556 00:57:11,010 --> 00:57:13,319 about downloading 1557 00:57:13,320 --> 00:57:16,019 a file? Why do I need to run JavaScript, 1558 00:57:16,020 --> 00:57:18,359 you know, daily to interact, to 1559 00:57:18,360 --> 00:57:20,429 show numbers to a website 1560 00:57:20,430 --> 00:57:23,129 and get numbers out of the website? 1561 00:57:23,130 --> 00:57:24,810 I need to run JavaScript 1562 00:57:26,070 --> 00:57:28,529 Y and HTML 1563 00:57:28,530 --> 00:57:30,659 five together 1564 00:57:30,660 --> 00:57:31,769 with CSS. 1565 00:57:31,770 --> 00:57:32,789 Look up. 1566 00:57:32,790 --> 00:57:34,829 Excellent works by Mario Heidrich. 1567 00:57:34,830 --> 00:57:37,559 That thing can be a tricked 1568 00:57:37,560 --> 00:57:39,030 into Turing completeness 1569 00:57:41,400 --> 00:57:43,469 via things like what the filling 1570 00:57:43,470 --> 00:57:45,749 of forms and it's been actually 1571 00:57:45,750 --> 00:57:47,309 proven. Turing complete 1572 00:57:48,990 --> 00:57:51,629 by I actually, 1573 00:57:51,630 --> 00:57:53,759 I'm failing on the reference, but it 1574 00:57:53,760 --> 00:57:56,039 is in our paper which you'll find 1575 00:57:56,040 --> 00:57:58,319 on the links site. 1576 00:57:58,320 --> 00:58:00,509 So we are surrounded 1577 00:58:00,510 --> 00:58:02,579 by completely useless and 1578 00:58:02,580 --> 00:58:04,679 unnecessary Turing 1579 00:58:04,680 --> 00:58:05,579 completeness. 1580 00:58:05,580 --> 00:58:07,769 And that's just it's 1581 00:58:07,770 --> 00:58:10,109 just there to break our trust. 1582 00:58:10,110 --> 00:58:12,509 It's just there to empower 1583 00:58:12,510 --> 00:58:14,849 the attacker, the up. 1584 00:58:16,650 --> 00:58:18,419 Competition, the minimum privileged 1585 00:58:18,420 --> 00:58:21,209 principle, the least privileged principle 1586 00:58:21,210 --> 00:58:23,309 should be that 1587 00:58:23,310 --> 00:58:25,379 computation also 1588 00:58:25,380 --> 00:58:27,479 is a privilege and it is 1589 00:58:27,480 --> 00:58:29,250 a privilege given to attacker. 1590 00:58:30,930 --> 00:58:33,089 So, Turing, completeness 1591 00:58:33,090 --> 00:58:34,289 where it doesn't belong. 1592 00:58:35,580 --> 00:58:37,199 You know, Turing completeness of 1593 00:58:37,200 --> 00:58:39,419 communication boundaries in particular, 1594 00:58:39,420 --> 00:58:41,609 where untrusted data arrives 1595 00:58:41,610 --> 00:58:44,249 is a really, really bad idea 1596 00:58:44,250 --> 00:58:45,719 if you haven't yet. 1597 00:58:45,720 --> 00:58:47,999 I encourage you to watch the talk 1598 00:58:48,000 --> 00:58:49,689 by Meredith Fetters on the science of 1599 00:58:49,690 --> 00:58:51,809 insecurity at 28 c 1600 00:58:51,810 --> 00:58:53,879 three. Again, you will find links 1601 00:58:53,880 --> 00:58:56,809 on length sector work site. 1602 00:58:56,810 --> 00:58:58,839 Have I responded? 1603 00:58:58,840 --> 00:59:01,579 Okay, yeah, so 1604 00:59:01,580 --> 00:59:03,559 the gentleman at microphone number one, 1605 00:59:03,560 --> 00:59:04,579 please? 1606 00:59:04,580 --> 00:59:05,539 Very quick. 1607 00:59:05,540 --> 00:59:06,739 I'm not sure if I understood this 1608 00:59:06,740 --> 00:59:07,759 correctly. 1609 00:59:07,760 --> 00:59:09,829 The tables that are used to 1610 00:59:09,830 --> 00:59:12,259 rewrite the sign codes are other part 1611 00:59:12,260 --> 00:59:14,239 of or not part of the code signing 1612 00:59:14,240 --> 00:59:15,240 process. 1613 00:59:17,860 --> 00:59:20,049 So many signing 1614 00:59:20,050 --> 00:59:23,029 schemes do not sign metadata. 1615 00:59:23,030 --> 00:59:24,030 Hurray. 1616 00:59:27,890 --> 00:59:28,890 Right. 1617 00:59:30,610 --> 00:59:31,689 So, like, 1618 00:59:33,070 --> 00:59:35,619 yeah, yeah, well, the answer is 1619 00:59:35,620 --> 00:59:37,959 again, and we've been asked 1620 00:59:37,960 --> 00:59:40,209 by, well, 1621 00:59:40,210 --> 00:59:42,309 I mean, Becks has done this for Elf, 1622 00:59:42,310 --> 00:59:44,589 but our P E 1623 00:59:44,590 --> 00:59:46,689 is a cousin of 1624 00:59:46,690 --> 00:59:48,819 elf with all 1625 00:59:48,820 --> 00:59:50,749 sorts of interesting properties. 1626 00:59:50,750 --> 00:59:52,869 MECO is a cousin 1627 00:59:52,870 --> 00:59:55,359 of wealth and neck. Oh, actually, 1628 00:59:55,360 --> 00:59:58,629 he does real location with bytecode, 1629 00:59:58,630 --> 01:00:00,909 a special dedicated bytecode, 1630 01:00:00,910 --> 01:00:01,910 not just 1631 01:00:03,520 --> 01:00:05,769 sue structures with offsets as 1632 01:00:05,770 --> 01:00:07,929 elf with offsets and types 1633 01:00:07,930 --> 01:00:09,999 and pointers to symbols. 1634 01:00:10,000 --> 01:00:11,289 That is actual bytecode. 1635 01:00:11,290 --> 01:00:14,049 The virtual machine is included for it. 1636 01:00:14,050 --> 01:00:15,279 And guess what? 1637 01:00:15,280 --> 01:00:17,349 Of course, it's 1638 01:00:17,350 --> 01:00:18,579 Turing complete as well. 1639 01:00:19,670 --> 01:00:21,829 OK, our time is up. 1640 01:00:21,830 --> 01:00:22,830 Thank you very much.