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/179 Thanks! 1 00:00:12,720 --> 00:00:14,069 Thanks for the introduction. 2 00:00:14,070 --> 00:00:16,229 It's good to be back in this in 3 00:00:16,230 --> 00:00:17,230 this room, 4 00:00:17,790 --> 00:00:20,309 I guess all of you know that 5 00:00:20,310 --> 00:00:20,639 memory 6 00:00:20,640 --> 00:00:22,589 corruption attacks are real and they 7 00:00:22,590 --> 00:00:24,239 have a long past. 8 00:00:25,470 --> 00:00:27,659 In this talk, we're going to work 9 00:00:27,660 --> 00:00:29,279 through the different kinds of memory 10 00:00:29,280 --> 00:00:30,629 corruption. 11 00:00:30,630 --> 00:00:31,469 What kind of 12 00:00:31,470 --> 00:00:33,569 passes an attacker can follow to 13 00:00:33,570 --> 00:00:35,310 exploit a memory vulnerability? 14 00:00:36,960 --> 00:00:37,829 And we'll also look 15 00:00:37,830 --> 00:00:39,899 at what kind of different defenses 16 00:00:39,900 --> 00:00:42,299 have to have been proposed in the last 30 17 00:00:42,300 --> 00:00:44,399 or 40 years of software development. 18 00:00:44,400 --> 00:00:46,079 And we'll also discuss why most of these 19 00:00:46,080 --> 00:00:48,359 defenses can be circumvented easily 20 00:00:48,360 --> 00:00:49,559 in just 21 00:00:49,560 --> 00:00:50,849 a couple of steps. 22 00:00:50,850 --> 00:00:53,099 So all these memory corruptions actually 23 00:00:53,100 --> 00:00:55,529 led to an arms race between attackers 24 00:00:55,530 --> 00:00:57,299 and defenders. 25 00:00:57,300 --> 00:00:59,469 And in the movie war games where you 26 00:00:59,470 --> 00:01:01,349 see in the background here, we are told 27 00:01:01,350 --> 00:01:02,849 that the only winning move is not 28 00:01:02,850 --> 00:01:04,348 to play, but well, we 29 00:01:04,349 --> 00:01:05,518 are hackers, right? 30 00:01:05,519 --> 00:01:07,259 So maybe we can change the rules of the 31 00:01:07,260 --> 00:01:09,989 game to actually win nevertheless, 32 00:01:09,990 --> 00:01:11,969 and we'll see how we can do that later 33 00:01:11,970 --> 00:01:12,970 on. 34 00:01:13,260 --> 00:01:15,180 So to start off with some numbers 35 00:01:16,950 --> 00:01:18,629 to convince you that memory corruption is 36 00:01:18,630 --> 00:01:20,909 actually a real thing if you just look at 37 00:01:20,910 --> 00:01:22,949 vulnerability classes, according to the 38 00:01:22,950 --> 00:01:24,119 list of common vulnerabilities and 39 00:01:24,120 --> 00:01:26,369 exposures on the x axis, 40 00:01:26,370 --> 00:01:28,589 we see two years from ninety nine. 41 00:01:28,590 --> 00:01:30,689 Then the data collection was started 42 00:01:30,690 --> 00:01:31,139 to 43 00:01:31,140 --> 00:01:32,140 last year 44 00:01:33,690 --> 00:01:35,849 and we grouped different kinds 45 00:01:35,850 --> 00:01:38,249 of vulnerabilities, according to 46 00:01:38,250 --> 00:01:39,250 a set of factors. 47 00:01:40,500 --> 00:01:43,019 And we see that there's just like a ton 48 00:01:43,020 --> 00:01:45,209 of attacks out there, even though we've 49 00:01:45,210 --> 00:01:47,219 been rolling out defense mechanism after 50 00:01:47,220 --> 00:01:49,319 defense mechanism after defense mechanism 51 00:01:49,320 --> 00:01:50,999 and academia has proposed like two 52 00:01:51,000 --> 00:01:53,309 hundred different defense mechanisms 53 00:01:53,310 --> 00:01:55,349 that are out there that haven't been 54 00:01:55,350 --> 00:01:57,599 adopted yet. And we'll also look into 55 00:01:57,600 --> 00:01:59,129 why these mechanisms have not been 56 00:01:59,130 --> 00:02:00,130 adopted. 57 00:02:01,080 --> 00:02:03,239 So these memory 58 00:02:03,240 --> 00:02:05,309 war or this war in memory is an 59 00:02:05,310 --> 00:02:06,779 ongoing war. 60 00:02:06,780 --> 00:02:08,999 And the problem inherently 61 00:02:09,000 --> 00:02:11,339 lies in the way how we write software 62 00:02:13,470 --> 00:02:14,819 so low level 63 00:02:14,820 --> 00:02:17,339 languages like C or C++, 64 00:02:17,340 --> 00:02:18,029 that 65 00:02:18,030 --> 00:02:20,129 trait type safety and memory safety 66 00:02:20,130 --> 00:02:22,199 for potential performance and study 67 00:02:22,200 --> 00:02:23,159 can get. 68 00:02:23,160 --> 00:02:25,349 So all the 69 00:02:25,350 --> 00:02:25,919 checks that 70 00:02:25,920 --> 00:02:27,779 are executed during the runtime of the 71 00:02:27,780 --> 00:02:30,149 application are completely in the control 72 00:02:30,150 --> 00:02:32,309 of the programmer, and the programmer 73 00:02:32,310 --> 00:02:34,619 can add or remove checks at 74 00:02:34,620 --> 00:02:37,229 his or her convenience. 75 00:02:37,230 --> 00:02:38,310 And well, 76 00:02:39,480 --> 00:02:41,879 the problem is that often 77 00:02:41,880 --> 00:02:42,089 these 78 00:02:42,090 --> 00:02:43,859 programmers forgets to add these checks, 79 00:02:43,860 --> 00:02:47,039 and this will lead to a whole set of bugs 80 00:02:47,040 --> 00:02:48,809 in addition to all the other high level 81 00:02:48,810 --> 00:02:50,999 bugs that exist in the software as well. 82 00:02:51,000 --> 00:02:53,399 And also, there's a large set of legacy 83 00:02:53,400 --> 00:02:55,499 code and new applications written in 84 00:02:55,500 --> 00:02:57,689 C and C++ that are prone to memory 85 00:02:57,690 --> 00:02:59,819 bugs. Let's just look at the 86 00:02:59,820 --> 00:03:01,739 Google Chrome browser. 87 00:03:01,740 --> 00:03:02,489 A software, 88 00:03:02,490 --> 00:03:04,349 a big software project that has just been 89 00:03:04,350 --> 00:03:06,029 started a couple of years ago. 90 00:03:06,030 --> 00:03:06,779 It's written 91 00:03:06,780 --> 00:03:08,279 in a kind 92 00:03:08,280 --> 00:03:10,259 of stripped down version of C++ that's 93 00:03:10,260 --> 00:03:11,549 very close to C, 94 00:03:11,550 --> 00:03:13,349 and it's it gets 95 00:03:13,350 --> 00:03:15,569 only four to six times 96 00:03:15,570 --> 00:03:15,839 each 97 00:03:15,840 --> 00:03:16,769 year. 98 00:03:16,770 --> 00:03:17,309 And that's 99 00:03:17,310 --> 00:03:19,289 supposed to be high quality code that has 100 00:03:19,290 --> 00:03:20,759 been just started a couple of 101 00:03:20,760 --> 00:03:21,869 years ago. 102 00:03:21,870 --> 00:03:24,719 And that clearly shows that we have no 103 00:03:24,720 --> 00:03:26,819 way how to to get around that problem and 104 00:03:26,820 --> 00:03:27,599 how to fix 105 00:03:27,600 --> 00:03:28,600 it right now. 106 00:03:30,060 --> 00:03:31,319 In addition, there 107 00:03:31,320 --> 00:03:33,539 are way too many bugs out there 108 00:03:33,540 --> 00:03:34,919 to find and fix manually. 109 00:03:37,110 --> 00:03:38,110 There's 110 00:03:39,810 --> 00:03:40,409 there's way 111 00:03:40,410 --> 00:03:42,659 too much code and so many bugs 112 00:03:42,660 --> 00:03:44,369 out there that we need some additional 113 00:03:44,370 --> 00:03:46,529 services and defense mechanisms that 114 00:03:46,530 --> 00:03:47,909 actually contains these 115 00:03:47,910 --> 00:03:50,159 bugs. So it's still a very 116 00:03:50,160 --> 00:03:51,749 valid 117 00:03:51,750 --> 00:03:53,879 approach to actually go, find and fix 118 00:03:53,880 --> 00:03:55,289 the bugs that are in there. 119 00:03:55,290 --> 00:03:57,689 But it's not feasible to protect the 120 00:03:57,690 --> 00:04:00,119 security of our systems by just fixing 121 00:04:00,120 --> 00:04:01,709 these bugs one after one because it would 122 00:04:01,710 --> 00:04:04,139 take way too much, way too much time. 123 00:04:04,140 --> 00:04:05,369 We need an additional approach 124 00:04:05,370 --> 00:04:06,370 that protects 125 00:04:08,040 --> 00:04:09,179 running software 126 00:04:09,180 --> 00:04:11,549 from attacks, even in the presence off 127 00:04:11,550 --> 00:04:13,259 of bugs in the software, and we'll look 128 00:04:13,260 --> 00:04:14,260 into that as well. 129 00:04:15,270 --> 00:04:18,028 So let's start with 130 00:04:18,029 --> 00:04:18,989 memory corruption. 131 00:04:18,990 --> 00:04:20,999 The root of of the problem that we are 132 00:04:21,000 --> 00:04:21,958 facing. 133 00:04:21,959 --> 00:04:24,119 And Andreas actually gave 134 00:04:24,120 --> 00:04:26,639 a very good talk a couple of days ago. 135 00:04:26,640 --> 00:04:28,889 Was it yesterday or two days ago, 136 00:04:28,890 --> 00:04:29,789 two days 137 00:04:29,790 --> 00:04:30,790 who seemed to talk 138 00:04:33,330 --> 00:04:34,330 OK about a. 139 00:04:35,070 --> 00:04:37,379 And he he gave a very good introduction 140 00:04:37,380 --> 00:04:39,299 into into memory corruption. 141 00:04:39,300 --> 00:04:41,429 And he told us that's the only 142 00:04:41,430 --> 00:04:43,689 winning option would be to 143 00:04:43,690 --> 00:04:44,909 recompile all our 144 00:04:44,910 --> 00:04:46,959 software with an 145 00:04:46,960 --> 00:04:49,289 extended C compiler that adds 146 00:04:49,290 --> 00:04:51,119 all these type checks on top of it. 147 00:04:51,120 --> 00:04:52,829 Well, all this stuff comes as an 148 00:04:52,830 --> 00:04:54,299 additional price tag of like two hundred 149 00:04:54,300 --> 00:04:56,609 and fifty percent performance drawback. 150 00:04:56,610 --> 00:04:58,979 So that might not be as feasible 151 00:04:58,980 --> 00:05:01,349 and if 152 00:05:01,350 --> 00:05:04,379 you want to compile any any regular code. 153 00:05:04,380 --> 00:05:05,380 So 154 00:05:06,660 --> 00:05:08,039 in this section, we're 155 00:05:08,040 --> 00:05:09,539 going to follow the same motivation like 156 00:05:09,540 --> 00:05:10,929 he had and we're going to enter. 157 00:05:10,930 --> 00:05:12,909 Use memory corruption, but using a more 158 00:05:12,910 --> 00:05:14,319 formal approach. 159 00:05:14,320 --> 00:05:16,209 So be systematic his these memory 160 00:05:16,210 --> 00:05:17,769 corruption into a model 161 00:05:17,770 --> 00:05:18,969 of 162 00:05:18,970 --> 00:05:20,889 poor memory attacks and defined security 163 00:05:20,890 --> 00:05:23,199 policies. On top of that model, 164 00:05:23,200 --> 00:05:25,329 that helps us classify different 165 00:05:25,330 --> 00:05:27,449 defense mechanism, according this 166 00:05:27,450 --> 00:05:28,450 this structure. 167 00:05:29,500 --> 00:05:31,059 So memory corruption 168 00:05:31,060 --> 00:05:33,459 on a very high level is an unintended 169 00:05:33,460 --> 00:05:35,589 modification of a memory location due to 170 00:05:35,590 --> 00:05:38,109 either a missing or a faulty, faulty 171 00:05:38,110 --> 00:05:40,239 safety check type check or anything 172 00:05:40,240 --> 00:05:42,909 like that. So the programmer forgot 173 00:05:42,910 --> 00:05:45,939 to add something that prohibits 174 00:05:45,940 --> 00:05:48,549 an attacker controlled inputs to modify 175 00:05:48,550 --> 00:05:50,739 some of our internal state of 176 00:05:50,740 --> 00:05:52,959 the program that might lead to 177 00:05:52,960 --> 00:05:55,029 some other follow up corruption. 178 00:05:55,030 --> 00:05:57,369 And I've I've shown a couple of lines 179 00:05:57,370 --> 00:05:59,259 of code in the bottom that shows a 180 00:05:59,260 --> 00:06:00,369 vulnerable function. 181 00:06:00,370 --> 00:06:02,529 And if the user is able 182 00:06:02,530 --> 00:06:04,659 to supply a specific value, 183 00:06:04,660 --> 00:06:06,819 the user can leave 184 00:06:06,820 --> 00:06:09,249 the bounds of the object that 185 00:06:09,250 --> 00:06:11,499 he or she is supposed to access and write 186 00:06:11,500 --> 00:06:12,609 anywhere into memory. 187 00:06:13,720 --> 00:06:15,789 And this is the core of 188 00:06:15,790 --> 00:06:17,549 any, any 189 00:06:17,550 --> 00:06:19,750 attraction that uses memory corruption. 190 00:06:21,730 --> 00:06:23,469 This bug is only exploitable if the 191 00:06:23,470 --> 00:06:25,269 address or the value is dependent on 192 00:06:25,270 --> 00:06:26,270 inputs. So if the 193 00:06:27,520 --> 00:06:29,619 attacker can craft a pass from the 194 00:06:29,620 --> 00:06:31,929 beginning of the execution or input flows 195 00:06:31,930 --> 00:06:33,369 into the program to the actual 196 00:06:33,370 --> 00:06:36,069 instruction, the dusty memory access 197 00:06:36,070 --> 00:06:38,169 and the attacker therefore 198 00:06:38,170 --> 00:06:40,269 sees all memory and we assume 199 00:06:40,270 --> 00:06:42,459 that the attacker can control all right 200 00:06:42,460 --> 00:06:44,589 memory using such and such an approach. 201 00:06:45,640 --> 00:06:47,299 So what is a let's 202 00:06:47,300 --> 00:06:49,089 splits this memory corruption attack into 203 00:06:49,090 --> 00:06:50,090 two different types? 204 00:06:51,220 --> 00:06:53,559 The first one is a temporal 205 00:06:53,560 --> 00:06:54,759 error 206 00:06:54,760 --> 00:06:57,189 where the uh, 207 00:06:57,190 --> 00:06:57,339 where 208 00:06:57,340 --> 00:06:59,529 we have a small, vulnerable function and 209 00:06:59,530 --> 00:07:01,149 at the beginning 210 00:07:01,150 --> 00:07:01,479 of the 211 00:07:01,480 --> 00:07:03,609 execution of the function, 212 00:07:03,610 --> 00:07:05,469 the pointer still points to the correct 213 00:07:05,470 --> 00:07:07,779 object and we run into a temporal 214 00:07:07,780 --> 00:07:08,679 error. 215 00:07:08,680 --> 00:07:10,899 If we freed up that object, which 216 00:07:10,900 --> 00:07:13,029 is perfectly fine, but later on, if the 217 00:07:13,030 --> 00:07:14,259 access that object. 218 00:07:17,690 --> 00:07:20,509 Then we get a memory corruption. 219 00:07:20,510 --> 00:07:22,669 And this could 220 00:07:22,670 --> 00:07:23,929 lead to some, maybe 221 00:07:23,930 --> 00:07:24,930 the 222 00:07:25,370 --> 00:07:26,989 memory allocator allocated some other 223 00:07:26,990 --> 00:07:28,339 memory in the background or some other 224 00:07:28,340 --> 00:07:30,229 object. I mean, you can use that box to 225 00:07:30,230 --> 00:07:31,369 overwrite that, 226 00:07:31,370 --> 00:07:32,370 that part of it. 227 00:07:34,430 --> 00:07:36,289 The other possible memory error is a 228 00:07:36,290 --> 00:07:37,759 spatial error. 229 00:07:37,760 --> 00:07:39,889 So something is 230 00:07:39,890 --> 00:07:41,779 a pointer is moving itself. 231 00:07:41,780 --> 00:07:43,759 The other one was a temporal error mode. 232 00:07:43,760 --> 00:07:46,099 A pointer is no longer here due to 233 00:07:46,100 --> 00:07:47,599 some change constraints during the 234 00:07:47,600 --> 00:07:49,129 execution of the program. 235 00:07:49,130 --> 00:07:51,289 And this this one is that the pointer 236 00:07:51,290 --> 00:07:52,549 itself moves along. 237 00:07:52,550 --> 00:07:54,199 So initially, 238 00:07:54,200 --> 00:07:56,299 two pointer points to a valid 239 00:07:56,300 --> 00:07:57,259 data point. 240 00:07:57,260 --> 00:07:59,119 It's used to write something and it's 241 00:07:59,120 --> 00:08:00,769 updated and later on. 242 00:08:00,770 --> 00:08:02,779 The pointer no longer points to the exact 243 00:08:02,780 --> 00:08:05,059 same object, but to a different 244 00:08:05,060 --> 00:08:06,349 one that is no longer valid. 245 00:08:06,350 --> 00:08:08,419 Maybe some found information or 246 00:08:08,420 --> 00:08:09,919 anything like that that can then be 247 00:08:09,920 --> 00:08:11,119 overwritten with 248 00:08:11,120 --> 00:08:12,049 the debug, and if 249 00:08:12,050 --> 00:08:13,729 that's attacker controlled, 250 00:08:14,990 --> 00:08:17,179 the attacker can use that as a first 251 00:08:17,180 --> 00:08:19,220 step to start the escalation process. 252 00:08:20,330 --> 00:08:22,609 So this is at the core 253 00:08:22,610 --> 00:08:24,079 of every attack, 254 00:08:24,080 --> 00:08:24,679 but what 255 00:08:24,680 --> 00:08:26,329 happens afterwards? 256 00:08:26,330 --> 00:08:28,519 So to discuss this part, we're going 257 00:08:28,520 --> 00:08:30,859 to look into the dominant attack 258 00:08:30,860 --> 00:08:33,649 vector that's used in these days for any 259 00:08:33,650 --> 00:08:35,928 software attacks that you see. 260 00:08:35,929 --> 00:08:37,639 Contraflow, high tech attacks 261 00:08:37,640 --> 00:08:39,798 are very common and basically 262 00:08:39,799 --> 00:08:42,058 the only or the biggest attack vector 263 00:08:42,059 --> 00:08:44,299 that's that's used today. 264 00:08:44,300 --> 00:08:46,399 And we'll look into the security policies 265 00:08:46,400 --> 00:08:49,009 and the defense mechanisms and follow 266 00:08:49,010 --> 00:08:51,409 each step that an attacker has to do to 267 00:08:51,410 --> 00:08:53,149 accomplish a contraflow hijack 268 00:08:53,150 --> 00:08:56,239 attack, given an example. 269 00:08:56,240 --> 00:08:58,369 So on a high level, 270 00:08:58,370 --> 00:08:58,969 we have 271 00:08:58,970 --> 00:08:59,689 a control flow 272 00:08:59,690 --> 00:09:00,799 graph 273 00:09:00,800 --> 00:09:02,929 with a set of basic blocks 274 00:09:02,930 --> 00:09:04,489 and the control flow 275 00:09:05,510 --> 00:09:05,959 flows 276 00:09:05,960 --> 00:09:07,999 from one basic block to the other. 277 00:09:08,000 --> 00:09:09,769 So let's assume it starts 278 00:09:11,120 --> 00:09:12,079 with the first basic 279 00:09:12,080 --> 00:09:14,359 block and then 280 00:09:14,360 --> 00:09:15,360 goes to the 281 00:09:16,760 --> 00:09:17,849 to the basic block. 282 00:09:17,850 --> 00:09:20,029 But now let's assume at a certain 283 00:09:20,030 --> 00:09:21,859 basic block, it ends with an indirect 284 00:09:21,860 --> 00:09:24,139 control flow transfer and the attacker 285 00:09:24,140 --> 00:09:26,479 is able to modify the code pointer 286 00:09:26,480 --> 00:09:28,009 that is used for that in their control 287 00:09:28,010 --> 00:09:29,299 for transfer somehow. 288 00:09:29,300 --> 00:09:31,189 So maybe the attacker can override an 289 00:09:31,190 --> 00:09:33,349 address on the on the stack, 290 00:09:33,350 --> 00:09:35,479 the return instruction pointer or 291 00:09:35,480 --> 00:09:37,159 overwrite the 292 00:09:37,160 --> 00:09:39,139 target address for the end, for an 293 00:09:39,140 --> 00:09:41,329 indirect jump or for an indirect 294 00:09:41,330 --> 00:09:42,649 call. 295 00:09:42,650 --> 00:09:44,419 Using that approach, the attacker can 296 00:09:44,420 --> 00:09:46,789 redirect the control flow from a valid 297 00:09:46,790 --> 00:09:49,879 control flow graph to a different, 298 00:09:49,880 --> 00:09:52,039 different part of the application 299 00:09:52,040 --> 00:09:54,109 that would never be reached otherwise. 300 00:09:54,110 --> 00:09:56,419 So the control flow of the software 301 00:09:56,420 --> 00:09:58,069 leaves the statically defined control 302 00:09:58,070 --> 00:10:00,139 flow graph and enters a 303 00:10:00,140 --> 00:10:01,759 new stage that would not be reached 304 00:10:01,760 --> 00:10:04,039 otherwise, which can be used 305 00:10:04,040 --> 00:10:06,199 to bootstrap something that's called or 306 00:10:06,200 --> 00:10:08,599 is called a beer machine. 307 00:10:08,600 --> 00:10:10,909 And then the attacker 308 00:10:10,910 --> 00:10:13,129 can reuse and continue to reuse existing 309 00:10:13,130 --> 00:10:15,289 codes, for example, using return oriented 310 00:10:15,290 --> 00:10:17,359 programing, chomp or into programing, 311 00:10:17,360 --> 00:10:18,859 or any of these other code reuse 312 00:10:18,860 --> 00:10:21,199 techniques, or even like in the old days, 313 00:10:21,200 --> 00:10:23,299 inject new code if there's if a 314 00:10:23,300 --> 00:10:25,489 page was readable 315 00:10:25,490 --> 00:10:26,690 and executed with permission. 316 00:10:27,920 --> 00:10:29,989 So on a on a high level, 317 00:10:29,990 --> 00:10:31,340 I want you to walk through 318 00:10:32,630 --> 00:10:33,259 a control flow 319 00:10:33,260 --> 00:10:35,389 hijack attack step by step and 320 00:10:35,390 --> 00:10:37,459 discuss the capabilities that an 321 00:10:37,460 --> 00:10:39,619 attacker actually needs to have 322 00:10:39,620 --> 00:10:41,599 to carry out the attacks and will then 323 00:10:41,600 --> 00:10:43,669 use these capabilities to discuss 324 00:10:43,670 --> 00:10:45,379 the different defense strategies. 325 00:10:45,380 --> 00:10:47,569 One step after the other so that we can 326 00:10:47,570 --> 00:10:49,369 see how we can refine and define 327 00:10:49,370 --> 00:10:50,840 different security policies 328 00:10:51,950 --> 00:10:53,779 after each other. So let's start the 329 00:10:53,780 --> 00:10:54,799 execution. 330 00:10:54,800 --> 00:10:56,390 Let's assume we restart 331 00:10:57,890 --> 00:10:59,929 the vulnerable function and we jump into 332 00:10:59,930 --> 00:11:01,609 that and we open up a new stack frame on 333 00:11:01,610 --> 00:11:02,610 the bottom. 334 00:11:03,260 --> 00:11:04,729 We start executing this vulnerable 335 00:11:04,730 --> 00:11:06,619 function, and we've allocated the 336 00:11:06,620 --> 00:11:08,129 argument to the vulnerable function on 337 00:11:08,130 --> 00:11:10,249 the stack. The return address, a 338 00:11:10,250 --> 00:11:12,589 safe base pointer and the compiler 339 00:11:12,590 --> 00:11:14,700 made space for the temporary error. 340 00:11:16,880 --> 00:11:19,099 As soon as we hit the vulnerable 341 00:11:19,100 --> 00:11:20,929 string copy function. 342 00:11:20,930 --> 00:11:22,999 The code starts copying 343 00:11:23,000 --> 00:11:24,679 data from an attacker controlled 344 00:11:25,730 --> 00:11:27,559 buffer into the 345 00:11:27,560 --> 00:11:29,869 stack array and built might 346 00:11:29,870 --> 00:11:31,189 overwrite the 347 00:11:31,190 --> 00:11:33,439 of the the other 348 00:11:33,440 --> 00:11:34,440 addresses. 349 00:11:35,570 --> 00:11:37,969 So if the attacker controls 350 00:11:37,970 --> 00:11:40,039 input is small enough to fit into the 351 00:11:40,040 --> 00:11:41,929 buffer, we don't care and everything is 352 00:11:41,930 --> 00:11:42,930 fine. 353 00:11:43,340 --> 00:11:46,069 If the attacker continues to write, 354 00:11:46,070 --> 00:11:46,249 we 355 00:11:46,250 --> 00:11:48,289 reach a memory safety violation, which is 356 00:11:48,290 --> 00:11:50,089 the first step that the attacker needs to 357 00:11:50,090 --> 00:11:51,679 be able to execute. 358 00:11:51,680 --> 00:11:54,289 So at this memory right instruction, 359 00:11:54,290 --> 00:11:55,519 the attacker needs to have the 360 00:11:55,520 --> 00:11:57,799 capabilities to circumvent the memory 361 00:11:57,800 --> 00:11:59,449 safety checks. So there must be a missing 362 00:11:59,450 --> 00:12:01,339 check somewhere, which is the very first 363 00:12:01,340 --> 00:12:03,559 SEC. As we continue 364 00:12:03,560 --> 00:12:04,189 in the next 365 00:12:04,190 --> 00:12:05,209 set, 366 00:12:05,210 --> 00:12:06,949 the attacker needs to circumvent the 367 00:12:06,950 --> 00:12:09,589 integrity of the code pointer itself. 368 00:12:09,590 --> 00:12:11,959 So only if the attacker can override 369 00:12:11,960 --> 00:12:13,429 the code pointer and is allowed to 370 00:12:13,430 --> 00:12:15,169 actually overwrite the code pointer 371 00:12:15,170 --> 00:12:17,409 detector can continuously attack. 372 00:12:17,410 --> 00:12:19,329 And in addition, the attacker 373 00:12:19,330 --> 00:12:20,679 actually needs to know 374 00:12:20,680 --> 00:12:22,659 with what value he or 375 00:12:22,660 --> 00:12:23,860 she needs to override 376 00:12:25,540 --> 00:12:26,949 the code pointer. 377 00:12:26,950 --> 00:12:28,689 So if the attacker doesn't know where the 378 00:12:28,690 --> 00:12:30,789 location of the system function in 379 00:12:30,790 --> 00:12:32,889 this case is, the attacker will not be 380 00:12:32,890 --> 00:12:35,259 able to succeed with the attack. 381 00:12:35,260 --> 00:12:37,029 And as the execution continues. 382 00:12:42,370 --> 00:12:44,589 People reach the return instruction and 383 00:12:44,590 --> 00:12:46,749 will reach the next step at their 384 00:12:46,750 --> 00:12:48,969 return instruction itself. 385 00:12:48,970 --> 00:12:50,109 The attacker needs to have the 386 00:12:50,110 --> 00:12:52,709 capabilities to actually execute 387 00:12:52,710 --> 00:12:54,969 the indirect contraflow transfer with 388 00:12:54,970 --> 00:12:57,039 a new is 389 00:12:57,040 --> 00:12:59,169 a new targets that would otherwise not be 390 00:12:59,170 --> 00:13:01,089 reached, and only if the attacker can 391 00:13:01,090 --> 00:13:03,909 circumvent all these checks 392 00:13:03,910 --> 00:13:05,889 or if these checks are missing, then the 393 00:13:05,890 --> 00:13:07,629 attacker will succeed with a contraflow, 394 00:13:07,630 --> 00:13:10,509 high tech attack on a high level. 395 00:13:10,510 --> 00:13:12,579 So all these steps are necessary 396 00:13:12,580 --> 00:13:14,619 for an attacker to succeed with an 397 00:13:14,620 --> 00:13:16,539 attack. So if you want to use retourner 398 00:13:16,540 --> 00:13:18,339 in the programing, we need to have all 399 00:13:18,340 --> 00:13:19,749 these capabilities and we need to have 400 00:13:19,750 --> 00:13:22,479 all that information to actually run it. 401 00:13:22,480 --> 00:13:23,829 And on the other hand, a defense 402 00:13:23,830 --> 00:13:26,019 mechanism can stop the attack at any 403 00:13:26,020 --> 00:13:28,149 of these steps as long as the attacker 404 00:13:28,150 --> 00:13:30,459 doesn't reach the bottom of the graph. 405 00:13:30,460 --> 00:13:32,709 The software is fine and the attack 406 00:13:32,710 --> 00:13:33,710 is not successful. 407 00:13:36,010 --> 00:13:38,979 Until recently, a very 408 00:13:38,980 --> 00:13:39,909 popular attack 409 00:13:39,910 --> 00:13:41,889 vector was 410 00:13:41,890 --> 00:13:42,189 coach. 411 00:13:42,190 --> 00:13:43,869 Corruption were actually code was 412 00:13:43,870 --> 00:13:44,979 rewritten, 413 00:13:44,980 --> 00:13:45,980 and 414 00:13:47,290 --> 00:13:49,599 I've actually read papers about that. 415 00:13:49,600 --> 00:13:51,819 Even nowadays, even though any 416 00:13:51,820 --> 00:13:54,039 processor or any CPU that I'm aware 417 00:13:54,040 --> 00:13:55,659 of nowadays has 418 00:13:57,850 --> 00:14:00,579 read only permissions and 419 00:14:00,580 --> 00:14:03,159 executable bits that can be used to 420 00:14:03,160 --> 00:14:05,289 restrict the right ability of many 421 00:14:05,290 --> 00:14:06,339 memory pages. 422 00:14:06,340 --> 00:14:07,340 So code 423 00:14:08,470 --> 00:14:10,629 an attacker can no longer inject code 424 00:14:10,630 --> 00:14:12,819 directly into the memory space of 425 00:14:12,820 --> 00:14:14,319 the application. 426 00:14:14,320 --> 00:14:16,509 So this attack is actually no 427 00:14:16,510 --> 00:14:17,859 longer a problem. 428 00:14:17,860 --> 00:14:19,929 But what's the big attack vector until 429 00:14:19,930 --> 00:14:21,859 the mid mid 2000s? 430 00:14:24,370 --> 00:14:26,769 So to to to close 431 00:14:26,770 --> 00:14:28,839 that part, the most 432 00:14:28,840 --> 00:14:31,059 common attack vector is our 433 00:14:31,060 --> 00:14:32,919 control flow. High tech attacks that 434 00:14:32,920 --> 00:14:35,319 reuse existing code inside the image 435 00:14:35,320 --> 00:14:37,479 of the application and code. 436 00:14:37,480 --> 00:14:39,729 Corruption attacks are no longer 437 00:14:39,730 --> 00:14:40,750 that much of a problem. 438 00:14:42,070 --> 00:14:44,229 And all the attacks that we've seen and 439 00:14:44,230 --> 00:14:46,629 in the beginning on the motivating slide 440 00:14:46,630 --> 00:14:48,370 are basically code corruption attacks. 441 00:14:49,390 --> 00:14:50,390 So 442 00:14:51,730 --> 00:14:52,239 what kind 443 00:14:52,240 --> 00:14:54,309 of defense strategy strategies have 444 00:14:54,310 --> 00:14:56,259 been proposed against his control for 445 00:14:56,260 --> 00:14:57,519 hijacking attacks? 446 00:14:57,520 --> 00:14:58,609 What's what's out there? 447 00:14:58,610 --> 00:15:00,309 What what can we do at each individual 448 00:15:00,310 --> 00:15:01,359 step? 449 00:15:01,360 --> 00:15:03,429 So on 450 00:15:03,430 --> 00:15:04,389 a first step 451 00:15:04,390 --> 00:15:06,039 on the memory safety step, we can 452 00:15:06,040 --> 00:15:07,839 actually stop the memory corruption from 453 00:15:07,840 --> 00:15:10,149 happening so we can look at each 454 00:15:10,150 --> 00:15:11,589 individual memory. 455 00:15:11,590 --> 00:15:13,569 Read a memory, right? 456 00:15:13,570 --> 00:15:15,219 If they violate 457 00:15:15,220 --> 00:15:17,739 some memory safety properties 458 00:15:17,740 --> 00:15:20,049 and like Andreas mentioned as well, 459 00:15:20,050 --> 00:15:22,329 they are safe dialect of C and C++ 460 00:15:22,330 --> 00:15:24,819 like secured or cyclone 461 00:15:24,820 --> 00:15:27,159 that actually enforce additional 462 00:15:27,160 --> 00:15:29,409 properties for each, 463 00:15:29,410 --> 00:15:30,490 each memory access. 464 00:15:31,720 --> 00:15:33,639 The drawback, of course, is that you need 465 00:15:33,640 --> 00:15:36,099 to rewrite your software in a 466 00:15:36,100 --> 00:15:37,569 in a in this new language, you need to 467 00:15:37,570 --> 00:15:40,269 constrain it to follow that pattern 468 00:15:40,270 --> 00:15:41,079 or you 469 00:15:41,080 --> 00:15:42,549 can retrofit. 470 00:15:42,550 --> 00:15:44,289 You can change to 471 00:15:44,290 --> 00:15:44,499 your 472 00:15:44,500 --> 00:15:46,839 compiler to add these additional checks 473 00:15:46,840 --> 00:15:48,699 automatically, whereas a possible 474 00:15:48,700 --> 00:15:51,099 performance degradation by using 475 00:15:51,100 --> 00:15:53,140 the soft bound and CTS approach. 476 00:15:54,610 --> 00:15:56,979 So in general, memory 477 00:15:56,980 --> 00:15:58,989 and forcing memory safety is considered 478 00:15:58,990 --> 00:16:00,220 to be too expensive. 479 00:16:01,630 --> 00:16:03,369 If you want memory safety, you could 480 00:16:03,370 --> 00:16:05,619 actually rewrite the software in a type 481 00:16:05,620 --> 00:16:08,049 safe and memory safe language like C or 482 00:16:08,050 --> 00:16:08,379 like 483 00:16:08,380 --> 00:16:10,569 Java or C Sharp, 484 00:16:10,570 --> 00:16:11,889 which would be 485 00:16:11,890 --> 00:16:14,319 much more convenient to 486 00:16:14,320 --> 00:16:16,179 instead of rewriting it in a language 487 00:16:16,180 --> 00:16:18,429 that supported arbitrary memory accesses 488 00:16:18,430 --> 00:16:18,879 in the first 489 00:16:18,880 --> 00:16:20,619 place and 490 00:16:20,620 --> 00:16:21,620 more natural that way. 491 00:16:23,980 --> 00:16:26,889 So rewriting in a safe language is 492 00:16:26,890 --> 00:16:28,389 the safest option. 493 00:16:28,390 --> 00:16:30,549 But while we still have this 494 00:16:30,550 --> 00:16:32,499 large set of legacy code, so we should 495 00:16:32,500 --> 00:16:34,119 look into a defense strategy that's 496 00:16:34,120 --> 00:16:36,339 actually feasible if 497 00:16:36,340 --> 00:16:37,749 he goes to the next step. 498 00:16:37,750 --> 00:16:39,579 We can enforce the integrity 499 00:16:39,580 --> 00:16:41,589 of a large 500 00:16:41,590 --> 00:16:43,649 set of read and write. 501 00:16:43,650 --> 00:16:45,639 So there 502 00:16:45,640 --> 00:16:47,589 are there's a large set of code pointers 503 00:16:47,590 --> 00:16:50,559 that's out there, and we can enforce 504 00:16:50,560 --> 00:16:50,679 the 505 00:16:50,680 --> 00:16:52,899 integrity of just code pointers by 506 00:16:52,900 --> 00:16:55,179 restricting it to 507 00:16:55,180 --> 00:16:57,459 specific security checks 508 00:16:57,460 --> 00:16:59,589 that are added either on the compiler 509 00:16:59,590 --> 00:17:01,749 side or at one 510 00:17:01,750 --> 00:17:04,059 one part of the runtime side. 511 00:17:04,060 --> 00:17:06,279 So there is right integrity testing 512 00:17:06,280 --> 00:17:08,588 that checks all the different memory 513 00:17:08,589 --> 00:17:10,509 rights and checks it checks them, 514 00:17:10,510 --> 00:17:11,510 according to a 515 00:17:12,550 --> 00:17:13,059 Points two 516 00:17:13,060 --> 00:17:14,889 graph that's that remain at compile 517 00:17:14,890 --> 00:17:15,818 time. 518 00:17:15,819 --> 00:17:18,219 And there's, of course, data execution 519 00:17:18,220 --> 00:17:20,649 prevention and readable XOR executable 520 00:17:20,650 --> 00:17:22,389 for code, which is kind of an integrity 521 00:17:22,390 --> 00:17:24,819 check for for just the code pages itself. 522 00:17:26,349 --> 00:17:29,679 The next step are probabilistic defenses. 523 00:17:29,680 --> 00:17:30,009 You can 524 00:17:30,010 --> 00:17:32,889 shuffle around all that stuff in memory 525 00:17:32,890 --> 00:17:34,869 and hope that the attacker will not be 526 00:17:34,870 --> 00:17:36,609 able to find out what 527 00:17:36,610 --> 00:17:38,189 kind of bird 528 00:17:38,190 --> 00:17:40,389 locations of your code are 529 00:17:40,390 --> 00:17:42,019 if detect. Who doesn't know where to jump 530 00:17:42,020 --> 00:17:44,059 to then he or she will have a hard time 531 00:17:44,060 --> 00:17:45,500 to succeed this the actual attack. 532 00:17:46,550 --> 00:17:47,550 And as the last step, 533 00:17:49,610 --> 00:17:50,269 there's 534 00:17:50,270 --> 00:17:52,369 flow integrity, for example, control flow 535 00:17:52,370 --> 00:17:55,099 integrity or data flow integrity 536 00:17:55,100 --> 00:17:57,349 that protects control flow transfers 537 00:17:57,350 --> 00:17:59,540 from one code location to the next one. 538 00:18:00,770 --> 00:18:03,259 So data flow integrity checks for 539 00:18:03,260 --> 00:18:04,969 what kind of buffers or what, what 540 00:18:04,970 --> 00:18:07,099 happens on a high level and control 541 00:18:07,100 --> 00:18:09,649 flow integrity only looks at the indirect 542 00:18:09,650 --> 00:18:11,749 control flow transfer, and we 543 00:18:11,750 --> 00:18:13,819 can add defense mechanisms 544 00:18:13,820 --> 00:18:15,019 that each of key steps 545 00:18:17,000 --> 00:18:17,599 the 546 00:18:17,600 --> 00:18:19,639 hottest currently discussed defense 547 00:18:19,640 --> 00:18:21,949 mechanism in academia is control 548 00:18:21,950 --> 00:18:23,059 flow integrity. 549 00:18:23,060 --> 00:18:24,979 So I want to go a little bit more into 550 00:18:24,980 --> 00:18:27,079 detail how this defense mechanism 551 00:18:27,080 --> 00:18:28,080 would actually work. 552 00:18:28,880 --> 00:18:31,819 The idea behind this defense mechanism 553 00:18:31,820 --> 00:18:33,919 is that you restrict 554 00:18:33,920 --> 00:18:36,109 all the control flow transfers to 555 00:18:36,110 --> 00:18:38,209 a statically determined graph of 556 00:18:38,210 --> 00:18:40,639 valid contraflow transfers. 557 00:18:40,640 --> 00:18:42,949 So at compile time, you run 558 00:18:42,950 --> 00:18:46,159 a points through analysis and you check. 559 00:18:46,160 --> 00:18:48,589 You get a statically determined 560 00:18:48,590 --> 00:18:49,159 control flow 561 00:18:49,160 --> 00:18:50,929 graph and 562 00:18:50,930 --> 00:18:53,149 each control flow location 563 00:18:53,150 --> 00:18:55,189 you check if the target 564 00:18:55,190 --> 00:18:56,899 is in the set 565 00:18:56,900 --> 00:18:57,739 of valid 566 00:18:57,740 --> 00:18:59,449 control flow transfers points. 567 00:18:59,450 --> 00:19:01,189 So let's say you are at the end of basic 568 00:19:01,190 --> 00:19:03,829 Block two, as shown on the slide. 569 00:19:03,830 --> 00:19:06,139 And according 570 00:19:06,140 --> 00:19:08,239 to the Static Control Flow Graph, we have 571 00:19:08,240 --> 00:19:10,549 two possible options where we can jump to 572 00:19:10,550 --> 00:19:12,439 at runtime. The add an additional check 573 00:19:12,440 --> 00:19:14,539 and see if it's either basic Block two 574 00:19:14,540 --> 00:19:16,789 or basic Block three if it's a different 575 00:19:16,790 --> 00:19:17,719 basic block. 576 00:19:17,720 --> 00:19:19,519 We can stop the and terminate the 577 00:19:19,520 --> 00:19:21,649 application with a memory 578 00:19:21,650 --> 00:19:22,099 or with 579 00:19:22,100 --> 00:19:23,749 a contraflow 580 00:19:23,750 --> 00:19:26,029 integrity violation and say that 581 00:19:26,030 --> 00:19:27,590 the attacker modified it somehow. 582 00:19:29,960 --> 00:19:32,179 But unfortunately, all the current 583 00:19:32,180 --> 00:19:34,369 implementations that are proposed and 584 00:19:34,370 --> 00:19:35,509 there are about 20 different 585 00:19:35,510 --> 00:19:37,279 implementations of contraflow integrity 586 00:19:37,280 --> 00:19:38,059 out there 587 00:19:38,060 --> 00:19:38,839 right now. 588 00:19:38,840 --> 00:19:40,579 All these implementations over 589 00:19:40,580 --> 00:19:42,649 approximate first of all, due to the 590 00:19:42,650 --> 00:19:44,749 static analysis at compile time, 591 00:19:44,750 --> 00:19:47,509 which is inherently imprecise because 592 00:19:47,510 --> 00:19:49,429 it doesn't consider runtime information 593 00:19:49,430 --> 00:19:51,559 or dynamically loaded code. 594 00:19:51,560 --> 00:19:53,689 And in addition to cut some corners and 595 00:19:53,690 --> 00:19:55,879 to get enough speed, 596 00:19:55,880 --> 00:19:58,249 they only have one set of indirect, 597 00:19:58,250 --> 00:19:59,719 indirect calls. 598 00:19:59,720 --> 00:20:01,819 One set of valid targets for each 599 00:20:01,820 --> 00:20:03,289 indirect called indirect trumps and 600 00:20:03,290 --> 00:20:04,519 return instructions. 601 00:20:04,520 --> 00:20:06,649 So again, if you're at the end of basic 602 00:20:06,650 --> 00:20:08,899 block number one, we see 603 00:20:08,900 --> 00:20:11,029 that according to the to the 604 00:20:11,030 --> 00:20:13,009 check, any of these 605 00:20:13,010 --> 00:20:15,079 very basic blocks would be a value 606 00:20:15,080 --> 00:20:17,179 transfer points, and the check would only 607 00:20:17,180 --> 00:20:18,859 ensure that you target 608 00:20:18,860 --> 00:20:21,199 actually a valid, valid basic 609 00:20:21,200 --> 00:20:23,269 block. But it would not ensure 610 00:20:23,270 --> 00:20:25,549 that it targets the only single one valid 611 00:20:25,550 --> 00:20:27,979 basic block that would be 612 00:20:27,980 --> 00:20:28,980 determined by 613 00:20:30,320 --> 00:20:31,999 the runtime information that you have. 614 00:20:33,500 --> 00:20:35,179 So what are the limitations and the 615 00:20:35,180 --> 00:20:37,189 drawbacks of these defense mechanisms? 616 00:20:37,190 --> 00:20:38,729 First of all, the precision is limited to 617 00:20:38,730 --> 00:20:40,639 the static analysis. 618 00:20:40,640 --> 00:20:43,099 All this imprecision leads ambiguities 619 00:20:43,100 --> 00:20:44,989 and other problems that you need to 620 00:20:44,990 --> 00:20:47,209 circumvent by adding a whole bunch 621 00:20:47,210 --> 00:20:50,299 of other stuff or losing precision. 622 00:20:50,300 --> 00:20:52,519 And most implementations choose 623 00:20:52,520 --> 00:20:54,499 to lose precision and end up with just 624 00:20:54,500 --> 00:20:56,689 one set of possible value targets. 625 00:20:56,690 --> 00:20:58,160 They enforce for every single 626 00:20:59,390 --> 00:21:01,339 possible targets. 627 00:21:01,340 --> 00:21:03,199 And other problem is that this static 628 00:21:03,200 --> 00:21:05,419 analysis must see all the code 629 00:21:05,420 --> 00:21:07,129 at the compile time. 630 00:21:07,130 --> 00:21:09,799 So support for dynamic libraries 631 00:21:09,800 --> 00:21:11,869 and dynamic loading and all that stuff 632 00:21:11,870 --> 00:21:13,729 becomes very challenging. 633 00:21:13,730 --> 00:21:15,889 So most sci fi solutions will not 634 00:21:15,890 --> 00:21:17,939 support shared libraries that are 635 00:21:17,940 --> 00:21:19,789 allotted dynamically at runtime, which is 636 00:21:19,790 --> 00:21:21,259 kind of a showstopper for current 637 00:21:21,260 --> 00:21:22,519 software 638 00:21:22,520 --> 00:21:23,520 on a 639 00:21:24,230 --> 00:21:25,339 regular Linux system. 640 00:21:25,340 --> 00:21:27,529 You cannot even link to Lipsy 641 00:21:27,530 --> 00:21:29,029 statically anymore. 642 00:21:29,030 --> 00:21:31,669 You have to link it as a 643 00:21:31,670 --> 00:21:32,599 as a shared library. 644 00:21:32,600 --> 00:21:34,759 Yeah, they drop that support a couple of 645 00:21:34,760 --> 00:21:36,980 years ago, and 646 00:21:39,680 --> 00:21:41,239 you're faced with the decision of either 647 00:21:41,240 --> 00:21:43,519 having performance overhead or additional 648 00:21:43,520 --> 00:21:44,630 imprecision in that area. 649 00:21:45,980 --> 00:21:48,289 So the current implementations all choose 650 00:21:48,290 --> 00:21:51,079 to have over approximation 651 00:21:51,080 --> 00:21:53,329 and loss of precision and 652 00:21:53,330 --> 00:21:55,729 end up with roughly five to 10 percent 653 00:21:55,730 --> 00:21:56,779 performance overhead. 654 00:21:59,150 --> 00:22:01,399 So this is currently 655 00:22:01,400 --> 00:22:03,889 the hottest, hottest alternative 656 00:22:03,890 --> 00:22:06,289 for defense mechanism because it already 657 00:22:06,290 --> 00:22:08,389 constrains the control flow 658 00:22:08,390 --> 00:22:09,829 just through the basic blocks that are 659 00:22:09,830 --> 00:22:11,479 out there. But it still has some 660 00:22:11,480 --> 00:22:13,460 drawbacks, and maybe we can get 661 00:22:14,630 --> 00:22:16,339 a finer notion of 662 00:22:16,340 --> 00:22:18,619 where we can set up new defense 663 00:22:18,620 --> 00:22:20,809 mechanisms that are more precise than 664 00:22:20,810 --> 00:22:21,949 this approach 665 00:22:21,950 --> 00:22:23,329 and actually have 666 00:22:23,330 --> 00:22:25,069 lower overhead because it's always kind 667 00:22:25,070 --> 00:22:26,569 of a compromise. 668 00:22:26,570 --> 00:22:26,989 But let's 669 00:22:26,990 --> 00:22:28,339 summarize the different, 670 00:22:29,660 --> 00:22:31,549 the different paths from the memory 671 00:22:31,550 --> 00:22:33,979 corruption down to the to the successful 672 00:22:33,980 --> 00:22:36,109 attack in a in a more general 673 00:22:36,110 --> 00:22:38,359 model, which allows us 674 00:22:38,360 --> 00:22:40,729 to classify the different attack 675 00:22:40,730 --> 00:22:42,419 and. Security policies. 676 00:22:42,420 --> 00:22:44,669 So again, we have our 677 00:22:44,670 --> 00:22:46,469 control flow, high tech attack that 678 00:22:46,470 --> 00:22:49,319 starts with a memory corruption first. 679 00:22:49,320 --> 00:22:51,029 The attacker has to control the memory 680 00:22:51,030 --> 00:22:52,979 corruption, then 681 00:22:52,980 --> 00:22:54,719 circumvent the integrity of the code 682 00:22:54,720 --> 00:22:57,059 pointer itself, circumvent 683 00:22:57,060 --> 00:22:59,219 the randomization and know the locations 684 00:22:59,220 --> 00:23:01,529 of code in the process 685 00:23:01,530 --> 00:23:03,599 image and then circumvent the control 686 00:23:03,600 --> 00:23:05,279 flow integrity checks 687 00:23:05,280 --> 00:23:06,280 at 688 00:23:06,810 --> 00:23:09,449 the indirect control flow transfer itself 689 00:23:09,450 --> 00:23:11,429 and other kind of attack that we quickly 690 00:23:11,430 --> 00:23:13,679 discussed as the code corruption attack 691 00:23:13,680 --> 00:23:15,749 that fits into this model as well. 692 00:23:15,750 --> 00:23:17,759 If the attacker just modifies the 693 00:23:17,760 --> 00:23:18,659 code 694 00:23:18,660 --> 00:23:20,759 and the randomization 695 00:23:20,760 --> 00:23:21,760 of the 696 00:23:22,440 --> 00:23:24,659 of the code layout, but 697 00:23:24,660 --> 00:23:25,139 we also 698 00:23:25,140 --> 00:23:27,599 have a large set of other attacks, namely 699 00:23:27,600 --> 00:23:29,879 data on the attacks that do not modify 700 00:23:29,880 --> 00:23:30,269 any 701 00:23:30,270 --> 00:23:32,369 of the of 702 00:23:32,370 --> 00:23:32,729 the order 703 00:23:32,730 --> 00:23:34,829 control flow data structures or the code 704 00:23:34,830 --> 00:23:37,379 itself. So we can actually copy 705 00:23:37,380 --> 00:23:39,809 all these boxes on the left hand side 706 00:23:39,810 --> 00:23:40,799 to the right hand side. 707 00:23:40,800 --> 00:23:43,109 And we can we can look into an 708 00:23:43,110 --> 00:23:45,419 attack that modifies data 709 00:23:45,420 --> 00:23:47,639 and data, locate 710 00:23:47,640 --> 00:23:50,099 and need to note the locations of data 711 00:23:50,100 --> 00:23:52,799 and data, location pointers 712 00:23:52,800 --> 00:23:54,869 and the data flow integrity 713 00:23:54,870 --> 00:23:57,029 as well, which kind of combines 714 00:23:57,030 --> 00:23:59,009 all the different steps and pass the 715 00:23:59,010 --> 00:24:01,169 attacker can take to 716 00:24:01,170 --> 00:24:03,239 to reach the bottom to actually 717 00:24:03,240 --> 00:24:04,739 execute some, some bad 718 00:24:04,740 --> 00:24:05,740 behavior. 719 00:24:06,390 --> 00:24:08,669 And the data only attacks are actually 720 00:24:08,670 --> 00:24:10,739 generalization, as code 721 00:24:10,740 --> 00:24:13,079 can just be seen as a subset of the data, 722 00:24:13,080 --> 00:24:14,849 and the code pointers are a subset of the 723 00:24:14,850 --> 00:24:15,959 data pointers. 724 00:24:15,960 --> 00:24:18,239 So the data side is 725 00:24:18,240 --> 00:24:20,309 the harder problem of the of 726 00:24:20,310 --> 00:24:21,310 the left hand side. 727 00:24:22,410 --> 00:24:24,509 And if you look at data 728 00:24:24,510 --> 00:24:25,679 on the attacks, 729 00:24:25,680 --> 00:24:26,699 the attacker 730 00:24:26,700 --> 00:24:29,549 is only able to modify 731 00:24:29,550 --> 00:24:29,999 part 732 00:24:30,000 --> 00:24:32,099 of the heap or off the stack and 733 00:24:32,100 --> 00:24:34,259 inject data values there that are then 734 00:24:34,260 --> 00:24:36,479 interpreted that by the application in 735 00:24:36,480 --> 00:24:36,899 a different 736 00:24:36,900 --> 00:24:37,900 way. 737 00:24:38,190 --> 00:24:40,109 And these attacks are very simple but 738 00:24:40,110 --> 00:24:41,159 powerful. 739 00:24:41,160 --> 00:24:43,289 So imagine that the attacker 740 00:24:43,290 --> 00:24:45,829 is able to control the admin variable, 741 00:24:45,830 --> 00:24:48,989 an FTP server or something like that. 742 00:24:48,990 --> 00:24:50,909 The attacker can use that approach to 743 00:24:50,910 --> 00:24:52,529 change the control flow 744 00:24:52,530 --> 00:24:52,889 of the 745 00:24:52,890 --> 00:24:55,169 application, but by just changing 746 00:24:55,170 --> 00:24:56,219 the value 747 00:24:56,220 --> 00:24:58,379 of the of the data itself and not 748 00:24:58,380 --> 00:25:00,599 changing any of the code pointers 749 00:25:00,600 --> 00:25:02,579 and circumventing code pointer integrity 750 00:25:02,580 --> 00:25:05,249 or anything higher level like that 751 00:25:05,250 --> 00:25:07,409 and using just such a simple change in 752 00:25:07,410 --> 00:25:08,969 memory, the attacker can already 753 00:25:08,970 --> 00:25:10,529 circumvent many of the other 754 00:25:10,530 --> 00:25:11,530 checks. 755 00:25:12,390 --> 00:25:13,390 But we'll see 756 00:25:15,300 --> 00:25:15,779 more about 757 00:25:15,780 --> 00:25:16,829 this hard problem later 758 00:25:16,830 --> 00:25:17,830 on. 759 00:25:18,360 --> 00:25:20,429 So what kind of defenses 760 00:25:20,430 --> 00:25:22,499 are actually deployed out there? 761 00:25:22,500 --> 00:25:23,999 What is what is 762 00:25:24,000 --> 00:25:25,049 the state of the art? 763 00:25:25,050 --> 00:25:27,509 How how far have become in the last 764 00:25:27,510 --> 00:25:29,249 20 years of research and defense 765 00:25:29,250 --> 00:25:30,250 mechanisms? 766 00:25:31,770 --> 00:25:33,059 Well, only a few 767 00:25:33,060 --> 00:25:35,279 of those have seen widespread use, 768 00:25:35,280 --> 00:25:37,499 and they'll look at each of those 769 00:25:37,500 --> 00:25:39,659 individual defenses and see how it 770 00:25:39,660 --> 00:25:41,639 handles different forms of attacks and 771 00:25:41,640 --> 00:25:44,089 how it fits into this model of attacks 772 00:25:44,090 --> 00:25:45,269 to be justified. 773 00:25:45,270 --> 00:25:47,279 And we can then see at which steps 774 00:25:47,280 --> 00:25:49,439 there's still something missing that we 775 00:25:49,440 --> 00:25:51,450 might be able to add on top of it. 776 00:25:52,770 --> 00:25:55,559 So the first 777 00:25:55,560 --> 00:25:57,599 and strongest protection that's currently 778 00:25:57,600 --> 00:26:00,779 in place is data execution prevention, 779 00:26:00,780 --> 00:26:01,049 which 780 00:26:01,050 --> 00:26:02,849 enforces the integrity of 781 00:26:02,850 --> 00:26:04,619 code on patch 782 00:26:04,620 --> 00:26:05,879 level granularity at all 783 00:26:05,880 --> 00:26:07,229 times. 784 00:26:07,230 --> 00:26:08,099 It's basically 785 00:26:08,100 --> 00:26:10,289 a hardware extension that adds an 786 00:26:10,290 --> 00:26:12,509 additional bit in the patch table 787 00:26:12,510 --> 00:26:14,759 that tells us or tell us the CPU 788 00:26:14,760 --> 00:26:15,629 if the 789 00:26:15,630 --> 00:26:17,819 stuff that is on that page 790 00:26:17,820 --> 00:26:19,979 is actually executable or just 791 00:26:19,980 --> 00:26:22,229 data and 792 00:26:22,230 --> 00:26:24,149 we can enforce 793 00:26:24,150 --> 00:26:24,779 by the 794 00:26:24,780 --> 00:26:26,969 loader and the kernel 795 00:26:26,970 --> 00:26:27,569 readable 796 00:26:27,570 --> 00:26:29,699 exe or executable patches so 797 00:26:29,700 --> 00:26:31,529 that a single page is either readable or 798 00:26:31,530 --> 00:26:33,779 executable, which mitigates against all 799 00:26:33,780 --> 00:26:35,909 the code corrupted attacks like dropping 800 00:26:35,910 --> 00:26:37,319 your shell code on the stack. 801 00:26:37,320 --> 00:26:39,209 That's no longer possible if the if the 802 00:26:39,210 --> 00:26:41,459 stack itself is not executable. 803 00:26:41,460 --> 00:26:43,679 And the nice thing is it has very 804 00:26:43,680 --> 00:26:44,699 low overheads 805 00:26:44,700 --> 00:26:46,799 like zero percent its hardware 806 00:26:46,800 --> 00:26:49,499 enforced and it's widely deployed. 807 00:26:49,500 --> 00:26:50,500 So 808 00:26:53,190 --> 00:26:53,819 but unfortunately, 809 00:26:53,820 --> 00:26:55,919 it has limitations as well. 810 00:26:55,920 --> 00:26:58,079 So, for example, it doesn't support 811 00:26:58,080 --> 00:27:00,329 self modifying code or any dynamically 812 00:27:00,330 --> 00:27:02,279 generated code as soon as you want a 813 00:27:02,280 --> 00:27:04,499 cheat compiler like for your JavaScript 814 00:27:04,500 --> 00:27:06,809 engine or for you or for your Java 815 00:27:06,810 --> 00:27:08,939 engine. You actually need memory pages 816 00:27:08,940 --> 00:27:10,919 that are both readable and executable, 817 00:27:10,920 --> 00:27:12,630 which leads to two other problems. 818 00:27:15,450 --> 00:27:17,069 But nevertheless, it's a very strong 819 00:27:17,070 --> 00:27:19,289 protection that enforces to the code 820 00:27:19,290 --> 00:27:21,059 integrity for the code that is protected 821 00:27:21,060 --> 00:27:23,279 that way. And let's see how it 822 00:27:23,280 --> 00:27:25,499 actually fits into the memory model. 823 00:27:25,500 --> 00:27:27,689 So it completely closes this attack 824 00:27:27,690 --> 00:27:29,669 vector on the very left hand side, where 825 00:27:29,670 --> 00:27:31,199 an attacker can override 826 00:27:31,200 --> 00:27:32,429 code 827 00:27:32,430 --> 00:27:34,349 in memory or add additional code in 828 00:27:34,350 --> 00:27:36,509 memory and completely protects us 829 00:27:36,510 --> 00:27:38,009 from this code corruption attack. 830 00:27:38,010 --> 00:27:40,509 And the only thing that remains is. 831 00:27:40,510 --> 00:27:42,209 A controversial high tech attack or data 832 00:27:42,210 --> 00:27:42,449 only 833 00:27:42,450 --> 00:27:43,919 attack, but we've got 834 00:27:43,920 --> 00:27:45,269 other defenses, right? 835 00:27:45,270 --> 00:27:46,650 So let's look at those as well. 836 00:27:48,390 --> 00:27:50,609 We've got air space layout randomization 837 00:27:50,610 --> 00:27:51,479 that has been 838 00:27:51,480 --> 00:27:52,480 called 839 00:27:53,790 --> 00:27:54,059 the 840 00:27:54,060 --> 00:27:56,399 new or has been introduced as a new 841 00:27:56,400 --> 00:27:58,709 and very powerful safety mechanism. 842 00:27:58,710 --> 00:28:00,749 And the idea is that it randomize us to 843 00:28:00,750 --> 00:28:03,419 locations of code and data regions 844 00:28:03,420 --> 00:28:05,099 all throughout the memory 845 00:28:05,100 --> 00:28:05,519 of an 846 00:28:05,520 --> 00:28:07,169 error you restart a program. 847 00:28:07,170 --> 00:28:09,239 And this is a probabilistic 848 00:28:09,240 --> 00:28:11,369 defense and it depends on the on 849 00:28:11,370 --> 00:28:13,529 the load or in both the OSes 850 00:28:13,530 --> 00:28:14,789 fall. 851 00:28:14,790 --> 00:28:17,099 A problem is that 852 00:28:17,100 --> 00:28:19,649 even though the attacker needs 853 00:28:19,650 --> 00:28:20,849 to 854 00:28:20,850 --> 00:28:22,919 find the location, this is 855 00:28:22,920 --> 00:28:24,629 actually not too hard 856 00:28:24,630 --> 00:28:26,309 because many 857 00:28:26,310 --> 00:28:28,409 applications contain some information 858 00:28:28,410 --> 00:28:29,429 leak 859 00:28:29,430 --> 00:28:31,409 and they'll tell you to point to 860 00:28:31,410 --> 00:28:32,879 offer of a 861 00:28:32,880 --> 00:28:34,139 specific object. 862 00:28:34,140 --> 00:28:35,579 For example, all JavaScript 863 00:28:35,580 --> 00:28:37,739 implementations returned 864 00:28:37,740 --> 00:28:39,059 the address of 865 00:28:39,060 --> 00:28:42,419 the of the object. 866 00:28:42,420 --> 00:28:44,489 If you just asked for the for the hash 867 00:28:44,490 --> 00:28:45,059 value of the 868 00:28:45,060 --> 00:28:46,559 object, because that's kind 869 00:28:46,560 --> 00:28:47,999 of a unique, unique value, 870 00:28:48,000 --> 00:28:49,000 right? 871 00:28:50,760 --> 00:28:52,229 And there are a whole bunch of these 872 00:28:52,230 --> 00:28:53,969 information leaks out there that can be 873 00:28:53,970 --> 00:28:55,559 can be exploited to gain additional 874 00:28:55,560 --> 00:28:56,560 information. 875 00:28:57,780 --> 00:29:00,029 So address space, layout, randomization 876 00:29:00,030 --> 00:29:01,859 and other randomization techniques. 877 00:29:01,860 --> 00:29:03,689 All these probabilistic techniques are 878 00:29:03,690 --> 00:29:06,149 very prone to information leaks. 879 00:29:06,150 --> 00:29:06,809 So instead of 880 00:29:06,810 --> 00:29:08,969 a one shot attack where we can attack 881 00:29:08,970 --> 00:29:11,219 the program or the application in one 882 00:29:11,220 --> 00:29:13,889 go, you get a two shot attack. 883 00:29:13,890 --> 00:29:16,109 So you first have to gain information 884 00:29:16,110 --> 00:29:18,179 about the application and then you can 885 00:29:18,180 --> 00:29:19,799 exploit it in the second step. 886 00:29:19,800 --> 00:29:20,909 And it's still not too 887 00:29:20,910 --> 00:29:22,259 hard, right? 888 00:29:22,260 --> 00:29:24,209 Maybe you have to find two bucks, but 889 00:29:24,210 --> 00:29:26,249 that's that's still doable. 890 00:29:26,250 --> 00:29:28,979 And in addition, at least on x86, 891 00:29:28,980 --> 00:29:31,609 a large set of code locations 892 00:29:31,610 --> 00:29:33,239 that remain static. 893 00:29:33,240 --> 00:29:35,099 Otherwise, you would get a more than 10 894 00:29:35,100 --> 00:29:37,049 percent performance impact. 895 00:29:37,050 --> 00:29:39,119 So the current Linux 896 00:29:39,120 --> 00:29:41,609 Aceler implementation still has large 897 00:29:41,610 --> 00:29:42,359 static control 898 00:29:42,360 --> 00:29:43,360 blocks 899 00:29:43,830 --> 00:29:45,839 for the for the main executable itself, 900 00:29:45,840 --> 00:29:47,099 for example. 901 00:29:47,100 --> 00:29:47,759 And if we 902 00:29:47,760 --> 00:29:49,649 would randomize 903 00:29:49,650 --> 00:29:52,199 that part as well, we would see a huge 904 00:29:53,400 --> 00:29:55,859 increase in performance overhead of 905 00:29:55,860 --> 00:29:58,379 more than 10 percent on average. 906 00:29:58,380 --> 00:29:58,799 And all the 907 00:29:58,800 --> 00:30:01,019 libraries there are already compilers 908 00:30:01,020 --> 00:30:02,669 position independent code 909 00:30:02,670 --> 00:30:04,859 so that the 910 00:30:04,860 --> 00:30:05,339 performance 911 00:30:05,340 --> 00:30:06,419 overhead comes 912 00:30:06,420 --> 00:30:07,420 from 913 00:30:09,240 --> 00:30:11,519 using an additional register for 914 00:30:11,520 --> 00:30:13,049 Re-look double code. 915 00:30:13,050 --> 00:30:14,249 So if you have 916 00:30:14,250 --> 00:30:14,699 codes 917 00:30:14,700 --> 00:30:16,859 that can be placed at any location in 918 00:30:16,860 --> 00:30:19,739 memory, you need to keep one register 919 00:30:19,740 --> 00:30:21,659 as a site that always keeps the base 920 00:30:21,660 --> 00:30:25,169 pointer off the of the current 921 00:30:25,170 --> 00:30:27,059 current code segment so that you can jump 922 00:30:27,060 --> 00:30:28,979 around in a code segment. 923 00:30:28,980 --> 00:30:31,229 If everything is at a static address like 924 00:30:31,230 --> 00:30:33,389 for the main executable, then you're fine 925 00:30:33,390 --> 00:30:34,949 because you don't need to keep that extra 926 00:30:34,950 --> 00:30:36,029 register. 927 00:30:36,030 --> 00:30:38,309 So if you tell the 928 00:30:38,310 --> 00:30:40,769 if you tell GTC to actually compile 929 00:30:40,770 --> 00:30:42,959 the code as relocated table, we see 930 00:30:42,960 --> 00:30:45,029 that for spec CPU benchmarks 931 00:30:45,030 --> 00:30:47,309 that I've shown here, you get a 932 00:30:47,310 --> 00:30:50,129 10 percent performance degradation, 933 00:30:50,130 --> 00:30:52,289 which is almost too costly for 934 00:30:52,290 --> 00:30:54,689 a for a security mechanism. 935 00:30:54,690 --> 00:30:57,359 So if we summarize 936 00:30:57,360 --> 00:30:59,999 this aerospace layout, randomization 937 00:31:00,000 --> 00:31:01,499 protection that we've got here, then we 938 00:31:01,500 --> 00:31:02,339 can see that, 939 00:31:02,340 --> 00:31:04,499 yeah, we've got some 940 00:31:04,500 --> 00:31:05,970 protection against 941 00:31:07,260 --> 00:31:09,569 the different forms of randomization. 942 00:31:09,570 --> 00:31:11,009 So both the 943 00:31:11,010 --> 00:31:11,969 locations of 944 00:31:11,970 --> 00:31:13,259 code gets 945 00:31:13,260 --> 00:31:15,509 randomized and the locations of data gets 946 00:31:15,510 --> 00:31:17,069 randomized, and both of those are 947 00:31:17,070 --> 00:31:19,229 scrambled around and it's 948 00:31:19,230 --> 00:31:21,449 harder for an attacker to 949 00:31:21,450 --> 00:31:23,669 to circumvent it as soon as the attacker 950 00:31:23,670 --> 00:31:24,929 learns the secret. 951 00:31:24,930 --> 00:31:26,969 So let's say you're attacking an Apache 952 00:31:26,970 --> 00:31:29,429 server and you crashed one threat 953 00:31:29,430 --> 00:31:30,809 and you got the information 954 00:31:30,810 --> 00:31:32,999 about the memory layout. 955 00:31:33,000 --> 00:31:34,199 You can use that information on the 956 00:31:34,200 --> 00:31:36,329 second threat because it's only 957 00:31:36,330 --> 00:31:38,849 randomized for each, for each process, 958 00:31:38,850 --> 00:31:39,850 but not for each threat. 959 00:31:42,130 --> 00:31:44,259 The last security mechanism that's out 960 00:31:44,260 --> 00:31:46,689 there are stacked canneries 961 00:31:46,690 --> 00:31:48,579 which protect the return instruction 962 00:31:48,580 --> 00:31:51,009 pointer on this deck, and it's a compiler 963 00:31:51,010 --> 00:31:52,959 based modification, and the compiler 964 00:31:52,960 --> 00:31:55,689 changes to stack layouts during 965 00:31:55,690 --> 00:31:57,999 the during 966 00:31:58,000 --> 00:31:59,289 the compilation. 967 00:31:59,290 --> 00:32:01,479 It's also probabilistic 968 00:32:01,480 --> 00:32:03,459 probabilistic protection as the compiler 969 00:32:03,460 --> 00:32:05,559 places a secret cookie 970 00:32:05,560 --> 00:32:07,559 next to a buffer that could be 971 00:32:08,890 --> 00:32:09,279 could be 972 00:32:09,280 --> 00:32:11,559 overrun by some, some 973 00:32:11,560 --> 00:32:13,449 missing integrity checks. 974 00:32:13,450 --> 00:32:14,829 And again, it's probabilistic. 975 00:32:14,830 --> 00:32:16,869 As soon as the attacker knows that 976 00:32:16,870 --> 00:32:18,369 cookie, the attacker can place that 977 00:32:18,370 --> 00:32:20,859 cookie and in the exploit 978 00:32:20,860 --> 00:32:23,019 and just circumvent the protection 979 00:32:23,020 --> 00:32:24,999 easily or the attacker can use it 980 00:32:25,000 --> 00:32:26,019 directed right? 981 00:32:27,100 --> 00:32:29,079 If it's not a continuous buffer, buffer 982 00:32:29,080 --> 00:32:31,119 overflow and circumvent the stack cookie 983 00:32:31,120 --> 00:32:33,279 that way, so there's no protection 984 00:32:33,280 --> 00:32:34,660 against targeted reader rights. 985 00:32:35,710 --> 00:32:36,699 But again, 986 00:32:36,700 --> 00:32:38,859 if you look into our model, we 987 00:32:38,860 --> 00:32:41,679 see that these stacked cookies protect 988 00:32:41,680 --> 00:32:42,549 a subset 989 00:32:42,550 --> 00:32:43,599 of all 990 00:32:43,600 --> 00:32:45,279 code pointers, namely the return 991 00:32:45,280 --> 00:32:47,619 instruction pointers with a very weak 992 00:32:47,620 --> 00:32:48,970 probabilistic protection. 993 00:32:50,710 --> 00:32:53,529 And that's basically all we have. 994 00:32:53,530 --> 00:32:55,509 So we don't have any protection against 995 00:32:55,510 --> 00:32:57,549 memory safety, corruption or memory 996 00:32:57,550 --> 00:32:57,909 safety 997 00:32:57,910 --> 00:32:59,739 errors, and we only have 998 00:32:59,740 --> 00:33:02,319 very limited and partial protection 999 00:33:02,320 --> 00:33:05,169 against any integrity violations. 1000 00:33:05,170 --> 00:33:05,799 So we do have 1001 00:33:05,800 --> 00:33:07,899 code integrity, which is a very good 1002 00:33:07,900 --> 00:33:10,239 thing and can be used to actually 1003 00:33:10,240 --> 00:33:12,309 build up much stronger defenses on 1004 00:33:12,310 --> 00:33:13,809 top of it. 1005 00:33:13,810 --> 00:33:17,049 But we don't have code pointer integrity 1006 00:33:17,050 --> 00:33:17,589 that is 1007 00:33:17,590 --> 00:33:20,319 effective against any randomization 1008 00:33:20,320 --> 00:33:21,669 attacks or 1009 00:33:21,670 --> 00:33:24,189 other other possible attacks, 1010 00:33:24,190 --> 00:33:24,579 and we don't 1011 00:33:24,580 --> 00:33:25,689 have any data integrity, 1012 00:33:25,690 --> 00:33:26,690 either. 1013 00:33:27,400 --> 00:33:29,789 Randomization is partially implemented. 1014 00:33:29,790 --> 00:33:31,299 We do have air space layout 1015 00:33:31,300 --> 00:33:33,159 randomization, but there are also 1016 00:33:33,160 --> 00:33:34,869 a bunch of other randomization schemes 1017 00:33:34,870 --> 00:33:36,099 that have been proposed 1018 00:33:36,100 --> 00:33:38,409 in in academia. 1019 00:33:38,410 --> 00:33:39,129 A drawback of 1020 00:33:39,130 --> 00:33:41,739 those is that many have a high, 1021 00:33:41,740 --> 00:33:42,069 higher 1022 00:33:42,070 --> 00:33:44,229 performance overhead of 10 or 1023 00:33:44,230 --> 00:33:45,230 more percent. 1024 00:33:46,880 --> 00:33:48,649 And we don't have any 1025 00:33:48,650 --> 00:33:50,569 control flow or data flow integrity 1026 00:33:50,570 --> 00:33:52,699 solutions that are implemented in this 1027 00:33:52,700 --> 00:33:53,149 in this current 1028 00:33:53,150 --> 00:33:54,379 system. 1029 00:33:54,380 --> 00:33:54,919 So if 1030 00:33:54,920 --> 00:33:56,659 you look at the model and combine all the 1031 00:33:56,660 --> 00:33:58,609 different defenses that we have, we see 1032 00:33:58,610 --> 00:34:00,409 that well, we have code corruption 1033 00:34:00,410 --> 00:34:01,339 protection, 1034 00:34:01,340 --> 00:34:02,340 which is a good thing. 1035 00:34:03,500 --> 00:34:06,289 We have stacked can risk that somehow 1036 00:34:06,290 --> 00:34:07,939 protect the return instruction pointers 1037 00:34:07,940 --> 00:34:08,928 on the stack, 1038 00:34:08,929 --> 00:34:09,979 which is not too bad, 1039 00:34:09,980 --> 00:34:11,809 right? It's at least something, and it's 1040 00:34:11,810 --> 00:34:13,069 cheap 1041 00:34:13,070 --> 00:34:13,669 and we 1042 00:34:13,670 --> 00:34:15,888 have a asla which randomized 1043 00:34:15,889 --> 00:34:17,988 us the locations of code and data 1044 00:34:17,989 --> 00:34:18,769 throughout the 1045 00:34:18,770 --> 00:34:19,729 application. 1046 00:34:19,730 --> 00:34:20,479 So we do it. 1047 00:34:20,480 --> 00:34:21,649 It looks like we have a decent 1048 00:34:21,650 --> 00:34:22,789 protection, right? 1049 00:34:22,790 --> 00:34:25,099 But all of these security mechanisms, 1050 00:34:25,100 --> 00:34:27,468 even if used in combinations, 1051 00:34:27,469 --> 00:34:30,229 can still be circumvented by using 1052 00:34:30,230 --> 00:34:31,549 techniques like return or into 1053 00:34:31,550 --> 00:34:32,809 programing. 1054 00:34:32,810 --> 00:34:34,820 And well, it looks like 1055 00:34:36,290 --> 00:34:36,408 the 1056 00:34:36,409 --> 00:34:38,359 defense mechanisms that we are using on 1057 00:34:38,360 --> 00:34:40,488 current systems are just not enough, 1058 00:34:40,489 --> 00:34:42,559 and we need to come up with something 1059 00:34:42,560 --> 00:34:44,479 that's better and that's stronger than 1060 00:34:44,480 --> 00:34:45,480 what we already have. 1061 00:34:46,639 --> 00:34:48,709 So you might ask, 1062 00:34:48,710 --> 00:34:49,039 why 1063 00:34:49,040 --> 00:34:51,738 did these stronger defenses fail? 1064 00:34:51,739 --> 00:34:54,138 Did we have more than a hundred 1065 00:34:54,139 --> 00:34:56,269 different alternatives that we 1066 00:34:56,270 --> 00:34:58,489 could just implement right away? 1067 00:34:58,490 --> 00:34:59,149 But all 1068 00:34:59,150 --> 00:35:01,879 of them failed due to a couple of reasons 1069 00:35:01,880 --> 00:35:03,619 or have not been been used to do a couple 1070 00:35:03,620 --> 00:35:05,809 of reasons. Well, first of all, they 1071 00:35:05,810 --> 00:35:07,849 have too much overhead. 1072 00:35:07,850 --> 00:35:09,529 If a defense mechanism has more than 10 1073 00:35:09,530 --> 00:35:10,999 percent overhead, 1074 00:35:11,000 --> 00:35:11,209 or 1075 00:35:11,210 --> 00:35:13,249 even if they have 10 percent overhead, 1076 00:35:13,250 --> 00:35:13,729 they're not going 1077 00:35:13,730 --> 00:35:15,069 to be used in 1078 00:35:15,070 --> 00:35:16,309 in the wild, right? 1079 00:35:16,310 --> 00:35:18,379 You're already using a C compiler, 1080 00:35:18,380 --> 00:35:19,639 and you're so happy. 1081 00:35:19,640 --> 00:35:21,499 If your C compiler gets a two percent 1082 00:35:21,500 --> 00:35:23,299 performance improvement, then you're not 1083 00:35:23,300 --> 00:35:25,369 going to give up like 200 percent just to 1084 00:35:25,370 --> 00:35:27,739 run it vis a vis a Type C version. 1085 00:35:27,740 --> 00:35:29,569 Otherwise, you would have implemented 1086 00:35:29,570 --> 00:35:31,699 your software in a type safe language in 1087 00:35:31,700 --> 00:35:32,700 the first place. 1088 00:35:35,580 --> 00:35:38,159 Or the next option is that 1089 00:35:38,160 --> 00:35:40,589 many of these defense mechanisms 1090 00:35:40,590 --> 00:35:42,869 lose compatibility to legacy and source 1091 00:35:42,870 --> 00:35:44,009 code. 1092 00:35:44,010 --> 00:35:46,889 So many systems 1093 00:35:46,890 --> 00:35:48,809 needs to have a static compilation. 1094 00:35:48,810 --> 00:35:50,699 For example, most of these contraflow 1095 00:35:50,700 --> 00:35:52,979 integrity solutions, they need to see all 1096 00:35:52,980 --> 00:35:55,139 the code at compile time, which leads to 1097 00:35:55,140 --> 00:35:57,089 statically executable, 1098 00:35:57,090 --> 00:36:00,389 static statically compiled executable. 1099 00:36:00,390 --> 00:36:02,639 And is this just not 1100 00:36:02,640 --> 00:36:04,659 feasible together with 1101 00:36:04,660 --> 00:36:05,819 shared library support? 1102 00:36:07,140 --> 00:36:09,149 In addition, a whole bunch of 1103 00:36:09,150 --> 00:36:11,219 defense mechanisms that rely on source 1104 00:36:11,220 --> 00:36:12,989 code modifications. 1105 00:36:12,990 --> 00:36:14,969 And if you have 200 million lines of 1106 00:36:14,970 --> 00:36:16,589 code, you're not going 1107 00:36:16,590 --> 00:36:18,899 to rewrite them in a in a safe language 1108 00:36:18,900 --> 00:36:21,059 of other safe version of your 1109 00:36:21,060 --> 00:36:23,069 of your sort of your programing 1110 00:36:23,070 --> 00:36:24,070 language. 1111 00:36:25,020 --> 00:36:26,579 And the last step or the 1112 00:36:26,580 --> 00:36:28,019 last reason why they have not been 1113 00:36:28,020 --> 00:36:29,020 adopted is 1114 00:36:29,610 --> 00:36:30,659 the 1115 00:36:30,660 --> 00:36:33,809 strong defense mechanisms need to 1116 00:36:33,810 --> 00:36:34,139 have 1117 00:36:34,140 --> 00:36:36,329 effectiveness against a large set of 1118 00:36:36,330 --> 00:36:38,159 attacks and the need to protect against 1119 00:36:38,160 --> 00:36:40,499 complete classes of attacks and not just 1120 00:36:40,500 --> 00:36:42,689 against the tiny little version of it. 1121 00:36:42,690 --> 00:36:44,849 So to summarize, defense mechanism 1122 00:36:44,850 --> 00:36:45,989 must be cheap. 1123 00:36:45,990 --> 00:36:47,669 They must be compatible to legacy and 1124 00:36:47,670 --> 00:36:49,259 source code, and this should be 1125 00:36:49,260 --> 00:36:50,260 effective. 1126 00:36:51,660 --> 00:36:53,939 So where do we go from 1127 00:36:53,940 --> 00:36:55,019 now? 1128 00:36:55,020 --> 00:36:57,030 What kind of options do we have? 1129 00:36:58,140 --> 00:37:00,299 We've seen that attackers are still 1130 00:37:00,300 --> 00:37:02,669 more powerful than defenders, and 1131 00:37:02,670 --> 00:37:04,769 defense mechanism mechanisms have a hard 1132 00:37:04,770 --> 00:37:07,769 time of getting a top adopted 1133 00:37:07,770 --> 00:37:10,289 and and 1134 00:37:10,290 --> 00:37:11,789 working into in the first place. 1135 00:37:12,840 --> 00:37:14,549 So there are several approaches that we 1136 00:37:14,550 --> 00:37:17,279 can do. We can change the compiler. 1137 00:37:17,280 --> 00:37:18,689 We can change to 1138 00:37:18,690 --> 00:37:19,690 the language 1139 00:37:20,580 --> 00:37:22,529 itself. Or we can change the runtime 1140 00:37:22,530 --> 00:37:23,819 system. 1141 00:37:23,820 --> 00:37:25,889 And let's quickly discuss 1142 00:37:25,890 --> 00:37:28,739 these three options one after the other. 1143 00:37:28,740 --> 00:37:29,740 So 1144 00:37:31,380 --> 00:37:33,779 memory safety or having memory safety 1145 00:37:33,780 --> 00:37:35,939 would be an awesome treat to 1146 00:37:35,940 --> 00:37:37,649 protect our software. 1147 00:37:37,650 --> 00:37:39,899 Unfortunately, if you just run 1148 00:37:39,900 --> 00:37:41,879 cell phones together with CTS, which 1149 00:37:41,880 --> 00:37:44,129 gives us some strong 1150 00:37:44,130 --> 00:37:47,609 form of memory safety for C and C++ 1151 00:37:47,610 --> 00:37:49,319 programs, we see that we have a 1152 00:37:49,320 --> 00:37:51,479 performance overhead of up to 250 1153 00:37:51,480 --> 00:37:53,759 percent, which is way too 1154 00:37:53,760 --> 00:37:55,919 much to run for commodity 1155 00:37:55,920 --> 00:37:56,999 software. 1156 00:37:57,000 --> 00:37:59,099 Imagine running your browser 1157 00:37:59,100 --> 00:38:00,449 with a two hundred and fifty percent 1158 00:38:00,450 --> 00:38:01,450 overhead. 1159 00:38:03,990 --> 00:38:05,669 But what we can do 1160 00:38:05,670 --> 00:38:06,569 is 1161 00:38:06,570 --> 00:38:08,759 we can try to enforce memory safety for 1162 00:38:08,760 --> 00:38:10,979 some pointers, just a subset 1163 00:38:10,980 --> 00:38:13,409 of the pointers, maybe not for all data, 1164 00:38:13,410 --> 00:38:15,899 but we can if we can somehow select 1165 00:38:15,900 --> 00:38:17,579 the amount of data that we actually want 1166 00:38:17,580 --> 00:38:18,599 to protect. 1167 00:38:18,600 --> 00:38:20,999 We could offer strong protection for this 1168 00:38:21,000 --> 00:38:23,189 subset of data without 1169 00:38:23,190 --> 00:38:25,409 taking control and protecting 1170 00:38:25,410 --> 00:38:27,029 all the data that is out there, which 1171 00:38:27,030 --> 00:38:29,699 will just lead to too much overhead. 1172 00:38:29,700 --> 00:38:31,439 And Mel, 1173 00:38:31,440 --> 00:38:32,789 maybe compiler analysis 1174 00:38:32,790 --> 00:38:33,790 will help. 1175 00:38:34,620 --> 00:38:35,909 There will definitely be some tricky 1176 00:38:35,910 --> 00:38:37,679 engineering to to make it work, 1177 00:38:37,680 --> 00:38:38,680 especially 1178 00:38:39,900 --> 00:38:41,489 these shared libraries 1179 00:38:41,490 --> 00:38:43,409 that should be supported and so on. 1180 00:38:43,410 --> 00:38:45,689 So we'll need to look into that 1181 00:38:45,690 --> 00:38:45,869 and 1182 00:38:45,870 --> 00:38:47,969 we can also use a safe 1183 00:38:47,970 --> 00:38:49,319 runtime system, 1184 00:38:49,320 --> 00:38:50,969 so some form 1185 00:38:50,970 --> 00:38:53,099 of secure execution platform 1186 00:38:53,100 --> 00:38:55,289 that must support legacy code and binary 1187 00:38:55,290 --> 00:38:56,290 code itself. 1188 00:38:58,860 --> 00:39:01,379 One possible solution will be 1189 00:39:01,380 --> 00:39:03,449 binary translation that translates 1190 00:39:03,450 --> 00:39:05,879 the application as we go along and 1191 00:39:05,880 --> 00:39:08,369 kind of detects what kind of 1192 00:39:08,370 --> 00:39:10,589 data pointers are important, what kind 1193 00:39:10,590 --> 00:39:11,789 of data regions are 1194 00:39:11,790 --> 00:39:14,159 used for 1195 00:39:14,160 --> 00:39:16,739 control flow transfers and then protect 1196 00:39:16,740 --> 00:39:18,779 these data locations using additional 1197 00:39:18,780 --> 00:39:20,819 steps on top of it. 1198 00:39:20,820 --> 00:39:22,679 And we can leverage to run time 1199 00:39:22,680 --> 00:39:24,599 information, dynamically collect 1200 00:39:24,600 --> 00:39:27,059 information which enables us more 1201 00:39:27,060 --> 00:39:29,340 precise or security checks on top of it. 1202 00:39:30,450 --> 00:39:32,729 So what we can do on a high level, 1203 00:39:32,730 --> 00:39:34,919 we can rapidly running application 1204 00:39:34,920 --> 00:39:37,259 into a secure 1205 00:39:37,260 --> 00:39:39,329 runtime platform that kind 1206 00:39:39,330 --> 00:39:41,489 of keeps collects 1207 00:39:41,490 --> 00:39:43,709 information as the application goes along 1208 00:39:43,710 --> 00:39:45,809 and then enforces that information. 1209 00:39:45,810 --> 00:39:47,999 But just for the 1210 00:39:48,000 --> 00:39:49,589 for the privileged data 1211 00:39:49,590 --> 00:39:51,809 locations that we want to protect and not 1212 00:39:51,810 --> 00:39:53,609 for all the data locations that are out 1213 00:39:53,610 --> 00:39:55,949 there. So we have two little sandbox 1214 00:39:55,950 --> 00:39:58,169 that wraps the application and 1215 00:39:58,170 --> 00:40:00,329 we can control the interaction. 1216 00:40:00,330 --> 00:40:01,949 We can rely on 1217 00:40:01,950 --> 00:40:03,989 the information that is available from 1218 00:40:03,990 --> 00:40:06,389 the loader so we can infer 1219 00:40:06,390 --> 00:40:07,139 some form 1220 00:40:07,140 --> 00:40:08,579 of control 1221 00:40:08,580 --> 00:40:11,339 flow integrity policy by just extracting 1222 00:40:11,340 --> 00:40:12,689 all the information at the loader 1223 00:40:12,690 --> 00:40:13,769 provides us. 1224 00:40:13,770 --> 00:40:14,279 So all the 1225 00:40:14,280 --> 00:40:15,280 different, 1226 00:40:16,860 --> 00:40:18,929 different symbol tables can be used 1227 00:40:18,930 --> 00:40:21,179 to restrict and refine that possible. 1228 00:40:21,180 --> 00:40:23,789 Allow targets for the 1229 00:40:23,790 --> 00:40:25,949 control flow transfer transfers that 1230 00:40:25,950 --> 00:40:28,469 are executed inside the sandbox, 1231 00:40:28,470 --> 00:40:29,999 and we can also check the interaction 1232 00:40:30,000 --> 00:40:31,000 with the system. 1233 00:40:34,080 --> 00:40:35,399 If you guys don't know 1234 00:40:35,400 --> 00:40:36,400 what 1235 00:40:37,680 --> 00:40:38,039 binary 1236 00:40:38,040 --> 00:40:39,569 translation is, I want to give you a 1237 00:40:39,570 --> 00:40:42,059 quick highlight instead of executing 1238 00:40:42,060 --> 00:40:42,629 the original 1239 00:40:42,630 --> 00:40:43,679 code. 1240 00:40:43,680 --> 00:40:46,259 We add a small virtualization 1241 00:40:46,260 --> 00:40:48,359 system on top of it and 1242 00:40:48,360 --> 00:40:51,059 virtualized it in one additional step. 1243 00:40:51,060 --> 00:40:53,369 So code is not executed on the barebones 1244 00:40:53,370 --> 00:40:55,529 hardware, but we actually compile code as 1245 00:40:55,530 --> 00:40:57,899 we go along in a just in time compilation 1246 00:40:57,900 --> 00:40:59,999 process that dynamically checks the 1247 00:41:00,000 --> 00:41:02,099 targets and origins, 1248 00:41:02,100 --> 00:41:03,599 gets the information from the 1249 00:41:03,600 --> 00:41:05,069 loader, 1250 00:41:05,070 --> 00:41:07,409 refines that information and adds 1251 00:41:07,410 --> 00:41:09,659 a whole bunch of additional security 1252 00:41:09,660 --> 00:41:11,729 checks into the Protect the code that 1253 00:41:11,730 --> 00:41:12,749 is then executed 1254 00:41:15,420 --> 00:41:17,129 on the on the real hardware. 1255 00:41:17,130 --> 00:41:19,259 And therefore we can enforce 1256 00:41:19,260 --> 00:41:22,019 some form of dynamic security policy 1257 00:41:22,020 --> 00:41:24,420 on top of it without too much overhead. 1258 00:41:25,440 --> 00:41:27,629 And we'll actually see how how far 1259 00:41:27,630 --> 00:41:29,459 we can we can go with that approach 1260 00:41:29,460 --> 00:41:29,909 or 1261 00:41:29,910 --> 00:41:32,189 if we have to tap into the compiler 1262 00:41:32,190 --> 00:41:33,209 information as far. 1263 00:41:34,750 --> 00:41:35,750 So 1264 00:41:37,360 --> 00:41:38,379 what did we learn? 1265 00:41:38,380 --> 00:41:40,300 How far did we did we come 1266 00:41:41,620 --> 00:41:44,049 what what will be the result 1267 00:41:44,050 --> 00:41:45,050 of all of this? 1268 00:41:46,000 --> 00:41:48,159 Well, first of all, 1269 00:41:48,160 --> 00:41:48,999 low level, low 1270 00:41:49,000 --> 00:41:50,409 level languages are here to stay. 1271 00:41:51,640 --> 00:41:53,859 We've seen that even nowadays, a whole 1272 00:41:53,860 --> 00:41:56,829 bunch of software projects are started 1273 00:41:56,830 --> 00:41:58,839 and newly started in these low level 1274 00:41:58,840 --> 00:42:00,129 languages. 1275 00:42:00,130 --> 00:42:00,399 And we 1276 00:42:00,400 --> 00:42:02,139 need protection against all different 1277 00:42:02,140 --> 00:42:04,209 forms of memory vulnerabilities, 1278 00:42:05,500 --> 00:42:07,599 and we need to adhere 1279 00:42:07,600 --> 00:42:10,119 to the performance characteristics. 1280 00:42:10,120 --> 00:42:12,039 We need to support the legacy code that's 1281 00:42:12,040 --> 00:42:13,119 out there. 1282 00:42:13,120 --> 00:42:15,969 We cannot allow source code changes 1283 00:42:15,970 --> 00:42:17,949 and we have to be compatible with a large 1284 00:42:17,950 --> 00:42:19,449 set of other options. 1285 00:42:21,210 --> 00:42:22,210 So. 1286 00:42:26,410 --> 00:42:28,540 We have we can use one 1287 00:42:30,670 --> 00:42:31,329 that we 1288 00:42:31,330 --> 00:42:33,519 can try to protect against 1289 00:42:33,520 --> 00:42:33,609 the 1290 00:42:33,610 --> 00:42:35,319 biggest attack 1291 00:42:35,320 --> 00:42:37,119 vector that is out there nowadays. 1292 00:42:37,120 --> 00:42:39,579 And we have to find a forum to mitigate 1293 00:42:39,580 --> 00:42:40,989 against this contraflow, high tech 1294 00:42:40,990 --> 00:42:43,509 attacks and secure execution 1295 00:42:43,510 --> 00:42:45,669 platform as one start. 1296 00:42:45,670 --> 00:42:47,709 But then we'll have to follow up to the 1297 00:42:47,710 --> 00:42:49,899 next lulls and adapt and change 1298 00:42:49,900 --> 00:42:52,779 our compilers this fall to get protection 1299 00:42:52,780 --> 00:42:54,699 that is stronger than what we already 1300 00:42:54,700 --> 00:42:57,039 have. And we have to rethink 1301 00:42:57,040 --> 00:42:59,469 the existing security 1302 00:42:59,470 --> 00:43:00,099 to suit 1303 00:43:00,100 --> 00:43:02,049 defense mechanisms that are rolled out 1304 00:43:02,050 --> 00:43:04,179 nowadays, especially 1305 00:43:04,180 --> 00:43:06,249 things like Stack can can raise that only 1306 00:43:06,250 --> 00:43:08,409 add little protection on top of it and be 1307 00:43:08,410 --> 00:43:10,299 much better spent is one or two percent 1308 00:43:10,300 --> 00:43:11,709 performance overhead 1309 00:43:11,710 --> 00:43:12,710 in 1310 00:43:13,300 --> 00:43:15,669 into other instructions that it can be 1311 00:43:15,670 --> 00:43:18,099 can implement a stronger security 1312 00:43:18,100 --> 00:43:19,150 policy on top of it 1313 00:43:20,860 --> 00:43:22,629 and future directions after that. 1314 00:43:22,630 --> 00:43:23,929 If if, 1315 00:43:23,930 --> 00:43:25,719 if if protected against controversial 1316 00:43:25,720 --> 00:43:27,369 high tech attack, then there are still 1317 00:43:27,370 --> 00:43:29,619 data attacks out there and data attacks 1318 00:43:29,620 --> 00:43:30,999 are a completely different problem that 1319 00:43:31,000 --> 00:43:31,329 we'll have 1320 00:43:31,330 --> 00:43:32,439 to tackle. 1321 00:43:32,440 --> 00:43:32,889 So I 1322 00:43:32,890 --> 00:43:34,299 strongly believe that if we can fix 1323 00:43:34,300 --> 00:43:36,549 contraflow, high tech attacks pretty 1324 00:43:36,550 --> 00:43:39,189 soon, but we'll still have to look into 1325 00:43:39,190 --> 00:43:41,049 the all the data attacks that are out 1326 00:43:41,050 --> 00:43:42,050 there. 1327 00:43:42,760 --> 00:43:44,919 But I want to end this 1328 00:43:44,920 --> 00:43:46,599 talk with that. 1329 00:43:46,600 --> 00:43:48,729 If the winning move is not to 1330 00:43:48,730 --> 00:43:50,889 play, then maybe we need to change the 1331 00:43:50,890 --> 00:43:52,329 rules of the game. 1332 00:43:52,330 --> 00:43:53,859 We are the 1333 00:43:53,860 --> 00:43:55,959 first software that ever runs so we 1334 00:43:55,960 --> 00:43:57,579 can actually constrain the system in 1335 00:43:57,580 --> 00:43:59,859 additional ways and changed the rules 1336 00:43:59,860 --> 00:44:02,199 of the game. Add additional security, 1337 00:44:02,200 --> 00:44:04,209 defends mechanism that are stronger and 1338 00:44:04,210 --> 00:44:05,709 protects the software from being 1339 00:44:05,710 --> 00:44:06,819 exploited. 1340 00:44:06,820 --> 00:44:07,309 And instead, I 1341 00:44:07,310 --> 00:44:08,559 would like to thank you for your 1342 00:44:08,560 --> 00:44:10,149 attention and I am happy to take your 1343 00:44:10,150 --> 00:44:11,150 questions. 1344 00:44:20,190 --> 00:44:21,719 Thanks so much for that really great 1345 00:44:21,720 --> 00:44:23,009 overview. 1346 00:44:23,010 --> 00:44:25,139 So the microphones are two on the 1347 00:44:25,140 --> 00:44:26,729 left and the right, and I will also take 1348 00:44:26,730 --> 00:44:28,139 questions from the internet. 1349 00:44:28,140 --> 00:44:30,299 Let's start with microphone number two. 1350 00:44:30,300 --> 00:44:32,879 Hello. It was great talk. 1351 00:44:32,880 --> 00:44:34,019 I kind of got two questions. 1352 00:44:34,020 --> 00:44:36,299 One of them is, you're 1353 00:44:36,300 --> 00:44:37,949 saying that we should look at moving 1354 00:44:37,950 --> 00:44:39,839 things like Java because that's a safer 1355 00:44:39,840 --> 00:44:41,969 language. But everyone is now seems 1356 00:44:41,970 --> 00:44:43,859 to be saying, get Java off your system, 1357 00:44:43,860 --> 00:44:45,719 don't use it because the number of 1358 00:44:45,720 --> 00:44:46,799 exploits. 1359 00:44:46,800 --> 00:44:48,899 So we're confronted with these 1360 00:44:48,900 --> 00:44:50,879 mixed messages now, you know, and the 1361 00:44:50,880 --> 00:44:53,249 other question I've got is 1362 00:44:53,250 --> 00:44:55,529 whenever I see memory 1363 00:44:55,530 --> 00:44:57,779 errors discussed, they always 1364 00:44:57,780 --> 00:44:59,699 discuss the stack. 1365 00:44:59,700 --> 00:45:01,949 People mutter about 1366 00:45:01,950 --> 00:45:03,779 he picks points, but I never see an 1367 00:45:03,780 --> 00:45:05,939 example of one, so I've no idea how 1368 00:45:05,940 --> 00:45:07,649 one would work. I can only see that he 1369 00:45:07,650 --> 00:45:09,749 picks police work by 1370 00:45:09,750 --> 00:45:11,879 modifying something on the heap. 1371 00:45:11,880 --> 00:45:14,039 I mean, the program would read that onto 1372 00:45:14,040 --> 00:45:15,329 the stack and then you'd have a stack 1373 00:45:15,330 --> 00:45:16,330 exploit. 1374 00:45:17,370 --> 00:45:19,409 Is there a way to directly exploit the 1375 00:45:19,410 --> 00:45:21,719 heap? And if there isn't, would simply 1376 00:45:21,720 --> 00:45:23,909 persuading people to read or use 1377 00:45:23,910 --> 00:45:26,039 the data into 1378 00:45:26,040 --> 00:45:27,780 the heap rather than the stack 1379 00:45:28,830 --> 00:45:30,929 harden a lot of programing in 1380 00:45:30,930 --> 00:45:33,269 low level languages or not? 1381 00:45:33,270 --> 00:45:35,099 Let me answer your first question first. 1382 00:45:36,870 --> 00:45:38,969 It's not Java, as well as in 1383 00:45:38,970 --> 00:45:40,739 the language that gets exploited. 1384 00:45:40,740 --> 00:45:43,019 It's Java, as in the crappy browser 1385 00:45:43,020 --> 00:45:44,459 plug in that gets exploited. 1386 00:45:45,720 --> 00:45:48,179 There's a whole bunch of fairly 1387 00:45:48,180 --> 00:45:48,629 secure 1388 00:45:48,630 --> 00:45:50,699 Java software that runs on the server 1389 00:45:50,700 --> 00:45:52,799 side, and that one is perfectly 1390 00:45:52,800 --> 00:45:54,179 secure. 1391 00:45:54,180 --> 00:45:56,309 But the Java plug in itself 1392 00:45:56,310 --> 00:45:58,649 that runs the NOWADAY browsers is 1393 00:45:58,650 --> 00:46:01,169 inherent is very insecure, and 1394 00:46:01,170 --> 00:46:01,439 this 1395 00:46:01,440 --> 00:46:02,939 plug in is actually written in a low 1396 00:46:02,940 --> 00:46:04,019 level language. 1397 00:46:04,020 --> 00:46:05,579 Most of the Java virtual machine is 1398 00:46:05,580 --> 00:46:07,649 written in C, and the attacks 1399 00:46:07,650 --> 00:46:08,650 happen against this, 1400 00:46:10,260 --> 00:46:12,389 this virtual machine and try to exploit 1401 00:46:12,390 --> 00:46:13,679 the virtual machine. 1402 00:46:13,680 --> 00:46:16,409 The attackers applies to Java code 1403 00:46:16,410 --> 00:46:18,539 and breaks the virtual machine. 1404 00:46:18,540 --> 00:46:19,109 But on the 1405 00:46:19,110 --> 00:46:21,449 other hand, on the server systems, 1406 00:46:21,450 --> 00:46:23,579 the Java runs perfectly safe 1407 00:46:23,580 --> 00:46:24,269 to 1408 00:46:24,270 --> 00:46:26,339 the towers and runs a large, 1409 00:46:26,340 --> 00:46:28,169 let's say, a data processing engine or 1410 00:46:28,170 --> 00:46:29,129 something like that. 1411 00:46:29,130 --> 00:46:31,469 And the attacker can only supply data, 1412 00:46:31,470 --> 00:46:32,470 but not code. 1413 00:46:33,390 --> 00:46:34,649 And then it's perfectly fine 1414 00:46:35,730 --> 00:46:37,439 and well, 1415 00:46:37,440 --> 00:46:39,569 you still have all these problems 1416 00:46:39,570 --> 00:46:42,269 with low level languages like C or C++ 1417 00:46:42,270 --> 00:46:44,279 that you can attack the 1418 00:46:44,280 --> 00:46:44,639 data 1419 00:46:44,640 --> 00:46:45,389 parts of the 1420 00:46:45,390 --> 00:46:46,679 application. 1421 00:46:46,680 --> 00:46:47,939 How does that work on the heap? 1422 00:46:47,940 --> 00:46:50,129 Because no one ever demonstrates how 1423 00:46:50,130 --> 00:46:51,119 that works. 1424 00:46:51,120 --> 00:46:53,279 I'd like to know how the 1425 00:46:53,280 --> 00:46:54,719 heap exploits work because everyone 1426 00:46:54,720 --> 00:46:55,979 always says they're there, but I never 1427 00:46:55,980 --> 00:46:58,079 see an example of one to one part. 1428 00:46:58,080 --> 00:46:58,739 One possible 1429 00:46:58,740 --> 00:47:00,779 way for a heat to exploit are the classic 1430 00:47:00,780 --> 00:47:01,559 use after free 1431 00:47:01,560 --> 00:47:03,059 exploit, where 1432 00:47:03,060 --> 00:47:06,089 you change some specific data structures 1433 00:47:06,090 --> 00:47:08,039 and not 1434 00:47:08,040 --> 00:47:09,629 one easy heap exploit could be. 1435 00:47:09,630 --> 00:47:12,749 You have you're writing in C++, 1436 00:47:12,750 --> 00:47:13,889 you have your 1437 00:47:13,890 --> 00:47:15,689 object somewhere on the stack, that 1438 00:47:15,690 --> 00:47:16,690 object is freed 1439 00:47:17,640 --> 00:47:18,099 and 1440 00:47:18,100 --> 00:47:20,339 the other object is located on top of it. 1441 00:47:20,340 --> 00:47:22,469 But you still get control over one 1442 00:47:22,470 --> 00:47:24,059 field off the old object because a 1443 00:47:24,060 --> 00:47:25,499 pointer points in there. 1444 00:47:25,500 --> 00:47:28,109 And conveniently, this 1445 00:47:28,110 --> 00:47:30,179 pointer points to the table pointer off 1446 00:47:30,180 --> 00:47:30,449 the new 1447 00:47:30,450 --> 00:47:32,039 object, and 1448 00:47:32,040 --> 00:47:34,049 you can then override overwrite the table 1449 00:47:34,050 --> 00:47:36,329 pointer. And as soon as that object 1450 00:47:36,330 --> 00:47:37,979 is used in the context of the 1451 00:47:37,980 --> 00:47:40,199 application, the attacker controlled V 1452 00:47:40,200 --> 00:47:42,479 table pointer will be followed and 1453 00:47:42,480 --> 00:47:44,459 some attacker controlled code will be 1454 00:47:44,460 --> 00:47:45,460 executed. 1455 00:47:46,170 --> 00:47:46,439 And you 1456 00:47:46,440 --> 00:47:48,299 don't. You didn't have to push anything 1457 00:47:48,300 --> 00:47:49,439 onto the stack. 1458 00:47:49,440 --> 00:47:50,579 It's all on the heap. 1459 00:47:50,580 --> 00:47:51,989 There will be an example, right? 1460 00:47:51,990 --> 00:47:53,579 OK. That's exactly what we're looking 1461 00:47:53,580 --> 00:47:54,580 for. OK. 1462 00:47:57,030 --> 00:47:58,919 All right, next question from the 1463 00:47:58,920 --> 00:47:59,920 microphone behind 1464 00:48:00,990 --> 00:48:01,990 us. 1465 00:48:02,760 --> 00:48:03,760 Hi. 1466 00:48:04,320 --> 00:48:06,449 I got a question concerning the 1467 00:48:06,450 --> 00:48:08,820 250 percent 1468 00:48:09,960 --> 00:48:11,030 performance tradeoff. 1469 00:48:12,510 --> 00:48:14,879 From what I understood 1470 00:48:14,880 --> 00:48:17,039 those, this tradeoff 1471 00:48:17,040 --> 00:48:19,679 comes from additional checks. 1472 00:48:19,680 --> 00:48:22,229 Those compiler extensions 1473 00:48:22,230 --> 00:48:23,340 put into your code, 1474 00:48:24,450 --> 00:48:26,669 but those 1475 00:48:26,670 --> 00:48:28,319 additional checks, shouldn't they have 1476 00:48:28,320 --> 00:48:30,359 been in your original code in the first 1477 00:48:30,360 --> 00:48:31,360 place? 1478 00:48:32,970 --> 00:48:35,249 Well, LVM, 1479 00:48:35,250 --> 00:48:36,599 well, Edra sanitizer 1480 00:48:37,830 --> 00:48:40,109 and soft pounds plus that implement those 1481 00:48:40,110 --> 00:48:41,669 checks, they have to be very 1482 00:48:41,670 --> 00:48:43,349 conservative. 1483 00:48:43,350 --> 00:48:43,979 They usually 1484 00:48:43,980 --> 00:48:45,299 run the analysis on a 1485 00:48:45,300 --> 00:48:46,300 per 1486 00:48:48,090 --> 00:48:50,159 on a per function basis, and they 1487 00:48:50,160 --> 00:48:52,289 have to instrument every single axis 1488 00:48:52,290 --> 00:48:52,439 that 1489 00:48:52,440 --> 00:48:54,779 you do you as a programmer, 1490 00:48:54,780 --> 00:48:56,939 you can actually think about, oh, 1491 00:48:56,940 --> 00:48:59,549 well, the attacker will never be able to 1492 00:48:59,550 --> 00:49:02,009 supply these and these values, and 1493 00:49:02,010 --> 00:49:03,869 the values will only be between one and 1494 00:49:03,870 --> 00:49:04,619 10. 1495 00:49:04,620 --> 00:49:05,459 If you know that 1496 00:49:05,460 --> 00:49:07,529 for sure, because the function that 1497 00:49:07,530 --> 00:49:08,549 you use 1498 00:49:08,550 --> 00:49:10,889 that the caller 1499 00:49:10,890 --> 00:49:13,109 actually just uses static 1500 00:49:13,110 --> 00:49:15,299 values, right? 1501 00:49:15,300 --> 00:49:17,519 So so you can actually use inherent 1502 00:49:17,520 --> 00:49:19,649 knowledge in between the caller and the 1503 00:49:19,650 --> 00:49:21,959 colleague to remove 1504 00:49:21,960 --> 00:49:24,259 Stacks as a programmer and 1505 00:49:24,260 --> 00:49:26,279 the software based approach compiler 1506 00:49:26,280 --> 00:49:28,319 based approach has to be conservative and 1507 00:49:28,320 --> 00:49:30,419 has to add all that. All the checks, in 1508 00:49:30,420 --> 00:49:32,639 addition to the C language, is very 1509 00:49:32,640 --> 00:49:34,859 diverse, so you have a large set 1510 00:49:34,860 --> 00:49:36,839 of different options that you can you can 1511 00:49:36,840 --> 00:49:38,669 add that makes all the analysis much, 1512 00:49:38,670 --> 00:49:39,839 much harder. 1513 00:49:39,840 --> 00:49:42,119 OK. I kind of anticipated 1514 00:49:42,120 --> 00:49:43,389 that answer. 1515 00:49:43,390 --> 00:49:45,989 And but isn't this 1516 00:49:45,990 --> 00:49:48,179 exactly kind of a kind of 1517 00:49:48,180 --> 00:49:49,439 the problem? 1518 00:49:49,440 --> 00:49:50,850 I mean, the programmer 1519 00:49:51,870 --> 00:49:54,539 thinking that at this point, 1520 00:49:54,540 --> 00:49:56,759 you can't the code can 1521 00:49:56,760 --> 00:49:57,779 be exploited. 1522 00:49:57,780 --> 00:50:00,029 But uh, yeah, 1523 00:50:00,030 --> 00:50:01,889 maybe the code is reused somewhere else 1524 00:50:01,890 --> 00:50:04,079 and the exact assumptions or 1525 00:50:04,080 --> 00:50:05,399 assumptions change and then you're 1526 00:50:05,400 --> 00:50:06,329 screwed. 1527 00:50:06,330 --> 00:50:07,979 Yeah, that's what happens. 1528 00:50:07,980 --> 00:50:09,059 OK. 1529 00:50:09,060 --> 00:50:10,679 All right. Now we take action on the 1530 00:50:10,680 --> 00:50:11,680 internet. 1531 00:50:12,070 --> 00:50:14,789 Uh, so first question from the internets 1532 00:50:14,790 --> 00:50:17,939 to new version of C and C++ 1533 00:50:17,940 --> 00:50:20,159 provide necessary protection mechanism 1534 00:50:20,160 --> 00:50:22,379 or language constructs 1535 00:50:22,380 --> 00:50:24,659 to to prevent common attacks, like 1536 00:50:24,660 --> 00:50:25,709 you mentioned. 1537 00:50:25,710 --> 00:50:27,719 I think you've covered a little bit of 1538 00:50:27,720 --> 00:50:29,549 that at the beginning of your thought. 1539 00:50:29,550 --> 00:50:30,899 If you could experiment. 1540 00:50:30,900 --> 00:50:31,979 Can you repeat the question? 1541 00:50:31,980 --> 00:50:34,289 OK, the question is the new version of C 1542 00:50:34,290 --> 00:50:36,899 and C++ provide necessary, 1543 00:50:36,900 --> 00:50:38,999 necessary protection mechanism or 1544 00:50:39,000 --> 00:50:41,399 language constructs to prevent common 1545 00:50:41,400 --> 00:50:42,400 attacks 1546 00:50:43,050 --> 00:50:45,879 to protect what detects common attacks. 1547 00:50:45,880 --> 00:50:46,979 Common. 1548 00:50:46,980 --> 00:50:47,999 OK. 1549 00:50:48,000 --> 00:50:49,000 No, don't 1550 00:50:50,330 --> 00:50:51,330 answer. 1551 00:50:52,440 --> 00:50:54,769 You can use tools like Edra 1552 00:50:54,770 --> 00:50:55,709 Sanitizer 1553 00:50:55,710 --> 00:50:57,299 or a whole bunch of 1554 00:50:57,300 --> 00:50:59,099 other analysis tools that run on top of 1555 00:50:59,100 --> 00:51:01,199 it. Or you can use soft 1556 00:51:01,200 --> 00:51:03,269 bones and CTS, which is also a 1557 00:51:03,270 --> 00:51:04,739 compiler extension. 1558 00:51:04,740 --> 00:51:07,799 And these tools basically use liberties 1559 00:51:07,800 --> 00:51:09,779 in the language specification to actually 1560 00:51:09,780 --> 00:51:10,949 inject additional 1561 00:51:12,180 --> 00:51:14,099 security checks on top of it. 1562 00:51:14,100 --> 00:51:15,100 But 1563 00:51:16,260 --> 00:51:18,389 most of these tools, like in 1564 00:51:18,390 --> 00:51:19,649 the academic 1565 00:51:19,650 --> 00:51:20,399 papers, these 1566 00:51:20,400 --> 00:51:21,479 tools are 1567 00:51:21,480 --> 00:51:24,069 advertised as are 1568 00:51:24,070 --> 00:51:26,249 usually advertised as debugging 1569 00:51:26,250 --> 00:51:27,299 tools 1570 00:51:27,300 --> 00:51:29,759 just because they have so much 1571 00:51:29,760 --> 00:51:31,350 or such such a huge overhead. 1572 00:51:33,330 --> 00:51:33,599 You can 1573 00:51:33,600 --> 00:51:35,339 definitely if you want safe software, you 1574 00:51:35,340 --> 00:51:38,189 can re compile a list with soft bones 1575 00:51:38,190 --> 00:51:40,079 and then you should be 1576 00:51:40,080 --> 00:51:41,789 if you should be good to go right. 1577 00:51:41,790 --> 00:51:42,509 But you, you will 1578 00:51:42,510 --> 00:51:44,429 hit the huge performance impact. 1579 00:51:46,290 --> 00:51:47,339 All right. 1580 00:51:47,340 --> 00:51:48,909 All right, another question for 1581 00:51:48,910 --> 00:51:50,039 microphone to place. 1582 00:51:50,040 --> 00:51:51,239 Yes, hello. 1583 00:51:51,240 --> 00:51:53,309 Uh, good to, uh, have 1584 00:51:53,310 --> 00:51:55,679 a question. This Gear VR 1585 00:51:55,680 --> 00:51:57,249 security kernel patches. 1586 00:51:57,250 --> 00:51:59,369 How does it fit into this picture? 1587 00:52:01,830 --> 00:52:03,209 Mm hmm. 1588 00:52:03,210 --> 00:52:05,669 So the security patches 1589 00:52:05,670 --> 00:52:07,530 are then a bunch of 1590 00:52:09,090 --> 00:52:09,539 hardening 1591 00:52:09,540 --> 00:52:11,759 patches against the kernel and 1592 00:52:11,760 --> 00:52:13,679 kernel modifications itself. 1593 00:52:13,680 --> 00:52:15,629 So that would be kind of a soft source 1594 00:52:15,630 --> 00:52:17,759 code based approach to actually 1595 00:52:17,760 --> 00:52:19,050 harden the software itself. 1596 00:52:21,030 --> 00:52:23,759 I guess they also have 1597 00:52:23,760 --> 00:52:25,379 the implement a whole bunch of 1598 00:52:25,380 --> 00:52:26,429 defense mechanism, right? 1599 00:52:26,430 --> 00:52:27,569 So they introduced, 1600 00:52:27,570 --> 00:52:29,219 uh, they introduced Asal. 1601 00:52:29,220 --> 00:52:30,220 All right. 1602 00:52:30,660 --> 00:52:31,919 So yeah, 1603 00:52:31,920 --> 00:52:34,069 even before it was in the 1604 00:52:34,070 --> 00:52:35,519 in the mainline kernel. 1605 00:52:35,520 --> 00:52:37,259 So did. 1606 00:52:37,260 --> 00:52:37,829 Did they have 1607 00:52:37,830 --> 00:52:39,539 multiple roles right today at new 1608 00:52:39,540 --> 00:52:41,699 security defense mechanism for user land? 1609 00:52:41,700 --> 00:52:43,199 They make exploitation of the kernel 1610 00:52:43,200 --> 00:52:44,849 itself harder. 1611 00:52:44,850 --> 00:52:46,739 Yeah, it's a it's a nice project, 1612 00:52:48,480 --> 00:52:51,209 but it's not the language based, 1613 00:52:51,210 --> 00:52:53,939 the the program in C, 1614 00:52:53,940 --> 00:52:54,119 and 1615 00:52:54,120 --> 00:52:55,409 they add all these nice security 1616 00:52:55,410 --> 00:52:58,199 features. So it's a good thing. 1617 00:52:58,200 --> 00:52:59,999 I got another question from the second 1618 00:53:00,000 --> 00:53:01,589 microphone down to number two. 1619 00:53:01,590 --> 00:53:04,259 Hi. Thanks for the great talk. 1620 00:53:04,260 --> 00:53:06,599 Is there anything? What's your opinion on 1621 00:53:06,600 --> 00:53:09,149 the secure function that Microsoft 1622 00:53:09,150 --> 00:53:11,219 has implemented from the C standard like 1623 00:53:12,360 --> 00:53:14,429 string copy and 1624 00:53:14,430 --> 00:53:15,869 you know that family of functions? 1625 00:53:17,490 --> 00:53:18,490 Well. 1626 00:53:27,360 --> 00:53:29,519 It's still see your rights, you can make 1627 00:53:29,520 --> 00:53:31,619 your mistakes somewhere else, 1628 00:53:31,620 --> 00:53:32,709 and not just there. 1629 00:53:32,710 --> 00:53:35,219 And do you feel that it 1630 00:53:35,220 --> 00:53:37,829 adds any protection like 1631 00:53:37,830 --> 00:53:39,869 that? A programmer would be less likely 1632 00:53:39,870 --> 00:53:41,849 to make a mistake using these functions. 1633 00:53:41,850 --> 00:53:43,829 Well, it's it's definitely better than 1634 00:53:43,830 --> 00:53:46,109 than the non-secure version. 1635 00:53:46,110 --> 00:53:48,239 But the question is how much 1636 00:53:48,240 --> 00:53:49,259 better is it? 1637 00:53:49,260 --> 00:53:50,309 Or it 1638 00:53:50,310 --> 00:53:51,749 might solve a 1639 00:53:51,750 --> 00:53:52,379 small set of 1640 00:53:52,380 --> 00:53:53,819 problems, but then there are others 1641 00:53:53,820 --> 00:53:56,789 that are still cylinder, so it's 1642 00:53:56,790 --> 00:53:58,209 very debatable question. 1643 00:53:58,210 --> 00:53:59,279 All right. And it 1644 00:53:59,280 --> 00:54:00,209 was an easy fix 1645 00:54:00,210 --> 00:54:02,729 that they could add 1646 00:54:02,730 --> 00:54:03,929 very quickly. 1647 00:54:03,930 --> 00:54:04,649 But it's not 1648 00:54:04,650 --> 00:54:06,449 a sort fix that will save the inherent 1649 00:54:06,450 --> 00:54:07,449 problem of these little love 1650 00:54:07,450 --> 00:54:09,599 languages, especially 1651 00:54:09,600 --> 00:54:10,169 as it only 1652 00:54:10,170 --> 00:54:12,299 fixes like the a couple of 1653 00:54:12,300 --> 00:54:13,300 functions. 1654 00:54:14,130 --> 00:54:15,029 All right, I think we had another 1655 00:54:15,030 --> 00:54:16,739 question from the internet. 1656 00:54:16,740 --> 00:54:17,879 There are two more questions. 1657 00:54:17,880 --> 00:54:20,189 The first one is, uh, are you aware 1658 00:54:20,190 --> 00:54:22,619 of the existence of muscle lipsy 1659 00:54:22,620 --> 00:54:24,669 for the which makes it so you can 1660 00:54:24,670 --> 00:54:27,339 eclipsing muscle Lipsy and 1661 00:54:27,340 --> 00:54:29,459 so which 1662 00:54:29,460 --> 00:54:31,859 makes static linking feasible? 1663 00:54:31,860 --> 00:54:32,399 Yeah, there are 1664 00:54:32,400 --> 00:54:34,589 a bunch of ellipses that are statically 1665 00:54:34,590 --> 00:54:35,590 drinkable. 1666 00:54:36,600 --> 00:54:38,159 Yeah, there are. But the standard, 1667 00:54:38,160 --> 00:54:39,419 the each Lipsy is 1668 00:54:39,420 --> 00:54:40,420 not. 1669 00:54:41,620 --> 00:54:42,629 OK. 1670 00:54:42,630 --> 00:54:44,699 Next question is, uh, 1671 00:54:44,700 --> 00:54:46,769 if you compare all your programs for 1672 00:54:46,770 --> 00:54:48,899 yourself with the custom set of C 1673 00:54:48,900 --> 00:54:51,839 Flux or presumably L diplomas, what 1674 00:54:51,840 --> 00:54:54,749 would you consider your binaries secure 1675 00:54:54,750 --> 00:54:56,849 because no one else knows the exact Lipsy 1676 00:54:56,850 --> 00:54:57,850 address? 1677 00:55:00,220 --> 00:55:01,719 That's the same problem, right, as soon 1678 00:55:01,720 --> 00:55:01,879 as 1679 00:55:01,880 --> 00:55:04,089 you have 1680 00:55:04,090 --> 00:55:05,199 an information 1681 00:55:05,200 --> 00:55:07,269 leak off, like 1682 00:55:07,270 --> 00:55:07,819 I assume 1683 00:55:07,820 --> 00:55:09,579 the application that you compile yourself 1684 00:55:09,580 --> 00:55:11,050 processes, input and output. 1685 00:55:12,270 --> 00:55:14,679 And if 1686 00:55:14,680 --> 00:55:16,839 you get the binary, you can reverse that 1687 00:55:16,840 --> 00:55:17,349 one 1688 00:55:17,350 --> 00:55:19,479 or yeah, it's it's 1689 00:55:19,480 --> 00:55:20,480 still C, right? 1690 00:55:24,710 --> 00:55:26,669 Do you have any more questions? 1691 00:55:26,670 --> 00:55:28,369 Yeah, I'm great. 1692 00:55:28,370 --> 00:55:31,159 Well, before we wrap up this talk, 1693 00:55:31,160 --> 00:55:32,719 I would just like to remind everyone to 1694 00:55:32,720 --> 00:55:34,699 provide feedback on the impact these 1695 00:55:36,170 --> 00:55:37,369 presentations. 1696 00:55:37,370 --> 00:55:39,679 We get feedback also helps us speakers 1697 00:55:39,680 --> 00:55:42,229 a lot, so please go online, 1698 00:55:42,230 --> 00:55:44,389 provide the feedback and was that I would 1699 00:55:44,390 --> 00:55:46,339 like to thank us for that really 1700 00:55:46,340 --> 00:55:48,799 comprehensive overview of this 1701 00:55:48,800 --> 00:55:50,059 problem. Class and security. 1702 00:55:50,060 --> 00:55:51,060 Thank you very much, my thanks.