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/496 Thanks! 1 00:00:11,370 --> 00:00:13,619 Enthusiastically, a cashier and 2 00:00:13,620 --> 00:00:15,899 a security researcher, 3 00:00:15,900 --> 00:00:18,479 assistant professor at Purdue University 4 00:00:18,480 --> 00:00:19,919 in Indiana. 5 00:00:19,920 --> 00:00:21,989 So let's hear what he has 6 00:00:21,990 --> 00:00:24,149 on new 7 00:00:24,150 --> 00:00:26,669 corruption attacks. 8 00:00:26,670 --> 00:00:28,230 Thank you very much for the introduction. 9 00:00:35,870 --> 00:00:37,249 Thanks, guys. 10 00:00:37,250 --> 00:00:39,049 Wait was applause for until after the 11 00:00:39,050 --> 00:00:41,149 talk, this is 12 00:00:41,150 --> 00:00:43,279 not just my work, but the work of a whole 13 00:00:43,280 --> 00:00:45,169 bunch of students that I want to give 14 00:00:45,170 --> 00:00:47,449 credit to add a whole bunch 15 00:00:47,450 --> 00:00:49,639 of different places from Sorich 16 00:00:49,640 --> 00:00:52,009 to UC Berkeley to Purdue 17 00:00:52,010 --> 00:00:55,099 University and a bunch of other places. 18 00:00:55,100 --> 00:00:57,469 And I want to especially 19 00:00:57,470 --> 00:00:59,629 call out Nicholas Carlini, who did a lot 20 00:00:59,630 --> 00:01:01,369 of the coding work. 21 00:01:01,370 --> 00:01:03,559 And this gives me the opportunity 22 00:01:03,560 --> 00:01:05,749 to give you a little bit 23 00:01:05,750 --> 00:01:07,819 of a peek towards a demo 24 00:01:07,820 --> 00:01:10,039 that I will do at the end of the talk, 25 00:01:10,040 --> 00:01:12,199 and we will drop something interesting at 26 00:01:12,200 --> 00:01:14,239 the end of the talk. So stay tuned. 27 00:01:14,240 --> 00:01:16,699 But this is not just a talk on 28 00:01:16,700 --> 00:01:17,809 memory corruption, but 29 00:01:19,310 --> 00:01:21,109 a whole journey that happens. 30 00:01:21,110 --> 00:01:23,299 And it can best be described 31 00:01:23,300 --> 00:01:25,369 as Dr. Strangelove or how I learned 32 00:01:25,370 --> 00:01:27,599 to stop worrying and laughter fault 33 00:01:29,520 --> 00:01:31,459 in the in the last couple of years, I've 34 00:01:31,460 --> 00:01:34,219 worked a lot of a lot of 35 00:01:34,220 --> 00:01:36,379 a lot of time, a long time with 36 00:01:36,380 --> 00:01:38,449 software and different forms of 37 00:01:38,450 --> 00:01:40,669 vulnerability's, memory, corruptions and 38 00:01:40,670 --> 00:01:42,419 a whole bunch of. 39 00:01:42,420 --> 00:01:44,699 Bad things that can happen and the world 40 00:01:44,700 --> 00:01:46,829 that we are currently living in is that 41 00:01:46,830 --> 00:01:48,389 all the software that we are running on 42 00:01:48,390 --> 00:01:50,819 our systems is unsafe and insecure 43 00:01:50,820 --> 00:01:53,879 and low level languages like in C++ 44 00:01:53,880 --> 00:01:55,619 trade, all the type safety and memory 45 00:01:55,620 --> 00:01:58,019 safety for a so-called potential 46 00:01:58,020 --> 00:01:59,039 of performance. 47 00:01:59,040 --> 00:02:00,899 They don't necessarily give you the 48 00:02:00,900 --> 00:02:03,389 performance, but they allow you to 49 00:02:03,390 --> 00:02:05,489 maybe get the performance, but you 50 00:02:05,490 --> 00:02:07,469 lose all the type safety and memory 51 00:02:07,470 --> 00:02:09,179 safety that you would get otherwise from 52 00:02:09,180 --> 00:02:10,439 safer languages. 53 00:02:10,440 --> 00:02:12,539 And the programmer himself or 54 00:02:12,540 --> 00:02:14,609 herself is responsible for all the 55 00:02:14,610 --> 00:02:16,739 checks that have to be coded 56 00:02:16,740 --> 00:02:18,809 explicitly into the source code. 57 00:02:18,810 --> 00:02:20,849 And if any of these checks are missing, 58 00:02:20,850 --> 00:02:23,129 then a program just explodes 59 00:02:23,130 --> 00:02:24,629 in your face. 60 00:02:24,630 --> 00:02:26,699 But it's not just a large set 61 00:02:26,700 --> 00:02:28,289 of legacy applications that we are 62 00:02:28,290 --> 00:02:30,329 running on our current systems, but also 63 00:02:30,330 --> 00:02:32,129 a whole bunch of new applications that 64 00:02:32,130 --> 00:02:34,319 are being written in C and C++ 65 00:02:34,320 --> 00:02:36,059 that are still prone to different forms 66 00:02:36,060 --> 00:02:37,709 of memory corruption books. 67 00:02:37,710 --> 00:02:40,229 And it just want to call out that even 68 00:02:40,230 --> 00:02:42,899 at companies like Google, where 69 00:02:42,900 --> 00:02:45,299 they look very closely 70 00:02:45,300 --> 00:02:47,519 to coding standards and code reviews, 71 00:02:47,520 --> 00:02:49,469 they still have a whole bunch of security 72 00:02:49,470 --> 00:02:51,329 vulnerabilities. If you just look at the 73 00:02:51,330 --> 00:02:53,369 at the Google Chrome browser that is 74 00:02:53,370 --> 00:02:54,830 being pwned every single year, 75 00:02:56,550 --> 00:02:58,889 also while finding and fixing 76 00:02:58,890 --> 00:03:00,749 bugs is very important, there are just 77 00:03:00,750 --> 00:03:02,819 too many books out there to find and fix 78 00:03:02,820 --> 00:03:04,649 manually. So we have to protect the 79 00:03:04,650 --> 00:03:06,989 integrity of our systems 80 00:03:06,990 --> 00:03:09,209 through some form of additional safety 81 00:03:09,210 --> 00:03:10,979 mechanisms that are out there. 82 00:03:10,980 --> 00:03:12,719 And if you just look back at the 83 00:03:13,740 --> 00:03:15,989 over the last two years or 84 00:03:15,990 --> 00:03:17,219 the last couple of months, there have 85 00:03:17,220 --> 00:03:19,709 been a whole bunch of security 86 00:03:19,710 --> 00:03:21,329 vulnerabilities out there that are 87 00:03:21,330 --> 00:03:24,029 calling for stronger and better defenses. 88 00:03:24,030 --> 00:03:25,949 And just to call out the few that made it 89 00:03:25,950 --> 00:03:27,839 to the press, there was heart Heartbleed 90 00:03:27,840 --> 00:03:30,060 that basically corrupted all the 91 00:03:31,080 --> 00:03:33,029 all the crypto keys out there on all the 92 00:03:33,030 --> 00:03:34,589 different servers that we were running. 93 00:03:34,590 --> 00:03:36,179 There was shell shocked that allowed us 94 00:03:36,180 --> 00:03:38,369 to execute arbitrary commands 95 00:03:38,370 --> 00:03:40,079 on different different servers. 96 00:03:40,080 --> 00:03:41,969 And there was there was ghost, which 97 00:03:41,970 --> 00:03:44,069 basically allowed us arbitrary memory 98 00:03:44,070 --> 00:03:46,409 corruptions in any program 99 00:03:46,410 --> 00:03:49,319 that just didn't get hosted by name call. 100 00:03:49,320 --> 00:03:51,479 So what we are 101 00:03:51,480 --> 00:03:53,849 facing is a huge 102 00:03:53,850 --> 00:03:55,949 amount of memory unsafety that 103 00:03:55,950 --> 00:03:58,019 our current programs have 104 00:03:58,020 --> 00:03:59,909 and that we have to deal this through 105 00:03:59,910 --> 00:04:02,129 different forms of additional 106 00:04:02,130 --> 00:04:04,049 security mechanisms and security 107 00:04:04,050 --> 00:04:05,459 guarantees. 108 00:04:05,460 --> 00:04:07,649 But let me take a step back and talk 109 00:04:07,650 --> 00:04:09,659 to you a little bit about the different 110 00:04:09,660 --> 00:04:11,159 memory safety problems that we are 111 00:04:11,160 --> 00:04:12,119 facing. 112 00:04:12,120 --> 00:04:13,769 So to give you some some additional 113 00:04:13,770 --> 00:04:14,770 background 114 00:04:16,079 --> 00:04:18,028 at the core of any security 115 00:04:18,029 --> 00:04:20,219 vulnerability, there is an 116 00:04:20,220 --> 00:04:22,289 invalid reference 117 00:04:22,290 --> 00:04:24,569 ETAs through a dangling pointer, what 118 00:04:24,570 --> 00:04:26,729 we call a temporal reference, which is at 119 00:04:26,730 --> 00:04:28,919 one point in time our point 120 00:04:28,920 --> 00:04:30,419 during the low level language pointed to 121 00:04:30,420 --> 00:04:32,669 a valid allocated object 122 00:04:32,670 --> 00:04:35,189 which was later freed by the programmer 123 00:04:35,190 --> 00:04:37,589 and is still accessed 124 00:04:37,590 --> 00:04:39,749 after after the fact, after it has 125 00:04:39,750 --> 00:04:41,129 been allocated. 126 00:04:41,130 --> 00:04:42,929 And the other alternative is an out of 127 00:04:42,930 --> 00:04:44,999 bounds pointer, which we call spatial 128 00:04:45,000 --> 00:04:46,049 memory corruption. 129 00:04:46,050 --> 00:04:48,179 That is the pointer at one point in 130 00:04:48,180 --> 00:04:50,429 time pointed into the into 131 00:04:50,430 --> 00:04:52,739 a valid object and then 132 00:04:52,740 --> 00:04:55,079 through the execution of the program, 133 00:04:55,080 --> 00:04:57,569 started to move outside of the object 134 00:04:57,570 --> 00:04:59,579 and is now pointing into an illegal 135 00:04:59,580 --> 00:05:01,709 memory region, which is 136 00:05:01,710 --> 00:05:03,959 it? Was it it moved out 137 00:05:03,960 --> 00:05:06,059 of the of the correct bounds 138 00:05:06,060 --> 00:05:07,739 of the object. 139 00:05:07,740 --> 00:05:10,289 But it's only a violation 140 00:05:10,290 --> 00:05:12,599 or an invalid 141 00:05:12,600 --> 00:05:14,999 reference if the pointer is read, 142 00:05:15,000 --> 00:05:16,199 written or freed. 143 00:05:16,200 --> 00:05:18,599 According to the C language standard, 144 00:05:18,600 --> 00:05:20,699 you are completely free to have 145 00:05:20,700 --> 00:05:22,499 out of bounds pointers. 146 00:05:22,500 --> 00:05:24,869 You're free to have dangling pointers 147 00:05:24,870 --> 00:05:26,399 as long as you do not, you reference 148 00:05:26,400 --> 00:05:28,169 them. And this makes finding these 149 00:05:28,170 --> 00:05:30,419 vulnerabilities in books so 150 00:05:30,420 --> 00:05:32,519 hard because it only 151 00:05:32,520 --> 00:05:34,559 becomes a bug if you are actually using 152 00:05:34,560 --> 00:05:36,659 this invalid pointer, but not if you just 153 00:05:36,660 --> 00:05:37,949 have them in the program. 154 00:05:37,950 --> 00:05:40,199 And at any point in time, there are tons 155 00:05:40,200 --> 00:05:42,479 and tons of of illegal pointers 156 00:05:42,480 --> 00:05:44,429 in the program, which is completely safe 157 00:05:44,430 --> 00:05:46,679 until you dereference them. 158 00:05:46,680 --> 00:05:48,689 And there are two types of attacks that 159 00:05:48,690 --> 00:05:51,029 build on these memory 160 00:05:51,030 --> 00:05:53,129 and safety issues and are 161 00:05:53,130 --> 00:05:55,199 either contraflow hatcheck attacks where 162 00:05:55,200 --> 00:05:57,119 an attacker tries to execute some form of 163 00:05:57,120 --> 00:05:59,249 code or inject new 164 00:05:59,250 --> 00:06:01,469 code or just execute some some different 165 00:06:01,470 --> 00:06:03,329 behavior that is not inherent to the 166 00:06:03,330 --> 00:06:04,769 original program. 167 00:06:04,770 --> 00:06:07,139 Or alternatively, are data only attacks 168 00:06:07,140 --> 00:06:09,059 where where the attacker changes some 169 00:06:09,060 --> 00:06:11,129 data that is then used along the way 170 00:06:11,130 --> 00:06:13,199 of the program to change some internal 171 00:06:13,200 --> 00:06:15,569 state of the after program 172 00:06:15,570 --> 00:06:17,909 to achieve a specific specific 173 00:06:17,910 --> 00:06:18,910 behavior. 174 00:06:19,590 --> 00:06:22,259 Today in this talk, we focus on executing 175 00:06:22,260 --> 00:06:24,329 code only because this is usually the 176 00:06:24,330 --> 00:06:26,219 prime motivation of an attacker. 177 00:06:26,220 --> 00:06:28,559 An attacker wants to execute code 178 00:06:28,560 --> 00:06:30,719 on a on a compute platform to 179 00:06:30,720 --> 00:06:32,879 get additional capabilities on top of 180 00:06:32,880 --> 00:06:33,819 it. 181 00:06:33,820 --> 00:06:35,969 So how does a control flow hijack 182 00:06:35,970 --> 00:06:39,179 attack look like basically 183 00:06:39,180 --> 00:06:41,309 in in high 184 00:06:41,310 --> 00:06:43,809 level terms? We can abstract a program 185 00:06:43,810 --> 00:06:46,419 into some form of control flow graph, 186 00:06:46,420 --> 00:06:48,429 and then the execution of the program 187 00:06:48,430 --> 00:06:50,980 follows this control flow graph and 188 00:06:52,300 --> 00:06:54,399 passes from one notes to 189 00:06:54,400 --> 00:06:56,319 the other one, thereby executing the 190 00:06:56,320 --> 00:06:56,889 program. 191 00:06:56,890 --> 00:06:59,049 And in this sample control flow graph, 192 00:06:59,050 --> 00:07:00,819 we have a small loop and a and a 193 00:07:00,820 --> 00:07:02,709 condition that then breaks out of the 194 00:07:02,710 --> 00:07:04,869 loop and the control 195 00:07:04,870 --> 00:07:06,189 flow of the application as the 196 00:07:06,190 --> 00:07:08,499 application is executing passes 197 00:07:08,500 --> 00:07:10,329 through this control flow graph, which is 198 00:07:10,330 --> 00:07:12,519 an abstract concept that compiler writers 199 00:07:12,520 --> 00:07:13,839 usually use. 200 00:07:13,840 --> 00:07:15,999 And it moves from 201 00:07:16,000 --> 00:07:17,829 one nodes to the other node as we are 202 00:07:17,830 --> 00:07:20,139 executing through the program. 203 00:07:20,140 --> 00:07:22,239 And attacker at one point in time might 204 00:07:22,240 --> 00:07:24,999 be able to modify a code pointer. 205 00:07:25,000 --> 00:07:26,979 Code pointers can be either function 206 00:07:26,980 --> 00:07:29,449 returns, indirect Trump's or indirect 207 00:07:29,450 --> 00:07:31,539 calls. These are all instructions 208 00:07:31,540 --> 00:07:33,789 that are used on our hardware to 209 00:07:33,790 --> 00:07:36,039 control how the 210 00:07:36,040 --> 00:07:38,409 control passes from one basic block 211 00:07:38,410 --> 00:07:40,179 to another, basic block, basically from 212 00:07:40,180 --> 00:07:42,309 one node in the graph to another node in 213 00:07:42,310 --> 00:07:44,379 the graph. And if an attacker can control 214 00:07:44,380 --> 00:07:46,059 these code Pinder's that are then used in 215 00:07:46,060 --> 00:07:48,339 the program, the attacker can redirect 216 00:07:48,340 --> 00:07:50,679 the execution to a different location. 217 00:07:50,680 --> 00:07:53,349 So after modifying such a code pointer 218 00:07:53,350 --> 00:07:55,299 through one of the earlier mentioned 219 00:07:55,300 --> 00:07:57,429 memory corruption vulnerabilities, the 220 00:07:57,430 --> 00:07:59,799 control flow leaves to validate control 221 00:07:59,800 --> 00:08:02,079 flow graph and starts executing 222 00:08:02,080 --> 00:08:04,209 new new 223 00:08:04,210 --> 00:08:06,519 instructions at a different location 224 00:08:06,520 --> 00:08:07,520 and basically 225 00:08:08,770 --> 00:08:11,079 leaving the valid control flow graph. 226 00:08:11,080 --> 00:08:13,119 And the attacker can then reuse different 227 00:08:13,120 --> 00:08:15,309 parts of existing codes 228 00:08:15,310 --> 00:08:17,199 that are in the execution image of the 229 00:08:17,200 --> 00:08:19,329 process and either through 230 00:08:19,330 --> 00:08:21,129 return instructions. 231 00:08:21,130 --> 00:08:22,719 Then it is called return or into 232 00:08:22,720 --> 00:08:24,789 programing or through indirect 233 00:08:24,790 --> 00:08:26,889 trump or indirect instructions and 234 00:08:26,890 --> 00:08:29,319 is called trump oriented programing. 235 00:08:29,320 --> 00:08:31,959 But let's switch to view a little bit and 236 00:08:31,960 --> 00:08:34,689 look at the particular code example. 237 00:08:34,690 --> 00:08:36,759 So we do have a small, vulnerable 238 00:08:36,760 --> 00:08:38,739 function of a couple of lines of code. 239 00:08:38,740 --> 00:08:40,359 And let's just assume that the attacker 240 00:08:40,360 --> 00:08:42,489 controls the two parameters given 241 00:08:42,490 --> 00:08:43,959 to this function, user and user. 242 00:08:43,960 --> 00:08:46,149 Two, we also have a function 243 00:08:46,150 --> 00:08:48,699 pointer that is that is being 244 00:08:48,700 --> 00:08:50,319 defined somewhere in this in this 245 00:08:50,320 --> 00:08:51,320 program. 246 00:08:52,060 --> 00:08:54,429 But the attacker can use 247 00:08:54,430 --> 00:08:56,619 these parameters that are passed 248 00:08:56,620 --> 00:08:58,929 to the function to actually override 249 00:08:58,930 --> 00:09:00,429 part of the function pointers. 250 00:09:00,430 --> 00:09:01,569 We will see later. 251 00:09:01,570 --> 00:09:03,909 And the underlying problem is that 252 00:09:05,240 --> 00:09:07,419 the attacker can force an 253 00:09:07,420 --> 00:09:09,669 out of bounds memory right through 254 00:09:09,670 --> 00:09:12,099 this behavior by forging 255 00:09:12,100 --> 00:09:14,209 an out of bounds pointer and then be 256 00:09:14,210 --> 00:09:16,239 referencing that pointer to write the 257 00:09:16,240 --> 00:09:18,399 specific value to to this memory 258 00:09:18,400 --> 00:09:19,299 location. 259 00:09:19,300 --> 00:09:21,489 If you look at the stack or the memory 260 00:09:21,490 --> 00:09:23,589 layout of the program, we see the 261 00:09:23,590 --> 00:09:24,699 individual variables. 262 00:09:24,700 --> 00:09:26,589 Q We see the buffer, we see the function 263 00:09:26,590 --> 00:09:28,689 pointer and we also have a piece of 264 00:09:28,690 --> 00:09:29,690 code at the bottom. 265 00:09:30,940 --> 00:09:33,939 So initially in a valid execution, 266 00:09:33,940 --> 00:09:36,039 the pointer queue would point somewhere 267 00:09:36,040 --> 00:09:38,409 into the buffer and the value user 268 00:09:38,410 --> 00:09:40,269 two would be written into the buffer. 269 00:09:40,270 --> 00:09:42,639 It can then be used by the program in an 270 00:09:42,640 --> 00:09:44,739 odd way, but the attacker 271 00:09:44,740 --> 00:09:45,789 can use this 272 00:09:47,230 --> 00:09:48,939 addition to redirect the pointer. 273 00:09:48,940 --> 00:09:51,069 Q To point to 274 00:09:51,070 --> 00:09:52,449 the function pointer to the memory 275 00:09:52,450 --> 00:09:53,949 location of the function pointer instead 276 00:09:53,950 --> 00:09:55,749 of into the buffer. 277 00:09:55,750 --> 00:09:57,849 And as we continue, when it is 278 00:09:57,850 --> 00:10:00,189 being is being referenced, 279 00:10:00,190 --> 00:10:02,319 the attacker can override this function 280 00:10:02,320 --> 00:10:04,659 pointer and then make it point into 281 00:10:04,660 --> 00:10:06,609 the code below. 282 00:10:06,610 --> 00:10:09,189 And as soon as the 283 00:10:09,190 --> 00:10:11,709 program executes or give references, 284 00:10:11,710 --> 00:10:13,209 this function pointer, which has been 285 00:10:13,210 --> 00:10:15,279 overwritten by the attacker in steps 286 00:10:15,280 --> 00:10:17,409 one and two before the attacker can 287 00:10:17,410 --> 00:10:19,869 start executing codes 288 00:10:19,870 --> 00:10:21,639 that is being controlled by the attacker 289 00:10:21,640 --> 00:10:24,399 and reuse different forms of gadgets. 290 00:10:24,400 --> 00:10:26,469 And these are basically the two building 291 00:10:26,470 --> 00:10:28,689 blocks that we have in current 292 00:10:28,690 --> 00:10:31,029 attacks and that attackers use 293 00:10:31,030 --> 00:10:33,819 to actually get control over the program. 294 00:10:33,820 --> 00:10:37,329 First, we have memory unsafety 295 00:10:37,330 --> 00:10:38,919 or memory safety violation that the 296 00:10:38,920 --> 00:10:41,859 attacker uses to build up the 297 00:10:41,860 --> 00:10:43,449 later steps of the exploit. 298 00:10:43,450 --> 00:10:45,729 And then the control 299 00:10:45,730 --> 00:10:47,949 flow of the application leads to valid 300 00:10:47,950 --> 00:10:50,229 control flow graph of the application and 301 00:10:50,230 --> 00:10:52,149 then the attacker executes arbitrary 302 00:10:52,150 --> 00:10:53,259 code. 303 00:10:53,260 --> 00:10:55,509 But we do have safety measures, 304 00:10:55,510 --> 00:10:58,089 right? There has been a plethora 305 00:10:58,090 --> 00:11:00,159 of proposals of different forms of 306 00:11:00,160 --> 00:11:02,139 safety mechanisms that have been added 307 00:11:02,140 --> 00:11:03,879 over the last couple of years. 308 00:11:03,880 --> 00:11:05,679 And we've got a whole bunch of different 309 00:11:05,680 --> 00:11:07,869 defenses that are 310 00:11:07,870 --> 00:11:10,029 active on our current systems. 311 00:11:10,030 --> 00:11:12,249 And let's just quickly go through them 312 00:11:12,250 --> 00:11:14,079 so that we can see where their 313 00:11:14,080 --> 00:11:16,419 limitations are and what other things 314 00:11:16,420 --> 00:11:17,649 are possible. 315 00:11:17,650 --> 00:11:19,719 So we started off this data 316 00:11:19,720 --> 00:11:21,879 execution prevention, where we 317 00:11:21,880 --> 00:11:23,979 removed the writable 318 00:11:23,980 --> 00:11:26,049 bit from several locations 319 00:11:26,050 --> 00:11:28,149 in memory and the executable bit from 320 00:11:28,150 --> 00:11:30,309 other locations before data 321 00:11:30,310 --> 00:11:31,929 execution prevention. 322 00:11:31,930 --> 00:11:34,239 We could just inject our new code 323 00:11:34,240 --> 00:11:36,759 somewhere on the stack or on the heap, 324 00:11:36,760 --> 00:11:38,859 and the attacker could just redirect 325 00:11:38,860 --> 00:11:40,959 the execution to these locations on the 326 00:11:40,960 --> 00:11:41,959 stack. And he. 327 00:11:41,960 --> 00:11:44,389 And then execute this newly injected 328 00:11:44,390 --> 00:11:46,279 code, but with the advent of data 329 00:11:46,280 --> 00:11:48,439 execution prevention, attackers have to 330 00:11:48,440 --> 00:11:50,929 resort to already pre existing 331 00:11:50,930 --> 00:11:53,689 code as no new code can be injected 332 00:11:53,690 --> 00:11:55,339 into the executing image of the 333 00:11:55,340 --> 00:11:56,299 application. 334 00:11:56,300 --> 00:11:58,369 So this ensures that we can 335 00:11:58,370 --> 00:12:00,469 no longer just inject new code 336 00:12:00,470 --> 00:12:02,029 like Shell code or and 337 00:12:03,170 --> 00:12:05,749 or other pieces of code that can be 338 00:12:05,750 --> 00:12:07,879 used by the attacker to escalate his or 339 00:12:07,880 --> 00:12:09,379 her privileges. 340 00:12:09,380 --> 00:12:11,569 A second step is space 341 00:12:11,570 --> 00:12:13,249 layout randomization. 342 00:12:13,250 --> 00:12:15,319 Instead of allocating all 343 00:12:15,320 --> 00:12:17,299 the different pieces of 344 00:12:18,680 --> 00:12:21,079 often of an application 345 00:12:21,080 --> 00:12:23,139 and well-known locations which are 346 00:12:23,140 --> 00:12:25,489 scrambled these locations around every 347 00:12:25,490 --> 00:12:27,619 single time the application is started. 348 00:12:27,620 --> 00:12:30,079 And this makes it harder for the 349 00:12:30,080 --> 00:12:32,719 attacker to guess where the 350 00:12:32,720 --> 00:12:34,340 very exact locations are. 351 00:12:35,450 --> 00:12:37,369 Obviously, this is prone to information 352 00:12:37,370 --> 00:12:39,409 leaks. If the attacker can somehow learn 353 00:12:39,410 --> 00:12:41,419 where these individual locations are, the 354 00:12:41,420 --> 00:12:43,219 attacker can build and exploit that 355 00:12:43,220 --> 00:12:44,220 actually 356 00:12:45,290 --> 00:12:47,629 can mitigate these defenses. 357 00:12:47,630 --> 00:12:50,179 We also have stack can to place 358 00:12:50,180 --> 00:12:52,399 strategic values on the stack that 359 00:12:52,400 --> 00:12:54,469 should not be overwritten and 360 00:12:54,470 --> 00:12:56,659 safe except in handlers on top of that, 361 00:12:56,660 --> 00:12:58,789 that guarantee that 362 00:12:58,790 --> 00:13:01,519 the exceptions follow predefined 363 00:13:01,520 --> 00:13:02,839 pattern. 364 00:13:02,840 --> 00:13:05,149 So we've got a whole bunch of defenses 365 00:13:05,150 --> 00:13:07,279 out there that 366 00:13:07,280 --> 00:13:09,379 protect us from some 367 00:13:09,380 --> 00:13:11,059 of the vulnerabilities that are out 368 00:13:11,060 --> 00:13:13,909 there. But as we see this, all the 369 00:13:13,910 --> 00:13:15,949 all the successful exploits on current 370 00:13:15,950 --> 00:13:18,109 software, these defenses 371 00:13:18,110 --> 00:13:20,329 are not complete and are at 372 00:13:20,330 --> 00:13:22,729 best partial and make attacks 373 00:13:22,730 --> 00:13:24,199 a little bit harder. 374 00:13:24,200 --> 00:13:26,359 But they do in no means stop the attacks. 375 00:13:27,670 --> 00:13:28,670 Also, 376 00:13:29,830 --> 00:13:30,999 are Aerospace Ltd. 377 00:13:31,000 --> 00:13:32,439 randomization and data execution 378 00:13:32,440 --> 00:13:34,359 prevention are only effective in 379 00:13:34,360 --> 00:13:36,849 combination if both of them are used 380 00:13:36,850 --> 00:13:39,009 together on the honor system at both 381 00:13:39,010 --> 00:13:41,919 times, because if you break 382 00:13:41,920 --> 00:13:44,169 data execution prevention, you 383 00:13:44,170 --> 00:13:46,239 can inject new code if you break 384 00:13:46,240 --> 00:13:48,399 a seal or, you know, the addresses of 385 00:13:48,400 --> 00:13:51,039 existing code and just stitch 386 00:13:51,040 --> 00:13:53,529 newly new locations and code locations 387 00:13:53,530 --> 00:13:56,079 together and then re execute 388 00:13:56,080 --> 00:13:58,209 already existing code 389 00:13:58,210 --> 00:14:00,399 as soon as you break a seal or you 390 00:14:00,400 --> 00:14:02,469 can reuse these existing code 391 00:14:02,470 --> 00:14:03,969 code locations. 392 00:14:03,970 --> 00:14:06,189 And I just mentioned before that 393 00:14:06,190 --> 00:14:08,259 information leaks actually enable 394 00:14:08,260 --> 00:14:10,419 you to infer the locations of 395 00:14:10,420 --> 00:14:12,789 specific pieces of code and you can then 396 00:14:12,790 --> 00:14:14,679 stitch together the well-known code 397 00:14:14,680 --> 00:14:16,869 locations to gain full 398 00:14:16,870 --> 00:14:19,269 code executions on desktop 399 00:14:19,270 --> 00:14:21,669 systems. Such information leaks are quite 400 00:14:21,670 --> 00:14:23,829 common and it is 401 00:14:23,830 --> 00:14:25,809 possible to find information leaks and 402 00:14:25,810 --> 00:14:28,749 different pieces of software on servers. 403 00:14:28,750 --> 00:14:30,729 In the last couple of years, code reuse 404 00:14:30,730 --> 00:14:32,889 attacks have decreased 405 00:14:32,890 --> 00:14:35,379 and attacks have gotten harder 406 00:14:35,380 --> 00:14:38,079 due to the 407 00:14:38,080 --> 00:14:40,089 because there just aren't that many 408 00:14:40,090 --> 00:14:42,129 information leaks on servers. 409 00:14:42,130 --> 00:14:44,350 So this summer we actually 410 00:14:46,000 --> 00:14:49,029 worked on an attack that 411 00:14:49,030 --> 00:14:51,129 leaks the accelerators basically at 412 00:14:51,130 --> 00:14:54,399 randomization based addresses of 413 00:14:54,400 --> 00:14:56,679 all the concurrently running virtual 414 00:14:56,680 --> 00:14:58,749 machines for 415 00:14:58,750 --> 00:15:00,339 different Windows versions and different 416 00:15:00,340 --> 00:15:02,679 Linux versions by 417 00:15:02,680 --> 00:15:04,929 using and memory. 418 00:15:04,930 --> 00:15:07,029 Did the application side channel 419 00:15:07,030 --> 00:15:09,249 that many cloud infrastructures 420 00:15:09,250 --> 00:15:11,649 used? And we can basically learn the. 421 00:15:13,180 --> 00:15:15,339 SLR based addresses of concurrently 422 00:15:15,340 --> 00:15:18,309 running virtual machines by just 423 00:15:18,310 --> 00:15:21,159 generating random or 424 00:15:21,160 --> 00:15:23,289 well-known memory pages that are 425 00:15:23,290 --> 00:15:25,209 just iterate through the available 426 00:15:25,210 --> 00:15:27,369 entropy bits of the 427 00:15:27,370 --> 00:15:29,469 Esler our base addresses and then 428 00:15:29,470 --> 00:15:31,029 learn these other addresses. 429 00:15:31,030 --> 00:15:32,799 But for more information, I would like to 430 00:15:32,800 --> 00:15:34,929 refer you to the to the paper and 431 00:15:34,930 --> 00:15:37,389 to the to the rootstock. 432 00:15:37,390 --> 00:15:39,339 Also, the folks that worked on it, the 433 00:15:39,340 --> 00:15:41,409 two students or the two other 434 00:15:41,410 --> 00:15:42,819 folks that are working on it are here as 435 00:15:42,820 --> 00:15:44,979 well. And they can be reached to if 436 00:15:44,980 --> 00:15:46,479 you if you have questions. 437 00:15:46,480 --> 00:15:48,969 So the status of the diploid 438 00:15:48,970 --> 00:15:50,859 defenses is fairly incomplete. 439 00:15:50,860 --> 00:15:53,519 And we constantly see a lot of attacks 440 00:15:53,520 --> 00:15:56,229 that are going on and exploits 441 00:15:56,230 --> 00:15:58,389 are possible on current systems. 442 00:15:58,390 --> 00:16:00,339 But there must be some secret plan 443 00:16:00,340 --> 00:16:02,739 somewhere out there that helps us protect 444 00:16:02,740 --> 00:16:04,749 against many of these new upcoming 445 00:16:04,750 --> 00:16:07,239 attacks. We somehow have to defend 446 00:16:07,240 --> 00:16:09,669 against all of these new exploits. 447 00:16:09,670 --> 00:16:11,929 And academia has come out of this 448 00:16:11,930 --> 00:16:14,049 mess, hundreds of different proposals 449 00:16:14,050 --> 00:16:16,509 on how we can protect against these 450 00:16:16,510 --> 00:16:18,159 these different forms of memory safety 451 00:16:18,160 --> 00:16:19,209 vulnerabilities. 452 00:16:19,210 --> 00:16:21,879 Many of them are very unpractical 453 00:16:21,880 --> 00:16:23,979 due to a high 454 00:16:23,980 --> 00:16:26,169 EDAR, high performance overhead or 455 00:16:26,170 --> 00:16:27,369 other forms of overhead or 456 00:16:27,370 --> 00:16:29,979 incompatibilities with existing software. 457 00:16:29,980 --> 00:16:32,199 But two proposals that are 458 00:16:32,200 --> 00:16:34,539 gaining more and more momentum, our stack 459 00:16:34,540 --> 00:16:36,699 integrity and control for integrity. 460 00:16:36,700 --> 00:16:37,929 And we are seeing more and more 461 00:16:37,930 --> 00:16:40,059 deployment of these these two 462 00:16:40,060 --> 00:16:41,379 defense mechanisms. 463 00:16:41,380 --> 00:16:43,899 But let's start with Steck integrity. 464 00:16:43,900 --> 00:16:46,989 So we want to enforce 465 00:16:46,990 --> 00:16:49,689 an additional set of restrictions 466 00:16:49,690 --> 00:16:51,909 on return instructions, 467 00:16:53,320 --> 00:16:55,539 on the source code 468 00:16:55,540 --> 00:16:58,359 level. The return instructions 469 00:16:58,360 --> 00:17:00,789 or the return from a function 470 00:17:00,790 --> 00:17:02,979 to the caller is a very well-defined 471 00:17:02,980 --> 00:17:05,049 function and it is usually a 472 00:17:05,050 --> 00:17:07,118 one way function. You can only return to 473 00:17:07,119 --> 00:17:09,279 one specific color 474 00:17:09,280 --> 00:17:11,919 at any single time in the 475 00:17:11,920 --> 00:17:13,779 during the execution of the program. 476 00:17:13,780 --> 00:17:16,419 But at the hardware level, this is not 477 00:17:16,420 --> 00:17:18,459 a restricted operation. 478 00:17:18,460 --> 00:17:20,529 As the 479 00:17:20,530 --> 00:17:22,868 return instructions implemented on 480 00:17:22,869 --> 00:17:25,269 all the existing hardware architectures, 481 00:17:25,270 --> 00:17:27,608 it basically allows you to read a code 482 00:17:27,609 --> 00:17:30,249 pointer from the stack and then redirect 483 00:17:30,250 --> 00:17:32,469 the execution flow to an arbitrary 484 00:17:32,470 --> 00:17:33,759 code locations. 485 00:17:33,760 --> 00:17:35,979 And what SEC integrity does is 486 00:17:35,980 --> 00:17:37,869 it takes the semantics from the 487 00:17:37,870 --> 00:17:39,579 programing language, from this high level 488 00:17:39,580 --> 00:17:41,529 programing language, and enforces the 489 00:17:41,530 --> 00:17:43,749 semantics on the overly 490 00:17:43,750 --> 00:17:45,999 permissive instruction at 491 00:17:46,000 --> 00:17:47,559 the at the hardware level. 492 00:17:48,580 --> 00:17:50,709 So one example to enforce Steck 493 00:17:50,710 --> 00:17:52,929 integrity could be to protect 494 00:17:52,930 --> 00:17:54,999 the return instructions through 495 00:17:55,000 --> 00:17:56,559 a shadow stack. 496 00:17:56,560 --> 00:17:58,059 So, for example, if you do have these 497 00:17:58,060 --> 00:17:59,060 code snippets here. 498 00:18:01,150 --> 00:18:03,939 That are where we can 499 00:18:03,940 --> 00:18:06,159 call food from 500 00:18:06,160 --> 00:18:07,900 either function or function B. 501 00:18:09,310 --> 00:18:11,319 We can enforce additional integrity on 502 00:18:11,320 --> 00:18:14,349 top of these these functions 503 00:18:14,350 --> 00:18:16,509 or on top of these returns on 504 00:18:16,510 --> 00:18:17,859 the hardware level. 505 00:18:17,860 --> 00:18:20,469 Then as we are executing function food, 506 00:18:20,470 --> 00:18:22,629 we can return to any bytes 507 00:18:22,630 --> 00:18:25,179 that is executable or map this executable 508 00:18:25,180 --> 00:18:27,309 in the in the image of the 509 00:18:27,310 --> 00:18:28,659 executing process. 510 00:18:28,660 --> 00:18:30,639 But with Steck integrity, we can enforce 511 00:18:30,640 --> 00:18:33,459 that. If Function A is calling for, 512 00:18:33,460 --> 00:18:35,529 we will return only to function 513 00:18:35,530 --> 00:18:38,469 A. as soon as we return from function. 514 00:18:38,470 --> 00:18:40,299 On the other hand, if you're calling food 515 00:18:40,300 --> 00:18:42,369 from function B, we can ensure 516 00:18:42,370 --> 00:18:44,499 that food will only 517 00:18:44,500 --> 00:18:46,569 be able to return to function B. 518 00:18:46,570 --> 00:18:48,969 at this point in time, and thereby 519 00:18:48,970 --> 00:18:51,519 we can ensure that the guarantees 520 00:18:51,520 --> 00:18:54,099 on the programing language level 521 00:18:54,100 --> 00:18:55,689 and the semantics on the programing 522 00:18:55,690 --> 00:18:57,759 language level will be upheld 523 00:18:57,760 --> 00:18:59,949 by the underlying executing program. 524 00:18:59,950 --> 00:19:01,899 And we can guarantee that the contraflow 525 00:19:01,900 --> 00:19:04,209 never leaves this to static, 526 00:19:04,210 --> 00:19:06,159 well-defined grofe. 527 00:19:06,160 --> 00:19:08,199 The second security principle that I 528 00:19:08,200 --> 00:19:10,239 would like to talk about is control for 529 00:19:10,240 --> 00:19:12,309 integrity and control. 530 00:19:12,310 --> 00:19:13,969 Integrity. 531 00:19:13,970 --> 00:19:16,279 At a concept level tries to ensure 532 00:19:16,280 --> 00:19:18,559 that the execution of the program 533 00:19:18,560 --> 00:19:20,569 never leaves the statically determined 534 00:19:20,570 --> 00:19:23,029 control flow graph to ensure 535 00:19:23,030 --> 00:19:25,099 the security property, we first have 536 00:19:25,100 --> 00:19:26,749 to statically construct a control flow 537 00:19:26,750 --> 00:19:27,529 graph. 538 00:19:27,530 --> 00:19:30,469 And for each individual 539 00:19:30,470 --> 00:19:32,929 in their control flow transfer 540 00:19:32,930 --> 00:19:35,239 instruction, we have to find the set 541 00:19:35,240 --> 00:19:37,669 of allowed targets at 542 00:19:37,670 --> 00:19:39,769 at compile time and 543 00:19:39,770 --> 00:19:40,729 at runtime. 544 00:19:40,730 --> 00:19:43,009 We execute an online set check. 545 00:19:43,010 --> 00:19:44,929 So for each in their own control flow 546 00:19:44,930 --> 00:19:47,449 transfer, we do have a check 547 00:19:47,450 --> 00:19:49,579 if the target is any 548 00:19:49,580 --> 00:19:51,079 of the possible targets that were 549 00:19:51,080 --> 00:19:53,149 determined at compile time, 550 00:19:53,150 --> 00:19:55,219 if it is in this set of targets, 551 00:19:55,220 --> 00:19:57,019 we allow the check to continue. 552 00:19:57,020 --> 00:19:58,939 If it is not, then we terminate the 553 00:19:58,940 --> 00:19:59,940 application. 554 00:20:01,540 --> 00:20:03,609 So to show this to 555 00:20:03,610 --> 00:20:06,369 you symbolically, if we execute. 556 00:20:08,350 --> 00:20:09,939 A function pointer, if you execute a 557 00:20:09,940 --> 00:20:11,649 function through a function pointer 558 00:20:11,650 --> 00:20:13,749 without contraflow integrity, we 559 00:20:13,750 --> 00:20:15,849 can basically reach 560 00:20:15,850 --> 00:20:18,069 any possible executable byte 561 00:20:18,070 --> 00:20:20,199 in memory. So there are no restrictions 562 00:20:20,200 --> 00:20:21,549 on the machine level. 563 00:20:21,550 --> 00:20:23,349 Same for the return instruction. 564 00:20:23,350 --> 00:20:25,059 They can basically return to any 565 00:20:25,060 --> 00:20:27,369 arbitrary executable instruction 566 00:20:27,370 --> 00:20:28,989 with contraflow integrity. 567 00:20:28,990 --> 00:20:30,819 We add additional restrictions, so we 568 00:20:30,820 --> 00:20:32,829 first check the function pointer. 569 00:20:32,830 --> 00:20:34,449 If it is in this set of statically 570 00:20:34,450 --> 00:20:35,739 determined targets. 571 00:20:35,740 --> 00:20:37,929 If it is not, then we terminate 572 00:20:37,930 --> 00:20:39,219 the application. 573 00:20:39,220 --> 00:20:42,009 Same for return instruction. 574 00:20:42,010 --> 00:20:44,409 We check the number. 575 00:20:44,410 --> 00:20:47,349 The current return instruction is used 576 00:20:47,350 --> 00:20:49,359 at runtime against the statically 577 00:20:49,360 --> 00:20:52,149 determined set of aloud instructions 578 00:20:52,150 --> 00:20:54,729 or allowed targets at compile time. 579 00:20:54,730 --> 00:20:56,829 If it is in this set, then we allow it 580 00:20:56,830 --> 00:20:57,830 to happen. 581 00:20:58,630 --> 00:21:01,209 So this is slightly different from 582 00:21:01,210 --> 00:21:03,219 stack integrity that I talked about 583 00:21:03,220 --> 00:21:04,220 before, right? 584 00:21:06,690 --> 00:21:08,909 And we'll see a larger example 585 00:21:08,910 --> 00:21:11,399 in in a bit, but what basically happens 586 00:21:11,400 --> 00:21:13,499 is that under contraflow 587 00:21:13,500 --> 00:21:15,689 integrity, the attacker 588 00:21:15,690 --> 00:21:17,849 may write to memory 589 00:21:17,850 --> 00:21:20,039 at any possible time 590 00:21:20,040 --> 00:21:22,199 and the underlying memory safety 591 00:21:22,200 --> 00:21:25,139 violation is allowed to happen 592 00:21:25,140 --> 00:21:27,359 only at a later point in time. 593 00:21:27,360 --> 00:21:29,579 This code pointer is verified when 594 00:21:29,580 --> 00:21:32,429 it is used and there is some time between 595 00:21:32,430 --> 00:21:34,589 the underlying memory corruption 596 00:21:34,590 --> 00:21:37,169 that the attacker can can use 597 00:21:37,170 --> 00:21:39,299 until the code pointer is checked later 598 00:21:39,300 --> 00:21:41,309 on and are something that the attacker 599 00:21:41,310 --> 00:21:43,470 can influence in that time window. 600 00:21:44,630 --> 00:21:46,759 But let's go back to the to 601 00:21:46,760 --> 00:21:48,949 the example on the 602 00:21:48,950 --> 00:21:51,139 two callers that both call 603 00:21:51,140 --> 00:21:54,199 for under a contraflow integrity 604 00:21:54,200 --> 00:21:56,389 policy on the stack, 605 00:21:56,390 --> 00:21:59,419 if a court function FUX, 606 00:21:59,420 --> 00:22:02,089 then FUX can later return 607 00:22:02,090 --> 00:22:04,309 to either A or B, both 608 00:22:04,310 --> 00:22:05,629 are valid targets. 609 00:22:05,630 --> 00:22:08,329 And the analysis that looked 610 00:22:08,330 --> 00:22:10,699 or searched through the 611 00:22:10,700 --> 00:22:12,819 code, through the source code found 612 00:22:12,820 --> 00:22:14,809 that both A and B are calling function 613 00:22:14,810 --> 00:22:16,879 food. So both A and 614 00:22:16,880 --> 00:22:19,519 B are are allowed return targets 615 00:22:19,520 --> 00:22:21,439 when returning from food. 616 00:22:21,440 --> 00:22:23,719 And maybe the attacker can use 617 00:22:23,720 --> 00:22:26,029 this to his 618 00:22:26,030 --> 00:22:28,129 or her advantage at one point in time 619 00:22:28,130 --> 00:22:30,229 to redirect the 620 00:22:30,230 --> 00:22:32,299 control flow to either A or 621 00:22:32,300 --> 00:22:34,469 B, as both targets are allowed 622 00:22:34,470 --> 00:22:36,829 at runtime compared 623 00:22:36,830 --> 00:22:39,139 to the statically determined 624 00:22:39,140 --> 00:22:41,119 set of targets. 625 00:22:41,120 --> 00:22:43,459 And this basically brings me to 626 00:22:43,460 --> 00:22:45,589 new forms or novel code reuse 627 00:22:45,590 --> 00:22:46,489 attacks. 628 00:22:46,490 --> 00:22:48,199 And I would like to start with contraflow 629 00:22:48,200 --> 00:22:50,509 bending, which is trying to work with 630 00:22:50,510 --> 00:22:53,689 Nicolas Carlini and Antonio Barazi. 631 00:22:53,690 --> 00:22:55,400 That did most of the work, 632 00:22:56,690 --> 00:22:58,969 both at one of them is at UC 633 00:22:58,970 --> 00:23:01,249 Berkeley, the other one at work. 634 00:23:01,250 --> 00:23:03,349 And the underlying idea is 635 00:23:03,350 --> 00:23:05,509 that instead of hijacking the 636 00:23:05,510 --> 00:23:07,909 contraflow to a totally new location 637 00:23:07,910 --> 00:23:10,309 in memory, which is bend's to control, 638 00:23:10,310 --> 00:23:12,379 flow a little bit along a 639 00:23:12,380 --> 00:23:14,729 valid control flow graph. 640 00:23:14,730 --> 00:23:17,009 So we are not reaching new 641 00:23:17,010 --> 00:23:19,559 locations that are not visible 642 00:23:19,560 --> 00:23:21,329 in the program, but we are bending the 643 00:23:21,330 --> 00:23:23,579 contraflow along the way. 644 00:23:23,580 --> 00:23:25,769 So if we look at an execution 645 00:23:25,770 --> 00:23:28,409 of a program, each individual contraflow 646 00:23:28,410 --> 00:23:31,349 transfer is valid by itself. 647 00:23:31,350 --> 00:23:34,349 But the trace of contraflow transfers 648 00:23:34,350 --> 00:23:36,629 is not valid and might not 649 00:23:36,630 --> 00:23:38,849 match the non exploit case. 650 00:23:38,850 --> 00:23:41,729 So if you look at a trace, the individual 651 00:23:41,730 --> 00:23:43,829 look for transfer 652 00:23:43,830 --> 00:23:45,659 might not be possible due to the 653 00:23:45,660 --> 00:23:48,179 different constraints that are upheld 654 00:23:48,180 --> 00:23:50,159 along the the trains. 655 00:23:50,160 --> 00:23:52,559 But each individual contraflow transfer 656 00:23:52,560 --> 00:23:53,790 by itself is valid, 657 00:23:54,870 --> 00:23:56,879 and this will allow us to circumvent 658 00:23:56,880 --> 00:23:58,769 static, fully precise contraflow 659 00:23:58,770 --> 00:23:59,770 integrity. 660 00:24:00,490 --> 00:24:02,140 As we all see you in a bit. 661 00:24:03,410 --> 00:24:06,019 The underlying limitation of CFI 662 00:24:06,020 --> 00:24:08,239 is that it is stateless 663 00:24:08,240 --> 00:24:10,849 and each individual state is verified 664 00:24:10,850 --> 00:24:12,919 without any context and 665 00:24:12,920 --> 00:24:14,689 control for integrity as a security 666 00:24:14,690 --> 00:24:17,719 policy is unaware of all the constraints 667 00:24:17,720 --> 00:24:19,310 between the individual states. 668 00:24:24,470 --> 00:24:27,499 So any bending of the contraflow 669 00:24:27,500 --> 00:24:29,809 along possible valuable 670 00:24:29,810 --> 00:24:32,179 states is undetectable, as according 671 00:24:32,180 --> 00:24:34,609 to what the contraflow integrity policy 672 00:24:34,610 --> 00:24:35,779 can observe. 673 00:24:35,780 --> 00:24:38,599 So as an attacker, we have to search APOs 674 00:24:38,600 --> 00:24:40,819 in this abstract contraflow graph 675 00:24:40,820 --> 00:24:42,979 that matches the desired behavior of 676 00:24:42,980 --> 00:24:43,980 the attacker. 677 00:24:45,020 --> 00:24:47,479 And I'm not talking about 678 00:24:47,480 --> 00:24:49,880 some weak form of control for integrity, 679 00:24:51,050 --> 00:24:53,149 weak control, for integrity has 680 00:24:53,150 --> 00:24:55,399 been broken and is known to be broken. 681 00:24:55,400 --> 00:24:57,589 And there's a whole bunch of papers 682 00:24:57,590 --> 00:24:59,689 that were published at different security 683 00:24:59,690 --> 00:25:02,179 conferences last year that show 684 00:25:02,180 --> 00:25:04,099 that weak forms of control for integrity 685 00:25:04,100 --> 00:25:05,509 is broken. 686 00:25:05,510 --> 00:25:08,029 And by the way, Microsoft, Microsoft 687 00:25:08,030 --> 00:25:10,099 contraflow guard is an instance of 688 00:25:10,100 --> 00:25:12,289 a weak control for integrity mechanism 689 00:25:12,290 --> 00:25:14,449 and can be can be broken by any 690 00:25:14,450 --> 00:25:16,459 of these mechanisms that were just cited 691 00:25:16,460 --> 00:25:17,460 here. 692 00:25:17,840 --> 00:25:19,759 It might make the attack a little bit 693 00:25:19,760 --> 00:25:22,339 harder or harder in some cases, 694 00:25:22,340 --> 00:25:24,529 but it does not stop any attack from 695 00:25:24,530 --> 00:25:25,999 happening. 696 00:25:26,000 --> 00:25:28,649 So let's move to strong CFI 697 00:25:28,650 --> 00:25:31,099 and see what we can do under a strong 698 00:25:31,100 --> 00:25:33,199 control for integrity policy. 699 00:25:33,200 --> 00:25:35,479 The assumption that we use this, 700 00:25:35,480 --> 00:25:37,579 that we define a very 701 00:25:37,580 --> 00:25:40,009 precise or precise as possible 702 00:25:40,010 --> 00:25:41,509 control flow graph. 703 00:25:41,510 --> 00:25:43,489 So we assume that there is no over 704 00:25:43,490 --> 00:25:44,490 approximation. 705 00:25:45,580 --> 00:25:47,859 And any possible compiler 706 00:25:47,860 --> 00:25:50,289 or compile time analysis will always 707 00:25:50,290 --> 00:25:52,509 have an approximation and 708 00:25:52,510 --> 00:25:54,879 thereby have imprecision along 709 00:25:54,880 --> 00:25:57,009 the way, but if we assume that there is 710 00:25:57,010 --> 00:25:59,139 no over approximation and we have the 711 00:25:59,140 --> 00:26:01,299 most precise possible contraflow graph 712 00:26:01,300 --> 00:26:03,399 and then show that this contraflow graph 713 00:26:03,400 --> 00:26:05,859 is broken, then by design 714 00:26:05,860 --> 00:26:08,229 we can show that any possible 715 00:26:08,230 --> 00:26:10,329 SIFY implementation can be broken 716 00:26:10,330 --> 00:26:11,979 this way because even this is 717 00:26:11,980 --> 00:26:14,409 unrealistically overly precise 718 00:26:14,410 --> 00:26:15,639 contraflow graph. 719 00:26:15,640 --> 00:26:16,810 We can still break it 720 00:26:18,220 --> 00:26:20,499 because we assume that there's some 721 00:26:20,500 --> 00:26:23,559 form of STAC integrity for some cases 722 00:26:23,560 --> 00:26:25,849 and thereby define fully precise 723 00:26:25,850 --> 00:26:28,029 static CFI so that a 724 00:26:28,030 --> 00:26:30,159 transfer in the contraflow graph 725 00:26:30,160 --> 00:26:32,109 or in the program is only allowed if 726 00:26:32,110 --> 00:26:34,209 there's some benign execution that 727 00:26:34,210 --> 00:26:36,639 uses it. So if you have a witness 728 00:26:36,640 --> 00:26:38,409 of an execution, Chris, that actually 729 00:26:38,410 --> 00:26:40,599 uses this target, only in this case 730 00:26:40,600 --> 00:26:42,939 will we allow the targeted runtime. 731 00:26:44,400 --> 00:26:46,890 Let's look at two possible 732 00:26:48,150 --> 00:26:50,249 two possible forms of CFI. 733 00:26:50,250 --> 00:26:52,889 First one, contraflow integrity form 734 00:26:52,890 --> 00:26:55,229 with and then without 735 00:26:55,230 --> 00:26:57,359 STAC integrity and 736 00:26:57,360 --> 00:26:58,319 for simplicity. 737 00:26:58,320 --> 00:27:00,389 Let's start the CFI 738 00:27:00,390 --> 00:27:02,099 without STAC integrity. 739 00:27:02,100 --> 00:27:04,559 So let's assume we have the strongest 740 00:27:04,560 --> 00:27:06,749 possible analysis under control flow 741 00:27:06,750 --> 00:27:07,229 graph. 742 00:27:07,230 --> 00:27:09,629 And we have very small sets of possible 743 00:27:09,630 --> 00:27:11,759 targets for each individual 744 00:27:11,760 --> 00:27:13,589 in their control for transfer. 745 00:27:13,590 --> 00:27:16,049 What is the best attack that we can do 746 00:27:16,050 --> 00:27:17,279 under this condition? 747 00:27:19,190 --> 00:27:21,559 Ideally, we will resort 748 00:27:21,560 --> 00:27:23,389 to some form of return oriented 749 00:27:23,390 --> 00:27:25,819 programing, and 750 00:27:25,820 --> 00:27:27,979 if you don't have Steck integrity, the 751 00:27:27,980 --> 00:27:30,229 goal of an attacker is to find some 752 00:27:30,230 --> 00:27:32,569 path to, for example, system 753 00:27:32,570 --> 00:27:35,329 in this control flow graph that we have. 754 00:27:35,330 --> 00:27:38,179 And we have to find a set of constraints 755 00:27:38,180 --> 00:27:40,309 and memory locations that we have 756 00:27:40,310 --> 00:27:42,379 to write to to divert control 757 00:27:42,380 --> 00:27:44,569 flow of the program along this 758 00:27:44,570 --> 00:27:46,789 path, which might be constrained 759 00:27:46,790 --> 00:27:48,319 through the memory vulnerability that we 760 00:27:48,320 --> 00:27:49,339 have. 761 00:27:49,340 --> 00:27:51,199 And as a second step, we have to control 762 00:27:51,200 --> 00:27:52,489 the arguments, the system. 763 00:27:53,980 --> 00:27:56,169 And we might ask 764 00:27:56,170 --> 00:27:58,299 ourselves, what does such a control flow 765 00:27:58,300 --> 00:28:00,279 graph actually look like? 766 00:28:00,280 --> 00:28:02,499 And for a long time we thought 767 00:28:02,500 --> 00:28:04,749 that this photograph is this super, 768 00:28:04,750 --> 00:28:07,089 super complex graph that is very 769 00:28:07,090 --> 00:28:09,369 complicated. And it will be almost 770 00:28:09,370 --> 00:28:11,559 impossible for an attacker 771 00:28:11,560 --> 00:28:13,329 to find a pass from the actual 772 00:28:13,330 --> 00:28:15,519 vulnerability through this complex 773 00:28:15,520 --> 00:28:17,589 graph and thereby controlling 774 00:28:17,590 --> 00:28:18,879 all the different arguments and 775 00:28:18,880 --> 00:28:21,279 constraints to then actually reach 776 00:28:21,280 --> 00:28:23,659 system on the other end. 777 00:28:23,660 --> 00:28:25,729 So the assumption is that it is very 778 00:28:25,730 --> 00:28:28,129 unlikely that an attacker will 779 00:28:28,130 --> 00:28:29,480 be able to find such a 780 00:28:30,710 --> 00:28:33,459 such a pass, but. 781 00:28:33,460 --> 00:28:35,319 What does a contraflow photograph really 782 00:28:35,320 --> 00:28:36,320 look like? 783 00:28:36,980 --> 00:28:39,049 In fact, we found that there's 784 00:28:39,050 --> 00:28:41,569 a large amount of functions 785 00:28:41,570 --> 00:28:44,149 that are basically connecting 786 00:28:44,150 --> 00:28:46,669 and then connecting to control flow graph 787 00:28:46,670 --> 00:28:48,259 between all of these individual 788 00:28:48,260 --> 00:28:50,839 locations, there are 789 00:28:50,840 --> 00:28:53,359 all these functions like MWM, Kopi 790 00:28:53,360 --> 00:28:55,669 Mallock and a whole bunch of of 791 00:28:55,670 --> 00:28:57,739 other functions or printf that 792 00:28:57,740 --> 00:28:59,899 basically connect an arbitrary point 793 00:28:59,900 --> 00:29:01,789 in the control flow graph with another 794 00:29:01,790 --> 00:29:03,169 arbitrary point. 795 00:29:03,170 --> 00:29:04,639 These functions are called from 796 00:29:04,640 --> 00:29:07,579 everywhere, and many of these functions 797 00:29:07,580 --> 00:29:10,039 can override their own return address or 798 00:29:10,040 --> 00:29:11,839 in a later point call a function that 799 00:29:11,840 --> 00:29:13,609 will then be able to override its return 800 00:29:13,610 --> 00:29:15,979 addresses and under the control 801 00:29:15,980 --> 00:29:17,809 flow integrity policy to present it 802 00:29:17,810 --> 00:29:21,199 before. As soon as we find 803 00:29:21,200 --> 00:29:23,449 such a function, we can return to any 804 00:29:23,450 --> 00:29:25,639 of the possible callers of this function 805 00:29:25,640 --> 00:29:28,009 and thereby connect to arbitrary 806 00:29:28,010 --> 00:29:29,959 points in this control flow graph, 807 00:29:29,960 --> 00:29:31,639 because both of these points will call 808 00:29:31,640 --> 00:29:32,640 this function. 809 00:29:34,210 --> 00:29:36,639 And then we can easily find a pass 810 00:29:36,640 --> 00:29:38,499 through the control flow graph from the 811 00:29:38,500 --> 00:29:40,449 vulnerability to the system and then 812 00:29:40,450 --> 00:29:42,339 control the arguments and the attacker 813 00:29:42,340 --> 00:29:43,340 wins. 814 00:29:44,270 --> 00:29:46,339 The dispatcher functions are 815 00:29:46,340 --> 00:29:48,769 often frequently called, and yet the 816 00:29:48,770 --> 00:29:51,109 arguments can be under the attackers 817 00:29:51,110 --> 00:29:52,909 control through the different forms of 818 00:29:52,910 --> 00:29:54,679 memory corruptions that we discussed 819 00:29:54,680 --> 00:29:56,839 before, the dispatcher 820 00:29:56,840 --> 00:29:59,059 functions may override their own return 821 00:29:59,060 --> 00:29:59,989 address. 822 00:29:59,990 --> 00:30:02,299 So if you look at the simple men copy 823 00:30:04,040 --> 00:30:06,589 call where the attacker can 824 00:30:06,590 --> 00:30:08,809 supply to the three arguments we just 825 00:30:08,810 --> 00:30:10,549 use, this meme can't be called to 826 00:30:10,550 --> 00:30:12,199 override to 827 00:30:13,430 --> 00:30:16,309 its own return target and then redirect 828 00:30:16,310 --> 00:30:18,499 and connect these two parts of 829 00:30:18,500 --> 00:30:19,549 the control flow graph. 830 00:30:19,550 --> 00:30:21,769 Basically, we generate a shortcut 831 00:30:21,770 --> 00:30:23,539 through this control flow graph and then 832 00:30:23,540 --> 00:30:25,699 redirect the execution of flow to 833 00:30:25,700 --> 00:30:27,859 the other part and can then continue on 834 00:30:27,860 --> 00:30:28,860 at our location. 835 00:30:29,780 --> 00:30:31,879 And we can 836 00:30:31,880 --> 00:30:34,159 basically supply the attacker data, 837 00:30:34,160 --> 00:30:36,649 which is the other location that called 838 00:30:36,650 --> 00:30:38,839 meme copy, overwrite your return 839 00:30:38,840 --> 00:30:41,029 address, make a shortcut 840 00:30:41,030 --> 00:30:43,099 and then start executing closer 841 00:30:43,100 --> 00:30:45,199 to a system until we can execute 842 00:30:45,200 --> 00:30:46,490 our our code. 843 00:30:48,190 --> 00:30:50,889 So basically, contraflow 844 00:30:50,890 --> 00:30:53,109 integrity without any form of 845 00:30:53,110 --> 00:30:55,309 integrity is broken, these 846 00:30:55,310 --> 00:30:57,579 stateless defenses are completely 847 00:30:57,580 --> 00:30:59,949 insufficient for this stack based attacks 848 00:30:59,950 --> 00:31:02,559 that we present here and 849 00:31:02,560 --> 00:31:04,959 such. This dispatcher functions 850 00:31:04,960 --> 00:31:06,969 are fairly frequent and we can find 851 00:31:06,970 --> 00:31:08,439 different set of dispatcher functions 852 00:31:08,440 --> 00:31:09,759 that are basically being called from 853 00:31:09,760 --> 00:31:11,829 everywhere, both in the in the 854 00:31:11,830 --> 00:31:13,539 standard libraries that are supplied and 855 00:31:13,540 --> 00:31:16,059 used everywhere, but also 856 00:31:16,060 --> 00:31:18,519 in the actual code of the 857 00:31:18,520 --> 00:31:19,520 of the programs. 858 00:31:21,880 --> 00:31:24,069 GTECH now becomes 859 00:31:24,070 --> 00:31:25,599 program dependent. 860 00:31:25,600 --> 00:31:28,179 So while the defense 861 00:31:28,180 --> 00:31:30,429 does not stop the ongoing attack, 862 00:31:30,430 --> 00:31:32,649 it makes the attack harder and 863 00:31:32,650 --> 00:31:34,729 the attacker at least has to find the 864 00:31:34,730 --> 00:31:36,819 dispatcher functions and then find the 865 00:31:36,820 --> 00:31:38,679 shortcut through the control graph. 866 00:31:38,680 --> 00:31:40,959 But the attack is still possible. 867 00:31:40,960 --> 00:31:43,239 So it looks like we are 868 00:31:44,510 --> 00:31:45,699 under some trouble here. 869 00:31:45,700 --> 00:31:47,859 Right. But we still 870 00:31:47,860 --> 00:31:50,469 make the attack a little bit harder. 871 00:31:50,470 --> 00:31:52,959 So another attack 872 00:31:52,960 --> 00:31:55,329 that was presented fairly 873 00:31:55,330 --> 00:31:57,399 recently is 874 00:31:57,400 --> 00:32:00,059 counterfeit object oriented programing. 875 00:32:00,060 --> 00:32:02,199 And this is 876 00:32:02,200 --> 00:32:04,569 not my work and not the 877 00:32:04,570 --> 00:32:06,639 work of my collaborators, but I found 878 00:32:06,640 --> 00:32:08,949 it a very neat, neat 879 00:32:08,950 --> 00:32:10,720 attack that that. 880 00:32:11,940 --> 00:32:13,979 Should be mentioned here as well, and the 881 00:32:13,980 --> 00:32:16,199 underlying idea is that a function 882 00:32:16,200 --> 00:32:18,419 can be a Gachet by itself 883 00:32:18,420 --> 00:32:20,609 and you can reconnect and 884 00:32:20,610 --> 00:32:22,740 tie together different parts, often 885 00:32:25,020 --> 00:32:27,839 of countrified objects, to execute 886 00:32:27,840 --> 00:32:29,969 interesting behavior. 887 00:32:29,970 --> 00:32:31,440 So if you look at this, 888 00:32:32,490 --> 00:32:34,709 this C++ code here where 889 00:32:34,710 --> 00:32:37,619 we define a small class 890 00:32:37,620 --> 00:32:39,899 and we have this 891 00:32:39,900 --> 00:32:42,119 little this structure over there that 892 00:32:42,120 --> 00:32:44,249 is, of course, a virtual 893 00:32:44,250 --> 00:32:46,589 the structure and the virtual 894 00:32:46,590 --> 00:32:49,259 keyboard in C++ tells the compiler, 895 00:32:49,260 --> 00:32:51,539 hey, I want this to be an indirect 896 00:32:51,540 --> 00:32:52,540 call. 897 00:32:53,010 --> 00:32:55,049 And this allows us to. 898 00:32:56,460 --> 00:32:58,829 Redirect execution, because 899 00:32:58,830 --> 00:33:01,379 we just heard that redirect 900 00:33:01,380 --> 00:33:02,729 indirect calls are 901 00:33:03,930 --> 00:33:05,619 the underlying principle for all these 902 00:33:05,620 --> 00:33:06,959 contraflow, hatcheck attacks. 903 00:33:09,500 --> 00:33:11,809 But then again, there is in 904 00:33:11,810 --> 00:33:13,399 this example in this district, which is 905 00:33:13,400 --> 00:33:15,529 iterate through a list of 906 00:33:15,530 --> 00:33:18,199 of students that will all be allocated 907 00:33:18,200 --> 00:33:20,509 and we call different forms of 908 00:33:20,510 --> 00:33:23,149 virtual functions on all of these 909 00:33:23,150 --> 00:33:24,769 all of these objects that we have 910 00:33:24,770 --> 00:33:25,729 accumulated. 911 00:33:25,730 --> 00:33:28,429 Now, assume that the attacker controls 912 00:33:28,430 --> 00:33:30,919 the to list of students 913 00:33:30,920 --> 00:33:32,899 that we have or the area of students, 914 00:33:32,900 --> 00:33:35,059 then the attacker can certainly generate 915 00:33:35,060 --> 00:33:38,209 a set of virtual targets 916 00:33:38,210 --> 00:33:40,939 and can reuse existing 917 00:33:40,940 --> 00:33:43,489 virtual virtual tables 918 00:33:43,490 --> 00:33:45,739 to execute arbitrary 919 00:33:45,740 --> 00:33:46,879 behavior. 920 00:33:46,880 --> 00:33:50,029 And as a second step of 921 00:33:50,030 --> 00:33:52,769 use these different forms of 922 00:33:52,770 --> 00:33:54,829 virtual tables and connect them in 923 00:33:54,830 --> 00:33:56,359 a new way. 924 00:33:56,360 --> 00:33:58,039 And there are different forms of 925 00:33:58,040 --> 00:34:00,319 arithmetic gadgets, there are 926 00:34:00,320 --> 00:34:01,489 different forms of 927 00:34:03,080 --> 00:34:04,759 other gadgets as well, right. 928 00:34:04,760 --> 00:34:06,919 So, for example, in this simple 929 00:34:06,920 --> 00:34:09,109 update score, we've got an arithmetic 930 00:34:09,110 --> 00:34:12,049 gadget that we can combine 931 00:34:12,050 --> 00:34:14,119 and a copy gadgets 932 00:34:14,120 --> 00:34:16,399 as well. Then attacker can just stitch 933 00:34:16,400 --> 00:34:17,400 together. 934 00:34:20,120 --> 00:34:22,549 Also, they presented an interesting 935 00:34:22,550 --> 00:34:24,919 technique that allows them to overlay 936 00:34:24,920 --> 00:34:27,079 objects, remember, the 937 00:34:27,080 --> 00:34:28,789 memory is under the control of the 938 00:34:28,790 --> 00:34:30,919 attacker and instead of just 939 00:34:30,920 --> 00:34:33,289 having each object by itself, 940 00:34:33,290 --> 00:34:35,749 the objects themselves can overlay 941 00:34:35,750 --> 00:34:38,149 each other and 942 00:34:38,150 --> 00:34:39,709 the memory layout for a simple 943 00:34:40,820 --> 00:34:42,709 exam. Objects would, for example, look 944 00:34:42,710 --> 00:34:44,779 like as shown on the on the right hand 945 00:34:44,780 --> 00:34:46,279 side, on the screen. 946 00:34:46,280 --> 00:34:48,799 But the attacker can then use existing 947 00:34:48,800 --> 00:34:50,869 fields and overlay these fields 948 00:34:50,870 --> 00:34:53,119 with other objects and thereby 949 00:34:53,120 --> 00:34:55,369 use different forms of arithmetic 950 00:34:55,370 --> 00:34:57,799 gadgets to, for example, update the 951 00:34:57,800 --> 00:35:00,169 virtual pointer table of that object 952 00:35:00,170 --> 00:35:02,139 and redirected to somewhere else. 953 00:35:04,490 --> 00:35:06,739 And through this object overlays, 954 00:35:06,740 --> 00:35:08,689 the attacker can just stitch together 955 00:35:08,690 --> 00:35:11,059 individual individual gadgets 956 00:35:11,060 --> 00:35:14,059 and then get different forms of arbitrary 957 00:35:14,060 --> 00:35:15,730 executions, arbitrary behavior, 958 00:35:17,510 --> 00:35:19,759 and this looks pretty bad if we combine 959 00:35:19,760 --> 00:35:21,949 these two these two attacks both 960 00:35:21,950 --> 00:35:24,079 control flow bending and countrified, 961 00:35:24,080 --> 00:35:26,369 object oriented programing. 962 00:35:26,370 --> 00:35:28,439 But, well, we do have a large amount 963 00:35:28,440 --> 00:35:30,599 of control for integrity proposals out 964 00:35:30,600 --> 00:35:32,729 there, so we might want to 965 00:35:32,730 --> 00:35:34,919 look at how well they hold up 966 00:35:34,920 --> 00:35:36,689 against all of these different forms of 967 00:35:36,690 --> 00:35:39,029 attacks. And I picked out a bunch 968 00:35:39,030 --> 00:35:41,249 of different different control 969 00:35:41,250 --> 00:35:43,259 for integrity mechanisms that have been 970 00:35:43,260 --> 00:35:45,270 proposed either by academia 971 00:35:46,350 --> 00:35:47,639 or by 972 00:35:48,990 --> 00:35:51,209 Google or Microsoft and 973 00:35:51,210 --> 00:35:53,909 others. So there's there's a lockdown 974 00:35:53,910 --> 00:35:56,219 that enforces the 975 00:35:56,220 --> 00:35:58,289 control integrity policy on top of 976 00:35:58,290 --> 00:36:00,479 binaries by using a form of binary 977 00:36:00,480 --> 00:36:02,009 analysis. So you don't need source code 978 00:36:02,010 --> 00:36:03,299 for that. 979 00:36:03,300 --> 00:36:05,759 There is MacFadyen Pasiphae, 980 00:36:05,760 --> 00:36:08,189 which are two forms of source based 981 00:36:08,190 --> 00:36:10,259 control for integrity that need 982 00:36:10,260 --> 00:36:12,389 a full compile time analysis 983 00:36:12,390 --> 00:36:13,649 of all the available code. 984 00:36:14,690 --> 00:36:17,129 There's Google, LLB, TFI 985 00:36:17,130 --> 00:36:19,349 that has been recently released and is 986 00:36:19,350 --> 00:36:21,809 in the process of being upstream into the 987 00:36:21,810 --> 00:36:24,539 New Year releases of LVM. 988 00:36:24,540 --> 00:36:26,879 And there's also Google FCC, 989 00:36:26,880 --> 00:36:29,159 which they presented last year but have 990 00:36:29,160 --> 00:36:31,349 since redacted and removed from 991 00:36:31,350 --> 00:36:33,779 resource base. And we'll see a little bit 992 00:36:33,780 --> 00:36:36,179 in a little bit why they removed 993 00:36:36,180 --> 00:36:37,379 the FCC. 994 00:36:37,380 --> 00:36:39,749 And there's also Microsoft 995 00:36:39,750 --> 00:36:41,159 contraflow guard. 996 00:36:41,160 --> 00:36:44,069 There are many, many others that 997 00:36:44,070 --> 00:36:46,529 implement different sub policies 998 00:36:46,530 --> 00:36:48,929 of these CFI mechanisms 999 00:36:48,930 --> 00:36:50,039 here. 1000 00:36:50,040 --> 00:36:52,199 So just to to give 1001 00:36:52,200 --> 00:36:54,629 you some context, when we are talking 1002 00:36:54,630 --> 00:36:56,879 about TFI, the 1003 00:36:56,880 --> 00:36:59,009 strengths of the defense depends on 1004 00:36:59,010 --> 00:37:00,989 the size of the equivalence classes that 1005 00:37:00,990 --> 00:37:01,979 we have. 1006 00:37:01,980 --> 00:37:04,139 And if you have 1007 00:37:04,140 --> 00:37:06,509 a certain piece of code, we have 1008 00:37:06,510 --> 00:37:09,239 a set of indirect control for transfers 1009 00:37:09,240 --> 00:37:11,189 and these are the instructions shown on 1010 00:37:11,190 --> 00:37:13,199 the left. All these instructions can be 1011 00:37:13,200 --> 00:37:15,169 used by an attacker to redirect 1012 00:37:15,170 --> 00:37:17,189 contraflow from one location to an 1013 00:37:17,190 --> 00:37:18,629 arbitrary other location. 1014 00:37:20,340 --> 00:37:23,099 Any contraflow integrity analysis 1015 00:37:23,100 --> 00:37:25,349 will return a set of 1016 00:37:25,350 --> 00:37:26,909 equivalence classes. 1017 00:37:26,910 --> 00:37:29,069 An equivalence class contains 1018 00:37:29,070 --> 00:37:31,199 a set of targets that are allowed 1019 00:37:31,200 --> 00:37:32,699 at specific locations. 1020 00:37:32,700 --> 00:37:34,769 And here in this example, 1021 00:37:34,770 --> 00:37:36,689 I'm showing three different equivalence 1022 00:37:36,690 --> 00:37:37,739 classes. 1023 00:37:37,740 --> 00:37:39,899 And the last two 1024 00:37:39,900 --> 00:37:41,969 call instructions are using the same 1025 00:37:41,970 --> 00:37:44,279 equivalence class. So multiple indirect 1026 00:37:44,280 --> 00:37:46,409 control for transfers can map to the same 1027 00:37:46,410 --> 00:37:48,509 equivalence class and the same 1028 00:37:48,510 --> 00:37:50,729 set of targets are allowed at these 1029 00:37:50,730 --> 00:37:52,169 different indirect control flow 1030 00:37:52,170 --> 00:37:53,769 transfers. 1031 00:37:53,770 --> 00:37:56,149 And then there's the size of 1032 00:37:56,150 --> 00:37:58,329 of an equivalence class, which 1033 00:37:58,330 --> 00:38:00,579 shows how much 1034 00:38:00,580 --> 00:38:02,799 opportunity the attacker has to 1035 00:38:02,800 --> 00:38:04,989 redirect the control flow 1036 00:38:04,990 --> 00:38:07,149 to different locations, and 1037 00:38:07,150 --> 00:38:09,399 ideally, you want to have many 1038 00:38:09,400 --> 00:38:11,499 equivalence classes with a 1039 00:38:11,500 --> 00:38:12,880 very small size. 1040 00:38:14,320 --> 00:38:16,689 The smaller, the size, ideally, 1041 00:38:16,690 --> 00:38:18,789 the size of an equivalence 1042 00:38:18,790 --> 00:38:20,709 class would be one in that case, the 1043 00:38:20,710 --> 00:38:22,809 attacker would not have an opportunity 1044 00:38:22,810 --> 00:38:24,819 to redirect contraflow to an alternate 1045 00:38:24,820 --> 00:38:25,820 locations, 1046 00:38:27,100 --> 00:38:29,109 but at best, if we want these equivalent 1047 00:38:29,110 --> 00:38:30,839 classes to be as small as possible. 1048 00:38:32,140 --> 00:38:34,299 So we looked at 1049 00:38:34,300 --> 00:38:36,549 the precision on the forward 1050 00:38:36,550 --> 00:38:38,949 edge. So for indirect call and indirect 1051 00:38:38,950 --> 00:38:41,139 Trump instructions and 1052 00:38:41,140 --> 00:38:42,909 we looked at the sizes of equivalence 1053 00:38:42,910 --> 00:38:45,099 classes and represent whisker 1054 00:38:45,100 --> 00:38:47,229 plots where we show both 1055 00:38:47,230 --> 00:38:49,569 the median with the red arrow 1056 00:38:49,570 --> 00:38:50,570 of the 1057 00:38:51,640 --> 00:38:53,889 of the sizes of the equivalence classes, 1058 00:38:53,890 --> 00:38:55,899 the twenty five percentile and the 1059 00:38:55,900 --> 00:38:58,149 seventy five percentile. 1060 00:38:58,150 --> 00:39:00,459 But we also show with these little pluses 1061 00:39:00,460 --> 00:39:02,680 on the side, different forms of outliers. 1062 00:39:04,510 --> 00:39:06,729 The different 1063 00:39:06,730 --> 00:39:08,949 CFI policies are on 1064 00:39:08,950 --> 00:39:11,329 the x axis and dynamic 1065 00:39:11,330 --> 00:39:13,749 shows the amount of possible 1066 00:39:13,750 --> 00:39:16,269 targets are actually required at runtime. 1067 00:39:16,270 --> 00:39:18,489 So we executed all these these 1068 00:39:18,490 --> 00:39:20,529 software or all these programs and 1069 00:39:20,530 --> 00:39:22,809 measured how many indirect transfers 1070 00:39:22,810 --> 00:39:24,879 are actually used and how 1071 00:39:24,880 --> 00:39:26,259 many locations. 1072 00:39:26,260 --> 00:39:27,999 And if we if you look at all these 1073 00:39:28,000 --> 00:39:30,239 different locations, we see that there's 1074 00:39:30,240 --> 00:39:32,559 a surprisingly high amount 1075 00:39:32,560 --> 00:39:34,959 of indirect control for transfers with 1076 00:39:34,960 --> 00:39:38,019 a surprisingly high amount of transfers 1077 00:39:38,020 --> 00:39:40,239 that are targets that is being allowed by 1078 00:39:40,240 --> 00:39:43,599 all these these different policies. 1079 00:39:43,600 --> 00:39:45,759 And we see that in the under the 1080 00:39:45,760 --> 00:39:48,159 dynamic policy in many locations, 1081 00:39:48,160 --> 00:39:50,319 only very few targets are allowed. 1082 00:39:50,320 --> 00:39:52,449 And I would like to remind you that 1083 00:39:52,450 --> 00:39:53,859 this is a logarithmic scale. 1084 00:39:53,860 --> 00:39:56,289 So the higher up you go, the 1085 00:39:56,290 --> 00:39:58,060 more transfers are allowed. 1086 00:40:00,370 --> 00:40:02,379 Let me just point out a couple of of 1087 00:40:02,380 --> 00:40:05,409 interesting things for AFSC 1088 00:40:05,410 --> 00:40:07,779 in many locations, the 1089 00:40:07,780 --> 00:40:10,239 FCC collapsed all the equivalence 1090 00:40:10,240 --> 00:40:12,130 classes into a single set. 1091 00:40:13,410 --> 00:40:15,479 So all the possible locations 1092 00:40:15,480 --> 00:40:17,639 all in there for transfers are 1093 00:40:17,640 --> 00:40:19,800 allowed to use the same set of targets. 1094 00:40:21,180 --> 00:40:23,279 Which basically implements 1095 00:40:23,280 --> 00:40:25,439 week form off of CFI that 1096 00:40:25,440 --> 00:40:27,239 allows you to reuse all the possible 1097 00:40:27,240 --> 00:40:29,489 targets, and this is likely 1098 00:40:29,490 --> 00:40:31,619 the reason why he 1099 00:40:31,620 --> 00:40:32,770 was removed later on. 1100 00:40:34,230 --> 00:40:36,659 Also, we see that for 1101 00:40:36,660 --> 00:40:38,999 lockdown, the spread is usually fairly 1102 00:40:39,000 --> 00:40:41,069 big. So there's an 1103 00:40:41,070 --> 00:40:43,109 outlier out there that has a very high 1104 00:40:43,110 --> 00:40:45,269 amount of transfer that are 1105 00:40:45,270 --> 00:40:46,859 allowed for a specific location. 1106 00:40:46,860 --> 00:40:48,360 And this is due to the 1107 00:40:49,530 --> 00:40:51,689 problem is the binary analysis where 1108 00:40:51,690 --> 00:40:54,209 we require additional symbols 1109 00:40:54,210 --> 00:40:56,019 and information about the libraries. 1110 00:40:56,020 --> 00:40:57,989 And there's usually one library out there 1111 00:40:57,990 --> 00:40:59,759 that does not provide symbols. 1112 00:40:59,760 --> 00:41:02,219 And then a large amount of transfers 1113 00:41:02,220 --> 00:41:04,169 are possible due to limitations of the 1114 00:41:04,170 --> 00:41:05,349 binary analysis. 1115 00:41:05,350 --> 00:41:08,219 So you cannot recover all the information 1116 00:41:08,220 --> 00:41:10,379 about all the possible targets 1117 00:41:10,380 --> 00:41:12,479 in in the code. 1118 00:41:12,480 --> 00:41:14,819 There's also McAfee and PC 1119 00:41:14,820 --> 00:41:17,069 fine, and we see that for most programs 1120 00:41:17,070 --> 00:41:19,409 they actually provide roughly the same 1121 00:41:19,410 --> 00:41:20,909 amount of precision. 1122 00:41:20,910 --> 00:41:23,039 But at five, which is per inputs, you 1123 00:41:23,040 --> 00:41:25,199 find sometimes restricts the 1124 00:41:25,200 --> 00:41:27,449 amount of transfers that are allowed 1125 00:41:27,450 --> 00:41:29,699 due to an additional runtime analysis 1126 00:41:29,700 --> 00:41:30,700 that they do. 1127 00:41:32,150 --> 00:41:34,319 There's also the new 1128 00:41:34,320 --> 00:41:36,440 LVM CFI, which is 1129 00:41:37,580 --> 00:41:39,639 basically the second version of 1130 00:41:39,640 --> 00:41:42,049 FCC that Google recently released 1131 00:41:42,050 --> 00:41:44,149 and will be part of your 1132 00:41:44,150 --> 00:41:45,150 upcoming 1133 00:41:46,280 --> 00:41:48,589 album releases, and 1134 00:41:48,590 --> 00:41:50,959 it looks like as if it's much 1135 00:41:50,960 --> 00:41:53,389 closer to the limit 1136 00:41:53,390 --> 00:41:55,369 or the minimum amount of transfers that 1137 00:41:55,370 --> 00:41:57,899 are being allowed than the old version. 1138 00:41:57,900 --> 00:41:59,749 And it gives you a much tighter security 1139 00:41:59,750 --> 00:42:00,750 bound. 1140 00:42:04,650 --> 00:42:06,779 So let's look at a summary of 1141 00:42:06,780 --> 00:42:10,079 all these different CFI mechanisms 1142 00:42:10,080 --> 00:42:12,389 and in the graph before we've only 1143 00:42:12,390 --> 00:42:13,889 looked at the forward edge. 1144 00:42:13,890 --> 00:42:16,259 So how good is the position for indirect 1145 00:42:16,260 --> 00:42:18,059 calls and indirect jumps? 1146 00:42:18,060 --> 00:42:19,629 But there's also the backward edge. 1147 00:42:19,630 --> 00:42:21,759 And we've talked at the beginning of 1148 00:42:21,760 --> 00:42:23,009 of this talk a little bit about the 1149 00:42:23,010 --> 00:42:24,899 backward edge and the importance of 1150 00:42:24,900 --> 00:42:27,959 protecting the backward edge for 1151 00:42:27,960 --> 00:42:29,699 basic control, flow bending. 1152 00:42:29,700 --> 00:42:32,369 And as we see the first three CFI 1153 00:42:32,370 --> 00:42:34,439 mechanisms, AFSC, Microsoft 1154 00:42:34,440 --> 00:42:36,899 Contraflow Guard and LLB, CFI 1155 00:42:36,900 --> 00:42:38,489 basically have no protection on the 1156 00:42:38,490 --> 00:42:40,829 backward edge except the already 1157 00:42:40,830 --> 00:42:42,929 existing protections out 1158 00:42:42,930 --> 00:42:45,339 there. And this basically makes 1159 00:42:45,340 --> 00:42:47,699 contraflow bending trivially possible 1160 00:42:47,700 --> 00:42:50,129 and allows you to reconnect and stitch 1161 00:42:50,130 --> 00:42:52,109 the contraflow in any possible way you 1162 00:42:52,110 --> 00:42:54,479 would want to do for and 1163 00:42:54,480 --> 00:42:56,999 see if there is some protection 1164 00:42:57,000 --> 00:42:58,829 on the on the backward edge. 1165 00:42:58,830 --> 00:43:00,839 And it makes contraflow bending attacks 1166 00:43:00,840 --> 00:43:02,879 harder. And we have to find these 1167 00:43:02,880 --> 00:43:05,549 despatcher functions and shortcuts 1168 00:43:05,550 --> 00:43:08,909 in this contraflow graph for lockdown. 1169 00:43:08,910 --> 00:43:11,249 The due to the 1170 00:43:11,250 --> 00:43:13,409 strong protection on the backward edge 1171 00:43:13,410 --> 00:43:15,569 that it adds, we have to resort to 1172 00:43:15,570 --> 00:43:17,579 contraflow bending on the forward edge, 1173 00:43:17,580 --> 00:43:20,039 which makes the attack much harder. 1174 00:43:20,040 --> 00:43:22,829 But due to the limits of the static 1175 00:43:22,830 --> 00:43:24,929 binary analysis and the other binary 1176 00:43:24,930 --> 00:43:27,269 analysis, we can still find possible 1177 00:43:27,270 --> 00:43:28,499 targets. 1178 00:43:28,500 --> 00:43:30,239 So it looks like as if the set of 1179 00:43:30,240 --> 00:43:31,949 protections that are being proposed and 1180 00:43:31,950 --> 00:43:34,469 are being integrated in current systems 1181 00:43:34,470 --> 00:43:35,969 are fairly limited. 1182 00:43:35,970 --> 00:43:38,369 They do make the attacks harder. 1183 00:43:38,370 --> 00:43:40,709 And as soon as we add 1184 00:43:40,710 --> 00:43:42,839 Steck integrity to the mix, they will 1185 00:43:42,840 --> 00:43:45,150 make the attack attacks much harder. 1186 00:43:46,710 --> 00:43:49,229 So if you do have steck integrity, 1187 00:43:49,230 --> 00:43:51,389 we can greatly increase the protection 1188 00:43:51,390 --> 00:43:52,649 of current systems. 1189 00:43:52,650 --> 00:43:54,719 But as we've shown before, many of 1190 00:43:54,720 --> 00:43:56,789 the systems do not have STAC integrity at 1191 00:43:56,790 --> 00:43:57,939 all. 1192 00:43:57,940 --> 00:44:00,209 So let's just for for a second assume 1193 00:44:00,210 --> 00:44:02,369 that we do have STAC integrity, 1194 00:44:02,370 --> 00:44:04,439 then return oriented programing 1195 00:44:04,440 --> 00:44:06,509 is no longer an option and attack 1196 00:44:06,510 --> 00:44:08,069 becomes much harder. 1197 00:44:08,070 --> 00:44:10,019 The attacker now needs to find a path 1198 00:44:10,020 --> 00:44:11,789 through the set of virtual calls that are 1199 00:44:11,790 --> 00:44:14,129 out there and resort to some form 1200 00:44:14,130 --> 00:44:16,949 of restricted coop. 1201 00:44:16,950 --> 00:44:19,229 And the attack becomes really hard 1202 00:44:21,510 --> 00:44:23,639 and interpretor would 1203 00:44:23,640 --> 00:44:26,069 actually make attacks much simpler. 1204 00:44:26,070 --> 00:44:28,829 Assume that you have some piece of code 1205 00:44:28,830 --> 00:44:31,889 that you can inject into the 1206 00:44:31,890 --> 00:44:34,979 executing image of the application 1207 00:44:34,980 --> 00:44:37,109 that even under the constraints 1208 00:44:37,110 --> 00:44:39,509 of full, full control 1209 00:44:39,510 --> 00:44:41,609 for integrity still allows you to 1210 00:44:41,610 --> 00:44:43,110 execute a different code. 1211 00:44:44,500 --> 00:44:46,749 And you would be 1212 00:44:46,750 --> 00:44:50,019 surprised by how many Turing complete 1213 00:44:50,020 --> 00:44:52,269 interpreters there are, and 1214 00:44:52,270 --> 00:44:54,429 I would like to introduce you to 1215 00:44:54,430 --> 00:44:57,159 printf oriented programing 1216 00:44:57,160 --> 00:44:59,769 where we'll show that printf 1217 00:44:59,770 --> 00:45:02,229 is fully Turing complete 1218 00:45:02,230 --> 00:45:04,599 and we can translate any arbitrary 1219 00:45:04,600 --> 00:45:06,999 program to a format string. 1220 00:45:07,000 --> 00:45:09,279 We can do memory reetz. 1221 00:45:09,280 --> 00:45:11,409 We can do memory, right, and 1222 00:45:11,410 --> 00:45:13,329 we can actually implement conditionals as 1223 00:45:13,330 --> 00:45:14,330 well. 1224 00:45:15,540 --> 00:45:17,699 The program counter becomes 1225 00:45:17,700 --> 00:45:19,859 the counter in the format string, and 1226 00:45:19,860 --> 00:45:23,069 we can just move the program along. 1227 00:45:23,070 --> 00:45:25,469 If you want to do loops, we can actually 1228 00:45:25,470 --> 00:45:27,779 overwrite this program counter 1229 00:45:27,780 --> 00:45:30,089 or this format string counter as 1230 00:45:30,090 --> 00:45:32,519 different parts of the format, 1231 00:45:32,520 --> 00:45:34,319 the string are being printed to the 1232 00:45:34,320 --> 00:45:36,749 screen and we can reset and jump around 1233 00:45:36,750 --> 00:45:39,209 in this format string and then readjust 1234 00:45:39,210 --> 00:45:41,909 our program counter to implement 1235 00:45:41,910 --> 00:45:44,129 different chumps in this 1236 00:45:44,130 --> 00:45:46,229 in this abstract language that we that 1237 00:45:46,230 --> 00:45:48,839 we implement. 1238 00:45:48,840 --> 00:45:50,939 And we are presenting a Turing complete 1239 00:45:50,940 --> 00:45:53,129 domain specific language. 1240 00:45:53,130 --> 00:45:55,799 And to make things interesting for you. 1241 00:45:55,800 --> 00:45:57,419 I wanted to know, have you ever heard of 1242 00:45:57,420 --> 00:45:59,039 Brain Fuck? 1243 00:45:59,040 --> 00:46:00,749 It's like this fun Turing complete 1244 00:46:00,750 --> 00:46:02,879 language that only has eight 1245 00:46:02,880 --> 00:46:03,869 different symbols. 1246 00:46:03,870 --> 00:46:06,089 You can you can move a data 1247 00:46:06,090 --> 00:46:07,049 point or forward. 1248 00:46:07,050 --> 00:46:09,149 You can move a data point or backward. 1249 00:46:09,150 --> 00:46:11,279 You can increase the value 1250 00:46:11,280 --> 00:46:12,959 on the current cell. 1251 00:46:12,960 --> 00:46:14,879 You can decrease the value on the current 1252 00:46:14,880 --> 00:46:16,739 cell. You can write a character to the 1253 00:46:16,740 --> 00:46:18,809 screen, you can get a character and 1254 00:46:18,810 --> 00:46:20,249 you can jump conditionally back and 1255 00:46:20,250 --> 00:46:21,250 force. 1256 00:46:21,810 --> 00:46:24,569 There's a former string statement for 1257 00:46:24,570 --> 00:46:27,299 the incrementing the data pointer 1258 00:46:27,300 --> 00:46:30,659 diclemente the data pointer, adding, 1259 00:46:30,660 --> 00:46:33,119 subtracting, adding 1260 00:46:33,120 --> 00:46:34,120 character. 1261 00:46:37,750 --> 00:46:39,369 And even going back and forth, 1262 00:46:41,680 --> 00:46:43,989 depending on the 1263 00:46:43,990 --> 00:46:46,209 implementation of PRINTF, you can 1264 00:46:46,210 --> 00:46:48,639 overwrites this format, string 1265 00:46:48,640 --> 00:46:50,739 the format string counter and reset and 1266 00:46:50,740 --> 00:46:52,719 jump around in the in the format string, 1267 00:46:54,550 --> 00:46:57,129 which is what makes it 1268 00:46:57,130 --> 00:46:59,259 dependent on the Lipsy version that you 1269 00:46:59,260 --> 00:47:01,239 currently use to make things a little bit 1270 00:47:01,240 --> 00:47:03,669 easier. We assume that 1271 00:47:04,750 --> 00:47:06,909 we can we can call printf 1272 00:47:06,910 --> 00:47:09,069 in a loop. So we basically either 1273 00:47:09,070 --> 00:47:10,869 have to look at the current 1274 00:47:10,870 --> 00:47:13,119 implementation of printf 1275 00:47:13,120 --> 00:47:15,429 in the lipsey and overwrite this printf 1276 00:47:15,430 --> 00:47:17,589 internal data Vali's by using arbitrary 1277 00:47:17,590 --> 00:47:19,839 memory. Right. Or we just have to find 1278 00:47:19,840 --> 00:47:22,089 a loop that loops printf 1279 00:47:22,090 --> 00:47:23,409 in the current program, 1280 00:47:24,490 --> 00:47:26,649 which we can usually do 1281 00:47:26,650 --> 00:47:29,139 by in 1282 00:47:29,140 --> 00:47:31,089 many of the programs that we looked at. 1283 00:47:31,090 --> 00:47:33,939 And we can, we can break the 1284 00:47:33,940 --> 00:47:36,429 brain fuck interpretor into a simple 1285 00:47:36,430 --> 00:47:38,649 fach, execute and retire 1286 00:47:38,650 --> 00:47:40,749 loop that keeps executing 1287 00:47:40,750 --> 00:47:42,879 by just calling Printemps one 1288 00:47:42,880 --> 00:47:44,529 after the other. 1289 00:47:44,530 --> 00:47:46,659 So let me present 1290 00:47:46,660 --> 00:47:48,759 to you a short demo 1291 00:47:48,760 --> 00:47:51,129 on how we can translate arbitrary 1292 00:47:51,130 --> 00:47:53,769 brainwork programs into print statements 1293 00:47:53,770 --> 00:47:55,989 and then execute brain fuck by 1294 00:47:55,990 --> 00:47:57,859 just doing a call to a single print 1295 00:47:57,860 --> 00:47:58,860 printf. 1296 00:48:04,180 --> 00:48:05,739 So I have a set of. 1297 00:48:09,240 --> 00:48:11,529 Small brain 1298 00:48:11,530 --> 00:48:13,189 programs. 1299 00:48:13,190 --> 00:48:16,039 And let's just start with 1300 00:48:16,040 --> 00:48:18,319 the Fibonacci thing, this 1301 00:48:18,320 --> 00:48:20,419 this is a small brainwork program that 1302 00:48:20,420 --> 00:48:22,820 just calculates Fibonacci programs. 1303 00:48:26,990 --> 00:48:29,269 Let's compiled the program 1304 00:48:29,270 --> 00:48:30,489 and we do have a. 1305 00:48:39,270 --> 00:48:40,270 Small. 1306 00:48:42,200 --> 00:48:43,699 The screen is a little bit small, but 1307 00:48:44,810 --> 00:48:46,939 I've shown the GetUp page that 1308 00:48:46,940 --> 00:48:49,039 you can download the programs 1309 00:48:49,040 --> 00:48:50,869 yourself and try them out. 1310 00:48:59,770 --> 00:49:01,869 So we do run the printer 1311 00:49:01,870 --> 00:49:04,599 Fibonacci program in a single 1312 00:49:04,600 --> 00:49:07,419 print statement, and we are generating 1313 00:49:07,420 --> 00:49:09,669 different forms of Fibonacci Fibonacci 1314 00:49:09,670 --> 00:49:11,739 numbers and this is just a print 1315 00:49:11,740 --> 00:49:14,079 statement that we keep executing 1316 00:49:14,080 --> 00:49:16,659 and we keep executing this this brainwork 1317 00:49:16,660 --> 00:49:18,399 program to just generate numbers. 1318 00:49:19,560 --> 00:49:21,330 But there's another fun program that's. 1319 00:49:26,730 --> 00:49:28,769 There's another fun program ever heard 1320 00:49:28,770 --> 00:49:29,770 of. 1321 00:49:31,550 --> 00:49:33,019 Ninety nine bottles of beer. 1322 00:49:37,250 --> 00:49:39,889 It's a little bit longer program. 1323 00:49:41,740 --> 00:49:44,319 So let's just execute 1324 00:49:44,320 --> 00:49:46,079 this this program and see what it does. 1325 00:49:50,030 --> 00:49:52,009 And interestingly, you see that it gets 1326 00:49:52,010 --> 00:49:53,809 faster as you're drinking more and more 1327 00:49:53,810 --> 00:49:55,879 beer, as you're counting down the numbers 1328 00:49:55,880 --> 00:49:57,679 and printing out the values, it gets 1329 00:49:57,680 --> 00:49:58,750 much, much, much faster. 1330 00:50:00,470 --> 00:50:02,659 There's also a game of life in there 1331 00:50:02,660 --> 00:50:05,509 that you can play around with, there's a 1332 00:50:05,510 --> 00:50:08,149 Mandelbrot fractal and 1333 00:50:08,150 --> 00:50:09,150 a. 1334 00:50:11,580 --> 00:50:13,199 Sarah Pinski trying all that, you can 1335 00:50:13,200 --> 00:50:15,329 print all part in a 1336 00:50:15,330 --> 00:50:16,829 in a single print statement. 1337 00:50:18,650 --> 00:50:20,209 So there's there's a lot of fun that you 1338 00:50:20,210 --> 00:50:22,429 can do with this this interpreter 1339 00:50:22,430 --> 00:50:24,649 and it's open 1340 00:50:24,650 --> 00:50:26,599 source, you can use it, you can download 1341 00:50:26,600 --> 00:50:28,729 it, you can play around with it 1342 00:50:28,730 --> 00:50:29,730 and. 1343 00:50:30,510 --> 00:50:32,759 It is available from 1344 00:50:32,760 --> 00:50:35,189 today on, so go around, 1345 00:50:35,190 --> 00:50:36,899 play with it, play with detouring 1346 00:50:36,900 --> 00:50:39,609 completeness and. 1347 00:50:39,610 --> 00:50:40,829 Let's see what happens. 1348 00:50:43,140 --> 00:50:45,469 So let me conclude, 1349 00:50:45,470 --> 00:50:47,939 low level languages are here to stay 1350 00:50:47,940 --> 00:50:49,979 and these low level languages are full of 1351 00:50:49,980 --> 00:50:51,059 potential. 1352 00:50:51,060 --> 00:50:53,129 And as I've just shown, even with a 1353 00:50:53,130 --> 00:50:56,009 single call to printf that 1354 00:50:56,010 --> 00:50:58,349 can either be executed 1355 00:50:58,350 --> 00:51:00,869 in a loop or by 1356 00:51:00,870 --> 00:51:02,459 looking at the printf internal 1357 00:51:02,460 --> 00:51:04,799 implementation, you can wrap around 1358 00:51:04,800 --> 00:51:06,989 and show the full potential of 1359 00:51:06,990 --> 00:51:09,299 these low level programing languages. 1360 00:51:09,300 --> 00:51:11,159 And Bizerte machines are hiding 1361 00:51:11,160 --> 00:51:13,379 everywhere out there and there's a single 1362 00:51:13,380 --> 00:51:14,459 memory corruption. 1363 00:51:14,460 --> 00:51:16,199 So if you do have either a formal string 1364 00:51:16,200 --> 00:51:18,299 vulnerability or a memory corruption that 1365 00:51:18,300 --> 00:51:20,489 allows you to control the first 1366 00:51:20,490 --> 00:51:22,619 argument to print, if you can get 1367 00:51:22,620 --> 00:51:24,899 a Turing complete interpreter that allows 1368 00:51:24,900 --> 00:51:27,239 you to inject your own little program 1369 00:51:28,470 --> 00:51:30,599 without Steck integrity, the defenses 1370 00:51:30,600 --> 00:51:32,429 that we will add are broken and we have 1371 00:51:32,430 --> 00:51:34,559 to add STAC integrity, but 1372 00:51:34,560 --> 00:51:36,269 even mistake integrity. 1373 00:51:36,270 --> 00:51:37,409 The attacker can still 1374 00:51:38,730 --> 00:51:40,529 still do a lot of fun stuff. 1375 00:51:40,530 --> 00:51:42,809 And I encourage you to play 1376 00:51:42,810 --> 00:51:45,599 around with Vista code that we've added. 1377 00:51:45,600 --> 00:51:47,579 There's a simple Python script that 1378 00:51:47,580 --> 00:51:49,170 allows you to translate 1379 00:51:50,730 --> 00:51:53,129 the any brainwork program 1380 00:51:53,130 --> 00:51:55,199 into a longer 1381 00:51:55,200 --> 00:51:57,119 format string and a simple program. 1382 00:51:57,120 --> 00:51:58,839 The format strings are out there. 1383 00:51:58,840 --> 00:52:00,719 Go around and have fun. 1384 00:52:00,720 --> 00:52:01,720 Thank you. 1385 00:52:11,970 --> 00:52:14,219 Thank you. Yes, we have some minutes 1386 00:52:14,220 --> 00:52:16,379 for questions, if any, so we got 1387 00:52:16,380 --> 00:52:17,380 some microphones here. 1388 00:52:18,750 --> 00:52:19,779 Any questions? 1389 00:52:19,780 --> 00:52:22,319 Are you OK? 1390 00:52:22,320 --> 00:52:24,749 So go home, play with Prenter, 1391 00:52:26,820 --> 00:52:27,820 OK, I'll be around. 1392 00:52:29,460 --> 00:52:30,460 I have. 1393 00:52:31,920 --> 00:52:32,920 Pleco. 1394 00:52:34,690 --> 00:52:37,539 Yes, hello, hello is working, 1395 00:52:37,540 --> 00:52:39,809 OK, so think of it. 1396 00:52:39,810 --> 00:52:40,899 Very good presentation. 1397 00:52:40,900 --> 00:52:42,549 I have a small question. 1398 00:52:42,550 --> 00:52:45,159 You use person turn in your printer for 1399 00:52:45,160 --> 00:52:47,199 programing, but in some implementations 1400 00:52:47,200 --> 00:52:48,099 it's disabled. 1401 00:52:48,100 --> 00:52:49,389 Do you have any workarounds? 1402 00:52:50,750 --> 00:52:52,259 There's only person and that gives you 1403 00:52:52,260 --> 00:52:53,260 memory writes. 1404 00:52:54,710 --> 00:52:56,809 So the in any of 1405 00:52:56,810 --> 00:52:59,089 the lip that we've seen, it's 1406 00:52:59,090 --> 00:53:01,399 enabled so that there are obscure, in 1407 00:53:01,400 --> 00:53:03,349 fact, that Microsoft is disabled by 1408 00:53:03,350 --> 00:53:05,419 default, you have to call a special 1409 00:53:05,420 --> 00:53:06,689 function to enable it. 1410 00:53:06,690 --> 00:53:07,690 Yeah. 1411 00:53:08,640 --> 00:53:09,640 Thank you. 1412 00:53:11,440 --> 00:53:14,139 Please leave or stay silent. 1413 00:53:14,140 --> 00:53:15,619 Thank you. 1414 00:53:15,620 --> 00:53:17,689 Yes, so I was wondering, I recently 1415 00:53:17,690 --> 00:53:19,789 saw some discussion and you go closer to 1416 00:53:19,790 --> 00:53:20,829 the microphone, please. 1417 00:53:20,830 --> 00:53:22,069 Lolo, can you hear me? 1418 00:53:22,070 --> 00:53:24,439 Yeah. So I recently saw some discussions 1419 00:53:24,440 --> 00:53:26,539 about, um, on the mill 1420 00:53:26,540 --> 00:53:28,639 about something called Safe Steck 1421 00:53:28,640 --> 00:53:29,749 where they. 1422 00:53:29,750 --> 00:53:31,439 Yeah. I'm one of the officers. 1423 00:53:31,440 --> 00:53:33,349 Oh. OK. I was going to ask your opinion 1424 00:53:33,350 --> 00:53:35,029 on it but it's good to make it, it's 1425 00:53:35,030 --> 00:53:36,030 great. 1426 00:53:38,630 --> 00:53:40,789 There's, we released an earlier version 1427 00:53:40,790 --> 00:53:43,039 at OASDI. I said the current 1428 00:53:43,040 --> 00:53:45,109 version that made it into LVM is a 1429 00:53:45,110 --> 00:53:47,299 little bit restricted and it's 1430 00:53:47,300 --> 00:53:49,639 mostly geared as a as a debugging tool. 1431 00:53:49,640 --> 00:53:52,459 But the underlying idea is to 1432 00:53:52,460 --> 00:53:54,079 give you a tool that allows you to 1433 00:53:54,080 --> 00:53:56,149 predict Steck frames and give you STAC 1434 00:53:56,150 --> 00:53:58,429 integrity without any overhead. 1435 00:53:58,430 --> 00:53:59,719 So I think it's great. 1436 00:53:59,720 --> 00:54:01,999 It's a it's it's a it's a great tool 1437 00:54:02,000 --> 00:54:04,339 and it should make it into LVM 1438 00:54:04,340 --> 00:54:06,359 without all the additional overhead. 1439 00:54:06,360 --> 00:54:07,939 Yeah, I think it's awesome. 1440 00:54:07,940 --> 00:54:09,349 So thumbs up. 1441 00:54:09,350 --> 00:54:10,350 Thanks. 1442 00:54:12,610 --> 00:54:14,089 OK, thanks again. 1443 00:54:14,090 --> 00:54:15,090 Yes. 1444 00:54:15,490 --> 00:54:18,129 See you soon. So we're back here in 14 1445 00:54:18,130 --> 00:54:19,539 minutes for console hacking. 1446 00:54:19,540 --> 00:54:20,540 Thank you.