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/660 Thanks! 1 00:00:13,290 --> 00:00:15,059 OK, good morning. 2 00:00:18,660 --> 00:00:20,759 Good morning, welcome again to 3 00:00:20,760 --> 00:00:23,019 our second talk of the of the day. 4 00:00:24,300 --> 00:00:26,549 Our next speaker is a 5 00:00:26,550 --> 00:00:28,949 security researcher at Checkpoint 6 00:00:28,950 --> 00:00:31,049 and he will be talking to us today 7 00:00:31,050 --> 00:00:33,149 about exploiting seven and 8 00:00:33,150 --> 00:00:35,009 serializer mechanisms. 9 00:00:35,010 --> 00:00:37,109 So please give a big round 10 00:00:37,110 --> 00:00:38,520 of applause to your Nili. 11 00:00:45,820 --> 00:00:46,820 OK. 12 00:00:48,580 --> 00:00:51,339 Hi, uh, welcome to my talk, 13 00:00:51,340 --> 00:00:53,679 teaching the new dog old tricks, 14 00:00:53,680 --> 00:00:56,079 it's about preserving memory internals 15 00:00:56,080 --> 00:00:57,729 for security researchers. 16 00:00:57,730 --> 00:00:59,949 And I must give 17 00:00:59,950 --> 00:01:01,539 a disclaimer first. This is not to talk 18 00:01:01,540 --> 00:01:03,249 about puppy code. 19 00:01:03,250 --> 00:01:04,809 It's about being an interpreter. 20 00:01:04,810 --> 00:01:06,819 So I hope you enjoy it 21 00:01:07,960 --> 00:01:10,089 about me. My name is Yanai has 22 00:01:10,090 --> 00:01:12,519 already said I work at Checkpoint, 23 00:01:12,520 --> 00:01:14,499 my team and I work with many staff and 24 00:01:14,500 --> 00:01:17,049 networks. Embedded devices, 25 00:01:17,050 --> 00:01:19,359 exploits, client sites, exploits 26 00:01:19,360 --> 00:01:21,879 and also memory corruptions of all sorts. 27 00:01:21,880 --> 00:01:24,039 And today's agenda first 28 00:01:24,040 --> 00:01:26,589 will have a brief introduction about PPY 29 00:01:26,590 --> 00:01:28,299 and then we'll talk about PPY and 30 00:01:28,300 --> 00:01:29,769 Serializer Mechanism. 31 00:01:29,770 --> 00:01:31,209 After that, we'll talk about the 32 00:01:31,210 --> 00:01:32,949 implementation of the Zevo system, the 33 00:01:32,950 --> 00:01:35,649 value system of ENPI seven 34 00:01:35,650 --> 00:01:37,839 now gaining this knowledge of uncivilized 35 00:01:37,840 --> 00:01:39,759 and Zevo system. We'll see some bugs and 36 00:01:39,760 --> 00:01:41,409 vulnerabilities. 37 00:01:41,410 --> 00:01:43,059 After that, we'll discuss the internals 38 00:01:43,060 --> 00:01:44,649 of the allocator in pre seven. 39 00:01:44,650 --> 00:01:47,019 It's a new aligator and using 40 00:01:47,020 --> 00:01:49,119 our knowledge of the al-Qaeda and we 41 00:01:49,120 --> 00:01:51,039 can see how we can exploit the bugs and 42 00:01:51,040 --> 00:01:54,039 write remote code execution exploits, 43 00:01:54,040 --> 00:01:56,019 then we'll have conclusion's questions, 44 00:01:56,020 --> 00:01:57,189 etc.. 45 00:01:57,190 --> 00:01:58,299 So let's begin. 46 00:01:59,440 --> 00:02:01,929 PPY is the most used, 47 00:02:01,930 --> 00:02:03,999 uh, language in Web applications 48 00:02:04,000 --> 00:02:06,879 today for writing Web applications and 49 00:02:06,880 --> 00:02:09,038 basically its server side language and 50 00:02:09,039 --> 00:02:10,239 servers rule the world. 51 00:02:10,240 --> 00:02:12,279 All our information, all the data we have 52 00:02:12,280 --> 00:02:14,079 in applications is in the server side. 53 00:02:14,080 --> 00:02:16,299 So it's very interesting as 54 00:02:16,300 --> 00:02:18,729 a malicious attackers 55 00:02:18,730 --> 00:02:20,259 want to get some information to attack 56 00:02:20,260 --> 00:02:21,789 the servers usually. 57 00:02:21,790 --> 00:02:23,949 And when I said 58 00:02:23,950 --> 00:02:26,079 it's the most used language today 59 00:02:26,080 --> 00:02:27,669 to today, the most popular version of 60 00:02:27,670 --> 00:02:29,529 this language is version five. 61 00:02:29,530 --> 00:02:31,629 But unless you came up, 62 00:02:31,630 --> 00:02:34,329 a new version was released 63 00:02:34,330 --> 00:02:35,979 seven. And this is what we're going to 64 00:02:35,980 --> 00:02:37,419 talk about today. 65 00:02:37,420 --> 00:02:39,489 So it's the most simple, one 66 00:02:39,490 --> 00:02:40,809 of the most important languages today. 67 00:02:40,810 --> 00:02:43,149 And what about the security of 68 00:02:43,150 --> 00:02:44,499 P2P applications? 69 00:02:44,500 --> 00:02:46,869 Well, like every popular 70 00:02:46,870 --> 00:02:48,939 yeah. Every popular language 71 00:02:48,940 --> 00:02:51,309 has vulnerabilities written into 72 00:02:51,310 --> 00:02:52,959 it or written by it. 73 00:02:52,960 --> 00:02:55,149 So we know many vulnerabilities 74 00:02:55,150 --> 00:02:56,829 of fiscal injection in recent years and 75 00:02:56,830 --> 00:02:57,849 exercises. 76 00:02:57,850 --> 00:02:59,649 These are high level vulnerabilities and 77 00:02:59,650 --> 00:03:01,509 it depends on the code you're writing to 78 00:03:01,510 --> 00:03:03,069 your Web application. 79 00:03:03,070 --> 00:03:05,409 But there also memory corrections. 80 00:03:05,410 --> 00:03:06,999 How can you have memory corruptions in 81 00:03:07,000 --> 00:03:08,019 high level then, would you ask? 82 00:03:08,020 --> 00:03:10,089 Well, some of the functionality of PCB 83 00:03:10,090 --> 00:03:12,279 is implemented in the interpreter 84 00:03:12,280 --> 00:03:14,439 itself, which is written in the C, and 85 00:03:14,440 --> 00:03:16,509 when you pass user input to this kind of 86 00:03:16,510 --> 00:03:18,369 functionality and you have bugs there, 87 00:03:18,370 --> 00:03:20,259 you can get some exceptions. 88 00:03:20,260 --> 00:03:22,449 The most notable example for this 89 00:03:22,450 --> 00:03:24,579 is the insulated function which has 90 00:03:24,580 --> 00:03:26,919 been exploited many times over 91 00:03:26,920 --> 00:03:27,969 the recent years. 92 00:03:27,970 --> 00:03:29,739 And this is exactly the function we're 93 00:03:29,740 --> 00:03:31,869 going to talk about today. But in the new 94 00:03:31,870 --> 00:03:32,949 domain of P seven. 95 00:03:33,970 --> 00:03:37,179 So what about the history of unsterilized 96 00:03:37,180 --> 00:03:40,209 of too many civies, actually, 97 00:03:40,210 --> 00:03:42,909 and most of these vulnerabilities 98 00:03:42,910 --> 00:03:44,679 were exploited in object injection. 99 00:03:44,680 --> 00:03:46,279 So property oriented programing, if you 100 00:03:46,280 --> 00:03:48,339 heard of it. And this is a 101 00:03:48,340 --> 00:03:50,619 logical explanation. It depends on 102 00:03:50,620 --> 00:03:52,869 the application that 103 00:03:52,870 --> 00:03:54,759 is used, how this application to Peterffy 104 00:03:54,760 --> 00:03:57,489 application was written, but there also 105 00:03:57,490 --> 00:03:59,829 have been no corruptions and corruptions 106 00:03:59,830 --> 00:04:01,309 does not depend on the application. 107 00:04:01,310 --> 00:04:03,609 Moer corruption exploitation depends only 108 00:04:03,610 --> 00:04:05,049 on the B version. 109 00:04:05,050 --> 00:04:07,419 As I said, version five of version seven. 110 00:04:07,420 --> 00:04:10,149 And for memory corruptions in 111 00:04:10,150 --> 00:04:12,399 five, there was a generic exploit 112 00:04:12,400 --> 00:04:13,650 developed by Ionic 113 00:04:14,700 --> 00:04:16,879 Essar. Uh, it was described in Blacket 114 00:04:18,100 --> 00:04:19,449 2010. 115 00:04:19,450 --> 00:04:21,729 And this, uh, 116 00:04:21,730 --> 00:04:23,979 exploit could basically work on every 117 00:04:23,980 --> 00:04:26,469 five memory corruption and 118 00:04:26,470 --> 00:04:27,470 manner corruption you had. 119 00:04:28,780 --> 00:04:30,699 So as I said, it's a very old problem. 120 00:04:30,700 --> 00:04:33,099 But here is an example from, uh, 121 00:04:33,100 --> 00:04:35,619 this year on July, uh, 122 00:04:35,620 --> 00:04:37,419 this small website that I don't know if 123 00:04:37,420 --> 00:04:39,879 you're familiar with it, uh, open 124 00:04:39,880 --> 00:04:41,169 the backbone thing. 125 00:04:41,170 --> 00:04:43,929 And this bug bounty, um, 126 00:04:43,930 --> 00:04:46,329 attracted the attention of 127 00:04:46,330 --> 00:04:47,829 a company called Eventide. 128 00:04:47,830 --> 00:04:49,959 They looked at the API and found 129 00:04:49,960 --> 00:04:52,029 this, uh, API call a post 130 00:04:52,030 --> 00:04:54,009 request. And you can see a cookie here. 131 00:04:54,010 --> 00:04:55,839 And this cookie has a very interesting 132 00:04:55,840 --> 00:04:57,159 format. This is the format of an 133 00:04:57,160 --> 00:04:58,089 serialize. 134 00:04:58,090 --> 00:05:00,069 And of course, when you send, uh, the 135 00:05:00,070 --> 00:05:01,719 request, you get a response and you see 136 00:05:01,720 --> 00:05:03,879 that the scroll actually process, uh, 137 00:05:03,880 --> 00:05:06,129 this cookie. So we have a vulnerable 138 00:05:06,130 --> 00:05:07,839 and serialize right there. 139 00:05:07,840 --> 00:05:09,309 And what they did, the first and 140 00:05:09,310 --> 00:05:11,409 serialize and version five, this, uh, 141 00:05:11,410 --> 00:05:13,329 in this instance and found the new 142 00:05:13,330 --> 00:05:15,129 vulnerability exploited it got the 143 00:05:15,130 --> 00:05:16,130 bounty. 144 00:05:16,720 --> 00:05:18,189 So what about pre seven? 145 00:05:18,190 --> 00:05:19,239 I'm talking about all the time. 146 00:05:19,240 --> 00:05:21,579 Well, it's a new release of the language. 147 00:05:21,580 --> 00:05:24,249 It was, uh, released just a year ago 148 00:05:24,250 --> 00:05:26,379 and they kind of reimplemented 149 00:05:26,380 --> 00:05:27,639 everything for performance. 150 00:05:27,640 --> 00:05:29,679 So they re implemented a value system. 151 00:05:29,680 --> 00:05:31,029 They have implemented the memory 152 00:05:31,030 --> 00:05:32,709 allocation mechanisms. 153 00:05:32,710 --> 00:05:34,869 And for this reason, the 154 00:05:34,870 --> 00:05:37,269 exploitation technique of 155 00:05:37,270 --> 00:05:38,799 the memory corruption does not work 156 00:05:38,800 --> 00:05:40,899 anymore. Uh, exploitation of 157 00:05:40,900 --> 00:05:42,759 our corruptions depend heavily on the 158 00:05:42,760 --> 00:05:44,349 memory layout. And when you change all of 159 00:05:44,350 --> 00:05:45,350 that, nothing works. 160 00:05:46,930 --> 00:05:49,299 But still, we have the uncivilized 161 00:05:49,300 --> 00:05:51,489 functionality in P7 because you 162 00:05:51,490 --> 00:05:53,859 have some sort of backward compatibility 163 00:05:53,860 --> 00:05:56,469 and there have been some civs, 164 00:05:56,470 --> 00:05:58,569 object injections, Sageworks being purely 165 00:05:58,570 --> 00:06:00,849 logical, but the corruptions while 166 00:06:00,850 --> 00:06:02,379 still there, you can still find more 167 00:06:02,380 --> 00:06:03,609 corruption vulnerabilities in 168 00:06:03,610 --> 00:06:04,610 unsterilized. 169 00:06:05,680 --> 00:06:07,839 You don't have any remote exploits until 170 00:06:08,860 --> 00:06:10,149 this talk. More or less. 171 00:06:11,150 --> 00:06:13,129 Yeah, thanks for me. 172 00:06:13,130 --> 00:06:16,059 So let's talk about in Cirillo's 173 00:06:16,060 --> 00:06:17,949 and Unsterilized first. 174 00:06:17,950 --> 00:06:20,229 We have to I have to make 175 00:06:20,230 --> 00:06:20,859 something clear. 176 00:06:20,860 --> 00:06:22,239 You should say disorderlies and 177 00:06:22,240 --> 00:06:23,349 unsterilized is a grammatically 178 00:06:23,350 --> 00:06:25,359 incorrect. And if it bugs you, well, 179 00:06:25,360 --> 00:06:26,769 that's how it's going to be for the rest 180 00:06:26,770 --> 00:06:28,569 of these stocks. So I'm sorry, but 181 00:06:30,220 --> 00:06:32,349 we can go on and this is 182 00:06:32,350 --> 00:06:34,569 the documentation of the serializing 183 00:06:34,570 --> 00:06:35,980 unsterilized functionality in 184 00:06:37,420 --> 00:06:39,039 basically what SERIALIZE does. 185 00:06:39,040 --> 00:06:40,989 It takes values and converts them to a 186 00:06:40,990 --> 00:06:43,089 string that you can store 187 00:06:43,090 --> 00:06:44,199 and retrieve later. 188 00:06:44,200 --> 00:06:46,419 And unsterilized is the reverse 189 00:06:46,420 --> 00:06:48,459 operation. So you get the string in a 190 00:06:48,460 --> 00:06:50,259 specific format of unsterilized. 191 00:06:50,260 --> 00:06:52,629 You convert it back into a value. 192 00:06:52,630 --> 00:06:54,819 And this is very 193 00:06:54,820 --> 00:06:56,889 simple, you would say, but there have 194 00:06:56,890 --> 00:06:58,269 been too many vulnerabilities there and 195 00:06:58,270 --> 00:06:59,919 we'll see exactly why. 196 00:06:59,920 --> 00:07:01,269 So let's have an example of 197 00:07:01,270 --> 00:07:03,039 serialization. OK, soon we want to 198 00:07:03,040 --> 00:07:05,379 serialize this nice 199 00:07:05,380 --> 00:07:07,479 array that has another inside of it 200 00:07:07,480 --> 00:07:08,379 and so on. 201 00:07:08,380 --> 00:07:10,629 And we'll go step by step and serialize 202 00:07:10,630 --> 00:07:13,149 it to to Syria to unsterilized format. 203 00:07:13,150 --> 00:07:15,189 So first, we're serializing an array with 204 00:07:15,190 --> 00:07:16,539 four elements. 205 00:07:16,540 --> 00:07:18,219 So as you can see down below we have the 206 00:07:18,220 --> 00:07:20,859 string and it's a column for 207 00:07:20,860 --> 00:07:22,989 a four every column, four 208 00:07:22,990 --> 00:07:24,639 for four values. 209 00:07:24,640 --> 00:07:26,949 And in every 210 00:07:26,950 --> 00:07:28,659 array is actually a hash table or a 211 00:07:28,660 --> 00:07:29,919 dictionary. 212 00:07:29,920 --> 00:07:32,049 So it's a key value store. 213 00:07:32,050 --> 00:07:34,119 But when you have an array, it's 214 00:07:34,120 --> 00:07:35,169 the keys are implicit. 215 00:07:35,170 --> 00:07:37,719 The keys are just running index, 216 00:07:37,720 --> 00:07:39,109 running index and it's implicit. 217 00:07:39,110 --> 00:07:41,439 So we're serializing the first entry. 218 00:07:41,440 --> 00:07:43,339 It's integer zero as key. 219 00:07:43,340 --> 00:07:44,859 So you have Ikon zero. 220 00:07:44,860 --> 00:07:47,229 And now for the volume 221 00:07:47,230 --> 00:07:49,389 next we're serializing 222 00:07:49,390 --> 00:07:51,489 integer one for key and integer one three 223 00:07:51,490 --> 00:07:53,350 three seven as the volume 224 00:07:54,370 --> 00:07:57,069 and then we're serializing 225 00:07:57,070 --> 00:07:59,349 a string. So we have integer two 226 00:07:59,350 --> 00:08:00,909 as the key and string. 227 00:08:00,910 --> 00:08:02,919 So we have s four string Kullen five, 228 00:08:02,920 --> 00:08:03,909 four, five characters. 229 00:08:03,910 --> 00:08:04,839 Then we have Epel. 230 00:08:04,840 --> 00:08:06,759 This is the value of the string. 231 00:08:06,760 --> 00:08:08,619 Natsuo serializing another array so we 232 00:08:08,620 --> 00:08:10,839 have the implicit key integer free and 233 00:08:10,840 --> 00:08:12,909 the value a column free 234 00:08:12,910 --> 00:08:15,819 for three values in this 235 00:08:15,820 --> 00:08:16,959 nested area. 236 00:08:16,960 --> 00:08:19,449 Next we have an explicit key string 237 00:08:19,450 --> 00:08:21,369 so we have s four string column, one for 238 00:08:21,370 --> 00:08:23,499 one character a for the value of the 239 00:08:23,500 --> 00:08:25,569 string and this is the key and the value 240 00:08:25,570 --> 00:08:28,089 is integer one next to serializing 241 00:08:28,090 --> 00:08:29,889 a class and object actually. 242 00:08:29,890 --> 00:08:32,048 So we have gone back to the implicit 243 00:08:32,049 --> 00:08:34,239 keys. So it's integer zero as an implicit 244 00:08:34,240 --> 00:08:36,879 key. Then we have object 245 00:08:36,880 --> 00:08:38,859 that the class name has freekeh eight 246 00:08:38,860 --> 00:08:40,509 character. So it's called an eight 247 00:08:40,510 --> 00:08:43,149 column. The class name Usted declasse. 248 00:08:43,150 --> 00:08:45,039 Then we have Callon zero zero is the 249 00:08:45,040 --> 00:08:47,259 number of properties in this object. 250 00:08:47,260 --> 00:08:49,539 Zero properties, nothing in there, curly 251 00:08:49,540 --> 00:08:50,830 brackets with empty 252 00:08:52,060 --> 00:08:54,579 properties. Then we're serializing 253 00:08:54,580 --> 00:08:56,559 integer. One is key and integer seven 254 00:08:56,560 --> 00:08:57,969 fifty one as value. 255 00:08:57,970 --> 00:08:59,229 And this was the process of 256 00:08:59,230 --> 00:09:00,309 serialization. 257 00:09:00,310 --> 00:09:01,419 Quite straightforward. 258 00:09:01,420 --> 00:09:03,429 And we have this nice format that we know 259 00:09:03,430 --> 00:09:05,409 about. Next I want to show you exemptive 260 00:09:05,410 --> 00:09:07,479 and serialization and this would be the 261 00:09:07,480 --> 00:09:09,309 exact reverse. So it's going to be a bit 262 00:09:09,310 --> 00:09:11,659 boring. But I want to show 263 00:09:11,660 --> 00:09:14,229 something here. PPY supports 264 00:09:14,230 --> 00:09:16,509 a feature called References and 265 00:09:16,510 --> 00:09:17,889 References means that during an 266 00:09:17,890 --> 00:09:20,409 serialization in the format, 267 00:09:20,410 --> 00:09:21,969 we can specify instead of specifying a 268 00:09:21,970 --> 00:09:23,889 value such as integer or string, we can 269 00:09:23,890 --> 00:09:25,449 specify a reference. 270 00:09:25,450 --> 00:09:27,729 And this tells the mechanism, 271 00:09:27,730 --> 00:09:29,949 go back, see what was the 272 00:09:29,950 --> 00:09:32,229 end value we just passed, 273 00:09:32,230 --> 00:09:34,839 which is a and I want a copy of this 274 00:09:34,840 --> 00:09:37,539 value or a reference to this value. 275 00:09:37,540 --> 00:09:39,339 And in order to support this feature 276 00:09:39,340 --> 00:09:41,499 during an serialization, every value 277 00:09:41,500 --> 00:09:43,719 that is passed by the insulin's mechanism 278 00:09:43,720 --> 00:09:45,189 is kept a reference to. 279 00:09:45,190 --> 00:09:47,379 So we have this array cultivar Hegira 280 00:09:47,380 --> 00:09:48,549 in this in this area. 281 00:09:48,550 --> 00:09:50,799 We have pointers to every parsed value 282 00:09:50,800 --> 00:09:52,929 and let's see how it's done so first and 283 00:09:52,930 --> 00:09:55,329 serializing an array with four elements 284 00:09:55,330 --> 00:09:57,339 so you can see in the fresh area and it's 285 00:09:57,340 --> 00:09:59,169 one based error. You have pointer to this 286 00:09:59,170 --> 00:10:01,479 array we just instantiated. 287 00:10:01,480 --> 00:10:03,669 Next we have a key integer 288 00:10:03,670 --> 00:10:05,919 zero and value now and 289 00:10:05,920 --> 00:10:07,509 we considered the second pointer points 290 00:10:07,510 --> 00:10:09,789 to the null we just passed. 291 00:10:09,790 --> 00:10:11,889 Next we have integer one key 292 00:10:11,890 --> 00:10:13,869 integer one four three seven as a value 293 00:10:13,870 --> 00:10:15,679 and the third pointer points to one three 294 00:10:15,680 --> 00:10:16,749 three seven. 295 00:10:16,750 --> 00:10:18,849 Then we have the string Epel 296 00:10:18,850 --> 00:10:21,099 as the value and the first pointer for 297 00:10:21,100 --> 00:10:23,049 pointer points to this value. 298 00:10:24,130 --> 00:10:26,259 Next, we have this 299 00:10:26,260 --> 00:10:27,849 array. Now, this is an internal array, 300 00:10:27,850 --> 00:10:30,099 but the varnish area is 301 00:10:30,100 --> 00:10:31,669 a flat area. So even though we have some 302 00:10:31,670 --> 00:10:33,339 nice thing here, we have array within an 303 00:10:33,340 --> 00:10:35,709 array in the value IT values are 304 00:10:35,710 --> 00:10:37,839 nested, the very hash 305 00:10:37,840 --> 00:10:39,999 array is flat and the 306 00:10:40,000 --> 00:10:42,099 pointer points to the array NextEra and 307 00:10:42,100 --> 00:10:44,229 serializing the key A and 308 00:10:44,230 --> 00:10:45,459 the value one and. 309 00:10:45,460 --> 00:10:47,409 We have another pointer to the value, 310 00:10:47,410 --> 00:10:49,659 then we're in satiate, instantiating the 311 00:10:49,660 --> 00:10:52,149 steady objects, so we have another 312 00:10:52,150 --> 00:10:54,579 object there and a seven pointer points 313 00:10:54,580 --> 00:10:56,829 to this instantiated object. 314 00:10:56,830 --> 00:10:58,569 And now something interesting is going to 315 00:10:58,570 --> 00:11:00,909 happen. We're an serializing 316 00:11:00,910 --> 00:11:02,769 a reference to the third value. 317 00:11:02,770 --> 00:11:05,589 So what would happen here? 318 00:11:05,590 --> 00:11:06,939 The answer is functionality. 319 00:11:06,940 --> 00:11:09,429 We'll go and check the Rajeshwari, 320 00:11:09,430 --> 00:11:10,489 go to the third value. 321 00:11:10,490 --> 00:11:12,729 The third value here is the pointer 322 00:11:12,730 --> 00:11:15,219 to the integer one four, three, seven. 323 00:11:15,220 --> 00:11:17,319 And now we need to create 324 00:11:17,320 --> 00:11:18,879 a reference to this value. 325 00:11:18,880 --> 00:11:20,169 So this is what we do. 326 00:11:20,170 --> 00:11:22,179 We can serialize this value and we create 327 00:11:22,180 --> 00:11:24,399 a reference to a previously parsed 328 00:11:24,400 --> 00:11:27,519 value. So this hope supports 329 00:11:27,520 --> 00:11:29,439 this feature of references of backward 330 00:11:29,440 --> 00:11:31,659 references and this mechanism. 331 00:11:31,660 --> 00:11:33,939 This feature caused many bugs in the past 332 00:11:33,940 --> 00:11:36,519 because as you can see, we keep a pointer 333 00:11:36,520 --> 00:11:38,619 to stuff we maybe need maybe we 334 00:11:38,620 --> 00:11:39,519 don't need it again. 335 00:11:39,520 --> 00:11:41,679 And there has been some confusions over 336 00:11:41,680 --> 00:11:42,680 the years. 337 00:11:43,980 --> 00:11:46,529 If you got lost in this complicated 338 00:11:46,530 --> 00:11:47,939 format, there are some points I want you 339 00:11:47,940 --> 00:11:50,339 to remember. So first, it's a complicated 340 00:11:50,340 --> 00:11:51,929 format, OK? 341 00:11:51,930 --> 00:11:54,179 Yes, obviously in complicated formats 342 00:11:54,180 --> 00:11:56,969 leads to bugs and 343 00:11:56,970 --> 00:11:58,740 bugs. And we're going to see it soon. 344 00:12:00,120 --> 00:12:01,829 We have many, many ways to control 345 00:12:01,830 --> 00:12:04,109 allocations, right. Where instantiating 346 00:12:04,110 --> 00:12:06,179 objects were instantiating were and 347 00:12:06,180 --> 00:12:08,849 serializing strings of various lands. 348 00:12:08,850 --> 00:12:10,589 We are an serializing hash tables of 349 00:12:10,590 --> 00:12:12,629 various lands. So we have lots of control 350 00:12:12,630 --> 00:12:14,819 as users and we keep 351 00:12:14,820 --> 00:12:16,079 these references things. 352 00:12:16,080 --> 00:12:18,359 So we keep references backwards 353 00:12:18,360 --> 00:12:20,879 to things we unsterilized in the past and 354 00:12:20,880 --> 00:12:21,809 we can reuse them. 355 00:12:21,810 --> 00:12:23,489 So in his case, we have some use. 356 00:12:23,490 --> 00:12:25,319 After free, we managed to free some 357 00:12:25,320 --> 00:12:27,329 object in some magical way. 358 00:12:27,330 --> 00:12:28,829 We still have control and we can go 359 00:12:28,830 --> 00:12:30,929 forward as exploiters. 360 00:12:30,930 --> 00:12:33,149 So now we talk about the Zevo system 361 00:12:33,150 --> 00:12:34,349 in PPY. 362 00:12:34,350 --> 00:12:36,359 Now, Zervos are basically values like 363 00:12:36,360 --> 00:12:38,969 this, how to interpret their calls, 364 00:12:38,970 --> 00:12:41,099 values or host variables. 365 00:12:41,100 --> 00:12:42,179 This is a variable. 366 00:12:42,180 --> 00:12:44,249 I'm sorry that we have to stop, but 367 00:12:45,340 --> 00:12:47,069 there won't be much of it anymore any 368 00:12:47,070 --> 00:12:49,079 time soon. So anytime soon. 369 00:12:49,080 --> 00:12:51,479 And as high level language, 370 00:12:51,480 --> 00:12:52,979 we have a couple of features for our 371 00:12:52,980 --> 00:12:53,969 variables. 372 00:12:53,970 --> 00:12:56,069 One, we have automatic memory management 373 00:12:56,070 --> 00:12:58,319 or a garbage collection and we 374 00:12:58,320 --> 00:13:00,179 have this references reference. 375 00:13:00,180 --> 00:13:02,519 When Y is a reference 376 00:13:02,520 --> 00:13:05,009 to X, it means that the value 377 00:13:05,010 --> 00:13:07,799 of variable Y changes when the value of 378 00:13:07,800 --> 00:13:09,989 X changes and vice versa. 379 00:13:09,990 --> 00:13:12,209 So they both basically are variables 380 00:13:12,210 --> 00:13:13,230 holding the same value. 381 00:13:14,650 --> 00:13:16,739 And this is how the Zervos 382 00:13:16,740 --> 00:13:18,319 were implemented. In FY five. 383 00:13:18,320 --> 00:13:20,309 We had this struct called Zevo. 384 00:13:20,310 --> 00:13:21,959 It was on the hip, it was referenced, 385 00:13:21,960 --> 00:13:24,269 counted, and every Zevo was basically 386 00:13:24,270 --> 00:13:26,549 a pointer to this struct. 387 00:13:26,550 --> 00:13:28,349 And every time we created a new level, we 388 00:13:28,350 --> 00:13:30,959 had to create to allocate destruct 389 00:13:30,960 --> 00:13:33,509 on the hip and initialize it to 390 00:13:33,510 --> 00:13:36,329 the memory management was quite 391 00:13:36,330 --> 00:13:38,399 obvious. We have reference count and we 392 00:13:38,400 --> 00:13:40,259 have memory cycle detection. 393 00:13:40,260 --> 00:13:42,749 So it was a very simple algorithm 394 00:13:42,750 --> 00:13:44,369 which most people know about. 395 00:13:44,370 --> 00:13:46,589 And to make references to make 396 00:13:46,590 --> 00:13:48,539 two variables point to the same value was 397 00:13:48,540 --> 00:13:50,939 just to pointer is pointing to the same 398 00:13:50,940 --> 00:13:53,729 struct and everything was very simple, 399 00:13:53,730 --> 00:13:55,889 very nice, but it was 400 00:13:55,890 --> 00:13:58,379 slow. So when implementing 401 00:13:58,380 --> 00:14:01,529 P seven and having some motivation, 402 00:14:01,530 --> 00:14:04,349 motivations to change it and 403 00:14:04,350 --> 00:14:05,789 the implementors wanted list the 404 00:14:05,790 --> 00:14:07,919 references. Now if Zevo laser 405 00:14:07,920 --> 00:14:09,479 pointer, every time you need to reference 406 00:14:09,480 --> 00:14:11,219 a value, you have to dereference the 407 00:14:11,220 --> 00:14:13,629 pointer, which can be expensive. 408 00:14:13,630 --> 00:14:15,449 Also, every time you create a new value, 409 00:14:15,450 --> 00:14:17,069 even if it's for a short time, even if 410 00:14:17,070 --> 00:14:18,299 you know exactly where it is, we still 411 00:14:18,300 --> 00:14:20,399 have to make allocation on the hip, 412 00:14:20,400 --> 00:14:22,529 which can be expensive. 413 00:14:22,530 --> 00:14:24,479 So they designed a system for embedding. 414 00:14:24,480 --> 00:14:26,099 They said, OK, I don't want to see those 415 00:14:26,100 --> 00:14:27,299 to be just on the hip. 416 00:14:27,300 --> 00:14:28,439 I want to be able to embed them 417 00:14:28,440 --> 00:14:30,359 everywhere I went on the stack in order 418 00:14:30,360 --> 00:14:31,380 struct and so on. 419 00:14:32,490 --> 00:14:34,499 And this is how the new level system is 420 00:14:34,500 --> 00:14:36,299 implemented. We have this Zevo struct, 421 00:14:36,300 --> 00:14:37,409 but now it's a bit different. 422 00:14:37,410 --> 00:14:38,410 It's simpler. 423 00:14:39,270 --> 00:14:41,519 Zervos are just destruct and this 424 00:14:41,520 --> 00:14:43,739 contains only value in type. 425 00:14:43,740 --> 00:14:46,169 So there is no reference counting and 426 00:14:46,170 --> 00:14:48,179 we can put this struct wherever we want. 427 00:14:49,500 --> 00:14:51,599 And the value thing here 428 00:14:51,600 --> 00:14:53,099 can be one of two things. 429 00:14:53,100 --> 00:14:55,019 It can be a primitive type, for example, 430 00:14:55,020 --> 00:14:57,449 primitive type like integers or floats 431 00:14:57,450 --> 00:14:57,929 and so on. 432 00:14:57,930 --> 00:15:00,509 But PPY supports also strings. 433 00:15:00,510 --> 00:15:02,489 So if you want to support complex types 434 00:15:02,490 --> 00:15:04,619 like strings or objects, Disvalue would 435 00:15:04,620 --> 00:15:06,839 be a pointer to a complex struct 436 00:15:06,840 --> 00:15:09,299 and this fact will be on the hip. 437 00:15:09,300 --> 00:15:11,429 OK, so this struct will not be 438 00:15:11,430 --> 00:15:13,469 on the stack, it will be somewhere on the 439 00:15:13,470 --> 00:15:15,089 hip and it will also be referenced, 440 00:15:15,090 --> 00:15:16,090 counted. 441 00:15:17,310 --> 00:15:18,449 So here's an example. 442 00:15:18,450 --> 00:15:20,729 This is an integer, and in memory, 443 00:15:20,730 --> 00:15:22,919 we'll just have the value one three, 444 00:15:22,920 --> 00:15:25,499 three seven and the type long, 445 00:15:25,500 --> 00:15:27,239 that's it. We don't know where it is. 446 00:15:27,240 --> 00:15:29,279 And it's quite simple 447 00:15:30,630 --> 00:15:33,449 now to support reference counting. 448 00:15:33,450 --> 00:15:35,549 Now it's the responsibility of 449 00:15:35,550 --> 00:15:37,289 whoever initialize that initialized 450 00:15:37,290 --> 00:15:38,849 Decebal. Right. If Decebal is in a 451 00:15:38,850 --> 00:15:41,009 struct, whoever initialize destruct 452 00:15:41,010 --> 00:15:42,659 needs to clear it up. 453 00:15:42,660 --> 00:15:44,909 But there is one complication 454 00:15:44,910 --> 00:15:47,129 here. If the value is a primitive 455 00:15:47,130 --> 00:15:48,059 value, everything is good. 456 00:15:48,060 --> 00:15:50,639 But if it's a pointer to another struct, 457 00:15:50,640 --> 00:15:51,779 this structure should be referenced, 458 00:15:51,780 --> 00:15:53,759 counted and when it's referenced and this 459 00:15:53,760 --> 00:15:55,949 is how the garbage collection works, 460 00:15:55,950 --> 00:15:58,319 it checks disvalue pointed 461 00:15:58,320 --> 00:16:00,209 by this evil and it has also reference 462 00:16:00,210 --> 00:16:02,069 count and garbage collection. 463 00:16:02,070 --> 00:16:03,359 Now let's see an example. 464 00:16:03,360 --> 00:16:05,129 OK, so this is the string struct. 465 00:16:05,130 --> 00:16:06,539 As I said, it's a complex type. 466 00:16:06,540 --> 00:16:08,789 So this struct is on the hip 467 00:16:08,790 --> 00:16:10,589 and is pointed by Zevo. 468 00:16:10,590 --> 00:16:12,689 As you can see, the first field 469 00:16:12,690 --> 00:16:14,789 in this struct is the reference count 470 00:16:14,790 --> 00:16:17,129 and the left field is a flexible array 471 00:16:17,130 --> 00:16:19,269 member array, remember. 472 00:16:19,270 --> 00:16:21,659 So when 473 00:16:21,660 --> 00:16:23,819 when allocating a string, 474 00:16:23,820 --> 00:16:25,889 we allocate more data, enough 475 00:16:25,890 --> 00:16:28,379 memory to store to string content itself 476 00:16:28,380 --> 00:16:30,599 and we exit via this 477 00:16:30,600 --> 00:16:31,709 field. 478 00:16:31,710 --> 00:16:33,749 So this is what it looks like when we're 479 00:16:33,750 --> 00:16:34,750 initializing 480 00:16:36,180 --> 00:16:38,699 and variable string. 481 00:16:38,700 --> 00:16:40,859 Then we have this struct it's of 482 00:16:40,860 --> 00:16:42,989 type string. We're allocating the 483 00:16:42,990 --> 00:16:44,849 string on the hip. 484 00:16:44,850 --> 00:16:46,559 We initialize it with the values. 485 00:16:46,560 --> 00:16:48,719 You can see we put the value Epel here 486 00:16:48,720 --> 00:16:50,789 and we just point the Zevo 487 00:16:50,790 --> 00:16:52,769 to this string and the reference count is 488 00:16:52,770 --> 00:16:53,770 one. 489 00:16:54,120 --> 00:16:56,219 And this construct is under 490 00:16:56,220 --> 00:16:57,220 hyp. 491 00:16:58,410 --> 00:17:00,479 So how can we manage 492 00:17:00,480 --> 00:17:01,539 the references? 493 00:17:01,540 --> 00:17:03,629 How do the references feature 494 00:17:03,630 --> 00:17:04,630 was implemented 495 00:17:05,730 --> 00:17:08,368 this time? We cannot just make one 496 00:17:08,369 --> 00:17:10,559 zero point to another because they may be 497 00:17:10,560 --> 00:17:12,449 in different scopes. One can be instruct, 498 00:17:12,450 --> 00:17:14,848 the other can be on the stack and 499 00:17:14,849 --> 00:17:17,219 they must be managed. 500 00:17:17,220 --> 00:17:19,559 Right. So there is a solution 501 00:17:19,560 --> 00:17:21,779 here in PRPD 502 00:17:21,780 --> 00:17:24,149 implemented another 503 00:17:24,150 --> 00:17:26,368 type called references, and it's easier 504 00:17:26,369 --> 00:17:28,469 to show than experience or show how it 505 00:17:28,470 --> 00:17:29,470 works. 506 00:17:29,970 --> 00:17:32,099 Assume you have this variable X, 507 00:17:32,100 --> 00:17:33,449 which has one, four, three, seven, and 508 00:17:33,450 --> 00:17:35,039 now we have the verbal way, which is a 509 00:17:35,040 --> 00:17:37,469 reference to variable X. 510 00:17:37,470 --> 00:17:39,119 OK, so we have it in memory and I want to 511 00:17:39,120 --> 00:17:40,379 make a reference to it. 512 00:17:40,380 --> 00:17:43,259 So we initialize 513 00:17:43,260 --> 00:17:45,479 a new struct on the hip 514 00:17:45,480 --> 00:17:47,219 called the reference, and this struct has 515 00:17:47,220 --> 00:17:48,419 two fields. The first field is a 516 00:17:48,420 --> 00:17:50,699 reference count and a second field 517 00:17:50,700 --> 00:17:52,799 is another Zevo, and we initialize this 518 00:17:52,800 --> 00:17:55,289 Zevo value to be the same as X, 519 00:17:55,290 --> 00:17:57,029 so you can see it contains a copy of the 520 00:17:57,030 --> 00:17:59,759 value. Then we change the type of X 521 00:17:59,760 --> 00:18:01,649 to be a reference and now it points to 522 00:18:01,650 --> 00:18:02,879 the same reference and now we can 523 00:18:02,880 --> 00:18:04,799 initialize Y and we will be the same. 524 00:18:04,800 --> 00:18:06,509 So it also be a reference to something on 525 00:18:06,510 --> 00:18:08,729 the tape. So we moved the contents 526 00:18:08,730 --> 00:18:11,459 of X to the hip and now we can have 527 00:18:11,460 --> 00:18:13,259 the two civils X and Y. 528 00:18:13,260 --> 00:18:14,789 We just pointers through the hip like 529 00:18:14,790 --> 00:18:15,790 previously. 530 00:18:17,400 --> 00:18:19,769 The key thing to remember about Zervos is 531 00:18:19,770 --> 00:18:21,179 that they're designed for embedding so 532 00:18:21,180 --> 00:18:23,099 they can be in many places which can 533 00:18:23,100 --> 00:18:24,239 cause some bugs. 534 00:18:25,470 --> 00:18:28,169 The motivations or goals were achieved. 535 00:18:28,170 --> 00:18:30,089 There are less references and less hip 536 00:18:30,090 --> 00:18:32,189 usage, but making a 537 00:18:32,190 --> 00:18:34,559 reference is a bit complicated. 538 00:18:34,560 --> 00:18:36,809 Reference is not the feature 539 00:18:36,810 --> 00:18:39,119 that used too much except in exploits. 540 00:18:39,120 --> 00:18:40,449 So it is. 541 00:18:41,550 --> 00:18:43,709 Yeah. So this there 542 00:18:43,710 --> 00:18:45,809 is a trade off here between 543 00:18:45,810 --> 00:18:47,969 the Zervos are our most 544 00:18:47,970 --> 00:18:49,199 simple, but preference are more 545 00:18:49,200 --> 00:18:51,389 complicated and it's worth trade off in 546 00:18:51,390 --> 00:18:52,390 my opinion at least. 547 00:18:53,280 --> 00:18:55,499 So now that we know about and serialize 548 00:18:55,500 --> 00:18:57,569 and we know about Zevo, let's see 549 00:18:57,570 --> 00:18:58,910 some bugs and vulnerabilities. 550 00:19:00,210 --> 00:19:02,159 So first, the user financial value. 551 00:19:02,160 --> 00:19:04,289 Now, since Zervos 552 00:19:04,290 --> 00:19:06,479 used to be pointers, initializing 553 00:19:06,480 --> 00:19:08,339 pointers was very easy, right? 554 00:19:08,340 --> 00:19:10,049 Everybody knows how to initialize upon a 555 00:19:10,050 --> 00:19:11,549 pointer you just pointed to now and 556 00:19:11,550 --> 00:19:12,479 you're done. 557 00:19:12,480 --> 00:19:14,429 Initialize instructs is a different 558 00:19:14,430 --> 00:19:16,409 story, right? We need to initialize them 559 00:19:16,410 --> 00:19:18,689 with some macros or maybe some constants. 560 00:19:18,690 --> 00:19:20,399 It may take some time. 561 00:19:20,400 --> 00:19:22,589 And programmers tend to skip 562 00:19:22,590 --> 00:19:25,079 this phase if, if, if it's possible 563 00:19:25,080 --> 00:19:26,999 you don't initialize destructs, which is 564 00:19:27,000 --> 00:19:29,429 a problem. And this is a 565 00:19:29,430 --> 00:19:30,599 can lead to some vulnerability's. 566 00:19:30,600 --> 00:19:32,759 And this is the exact example here 567 00:19:32,760 --> 00:19:35,039 we have this function, the special object 568 00:19:35,040 --> 00:19:37,199 storage and serialize, and this 569 00:19:37,200 --> 00:19:39,719 function is the custom implementation 570 00:19:39,720 --> 00:19:41,849 of serialization of the struct 571 00:19:41,850 --> 00:19:43,859 SBL Object Storage. 572 00:19:43,860 --> 00:19:46,499 This class is implemented in C-code. 573 00:19:46,500 --> 00:19:49,079 Some of the classes in the SBL, the 574 00:19:49,080 --> 00:19:51,359 standard library are implemented in C 575 00:19:51,360 --> 00:19:52,769 and this is the case here. 576 00:19:52,770 --> 00:19:54,899 And as you can see, the first line, two 577 00:19:54,900 --> 00:19:57,329 variables are declared entry and 578 00:19:57,330 --> 00:19:58,979 these are Zevo. 579 00:19:58,980 --> 00:20:01,619 So there are Zevo struct 580 00:20:01,620 --> 00:20:03,689 and at no point in this code 581 00:20:03,690 --> 00:20:05,399 they're initialized. 582 00:20:05,400 --> 00:20:07,469 And after a few lines of code, we reach 583 00:20:07,470 --> 00:20:10,019 this statement calling 584 00:20:10,020 --> 00:20:12,029 the function Pevar and serialize. 585 00:20:12,030 --> 00:20:14,099 This is the C implementation of the 586 00:20:14,100 --> 00:20:15,749 unsterilized function. 587 00:20:15,750 --> 00:20:17,999 And the first value is a pointer to this 588 00:20:18,000 --> 00:20:19,139 that was never initialized. 589 00:20:19,140 --> 00:20:20,999 And this is supposed to be an out 590 00:20:21,000 --> 00:20:23,129 variable, but it's not 591 00:20:23,130 --> 00:20:24,989 OK. So but this is where we were going to 592 00:20:24,990 --> 00:20:27,809 store the string and serializing 593 00:20:27,810 --> 00:20:29,999 the next variable is P p points 594 00:20:30,000 --> 00:20:31,319 to the stringer and serializing. 595 00:20:31,320 --> 00:20:33,029 So this function, what it does, it's 596 00:20:33,030 --> 00:20:35,099 unsterilized is the string pointed by 597 00:20:35,100 --> 00:20:38,099 P and stores the value in F. 598 00:20:38,100 --> 00:20:40,199 However, internally we reach 599 00:20:40,200 --> 00:20:42,269 this line of code Zevo 600 00:20:42,270 --> 00:20:44,249 Pointer Destroy, which means please 601 00:20:44,250 --> 00:20:46,469 destroy the Zevo which is pointed by 602 00:20:46,470 --> 00:20:47,369 our Val. Right. 603 00:20:47,370 --> 00:20:49,409 And what is Auroville? In our case? 604 00:20:49,410 --> 00:20:50,729 It's inf. 605 00:20:50,730 --> 00:20:52,799 It's exactly the thing we did not 606 00:20:52,800 --> 00:20:54,269 initialize at no point. 607 00:20:54,270 --> 00:20:56,579 And the reason the code does this is 608 00:20:56,580 --> 00:20:59,019 to make sure there is no value in this 609 00:20:59,020 --> 00:21:01,469 before writing new values. 610 00:21:01,470 --> 00:21:03,299 But since this value was never 611 00:21:03,300 --> 00:21:05,429 initialized, what's in this value 612 00:21:05,430 --> 00:21:06,659 is garbage from the stack. 613 00:21:06,660 --> 00:21:08,579 And if you shape your stack correctly, 614 00:21:08,580 --> 00:21:10,889 you can cause some bad things to happen. 615 00:21:10,890 --> 00:21:13,229 So this was Sivi two dozen 16 seven 616 00:21:13,230 --> 00:21:14,550 four eight zero. 617 00:21:16,020 --> 00:21:17,549 OK, so the next example is type 618 00:21:17,550 --> 00:21:19,739 confusion. And we are 619 00:21:19,740 --> 00:21:21,059 going to rely on the fact that making 620 00:21:21,060 --> 00:21:23,819 references is very complicated 621 00:21:23,820 --> 00:21:26,009 process as you see any changes, the type 622 00:21:26,010 --> 00:21:28,139 of the Zevo, OK, and 623 00:21:28,140 --> 00:21:30,389 we can suspect somebody forgot 624 00:21:30,390 --> 00:21:31,769 about this possibility and this is 625 00:21:31,770 --> 00:21:33,569 exactly what's happened. 626 00:21:33,570 --> 00:21:35,519 So we have the same function again. 627 00:21:35,520 --> 00:21:37,589 And this is you have more 628 00:21:37,590 --> 00:21:39,089 lines of code from the same function, but 629 00:21:39,090 --> 00:21:41,159 it's the unsterilized of the SBL 630 00:21:41,160 --> 00:21:42,509 object storage. 631 00:21:42,510 --> 00:21:44,519 And as you can see in the second line 632 00:21:44,520 --> 00:21:45,989 here, we are calling the internal 633 00:21:45,990 --> 00:21:48,269 unsterilized and we're again converting 634 00:21:48,270 --> 00:21:50,579 the string pointed by P and 635 00:21:50,580 --> 00:21:53,189 stored to the result 636 00:21:53,190 --> 00:21:55,289 in the Zevo entry. 637 00:21:55,290 --> 00:21:57,359 OK, two lines later 638 00:21:57,360 --> 00:21:59,339 we're talking. The type of what we just 639 00:21:59,340 --> 00:22:01,349 unsterilized making sure is of type 640 00:22:01,350 --> 00:22:03,779 object, so you can see that if 641 00:22:03,780 --> 00:22:05,939 the type of entry is not the object, 642 00:22:05,940 --> 00:22:07,499 the function builds, better things 643 00:22:07,500 --> 00:22:09,839 happen. But if it's nothing 644 00:22:09,840 --> 00:22:11,819 should happen, but if it's a type object, 645 00:22:11,820 --> 00:22:13,829 we can go on and in the last line where 646 00:22:13,830 --> 00:22:14,830 an serializing 647 00:22:16,050 --> 00:22:18,149 the next value is advanced here and now 648 00:22:18,150 --> 00:22:20,219 it points onwards 649 00:22:20,220 --> 00:22:21,929 in the string and we're converting the 650 00:22:21,930 --> 00:22:25,199 string pointed by and store it into ENF. 651 00:22:25,200 --> 00:22:27,569 But what happens if enough is 652 00:22:27,570 --> 00:22:29,369 actually a reference to entry? 653 00:22:29,370 --> 00:22:30,689 Well, the type of entry is going to 654 00:22:30,690 --> 00:22:33,029 change and let's see how what happens. 655 00:22:33,030 --> 00:22:35,579 So first on serializing entry 656 00:22:35,580 --> 00:22:38,159 and it's an object and we're checking 657 00:22:38,160 --> 00:22:40,019 and this is actually an object and 658 00:22:40,020 --> 00:22:41,909 everything is good but next year and 659 00:22:41,910 --> 00:22:44,219 serializing ENF and ENF is 660 00:22:44,220 --> 00:22:46,829 a reference to entry. 661 00:22:46,830 --> 00:22:48,899 So according to the process, first 662 00:22:48,900 --> 00:22:51,149 we're allocating a Zen reference on the 663 00:22:51,150 --> 00:22:53,399 hip and we're initializing to be 664 00:22:53,400 --> 00:22:54,989 the copy of entry. 665 00:22:54,990 --> 00:22:56,939 Then we're changing the type of entry to 666 00:22:56,940 --> 00:22:59,099 be of type, reference and point to 667 00:22:59,100 --> 00:23:00,749 this reference. And of course, Lesli, 668 00:23:00,750 --> 00:23:03,029 we're initializing ENF, but 669 00:23:03,030 --> 00:23:05,039 in this process we actually change the 670 00:23:05,040 --> 00:23:07,109 type of entry after we 671 00:23:07,110 --> 00:23:08,039 checked it. 672 00:23:08,040 --> 00:23:10,109 So this is a bug and actually better 673 00:23:10,110 --> 00:23:11,110 things happen. 674 00:23:11,970 --> 00:23:13,739 It's not exploitable, but it's still a 675 00:23:13,740 --> 00:23:15,539 bug and was fixed. So this is about seven 676 00:23:15,540 --> 00:23:17,629 three two five eight in 677 00:23:17,630 --> 00:23:19,289 pieces system. 678 00:23:19,290 --> 00:23:21,479 OK, so here is this is the last bug 679 00:23:21,480 --> 00:23:23,939 for today and it's a use after three. 680 00:23:23,940 --> 00:23:26,249 And a problem stems from the fact that 681 00:23:26,250 --> 00:23:28,739 now Zyvox are embedded instructs 682 00:23:28,740 --> 00:23:30,929 and we keep pointers to receivals, but 683 00:23:30,930 --> 00:23:32,849 trucks have their own rules of how they 684 00:23:32,850 --> 00:23:35,249 change. And some structures 685 00:23:35,250 --> 00:23:37,379 tend to change to place in memory 686 00:23:37,380 --> 00:23:40,109 without telling any anything else. 687 00:23:40,110 --> 00:23:41,879 And if we keep using these pointers, 688 00:23:41,880 --> 00:23:43,739 we're actually pointing to Nauru, which 689 00:23:43,740 --> 00:23:46,559 is not not not valid anymore. 690 00:23:46,560 --> 00:23:48,809 So such a dynamic 691 00:23:48,810 --> 00:23:50,969 struct can be a hash table, for example. 692 00:23:50,970 --> 00:23:53,039 And this code is processing 693 00:23:53,040 --> 00:23:54,449 the data function. 694 00:23:54,450 --> 00:23:55,889 This function is a function that 695 00:23:55,890 --> 00:23:58,079 processes every hash table 696 00:23:58,080 --> 00:23:59,939 during the serialization, and tables can 697 00:23:59,940 --> 00:24:02,039 be also properties 698 00:24:02,040 --> 00:24:03,749 of an object. 699 00:24:03,750 --> 00:24:05,069 And here in the first line, we're 700 00:24:05,070 --> 00:24:07,319 declaring it variables and the next 701 00:24:07,320 --> 00:24:09,299 line we're adding a new entry to a hash 702 00:24:09,300 --> 00:24:10,259 table. 703 00:24:10,260 --> 00:24:12,419 So what we do here is Zend hash 704 00:24:12,420 --> 00:24:14,729 at new we're adding a new entry. 705 00:24:14,730 --> 00:24:17,339 The first parameter is the hash table 706 00:24:17,340 --> 00:24:19,139 and the second part is the key. 707 00:24:19,140 --> 00:24:20,729 And the result of this function is a 708 00:24:20,730 --> 00:24:22,859 pointer to this evil. 709 00:24:22,860 --> 00:24:23,879 That is the value. 710 00:24:23,880 --> 00:24:25,949 So we get data points to 711 00:24:25,950 --> 00:24:29,099 this Zevo we need to fill 712 00:24:29,100 --> 00:24:31,469 and then we're calling the last line. 713 00:24:31,470 --> 00:24:32,939 This line calls the internal 714 00:24:32,940 --> 00:24:35,219 implementation of Serialize and 715 00:24:35,220 --> 00:24:37,649 again, it converts the string 716 00:24:37,650 --> 00:24:39,809 pointed by P and starts is 717 00:24:39,810 --> 00:24:41,999 stores its value in data where 718 00:24:42,000 --> 00:24:44,099 data is pointing to not look at the 719 00:24:44,100 --> 00:24:45,509 list parameter here. 720 00:24:45,510 --> 00:24:47,219 It's the VA hash, this array we talked 721 00:24:47,220 --> 00:24:49,499 about in the previous part and 722 00:24:49,500 --> 00:24:52,919 VA hash keeps pointers to every 723 00:24:52,920 --> 00:24:55,469 piece of every value we passed, 724 00:24:55,470 --> 00:24:56,849 including data. 725 00:24:56,850 --> 00:24:58,769 So data points internally to the hash 726 00:24:58,770 --> 00:25:00,999 table and it is stored in the in 727 00:25:01,000 --> 00:25:02,579 the VA hash. 728 00:25:02,580 --> 00:25:04,409 But what happens if you manage to insert 729 00:25:04,410 --> 00:25:06,359 another value to the hash table? 730 00:25:06,360 --> 00:25:08,369 Then the hash will might resize right. 731 00:25:08,370 --> 00:25:10,589 Hash tables, gross sometimes in memory 732 00:25:10,590 --> 00:25:12,119 and when they grow internally they 733 00:25:12,120 --> 00:25:13,949 reallocate their memory to store 734 00:25:13,950 --> 00:25:15,359 additional values. 735 00:25:15,360 --> 00:25:17,399 So this is how it looks like in the first 736 00:25:17,400 --> 00:25:19,199 year and serializing an object. 737 00:25:19,200 --> 00:25:21,419 And this object has some properties, for 738 00:25:21,420 --> 00:25:23,159 example, it has to poverties zero and 739 00:25:23,160 --> 00:25:25,559 one. And then magically we managed 740 00:25:25,560 --> 00:25:27,749 to insert another value to the properties 741 00:25:27,750 --> 00:25:30,809 hash table and it reallocates. 742 00:25:30,810 --> 00:25:33,059 So now the hash points 743 00:25:33,060 --> 00:25:35,159 to the new value that was 744 00:25:35,160 --> 00:25:36,149 serialized. 745 00:25:36,150 --> 00:25:37,979 But the two previous values are not valid 746 00:25:37,980 --> 00:25:38,980 anymore. 747 00:25:39,570 --> 00:25:41,969 And this is not very common scenario. 748 00:25:41,970 --> 00:25:43,679 It's quite hard to exploit this or to 749 00:25:43,680 --> 00:25:45,719 trigger it is vulnerability, actually, 750 00:25:45,720 --> 00:25:48,749 because if you remember the format before 751 00:25:48,750 --> 00:25:50,939 and serializing an object, there 752 00:25:50,940 --> 00:25:53,129 is a number of properties in this object 753 00:25:53,130 --> 00:25:55,199 and B, makes sure the hash table 754 00:25:55,200 --> 00:25:57,329 has enough capacity to hold 755 00:25:57,330 --> 00:25:59,129 all these properties. 756 00:25:59,130 --> 00:26:00,130 Yep. 757 00:26:01,110 --> 00:26:03,029 There are two ways to do trigger this 758 00:26:03,030 --> 00:26:04,529 vulnerability. The first one is the wake 759 00:26:04,530 --> 00:26:06,659 up function, and this is a function 760 00:26:06,660 --> 00:26:08,729 that objects can define. 761 00:26:08,730 --> 00:26:10,979 And this function, this method is called 762 00:26:10,980 --> 00:26:13,349 after the object has been serialized. 763 00:26:13,350 --> 00:26:16,049 And if for some reason dysfunction 764 00:26:16,050 --> 00:26:18,539 defines a new 765 00:26:18,540 --> 00:26:20,909 property on the fly, then the interpreter 766 00:26:20,910 --> 00:26:23,069 is not aware of this beforehand. 767 00:26:23,070 --> 00:26:25,259 So inserting a new property on the fly 768 00:26:25,260 --> 00:26:26,729 can cause this. 769 00:26:26,730 --> 00:26:28,349 This can trigger this vulnerability. 770 00:26:28,350 --> 00:26:30,599 And also we have my all time favorite 771 00:26:30,600 --> 00:26:32,759 object in our class, the date interval 772 00:26:32,760 --> 00:26:34,919 class. And this class has a very 773 00:26:34,920 --> 00:26:36,269 interesting behavior. 774 00:26:36,270 --> 00:26:38,879 It does not initialize its properties 775 00:26:38,880 --> 00:26:41,039 hash table beforehand or 776 00:26:41,040 --> 00:26:42,040 it's actually 777 00:26:43,140 --> 00:26:45,269 only when accessing the properties of 778 00:26:45,270 --> 00:26:47,489 this object, then it defines 779 00:26:47,490 --> 00:26:49,229 and adds its properties to the hash 780 00:26:49,230 --> 00:26:51,449 table. So if we manage to 781 00:26:51,450 --> 00:26:53,639 come to some functionality, such as 782 00:26:53,640 --> 00:26:56,459 to string or wake up, that touches 783 00:26:56,460 --> 00:26:57,829 this object. 784 00:26:57,830 --> 00:26:59,879 Or some objects, properties such as the 785 00:26:59,880 --> 00:27:01,009 interval we can trigger this 786 00:27:01,010 --> 00:27:03,139 vulnerability, and 787 00:27:03,140 --> 00:27:05,389 this was Sivi 2016 seven four 788 00:27:05,390 --> 00:27:06,390 seven nine. 789 00:27:07,160 --> 00:27:09,409 So these bugs 790 00:27:09,410 --> 00:27:10,639 are complicated. There are still 791 00:27:10,640 --> 00:27:12,889 unsterilized vulnerabilities even 792 00:27:12,890 --> 00:27:14,449 between the time I submitted this stock 793 00:27:14,450 --> 00:27:16,609 and to date or has been at least one more 794 00:27:16,610 --> 00:27:19,039 that was reported and published, 795 00:27:20,150 --> 00:27:21,589 the vulnerabilities are a bit different 796 00:27:21,590 --> 00:27:22,999 than what we used to see because the 797 00:27:23,000 --> 00:27:25,309 civil system is a bit different, but 798 00:27:25,310 --> 00:27:27,229 still very corruptions. 799 00:27:27,230 --> 00:27:29,359 And these vulnerabilities let us 800 00:27:29,360 --> 00:27:31,429 use frid values as 801 00:27:31,430 --> 00:27:32,569 we've seen the two vulnerabilities. 802 00:27:32,570 --> 00:27:34,609 Let us reuse the feed values. 803 00:27:34,610 --> 00:27:36,739 And this is a property that we're 804 00:27:36,740 --> 00:27:38,809 going to need in order to exploit these 805 00:27:38,810 --> 00:27:39,810 vulnerabilities. 806 00:27:41,180 --> 00:27:43,849 So after we know about 807 00:27:43,850 --> 00:27:46,099 how the system works internally and 808 00:27:46,100 --> 00:27:48,229 is the civil system works and we 809 00:27:48,230 --> 00:27:50,299 found some bugs, are we going to talk 810 00:27:50,300 --> 00:27:51,859 a bit about the alligator? 811 00:27:51,860 --> 00:27:53,929 Because when exploiting this 812 00:27:53,930 --> 00:27:55,609 kind of corruption vulnerabilities, we 813 00:27:55,610 --> 00:27:57,799 need to know how the 814 00:27:57,800 --> 00:27:59,719 alligator works, how memory looks like. 815 00:28:00,980 --> 00:28:03,109 So we had the previous alligator 816 00:28:03,110 --> 00:28:04,489 of Peachtree five, and it's not too 817 00:28:04,490 --> 00:28:07,369 important, but it was he based alligator 818 00:28:07,370 --> 00:28:09,709 and every slot slot is the 819 00:28:09,710 --> 00:28:12,049 allocation unit in. 820 00:28:12,050 --> 00:28:14,269 OK, so it's called slot and it has 821 00:28:14,270 --> 00:28:17,779 this size and flex to each allocation 822 00:28:17,780 --> 00:28:19,789 and also a filius for caching. 823 00:28:19,790 --> 00:28:22,279 And it was it was very fine and was 824 00:28:22,280 --> 00:28:23,929 nice for exploiting. 825 00:28:23,930 --> 00:28:25,909 But now we have a different alligator. 826 00:28:25,910 --> 00:28:27,869 The alligator here is it's a completely 827 00:28:27,870 --> 00:28:30,379 right. There is nothing similar 828 00:28:30,380 --> 00:28:32,689 and it features beans or memory pulls as 829 00:28:32,690 --> 00:28:34,549 you know them and Frehley's. 830 00:28:34,550 --> 00:28:35,899 This is basically how the alligator 831 00:28:35,900 --> 00:28:37,219 works. These are the basic building 832 00:28:37,220 --> 00:28:38,239 blocks. 833 00:28:38,240 --> 00:28:40,069 And I'll go and throw some details at you 834 00:28:40,070 --> 00:28:42,350 and you probably see them or not. 835 00:28:43,400 --> 00:28:44,959 The alligator works in chunks of two 836 00:28:44,960 --> 00:28:46,909 megabytes from the operating system and 837 00:28:46,910 --> 00:28:49,489 these chunks are divided into pages. 838 00:28:49,490 --> 00:28:50,969 The first page is Page a script. 839 00:28:50,970 --> 00:28:53,389 He describes the chunk 840 00:28:53,390 --> 00:28:55,729 and it has a couple of strokes. 841 00:28:55,730 --> 00:28:57,439 The two important ones is the one 842 00:28:57,440 --> 00:28:59,509 describing the pages, which page 843 00:28:59,510 --> 00:29:02,119 pages are user free to use 844 00:29:02,120 --> 00:29:04,099 and pointers to the beans or to the 845 00:29:04,100 --> 00:29:07,159 Frehley's that were initialized. 846 00:29:07,160 --> 00:29:09,469 And every bin is a list 847 00:29:09,470 --> 00:29:12,049 of specific size we have the 32 848 00:29:12,050 --> 00:29:14,269 bytes mean we have the six invites being 849 00:29:14,270 --> 00:29:16,969 and it can spin over multiple pages. 850 00:29:16,970 --> 00:29:18,409 Now, let's say it in a way you can 851 00:29:18,410 --> 00:29:19,399 actually remember. 852 00:29:19,400 --> 00:29:21,559 So here is a chunk from the operating 853 00:29:21,560 --> 00:29:23,989 system. It's of two megabytes and it's 854 00:29:23,990 --> 00:29:26,449 divided. It is divided into pages. 855 00:29:26,450 --> 00:29:28,229 First page is the descriptor. 856 00:29:28,230 --> 00:29:29,479 You can see the free slots. 857 00:29:29,480 --> 00:29:31,969 It is just array of pointers 858 00:29:31,970 --> 00:29:34,249 to three lists and page info 859 00:29:34,250 --> 00:29:35,989 for each page. 860 00:29:35,990 --> 00:29:37,999 And this is what the bin looks like. 861 00:29:38,000 --> 00:29:40,339 So bin it can spend over multiple pages. 862 00:29:40,340 --> 00:29:42,499 This is the 16 bytes bin and we 863 00:29:42,500 --> 00:29:43,849 initialize it as a frailest. 864 00:29:43,850 --> 00:29:45,919 So every six invites points to the next 865 00:29:45,920 --> 00:29:48,169 bytes and we 866 00:29:48,170 --> 00:29:50,209 register it in the trunk descriptors. 867 00:29:50,210 --> 00:29:52,459 So we have the page information, 16 868 00:29:52,460 --> 00:29:54,559 bytes spends over two pages and 869 00:29:54,560 --> 00:29:55,799 pointed to the frailest. 870 00:29:57,470 --> 00:29:59,119 Now the allocation algorithm is quite 871 00:29:59,120 --> 00:30:01,289 simple. First, we want to 872 00:30:01,290 --> 00:30:03,559 assume we want to allocate the 873 00:30:03,560 --> 00:30:04,819 A of size 30. 874 00:30:04,820 --> 00:30:06,649 Then you check to which it belongs to. 875 00:30:06,650 --> 00:30:09,409 I think it belongs to bin number five. 876 00:30:09,410 --> 00:30:11,989 Then we check if there is freely 877 00:30:11,990 --> 00:30:14,329 available or is a bin initialized if 878 00:30:14,330 --> 00:30:16,219 there is no initialize been we initialize 879 00:30:16,220 --> 00:30:18,529 a newborn and then we just pop from the 880 00:30:18,530 --> 00:30:21,199 list. So assume you want to allocate 881 00:30:21,200 --> 00:30:22,399 thirty bytes. 882 00:30:22,400 --> 00:30:24,829 There is no thirty bytes been available 883 00:30:24,830 --> 00:30:25,849 right now, so we're 884 00:30:26,930 --> 00:30:28,759 initializing a newborn and then we just 885 00:30:28,760 --> 00:30:30,199 pop from the list. 886 00:30:30,200 --> 00:30:31,909 Assuming we want to make any replication 887 00:30:31,910 --> 00:30:33,709 of the same size. It's even simpler. 888 00:30:33,710 --> 00:30:35,329 You just pop from the feeblest. 889 00:30:36,690 --> 00:30:38,819 Freeing memory is the inverse 890 00:30:38,820 --> 00:30:41,079 operation, so we get some point. 891 00:30:41,080 --> 00:30:43,349 We want to freed back to the pool. 892 00:30:43,350 --> 00:30:45,509 So we checked which chunk it belongs and 893 00:30:45,510 --> 00:30:47,369 which page within the triangle belongs 894 00:30:47,370 --> 00:30:49,529 to. We read the descriptor to 895 00:30:49,530 --> 00:30:51,689 know to, which is to push it back and 896 00:30:51,690 --> 00:30:53,939 we push it back to the fullest. 897 00:30:53,940 --> 00:30:56,369 So as assume we want to free 898 00:30:56,370 --> 00:30:58,439 the first part of this 899 00:30:58,440 --> 00:31:00,659 bin, then we just see it belongs 900 00:31:00,660 --> 00:31:02,579 to the third page. We see the third page 901 00:31:02,580 --> 00:31:03,839 is of bin 32. 902 00:31:03,840 --> 00:31:05,699 We go to the frailest and we just push 903 00:31:05,700 --> 00:31:06,700 back. 904 00:31:08,690 --> 00:31:09,859 Well, I want to remember about the 905 00:31:09,860 --> 00:31:12,049 alligator. Is that the alligator is very, 906 00:31:12,050 --> 00:31:13,759 very predictable, which is important for 907 00:31:13,760 --> 00:31:16,069 us as exploiters and 908 00:31:16,070 --> 00:31:18,319 it's impossible to free just random 909 00:31:18,320 --> 00:31:19,279 punters. 910 00:31:19,280 --> 00:31:21,109 This was used in the previous 911 00:31:21,110 --> 00:31:22,519 exploitation technique, but it's not 912 00:31:22,520 --> 00:31:23,749 possible anymore because we have some 913 00:31:23,750 --> 00:31:25,489 meat operations and lookups and it's hard 914 00:31:25,490 --> 00:31:27,559 to forge memory to look 915 00:31:27,560 --> 00:31:29,989 the correct way for this to work 916 00:31:29,990 --> 00:31:32,149 and we can abuse this point is 917 00:31:32,150 --> 00:31:33,419 to get arbitrary, right. 918 00:31:33,420 --> 00:31:34,509 So we can change them. 919 00:31:34,510 --> 00:31:36,529 If we can change the frailest and then 920 00:31:36,530 --> 00:31:38,899 allocate a few slots, 921 00:31:38,900 --> 00:31:40,849 we might we can allocate to the place we 922 00:31:40,850 --> 00:31:42,709 want to. And I'm going to explain it much 923 00:31:42,710 --> 00:31:43,710 more later. 924 00:31:44,590 --> 00:31:46,839 So now that we have vulnerabilities and 925 00:31:46,840 --> 00:31:48,939 we know about the allocator and how 926 00:31:48,940 --> 00:31:51,199 it works, it's time to write an expert. 927 00:31:52,600 --> 00:31:55,419 And every exploit has a few stages, 928 00:31:55,420 --> 00:31:56,679 the most common on our leaks. 929 00:31:56,680 --> 00:31:58,239 So we want to leak some memory 930 00:31:58,240 --> 00:32:00,579 information to bypass days 931 00:32:00,580 --> 00:32:02,649 later than we would like to read 932 00:32:02,650 --> 00:32:04,869 some memory so we can read 933 00:32:04,870 --> 00:32:07,149 the data or gadget's 934 00:32:07,150 --> 00:32:08,169 function pointers. 935 00:32:08,170 --> 00:32:10,299 So on it would like to write, 936 00:32:10,300 --> 00:32:12,489 maybe write our code, maybe write 937 00:32:12,490 --> 00:32:14,589 some other stuff and we would like 938 00:32:14,590 --> 00:32:16,329 to execute. This is what we're here for. 939 00:32:17,910 --> 00:32:19,259 And first thing we're going to talk 940 00:32:19,260 --> 00:32:21,029 about, like I think is the most 941 00:32:21,030 --> 00:32:23,159 complicated part, and 942 00:32:23,160 --> 00:32:24,569 we're going to abuse the allocator. 943 00:32:24,570 --> 00:32:25,679 It's our best friend here. 944 00:32:27,120 --> 00:32:29,129 It's roughly based on the previous 945 00:32:29,130 --> 00:32:30,509 exploitation technique, but it's a 946 00:32:30,510 --> 00:32:32,339 generalization of it. 947 00:32:32,340 --> 00:32:33,629 And we're going to use our ability to 948 00:32:33,630 --> 00:32:35,099 serialize freed objects. 949 00:32:35,100 --> 00:32:37,289 And we believe we can serialize objects, 950 00:32:37,290 --> 00:32:39,029 not only use them, because this is how we 951 00:32:39,030 --> 00:32:39,929 initially started. Right. 952 00:32:39,930 --> 00:32:41,699 We have unsterilized if we're an 953 00:32:41,700 --> 00:32:43,889 serializing something, we probably it was 954 00:32:43,890 --> 00:32:46,079 serialized before. So we have some 955 00:32:46,080 --> 00:32:47,849 kind of a mechanism here that we 956 00:32:47,850 --> 00:32:49,259 serialize something and answer and 957 00:32:49,260 --> 00:32:50,460 serialized it back and so on. 958 00:32:52,260 --> 00:32:53,939 The Elkader, if you remember, is 959 00:32:53,940 --> 00:32:56,279 officially so it overrides everything 960 00:32:56,280 --> 00:32:57,749 that is passed to it. So if if free 961 00:32:57,750 --> 00:32:59,789 pointers, the al-Qaeda is going Afri 962 00:32:59,790 --> 00:33:01,919 slot's, that al-Qaida is going to 963 00:33:01,920 --> 00:33:03,329 override them. 964 00:33:03,330 --> 00:33:05,459 And after we freedon, we use 965 00:33:05,460 --> 00:33:07,919 them. We can read via these pointers 966 00:33:07,920 --> 00:33:09,689 and read some data. 967 00:33:09,690 --> 00:33:10,709 That was also Freeth. 968 00:33:11,880 --> 00:33:13,139 So this is how it's going to work. 969 00:33:13,140 --> 00:33:15,059 The placatory, the released and the first 970 00:33:15,060 --> 00:33:17,129 pointer is in this slots in the free 971 00:33:17,130 --> 00:33:18,629 slots is the next slot. 972 00:33:18,630 --> 00:33:19,759 It's just the pointer, right? 973 00:33:19,760 --> 00:33:21,869 So here is the free slot 974 00:33:21,870 --> 00:33:23,559 struct and you can see the first field is 975 00:33:23,560 --> 00:33:24,560 the pointer. 976 00:33:25,350 --> 00:33:27,449 And when we read Friede Objects, we can 977 00:33:27,450 --> 00:33:29,649 sometimes read via this pointer. 978 00:33:29,650 --> 00:33:32,069 I mean, we freed the slot 979 00:33:32,070 --> 00:33:33,869 and we're still using it so we can read 980 00:33:33,870 --> 00:33:36,149 VRD Responder and read to the next slot, 981 00:33:36,150 --> 00:33:37,559 next free slot. 982 00:33:37,560 --> 00:33:40,259 So here is my all time favorite 983 00:33:40,260 --> 00:33:42,659 class in the interval class. 984 00:33:42,660 --> 00:33:44,609 And as you can see, this how destruct is 985 00:33:44,610 --> 00:33:46,199 implemented in memory. And the first 986 00:33:46,200 --> 00:33:47,489 field is a pointer. 987 00:33:47,490 --> 00:33:48,629 How lucky we are. 988 00:33:48,630 --> 00:33:49,769 Right. 989 00:33:49,770 --> 00:33:51,929 And it points to distract and 990 00:33:51,930 --> 00:33:53,849 distract is a very simple struct. 991 00:33:53,850 --> 00:33:55,349 It has many fields, but all of them are 992 00:33:55,350 --> 00:33:57,299 integers. There are not only integers, 993 00:33:57,300 --> 00:33:59,969 integers. SLR is assigned Longlong, 994 00:33:59,970 --> 00:34:02,159 so they're also unsterilized and written 995 00:34:02,160 --> 00:34:03,599 back to the user. 996 00:34:03,600 --> 00:34:05,879 So when on serializing diskless, 997 00:34:05,880 --> 00:34:07,679 we're actually getting these numbers the 998 00:34:07,680 --> 00:34:09,839 year, the month that they and so on. 999 00:34:11,159 --> 00:34:12,988 So how are we going to forge link in 1000 00:34:12,989 --> 00:34:14,759 practice? First are going to allocate 1001 00:34:14,760 --> 00:34:17,189 this date interval and we will allocate 1002 00:34:17,190 --> 00:34:19,408 an object like for example a string 1003 00:34:19,409 --> 00:34:20,849 and then we're going to free both 1004 00:34:20,850 --> 00:34:23,519 objects. First the string, then the 1005 00:34:23,520 --> 00:34:24,520 date interval. 1006 00:34:25,590 --> 00:34:27,299 And the al-Qaeda is going to override the 1007 00:34:27,300 --> 00:34:28,888 date interval with a pointer to the 1008 00:34:28,889 --> 00:34:30,809 string, to the friede string, because 1009 00:34:30,810 --> 00:34:32,309 this is how it works. 1010 00:34:32,310 --> 00:34:34,229 And the card is also going to overwrite 1011 00:34:34,230 --> 00:34:35,939 this string with some pointers. 1012 00:34:35,940 --> 00:34:38,279 So when we serialize this date interval, 1013 00:34:38,280 --> 00:34:40,738 we were going to read this objects and 1014 00:34:40,739 --> 00:34:42,419 here's some hex dump for you because you 1015 00:34:42,420 --> 00:34:43,559 really wanted it. 1016 00:34:43,560 --> 00:34:45,569 And here is a you can see the Frehley's 1017 00:34:45,570 --> 00:34:47,488 before we start our exploit and now we 1018 00:34:47,489 --> 00:34:49,259 allocate that interval. 1019 00:34:49,260 --> 00:34:51,869 And as you can see, it points to some 1020 00:34:51,870 --> 00:34:52,948 strike that I initialized with 1021 00:34:52,949 --> 00:34:54,509 Venezuelans because it doesn't matter so 1022 00:34:54,510 --> 00:34:57,149 much. And we're also allocating 1023 00:34:57,150 --> 00:34:59,249 or an serializing a string one after 1024 00:34:59,250 --> 00:35:01,859 the other. And now we're offering 1025 00:35:01,860 --> 00:35:03,089 the two of them. 1026 00:35:03,090 --> 00:35:04,409 And as you can see, the date interval 1027 00:35:04,410 --> 00:35:06,719 pointer, the first pointer now points 1028 00:35:06,720 --> 00:35:08,249 to the Friede string and one on 1029 00:35:08,250 --> 00:35:10,589 serializing this date interval actually 1030 00:35:10,590 --> 00:35:12,329 gets the values in the string will get 1031 00:35:12,330 --> 00:35:14,429 these pointers as integers, which is very 1032 00:35:14,430 --> 00:35:15,430 nice. 1033 00:35:16,410 --> 00:35:17,469 How can read memory? 1034 00:35:17,470 --> 00:35:19,629 Well, we have this very nice struct 1035 00:35:19,630 --> 00:35:21,359 already. So if we can control this struct 1036 00:35:21,360 --> 00:35:23,819 fully, if we can control Zevo 1037 00:35:23,820 --> 00:35:26,039 fully, we can just change this pointer 1038 00:35:26,040 --> 00:35:27,419 to whatever we want. 1039 00:35:27,420 --> 00:35:29,849 So pointing the first field in the 1040 00:35:29,850 --> 00:35:32,219 date interval will let us read any 1041 00:35:32,220 --> 00:35:34,379 kind of memory we want if we don't 1042 00:35:34,380 --> 00:35:36,179 control the level fully, which can be the 1043 00:35:36,180 --> 00:35:37,980 case in 64, which it was the case. 1044 00:35:39,030 --> 00:35:41,219 There is a more complicated way and 1045 00:35:41,220 --> 00:35:42,869 I'm not going to discuss it here. 1046 00:35:42,870 --> 00:35:46,109 But basically we can use a different 1047 00:35:46,110 --> 00:35:48,359 object at a period object which 1048 00:35:48,360 --> 00:35:49,729 has a first first feel. 1049 00:35:49,730 --> 00:35:50,819 There's a point at which points to 1050 00:35:50,820 --> 00:35:52,349 another stock and destruct. 1051 00:35:52,350 --> 00:35:54,179 We control another pointer, that is to 1052 00:35:54,180 --> 00:35:56,039 enter a copy on an serialization so we 1053 00:35:56,040 --> 00:35:58,119 can read memory with 1054 00:35:58,120 --> 00:35:59,459 your copy. And you can see all the 1055 00:35:59,460 --> 00:36:01,619 details in the paper published 1056 00:36:01,620 --> 00:36:03,129 earlier this year. 1057 00:36:03,130 --> 00:36:04,849 I'll give you links in the end of this 1058 00:36:04,850 --> 00:36:05,850 stock. 1059 00:36:06,390 --> 00:36:09,099 How can we possibly write memory 1060 00:36:09,100 --> 00:36:11,339 o writing memory is a 1061 00:36:11,340 --> 00:36:13,679 much more complicated here and is 1062 00:36:13,680 --> 00:36:14,759 what we're gonna do. We're going to free 1063 00:36:14,760 --> 00:36:17,009 some strings back to the allocator and 1064 00:36:17,010 --> 00:36:18,629 in the strings are going to write 1065 00:36:18,630 --> 00:36:21,119 pointers to wherever we want, whichever 1066 00:36:21,120 --> 00:36:22,889 one we want to write. 1067 00:36:22,890 --> 00:36:25,349 Then we going to abuse the frailest and 1068 00:36:25,350 --> 00:36:26,819 we're going to change the pointer in the 1069 00:36:26,820 --> 00:36:28,409 field and going to increase them or 1070 00:36:28,410 --> 00:36:29,639 decrease them depending on our 1071 00:36:29,640 --> 00:36:30,640 vulnerability, 1072 00:36:31,950 --> 00:36:32,879 unordinary. 1073 00:36:32,880 --> 00:36:34,349 And at some point, if we increase them 1074 00:36:34,350 --> 00:36:37,019 enough, they will actually point 1075 00:36:37,020 --> 00:36:39,059 to this memory we want to write. 1076 00:36:39,060 --> 00:36:41,249 So after a few locations, we'll actually 1077 00:36:41,250 --> 00:36:43,169 have the memory. Elkader, give us the 1078 00:36:43,170 --> 00:36:44,199 address we want to write 1079 00:36:45,570 --> 00:36:48,029 and this is 1080 00:36:48,030 --> 00:36:49,529 what we want to happen. So how can we 1081 00:36:49,530 --> 00:36:51,529 free these strings? 1082 00:36:51,530 --> 00:36:53,939 As we said, every value we're passing 1083 00:36:53,940 --> 00:36:55,539 on, Serialize gets a reference in the 1084 00:36:55,540 --> 00:36:56,549 Treasury. 1085 00:36:56,550 --> 00:36:58,349 So we have reference to almost everything 1086 00:36:58,350 --> 00:37:00,119 and nothing is free during an 1087 00:37:00,120 --> 00:37:01,499 serialization. 1088 00:37:01,500 --> 00:37:03,839 Except there is one exception and 1089 00:37:03,840 --> 00:37:05,669 it's in the hash table. 1090 00:37:05,670 --> 00:37:07,229 We can use the same key twice. 1091 00:37:07,230 --> 00:37:09,479 Keys are not kept references 1092 00:37:09,480 --> 00:37:11,609 and if we're using the same key twice and 1093 00:37:11,610 --> 00:37:13,559 the keys can be strings, the second time 1094 00:37:13,560 --> 00:37:15,629 we're using Diski, it is free. 1095 00:37:15,630 --> 00:37:17,559 The hash table looks at the. 1096 00:37:17,560 --> 00:37:19,599 And says, now, I've already got this guy 1097 00:37:19,600 --> 00:37:21,099 I don't need anymore and freeze it back 1098 00:37:21,100 --> 00:37:23,259 to the alligator, no references to it 1099 00:37:23,260 --> 00:37:25,329 are made and it's back in the alligator 1100 00:37:25,330 --> 00:37:26,330 for us. 1101 00:37:27,280 --> 00:37:29,409 And the next thing we need to know is how 1102 00:37:29,410 --> 00:37:31,719 to abuse pointers in the Frehley's. 1103 00:37:31,720 --> 00:37:33,909 This is the most interesting part here. 1104 00:37:33,910 --> 00:37:34,910 And 1105 00:37:36,010 --> 00:37:38,199 the reason it is possible and it's very 1106 00:37:38,200 --> 00:37:40,389 common is because we have type 1107 00:37:40,390 --> 00:37:41,709 confusion here, right? 1108 00:37:41,710 --> 00:37:44,079 We have the free slots, which are first 1109 00:37:44,080 --> 00:37:46,149 field is a point there, but we 1110 00:37:46,150 --> 00:37:48,279 also have the something that was 1111 00:37:48,280 --> 00:37:49,749 free, the value that was free and we 1112 00:37:49,750 --> 00:37:51,429 still have a reference to it. 1113 00:37:51,430 --> 00:37:54,099 And on the hip, every 1114 00:37:55,780 --> 00:37:57,249 every struct on the hip has a reference 1115 00:37:57,250 --> 00:37:59,349 count and the reference reference count 1116 00:37:59,350 --> 00:38:01,119 is always the first field. 1117 00:38:01,120 --> 00:38:02,739 So if you take descender object, for 1118 00:38:02,740 --> 00:38:05,049 example, this first field 1119 00:38:05,050 --> 00:38:06,339 is a reference. 1120 00:38:06,340 --> 00:38:08,619 So if we have a type confusion between, 1121 00:38:08,620 --> 00:38:11,499 uh, an object, 1122 00:38:11,500 --> 00:38:13,509 so not that accurate, but if an object 1123 00:38:13,510 --> 00:38:15,009 was freed and we can still use it, 1124 00:38:15,010 --> 00:38:17,409 increasing the references or decreasing 1125 00:38:17,410 --> 00:38:20,049 the references to this object actually 1126 00:38:20,050 --> 00:38:22,359 increases or decreases a pointer. 1127 00:38:22,360 --> 00:38:25,299 So it is how we can control this pointer 1128 00:38:25,300 --> 00:38:26,529 and some more Hexham. 1129 00:38:26,530 --> 00:38:28,839 So this is part of the exploit 1130 00:38:28,840 --> 00:38:31,059 they wrote to bug seven one three 1131 00:38:31,060 --> 00:38:32,049 one one. 1132 00:38:32,050 --> 00:38:34,329 And here you can see that 1133 00:38:34,330 --> 00:38:36,459 we already freed the strings back to the 1134 00:38:36,460 --> 00:38:38,019 alligator. So you can see the four ones 1135 00:38:38,020 --> 00:38:39,579 in the up. 1136 00:38:39,580 --> 00:38:41,079 And now we're going to trigger the 1137 00:38:41,080 --> 00:38:42,759 vulnerability. The vulnerability here 1138 00:38:42,760 --> 00:38:44,380 lies in the array object 1139 00:38:45,520 --> 00:38:47,889 plus and parsing 1140 00:38:47,890 --> 00:38:49,959 it increases the pointer into 1141 00:38:49,960 --> 00:38:52,029 four by two. And now we have Yusoff. 1142 00:38:52,030 --> 00:38:54,939 They're free of this address. 1143 00:38:54,940 --> 00:38:56,799 The first that is pointed by the 1144 00:38:56,800 --> 00:38:58,719 frailest. It's still in the alligator, 1145 00:38:58,720 --> 00:39:00,909 but we have a reference to it. 1146 00:39:00,910 --> 00:39:03,429 And it was the 11th, uh, 1147 00:39:03,430 --> 00:39:04,449 value that we passed. 1148 00:39:04,450 --> 00:39:06,729 So eddying references to this address. 1149 00:39:06,730 --> 00:39:08,919 So R11 parsing, R11, so 1150 00:39:08,920 --> 00:39:11,199 on. We're increasing this pointer 1151 00:39:11,200 --> 00:39:13,329 by two every time and at 1152 00:39:13,330 --> 00:39:15,609 some point reach the values, just feed 1153 00:39:15,610 --> 00:39:18,069 back to the hip or back to the alligator. 1154 00:39:18,070 --> 00:39:20,169 So now if we allocate 1155 00:39:20,170 --> 00:39:22,319 twice from the spin, the first thing 1156 00:39:22,320 --> 00:39:24,549 we allocate at the object 1157 00:39:24,550 --> 00:39:26,649 that was corrupted and the second time 1158 00:39:26,650 --> 00:39:28,149 we will actually can write to four one 1159 00:39:28,150 --> 00:39:29,769 four one for one and we will fold. 1160 00:39:29,770 --> 00:39:31,149 But this is exactly what we wanted, 1161 00:39:31,150 --> 00:39:32,150 right? 1162 00:39:33,220 --> 00:39:35,349 So codification, after all, this code 1163 00:39:35,350 --> 00:39:36,790 execution is quite simple, 1164 00:39:37,840 --> 00:39:39,729 if very controlling, as evil, as I said, 1165 00:39:39,730 --> 00:39:41,919 the easiest way is to override a call. 1166 00:39:41,920 --> 00:39:43,599 You do you control some object. 1167 00:39:43,600 --> 00:39:45,849 You can decide what complex 1168 00:39:45,850 --> 00:39:47,559 it has, but if you don't control Zevo 1169 00:39:47,560 --> 00:39:49,659 fully, you can just we have a 1170 00:39:49,660 --> 00:39:51,309 right primitive so we can write that 1171 00:39:51,310 --> 00:39:52,960 function pointer and that's about it. 1172 00:39:54,040 --> 00:39:56,289 So takeaways from this 1173 00:39:56,290 --> 00:39:58,629 exploit the allocative is your friend. 1174 00:39:58,630 --> 00:40:00,879 Please use it, use it wisely. 1175 00:40:00,880 --> 00:40:02,679 And these primitives are usable. 1176 00:40:02,680 --> 00:40:03,879 They can be used in many different 1177 00:40:03,880 --> 00:40:05,799 vulnerabilities within the serialized 1178 00:40:05,800 --> 00:40:06,879 mechanism. 1179 00:40:06,880 --> 00:40:09,129 And combining all these primitives, you 1180 00:40:09,130 --> 00:40:10,750 get the remote code execution. 1181 00:40:13,050 --> 00:40:14,639 Conclusion from the talk, even though 1182 00:40:14,640 --> 00:40:16,049 you're writing your code in high level 1183 00:40:16,050 --> 00:40:17,669 language such as BHP, you're still 1184 00:40:17,670 --> 00:40:20,009 vulnerable to memory, 1185 00:40:20,010 --> 00:40:22,139 corruptions or other low level problems. 1186 00:40:23,310 --> 00:40:25,409 The new design of being is for 1187 00:40:25,410 --> 00:40:26,819 efficiency. You still have 1188 00:40:26,820 --> 00:40:29,009 vulnerabilities. I don't think it's 1189 00:40:29,010 --> 00:40:30,570 more secure or less secure in a way. 1190 00:40:31,890 --> 00:40:33,899 And the Elkader is exploit friendly. 1191 00:40:33,900 --> 00:40:36,029 Please, when you're writing an exploit, 1192 00:40:36,030 --> 00:40:37,249 use it. 1193 00:40:37,250 --> 00:40:39,359 Uh, and never, never, 1194 00:40:39,360 --> 00:40:41,549 never use in this function is a remote 1195 00:40:41,550 --> 00:40:42,659 code execution. 1196 00:40:42,660 --> 00:40:44,909 Basically, every time it was 1197 00:40:44,910 --> 00:40:47,069 in some somewhere in the reachable code, 1198 00:40:47,070 --> 00:40:48,070 it was exploited. 1199 00:40:49,470 --> 00:40:51,479 Some more information you can find in 1200 00:40:51,480 --> 00:40:53,219 Checkpoint blog and also a description of 1201 00:40:53,220 --> 00:40:55,469 this talk, I have a link to the paper 1202 00:40:55,470 --> 00:40:56,470 I just published 1203 00:40:57,810 --> 00:40:59,279 and they're going to be another 1204 00:40:59,280 --> 00:41:00,959 publication soon about the 1205 00:41:00,960 --> 00:41:02,429 vulnerabilities. I talk about more 1206 00:41:02,430 --> 00:41:04,469 information about them, and also a third 1207 00:41:04,470 --> 00:41:05,999 vulnerability, which I did not discuss 1208 00:41:06,000 --> 00:41:07,119 here. 1209 00:41:07,120 --> 00:41:09,179 Feedback system is a 1210 00:41:09,180 --> 00:41:11,609 second link and there is every 1211 00:41:11,610 --> 00:41:13,749 bug recorded and every vulnerability 1212 00:41:13,750 --> 00:41:16,139 is some of the bugs doesn't have civies, 1213 00:41:16,140 --> 00:41:17,140 unfortunately. 1214 00:41:18,000 --> 00:41:20,339 And the third link is Nikita Popover. 1215 00:41:20,340 --> 00:41:22,649 I think I pronounce his name correctly 1216 00:41:22,650 --> 00:41:24,809 blog. He's a main contributor to 1217 00:41:24,810 --> 00:41:26,609 B and he has many explanations about 1218 00:41:26,610 --> 00:41:29,189 internal mechanisms within between 1219 00:41:29,190 --> 00:41:30,989 if you want to contact me. So you have my 1220 00:41:30,990 --> 00:41:33,399 corporate e-mail, my Twitter and 1221 00:41:33,400 --> 00:41:35,489 most other platforms such 1222 00:41:35,490 --> 00:41:37,469 as Gitmo and so on, couch surfing, I 1223 00:41:37,470 --> 00:41:38,379 don't know. 1224 00:41:38,380 --> 00:41:40,589 Uh, so that's 1225 00:41:40,590 --> 00:41:42,030 it. Any questions? 1226 00:41:54,510 --> 00:41:56,729 Thank you and I if you have questions, 1227 00:41:56,730 --> 00:41:59,729 please line up next to the microphones 1228 00:41:59,730 --> 00:42:00,749 and ask your question. 1229 00:42:00,750 --> 00:42:02,550 If you are leaving, please do so quietly. 1230 00:42:04,290 --> 00:42:06,419 Any questions from here or 1231 00:42:06,420 --> 00:42:07,420 from the Internet? 1232 00:42:14,960 --> 00:42:16,309 People are overwhelmed. 1233 00:42:19,040 --> 00:42:20,539 So I'll start with a question, actually, 1234 00:42:20,540 --> 00:42:22,039 because I have one, I understand the 1235 00:42:22,040 --> 00:42:24,769 internals too much into the applications 1236 00:42:24,770 --> 00:42:26,839 of exploiting things they talk 1237 00:42:26,840 --> 00:42:28,219 about eventless in the wild. 1238 00:42:28,220 --> 00:42:30,379 Are we expected to see this in the wild? 1239 00:42:30,380 --> 00:42:32,599 Actually, P7 seven is not very 1240 00:42:32,600 --> 00:42:33,499 widely used. 1241 00:42:33,500 --> 00:42:35,179 I now think it's two percent. 1242 00:42:35,180 --> 00:42:36,619 It's just a year old. 1243 00:42:36,620 --> 00:42:38,839 But as soon as the big 1244 00:42:38,840 --> 00:42:41,149 platforms, the big storms will 1245 00:42:41,150 --> 00:42:44,449 move to this new language, I 1246 00:42:44,450 --> 00:42:46,369 predict we will see some of them other 1247 00:42:46,370 --> 00:42:48,589 vulnerabilities. But I assume we'll see 1248 00:42:48,590 --> 00:42:51,039 more exploits coming 1249 00:42:51,040 --> 00:42:52,040 next. 1250 00:42:52,490 --> 00:42:54,529 Questions from the audience or from the 1251 00:42:54,530 --> 00:42:55,530 Internet? 1252 00:42:56,340 --> 00:42:57,949 The Internet has a question. 1253 00:42:57,950 --> 00:42:58,849 Yes. 1254 00:42:58,850 --> 00:43:00,989 Yes. Are there any popular project 1255 00:43:00,990 --> 00:43:02,479 that are affected by these 1256 00:43:02,480 --> 00:43:03,480 vulnerabilities? 1257 00:43:04,280 --> 00:43:06,769 Not that I know of, not yet, because P7 1258 00:43:06,770 --> 00:43:08,719 is not widely used by now. 1259 00:43:08,720 --> 00:43:10,989 There are no big names using P2P 1260 00:43:10,990 --> 00:43:11,990 seven 1261 00:43:13,400 --> 00:43:15,589 sorry, Internet. 1262 00:43:15,590 --> 00:43:17,809 If you have more questions, then 1263 00:43:17,810 --> 00:43:18,810 go ahead. 1264 00:43:22,900 --> 00:43:25,050 I one from the audience, last chance. 1265 00:43:26,840 --> 00:43:28,789 OK, so again, please give a big round of 1266 00:43:28,790 --> 00:43:29,960 applause to United States.