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/512 Thanks! 1 00:00:08,970 --> 00:00:11,039 The recent book is always 2 00:00:11,040 --> 00:00:12,779 funny because we're going to present to 3 00:00:12,780 --> 00:00:14,999 you a look of the bus to 4 00:00:15,000 --> 00:00:16,550 catch a tux and Ruhama, 5 00:00:17,640 --> 00:00:19,779 so a few words about ourselves. 6 00:00:19,780 --> 00:00:22,019 So I just finished my 7 00:00:22,020 --> 00:00:23,579 pitch to you a couple of months ago. 8 00:00:23,580 --> 00:00:26,369 And I'm from in France. 9 00:00:26,370 --> 00:00:28,529 I'm from Germany originally, but I live 10 00:00:28,530 --> 00:00:29,909 in Austria for several years. 11 00:00:29,910 --> 00:00:32,008 And I started my PhD 12 00:00:32,009 --> 00:00:34,079 one year ago and I 13 00:00:34,080 --> 00:00:35,879 worked on Catch a Texan this year and 14 00:00:35,880 --> 00:00:38,129 also on Rosmer when I just found that all 15 00:00:38,130 --> 00:00:40,649 my laptops were very vulnerable 16 00:00:40,650 --> 00:00:41,650 to Rosemary. 17 00:00:43,550 --> 00:00:45,709 Yeah, so a few words about 18 00:00:45,710 --> 00:00:48,349 the timeline. So this is a story about 19 00:00:48,350 --> 00:00:49,519 Philipson in dirham. 20 00:00:49,520 --> 00:00:51,949 So it all started basically last 21 00:00:51,950 --> 00:00:54,109 year with schemozzle paper, which 22 00:00:54,110 --> 00:00:56,219 is called flipping bits in memory without 23 00:00:56,220 --> 00:00:58,429 executing them at the 24 00:00:58,430 --> 00:00:59,329 conference. 25 00:00:59,330 --> 00:01:02,119 So this is the original Ruhama book. 26 00:01:02,120 --> 00:01:04,219 With this first inspection, it 27 00:01:04,220 --> 00:01:05,749 will make sense later. 28 00:01:05,750 --> 00:01:07,789 And it was originally viewed as a 29 00:01:07,790 --> 00:01:10,009 reliability issue and the 30 00:01:10,010 --> 00:01:12,619 security community 31 00:01:12,620 --> 00:01:14,809 started to say it might not 32 00:01:14,810 --> 00:01:16,879 be such a good idea to flip it 33 00:01:16,880 --> 00:01:19,309 without accessing then in a security 34 00:01:19,310 --> 00:01:20,339 perspective. 35 00:01:20,340 --> 00:01:22,759 But some people were like, it's just 36 00:01:22,760 --> 00:01:24,589 a few bit flips and we can't really 37 00:01:24,590 --> 00:01:27,019 control them. So what could possibly 38 00:01:27,020 --> 00:01:28,020 go wrong? 39 00:01:28,430 --> 00:01:30,559 So yeah, actually a 40 00:01:30,560 --> 00:01:32,629 lot can go wrong, as I've 41 00:01:32,630 --> 00:01:34,729 shown, massive on and off like 42 00:01:34,730 --> 00:01:36,889 you, who built not one but 43 00:01:36,890 --> 00:01:39,379 two exploits using Ruhama 44 00:01:39,380 --> 00:01:42,169 with flaws. So they built a sandbox 45 00:01:42,170 --> 00:01:44,239 sandbox escape and a 46 00:01:44,240 --> 00:01:45,240 route explodes. 47 00:01:46,160 --> 00:01:47,659 So shortly after that. 48 00:01:47,660 --> 00:01:49,609 So Daniel started working on Ruhama 49 00:01:49,610 --> 00:01:51,169 results still flush. 50 00:01:51,170 --> 00:01:53,339 And I told him to 51 00:01:53,340 --> 00:01:55,069 you got to work on it. 52 00:01:56,150 --> 00:01:58,279 And we got our first bit, Flip's 53 00:01:58,280 --> 00:02:00,409 results on Ivy Bridge and has 54 00:02:00,410 --> 00:02:02,479 well, a few days later and 55 00:02:02,480 --> 00:02:04,819 this story about will self-assertion 56 00:02:04,820 --> 00:02:07,009 results. So the results here 57 00:02:07,010 --> 00:02:09,349 first, as are actually the 58 00:02:09,350 --> 00:02:11,629 building block of our 59 00:02:11,630 --> 00:02:13,909 first pit flips from script that 60 00:02:13,910 --> 00:02:15,889 we got a few weeks later. 61 00:02:22,970 --> 00:02:25,189 OK, so you will see what this is, this is 62 00:02:25,190 --> 00:02:27,289 a direct module at the module and 63 00:02:27,290 --> 00:02:29,899 let's see how it is organized 64 00:02:29,900 --> 00:02:32,059 internally. So, for example, 65 00:02:32,060 --> 00:02:34,159 if you have two modules, you can 66 00:02:34,160 --> 00:02:35,160 have two channels. 67 00:02:37,070 --> 00:02:39,259 It is composed of a backside 68 00:02:39,260 --> 00:02:40,789 in the front sides, which are called 69 00:02:40,790 --> 00:02:41,790 ranks. 70 00:02:42,650 --> 00:02:45,049 And on this Franck's, you have 71 00:02:45,050 --> 00:02:46,050 a chipps. 72 00:02:47,280 --> 00:02:49,679 So inside this ships, you have 73 00:02:49,680 --> 00:02:51,929 eight banks which are composed of 74 00:02:51,930 --> 00:02:53,249 rows and Naropa. 75 00:02:53,250 --> 00:02:55,019 So this is a logical view. 76 00:02:55,020 --> 00:02:57,239 We are not really interested of of 77 00:02:57,240 --> 00:02:59,339 it or of how it's actually 78 00:02:59,340 --> 00:03:00,239 implemented. 79 00:03:00,240 --> 00:03:02,549 So we have our data, 80 00:03:02,550 --> 00:03:04,679 the bits in the cells in these rows, 81 00:03:04,680 --> 00:03:06,899 and we can access only 82 00:03:06,900 --> 00:03:08,009 Ross Perot. 83 00:03:08,010 --> 00:03:09,899 So when you want to access some data, you 84 00:03:09,900 --> 00:03:12,689 will the activists 85 00:03:12,690 --> 00:03:14,549 will issue an activist comment on the 86 00:03:14,550 --> 00:03:16,479 role, which will copy the data into the 87 00:03:16,480 --> 00:03:17,639 Rowbotham. 88 00:03:17,640 --> 00:03:20,309 And due to how the dirham is 89 00:03:20,310 --> 00:03:23,069 designed, the cells are leaking. 90 00:03:23,070 --> 00:03:25,289 So we have to refresh 91 00:03:25,290 --> 00:03:27,569 to to put the shark back so 92 00:03:27,570 --> 00:03:30,389 that we won't have any data loss. 93 00:03:30,390 --> 00:03:32,939 And this is actually leaking faster 94 00:03:32,940 --> 00:03:35,129 upon proximate accesses, which 95 00:03:35,130 --> 00:03:37,229 leads to the Rahmberg. 96 00:03:37,230 --> 00:03:39,649 So there's Mosaab 97 00:03:39,650 --> 00:03:41,909 advice who says something which I 98 00:03:41,910 --> 00:03:43,469 really like an analogy. 99 00:03:43,470 --> 00:03:45,599 So Ruhama is like breaking into 100 00:03:45,600 --> 00:03:47,639 an apartment by repeatedly slamming 101 00:03:47,640 --> 00:03:49,859 neighbors door until the vibration 102 00:03:49,860 --> 00:03:51,539 open the door you were after. 103 00:03:53,970 --> 00:03:55,710 So let's see 104 00:03:56,730 --> 00:03:58,229 how it works. 105 00:03:58,230 --> 00:04:00,569 So you will issue an activist 106 00:04:00,570 --> 00:04:02,279 comment on the special role that will 107 00:04:02,280 --> 00:04:04,079 copy into the Rowbotham. 108 00:04:04,080 --> 00:04:06,509 And you want to issue a lot of activist 109 00:04:06,510 --> 00:04:08,669 comments as fast as possible on this 110 00:04:08,670 --> 00:04:10,769 role. The issue is that if you just 111 00:04:10,770 --> 00:04:13,379 access this role, 112 00:04:13,380 --> 00:04:14,819 it will just you will just go to the 113 00:04:14,820 --> 00:04:16,979 ROBERVAL, which acts like 114 00:04:16,980 --> 00:04:19,109 a cash. So you need to activate 115 00:04:19,110 --> 00:04:21,389 another rule and then destroy 116 00:04:21,390 --> 00:04:23,609 again another rule 117 00:04:23,610 --> 00:04:25,290 and then you have your bed flips. 118 00:04:26,400 --> 00:04:28,749 So this is really bad because we didn't 119 00:04:28,750 --> 00:04:30,809 touch this role at all and the 120 00:04:30,810 --> 00:04:31,810 be changed. 121 00:04:33,570 --> 00:04:34,889 Now, the thing is, 122 00:04:36,090 --> 00:04:38,579 we can't just access data 123 00:04:38,580 --> 00:04:40,919 in dirham just like that, because 124 00:04:40,920 --> 00:04:43,049 between the civil court and the dirham, 125 00:04:43,050 --> 00:04:44,369 you have to keep Yogesh. 126 00:04:44,370 --> 00:04:46,469 So if you just access data all 127 00:04:46,470 --> 00:04:48,659 over and all over again, it will reach 128 00:04:48,660 --> 00:04:49,979 not the Deran, but the cache. 129 00:04:49,980 --> 00:04:51,869 And you won't have this blip. 130 00:04:51,870 --> 00:04:54,299 So you need only non-cash 131 00:04:54,300 --> 00:04:55,679 accesses to reach that. 132 00:04:55,680 --> 00:04:57,959 Iran and all the original text 133 00:04:57,960 --> 00:04:59,540 used this selfless instruction. 134 00:05:00,660 --> 00:05:03,119 So this instruction actually flushes 135 00:05:03,120 --> 00:05:05,369 a line from the cash so that 136 00:05:05,370 --> 00:05:07,559 next access will be sealed from 137 00:05:07,560 --> 00:05:08,560 the. 138 00:05:10,170 --> 00:05:11,909 Now, a bit of background on this cash, 139 00:05:11,910 --> 00:05:13,889 because it's really important for the 140 00:05:13,890 --> 00:05:15,359 remainder of the talk. 141 00:05:15,360 --> 00:05:18,119 So now in modern processors, we have 142 00:05:18,120 --> 00:05:20,129 several calls. So let's say four calls 143 00:05:20,130 --> 00:05:22,379 and we have a really a hierarchy of 144 00:05:22,380 --> 00:05:23,459 different levels of cash. 145 00:05:23,460 --> 00:05:25,529 So here are three levels, level 146 00:05:25,530 --> 00:05:27,299 one and level two private, which call 147 00:05:27,300 --> 00:05:29,879 which means that calls you can access 148 00:05:29,880 --> 00:05:32,099 on each level one and two, 149 00:05:32,100 --> 00:05:33,629 but not one individual. 150 00:05:33,630 --> 00:05:34,630 For example, call three. 151 00:05:35,640 --> 00:05:37,709 And then we have this Lesterville cash, 152 00:05:37,710 --> 00:05:39,419 which is also divided into sort of 153 00:05:39,420 --> 00:05:40,709 slices. 154 00:05:40,710 --> 00:05:42,989 But these slices are shared across 155 00:05:42,990 --> 00:05:45,069 so called zero can access 156 00:05:45,070 --> 00:05:47,009 zero, but also slice one, two and three. 157 00:05:48,060 --> 00:05:49,949 And something that is also important in 158 00:05:49,950 --> 00:05:52,079 that this cash has the 159 00:05:52,080 --> 00:05:54,149 property of being inclusive, 160 00:05:54,150 --> 00:05:56,669 which means that all the data that is 161 00:05:56,670 --> 00:05:58,949 in level one and level two is also 162 00:05:58,950 --> 00:06:00,750 contained in this Castroville Cash. 163 00:06:02,660 --> 00:06:05,029 OK, let's now look at 164 00:06:05,030 --> 00:06:07,039 the Roy Hammer attack with the 165 00:06:07,040 --> 00:06:08,119 instruction. 166 00:06:08,120 --> 00:06:10,249 Now we have additionally to 167 00:06:10,250 --> 00:06:11,779 the dirham bank that we already had 168 00:06:11,780 --> 00:06:13,789 before, two cash sets. 169 00:06:13,790 --> 00:06:16,339 And there is a fixed mapping between 170 00:06:16,340 --> 00:06:19,429 dirham sales and 171 00:06:19,430 --> 00:06:21,949 physical addresses and thereby 172 00:06:21,950 --> 00:06:23,449 cash sets. 173 00:06:23,450 --> 00:06:25,549 So if we already have the 174 00:06:25,550 --> 00:06:27,589 data in the cash, we first have to call 175 00:06:27,590 --> 00:06:29,599 the flush instructions to throw it out of 176 00:06:29,600 --> 00:06:31,379 the cash. Then it's gone. 177 00:06:31,380 --> 00:06:33,679 Then we reloaded 178 00:06:33,680 --> 00:06:36,229 and then we reload the other address. 179 00:06:36,230 --> 00:06:37,339 Then we flush it again. 180 00:06:37,340 --> 00:06:39,649 Then we reload, then flush, then reload 181 00:06:39,650 --> 00:06:42,229 and flush, then reload and flush them. 182 00:06:42,230 --> 00:06:43,129 Slip. 183 00:06:43,130 --> 00:06:44,130 Great. 184 00:06:44,650 --> 00:06:47,229 OK, and before I continue with Rosemere, 185 00:06:47,230 --> 00:06:49,299 I want to talk 186 00:06:49,300 --> 00:06:52,209 about just one more ATEC. 187 00:06:52,210 --> 00:06:54,639 I talked about flash and reloader just a 188 00:06:54,640 --> 00:06:56,379 few seconds ago, right. 189 00:06:56,380 --> 00:06:58,489 Flash and reload is a very powerful 190 00:06:58,490 --> 00:07:00,549 and very accurate cache of tech. 191 00:07:00,550 --> 00:07:02,689 And you can do a lot of things 192 00:07:02,690 --> 00:07:05,169 with this is tech and it works exactly 193 00:07:05,170 --> 00:07:06,909 like what we just did. 194 00:07:06,910 --> 00:07:09,129 But instead of just hammering all 195 00:07:09,130 --> 00:07:11,739 the time, we measure whether 196 00:07:11,740 --> 00:07:13,869 a excess was served 197 00:07:13,870 --> 00:07:16,089 from the cache. So it is a cache hit or 198 00:07:16,090 --> 00:07:18,309 it was a cache miss and was served from 199 00:07:18,310 --> 00:07:20,619 the year. And apparently this takes 200 00:07:20,620 --> 00:07:22,689 a different time. 201 00:07:22,690 --> 00:07:24,909 And if you do this on a shared library, 202 00:07:24,910 --> 00:07:27,279 you can spy on other processes 203 00:07:27,280 --> 00:07:29,049 because these chat libraries, they might 204 00:07:29,050 --> 00:07:31,329 have a method to 205 00:07:31,330 --> 00:07:33,489 go to work 206 00:07:33,490 --> 00:07:35,439 the user with the user input. 207 00:07:35,440 --> 00:07:37,839 And you can see when the code 208 00:07:37,840 --> 00:07:39,819 from this chat library is loaded into the 209 00:07:39,820 --> 00:07:41,799 cache and you didn't loaded into the 210 00:07:41,800 --> 00:07:43,579 cache. So someone else did it. 211 00:07:43,580 --> 00:07:45,849 OK, that was user input. 212 00:07:45,850 --> 00:07:48,009 And you can furthermore automate these 213 00:07:48,010 --> 00:07:50,289 attacks. So when you can simulate the 214 00:07:50,290 --> 00:07:52,449 event that you want to spy on, you can 215 00:07:52,450 --> 00:07:54,789 automate the attack fully and 216 00:07:54,790 --> 00:07:57,069 also generate attacks on cryptographic 217 00:07:57,070 --> 00:07:59,319 algorithms to generate key loggers or 218 00:07:59,320 --> 00:08:01,179 part of the killers. 219 00:08:01,180 --> 00:08:03,429 And you can even perform cross animatics. 220 00:08:03,430 --> 00:08:05,529 If these VMS share memory, it's not 221 00:08:05,530 --> 00:08:07,659 a good idea to share a memory. 222 00:08:07,660 --> 00:08:08,660 OK. 223 00:08:12,730 --> 00:08:14,829 OK, so what we would 224 00:08:14,830 --> 00:08:17,289 like to do is to do this, 225 00:08:17,290 --> 00:08:19,689 this attack, this attack, but without 226 00:08:19,690 --> 00:08:22,029 the salesperson's friction, the global 227 00:08:22,030 --> 00:08:24,519 idea that we would like to avoid the SEAL 228 00:08:24,520 --> 00:08:27,039 section because it's really dependent. 229 00:08:27,040 --> 00:08:29,409 So it's a specific infection in 230 00:08:29,410 --> 00:08:31,509 the six and you won't have it 231 00:08:31,510 --> 00:08:32,408 in the architecture. 232 00:08:32,409 --> 00:08:34,509 And it's also not available 233 00:08:34,510 --> 00:08:36,729 from JavaScript. So it will 234 00:08:36,730 --> 00:08:38,979 really extend the world of possibilities 235 00:08:38,980 --> 00:08:41,439 to do to do this with flush. 236 00:08:41,440 --> 00:08:43,959 So our approach is to use 237 00:08:43,960 --> 00:08:46,059 regular memory accesses to 238 00:08:46,060 --> 00:08:47,229 evict the cache. 239 00:08:47,230 --> 00:08:49,509 And the nice thing about this is 240 00:08:49,510 --> 00:08:51,999 evicting the cache is really at the core 241 00:08:52,000 --> 00:08:54,189 of all cache attacks and this 242 00:08:54,190 --> 00:08:56,479 is really what we know how to do best. 243 00:08:56,480 --> 00:08:58,299 So let's use it 244 00:08:59,440 --> 00:09:01,779 so it works kind 245 00:09:01,780 --> 00:09:04,839 of the same. So we still have this 246 00:09:04,840 --> 00:09:06,399 gray line 247 00:09:07,420 --> 00:09:08,719 that we want to evict. 248 00:09:08,720 --> 00:09:10,449 And now what we're going to do is that 249 00:09:10,450 --> 00:09:13,059 we're going to access lots 250 00:09:13,060 --> 00:09:15,309 of addresses that will map to the same 251 00:09:15,310 --> 00:09:17,769 cash that until eventually 252 00:09:17,770 --> 00:09:19,989 it will evict the line we want. 253 00:09:21,180 --> 00:09:22,829 Now, something that is important here is 254 00:09:22,830 --> 00:09:24,929 that while we can choose in 255 00:09:24,930 --> 00:09:27,059 which case captured the exercise 256 00:09:27,060 --> 00:09:29,159 go, we cannot choose where in the 257 00:09:29,160 --> 00:09:30,839 cash sits, the excesses go. 258 00:09:30,840 --> 00:09:32,849 It depends on the replacement policies. 259 00:09:32,850 --> 00:09:35,069 So we just wait until 260 00:09:35,070 --> 00:09:36,239 we have a victim and 261 00:09:37,380 --> 00:09:39,449 then the next and the next access will be 262 00:09:39,450 --> 00:09:41,489 saved from the tyranny, which is exactly 263 00:09:41,490 --> 00:09:42,899 what we wanted. 264 00:09:42,900 --> 00:09:44,879 Then we have to do that over and over 265 00:09:44,880 --> 00:09:47,189 again until we have 266 00:09:47,190 --> 00:09:49,409 our bit flip without this selfless 267 00:09:49,410 --> 00:09:50,410 insurrection. 268 00:09:51,540 --> 00:09:53,609 Now, it looks 269 00:09:53,610 --> 00:09:55,529 nice and easy like this, but there are 270 00:09:55,530 --> 00:09:57,869 actually some challenges. 271 00:09:57,870 --> 00:09:59,879 First, how do we get these physical 272 00:09:59,880 --> 00:10:00,959 addresses in JavaScript? 273 00:10:00,960 --> 00:10:01,960 It's a sandbox. 274 00:10:03,120 --> 00:10:05,339 Second, which physical addresses 275 00:10:05,340 --> 00:10:07,349 do we need to access? 276 00:10:07,350 --> 00:10:09,479 In which order do we need to access them? 277 00:10:09,480 --> 00:10:11,609 And then finally, how do we get this 278 00:10:11,610 --> 00:10:14,519 accurate timings in JavaScript? 279 00:10:14,520 --> 00:10:16,769 So clearly, they are not that 280 00:10:16,770 --> 00:10:18,950 simple. It's not a trivial task. 281 00:10:21,180 --> 00:10:23,219 OK, let's talk about the first problem, 282 00:10:23,220 --> 00:10:24,929 physical addresses and theorem. 283 00:10:24,930 --> 00:10:26,999 So there is a fixed map from physical 284 00:10:27,000 --> 00:10:29,309 addresses to to different cells, 285 00:10:29,310 --> 00:10:31,169 but unfortunately it's not documented. 286 00:10:31,170 --> 00:10:34,109 Buy into it for several reasons. 287 00:10:34,110 --> 00:10:36,719 Mark Seabourne reverse engineered the 288 00:10:36,720 --> 00:10:38,789 mapping function for Sandbridge earlier 289 00:10:38,790 --> 00:10:41,099 this year. And we continue this reverse 290 00:10:41,100 --> 00:10:43,619 engineering just recently for Sandbridge, 291 00:10:43,620 --> 00:10:45,839 IVI, British, Haswa, Skylake and 292 00:10:45,840 --> 00:10:47,190 in different configurations. 293 00:10:49,170 --> 00:10:51,869 What you might have noticed, 294 00:10:51,870 --> 00:10:54,449 the robot serves 295 00:10:54,450 --> 00:10:56,639 as a cache and 296 00:10:56,640 --> 00:10:58,379 accessing something that is served from 297 00:10:58,380 --> 00:10:59,939 the current rollbar takes a different 298 00:10:59,940 --> 00:11:02,189 time than from a from another row. 299 00:11:02,190 --> 00:11:04,889 And if you have a real conflict that 300 00:11:04,890 --> 00:11:06,989 takes much more time 301 00:11:06,990 --> 00:11:08,819 and you can exploit this to build another 302 00:11:08,820 --> 00:11:09,820 tech. 303 00:11:10,200 --> 00:11:12,179 But let's stay with the physical 304 00:11:12,180 --> 00:11:13,409 addresses for now. 305 00:11:13,410 --> 00:11:16,079 And we now know that 306 00:11:16,080 --> 00:11:18,179 we now know the mapping from 307 00:11:18,180 --> 00:11:20,159 physical addresses to dirham cells, but 308 00:11:20,160 --> 00:11:21,779 we don't know the mapping from physical 309 00:11:21,780 --> 00:11:24,239 addresses from from JavaScript 310 00:11:24,240 --> 00:11:25,639 indices to physical addresses. 311 00:11:25,640 --> 00:11:26,640 Right. 312 00:11:27,060 --> 00:11:29,369 So the operating system always 313 00:11:29,370 --> 00:11:31,679 want to optimize wants to optimize 314 00:11:31,680 --> 00:11:33,749 everything. And one optimization is to 315 00:11:33,750 --> 00:11:35,759 use two megabyte pages and two megabyte 316 00:11:35,760 --> 00:11:37,919 pages are more efficient 317 00:11:37,920 --> 00:11:40,949 because you need fewer Tilba entries 318 00:11:40,950 --> 00:11:42,749 and therefore you can have more entries 319 00:11:42,750 --> 00:11:45,629 in the TILBA to translate 320 00:11:45,630 --> 00:11:46,979 visual addresses. 321 00:11:46,980 --> 00:11:49,709 And if you use two megabyte pages, 322 00:11:49,710 --> 00:11:51,779 you see 323 00:11:51,780 --> 00:11:53,469 that the last twenty one bits. 324 00:11:53,470 --> 00:11:55,649 So that's a two megabytes 325 00:11:55,650 --> 00:11:57,569 of the physical address and the virtual 326 00:11:57,570 --> 00:12:00,179 address. They are identical 327 00:12:00,180 --> 00:12:02,459 and now the mellark implementations say, 328 00:12:02,460 --> 00:12:03,719 OK, it's a good idea to 329 00:12:04,740 --> 00:12:06,809 use it to, to allocate large 330 00:12:06,810 --> 00:12:08,039 chunks of memory. 331 00:12:08,040 --> 00:12:10,139 And the operating system says, OK, it's a 332 00:12:10,140 --> 00:12:11,669 good idea to use two megabyte pages 333 00:12:11,670 --> 00:12:13,589 there. And then we have the last twenty 334 00:12:13,590 --> 00:12:14,939 one bits of the physical address in 335 00:12:14,940 --> 00:12:17,069 JavaScript, and that's 336 00:12:17,070 --> 00:12:19,199 probably a good idea. 337 00:12:19,200 --> 00:12:21,269 So furthermore, what we get 338 00:12:21,270 --> 00:12:22,270 from this. 339 00:12:23,020 --> 00:12:25,219 Is that we have several 340 00:12:25,220 --> 00:12:27,429 dirham roles per two megabyte page, 341 00:12:27,430 --> 00:12:29,619 so we know we have several roles 342 00:12:29,620 --> 00:12:31,749 that we can just now hammer and we 343 00:12:31,750 --> 00:12:33,339 have several concurrent addresses in the 344 00:12:33,340 --> 00:12:35,469 cash. So that addresses that map to the 345 00:12:35,470 --> 00:12:37,719 same cash set. So we can also perform 346 00:12:37,720 --> 00:12:39,009 eviction here. 347 00:12:39,010 --> 00:12:41,559 And if we do not have enough 348 00:12:41,560 --> 00:12:43,239 concurrent addresses, we can still use 349 00:12:43,240 --> 00:12:45,549 timing, information, timing, attacks for 350 00:12:45,550 --> 00:12:47,859 cross page information and connect 351 00:12:47,860 --> 00:12:49,089 these two megabyte pages. 352 00:12:49,090 --> 00:12:51,399 By that, you can also perform timing 353 00:12:51,400 --> 00:12:53,589 and text to completely 354 00:12:53,590 --> 00:12:56,379 work without two megabyte pages 355 00:12:56,380 --> 00:12:58,149 and with four kilobyte pages set. 356 00:12:58,150 --> 00:12:59,769 But that takes a lot more time. 357 00:13:01,360 --> 00:13:03,939 So the next question 358 00:13:03,940 --> 00:13:06,009 now, which physical addresses do we 359 00:13:06,010 --> 00:13:07,239 need to access? 360 00:13:07,240 --> 00:13:08,799 So I'm going to. 361 00:13:08,800 --> 00:13:11,019 Well, this is what we call LRU eviction, 362 00:13:11,020 --> 00:13:13,449 because it assumed that the cash uses LRU 363 00:13:13,450 --> 00:13:14,679 replacement policy. 364 00:13:14,680 --> 00:13:16,719 And this is actually exactly what I 365 00:13:16,720 --> 00:13:17,829 showed you before. 366 00:13:17,830 --> 00:13:20,079 We are going to access and addresses from 367 00:13:20,080 --> 00:13:21,729 the same cash set to evict. 368 00:13:21,730 --> 00:13:24,189 And we sip's and this is something 369 00:13:24,190 --> 00:13:25,959 that is also very known in the in the 370 00:13:25,960 --> 00:13:27,219 field of cash ATEX. 371 00:13:27,220 --> 00:13:29,409 And so it is called primaries and 372 00:13:29,410 --> 00:13:31,539 is documented in this article 373 00:13:31,540 --> 00:13:32,800 if you want to read them. 374 00:13:34,180 --> 00:13:36,489 No, we have this property 375 00:13:36,490 --> 00:13:38,049 of the Lesterville cash that it's 376 00:13:38,050 --> 00:13:39,159 inclusive. 377 00:13:39,160 --> 00:13:41,349 And what it means is that if we 378 00:13:41,350 --> 00:13:43,389 evict a line from the Lesterville cash, 379 00:13:43,390 --> 00:13:45,489 it will be evicted from the whole hinoki 380 00:13:45,490 --> 00:13:47,979 to just guarantee this inclusive 381 00:13:47,980 --> 00:13:50,409 property. So we just need to 382 00:13:50,410 --> 00:13:52,209 evict line from the last of it. 383 00:13:52,210 --> 00:13:54,489 Cash. That sounds easy, right? 384 00:13:54,490 --> 00:13:56,049 Actually, not that much. 385 00:13:56,050 --> 00:13:58,149 Again, so we need to 386 00:13:58,150 --> 00:14:00,309 know very precisely where 387 00:14:00,310 --> 00:14:02,499 the addresses are mapped in the cash. 388 00:14:02,500 --> 00:14:04,569 And for that, for the last about cash, we 389 00:14:04,570 --> 00:14:06,729 need to know first in which slice 390 00:14:06,730 --> 00:14:08,469 and address is going to be mapped. 391 00:14:08,470 --> 00:14:11,019 And there is an internal 392 00:14:11,020 --> 00:14:13,119 process also hash function that 393 00:14:13,120 --> 00:14:15,249 maps physical addresses into 394 00:14:15,250 --> 00:14:17,469 sleights and is and documented by 395 00:14:17,470 --> 00:14:18,470 Intel. 396 00:14:18,880 --> 00:14:20,949 So fortunately, just right 397 00:14:20,950 --> 00:14:23,259 before arriving in, that's 398 00:14:23,260 --> 00:14:25,449 what was what was I was tackling 399 00:14:25,450 --> 00:14:28,059 was a reverse engineered this 400 00:14:28,060 --> 00:14:30,339 dysfunction. And I actually succeeded 401 00:14:30,340 --> 00:14:31,899 in reversing it. 402 00:14:31,900 --> 00:14:34,329 And I was actually not alone. 403 00:14:34,330 --> 00:14:36,699 There were also other teams 404 00:14:36,700 --> 00:14:38,049 working on it. So if you want to release 405 00:14:38,050 --> 00:14:40,329 the gory details on how we did this 406 00:14:40,330 --> 00:14:42,429 and what we achieved, you can also 407 00:14:42,430 --> 00:14:45,729 look at this paper's now fun fact. 408 00:14:45,730 --> 00:14:47,949 This hash function is basically an XO 409 00:14:47,950 --> 00:14:49,929 of attributes. 410 00:14:49,930 --> 00:14:52,089 And yes, they call it a hash function. 411 00:14:55,390 --> 00:14:57,909 OK, so 412 00:14:57,910 --> 00:14:59,979 for the replacement policy we just heard, 413 00:14:59,980 --> 00:15:02,379 LRU eviction is justice and exercise 414 00:15:02,380 --> 00:15:04,479 to address that map to the same Cash 415 00:15:04,480 --> 00:15:06,309 said. And we will just revisit this 416 00:15:06,310 --> 00:15:07,329 shortly. 417 00:15:07,330 --> 00:15:09,519 So the LRU replacement 418 00:15:09,520 --> 00:15:11,679 policy says the oldest entry is replaced 419 00:15:11,680 --> 00:15:13,449 first. So we need to have some kind of 420 00:15:13,450 --> 00:15:15,459 time stamp for every cache line. 421 00:15:15,460 --> 00:15:17,589 And now when we access any 422 00:15:17,590 --> 00:15:19,659 address, it is maybe loaded into the 423 00:15:19,660 --> 00:15:21,579 cache or maybe it is already there and 424 00:15:21,580 --> 00:15:23,539 the time stamp is updated. 425 00:15:23,540 --> 00:15:25,449 And if we do this end times for an end, 426 00:15:25,450 --> 00:15:27,279 we catch set. 427 00:15:27,280 --> 00:15:29,709 Then we have certainly evicted 428 00:15:29,710 --> 00:15:32,259 the targeted address 429 00:15:32,260 --> 00:15:34,449 now on more recent CPU's. 430 00:15:34,450 --> 00:15:36,009 That's not true anymore. 431 00:15:36,010 --> 00:15:38,349 They don't have LRU replacement policy 432 00:15:38,350 --> 00:15:40,089 and that's not good because if you try 433 00:15:40,090 --> 00:15:42,219 LRU eviction and such and such 434 00:15:42,220 --> 00:15:44,499 a c.p.u, it might look like this. 435 00:15:44,500 --> 00:15:47,829 So, yeah, it's just something 436 00:15:47,830 --> 00:15:49,389 you can understand a little bit more. 437 00:15:49,390 --> 00:15:52,359 But but that's too much for this talk. 438 00:15:52,360 --> 00:15:54,489 What I can say, we only 439 00:15:54,490 --> 00:15:56,589 have a 75 percent 440 00:15:56,590 --> 00:15:59,049 success rate on 441 00:15:59,050 --> 00:16:01,329 Hatswell if we perform LRU 442 00:16:01,330 --> 00:16:03,429 eviction and we of 443 00:16:03,430 --> 00:16:05,169 course, we can perform more excess more 444 00:16:05,170 --> 00:16:07,389 than the cash is, 445 00:16:07,390 --> 00:16:09,699 then the size of the cash said. 446 00:16:09,700 --> 00:16:11,859 But this would be to slow. 447 00:16:11,860 --> 00:16:13,549 The success rate will be higher. 448 00:16:13,550 --> 00:16:15,429 So it would work for cash tax, but it 449 00:16:15,430 --> 00:16:17,139 would not work for Rose-Marie. 450 00:16:17,140 --> 00:16:18,939 Instead, we have to think about how to 451 00:16:18,940 --> 00:16:21,249 trick the cash into 452 00:16:21,250 --> 00:16:23,379 evicting the targeted 453 00:16:23,380 --> 00:16:25,689 address earlier. So tricking the cash 454 00:16:25,690 --> 00:16:28,149 in, falling back to LRU eviction. 455 00:16:28,150 --> 00:16:30,249 And one strategy to do that is 456 00:16:30,250 --> 00:16:31,209 this pattern. 457 00:16:31,210 --> 00:16:33,459 So you can see first we exis address 458 00:16:33,460 --> 00:16:36,069 one, then we address two, then we 459 00:16:36,070 --> 00:16:37,569 address one again, then two. 460 00:16:37,570 --> 00:16:39,279 And then two and three and two and three 461 00:16:39,280 --> 00:16:40,389 and so on. 462 00:16:40,390 --> 00:16:42,579 And using this excess pattern, we 463 00:16:42,580 --> 00:16:44,739 have a fast and effective eviction has 464 00:16:44,740 --> 00:16:46,629 with CPU's and also an Ivy bridge. 465 00:16:46,630 --> 00:16:49,539 And it also works similarly on Skylake. 466 00:16:49,540 --> 00:16:51,609 And with this eviction strategy, we can 467 00:16:51,610 --> 00:16:53,439 achieve an eviction rate of more than 468 00:16:53,440 --> 00:16:56,019 ninety nine point nine seven percent. 469 00:16:56,020 --> 00:16:57,730 And this is enough for tremoring. 470 00:16:59,070 --> 00:17:02,399 So there's one remaining question 471 00:17:02,400 --> 00:17:03,869 how to get accurate timing and 472 00:17:03,870 --> 00:17:05,249 JavaScript, and we need the accurate 473 00:17:05,250 --> 00:17:07,049 timing for two purposes. 474 00:17:07,050 --> 00:17:08,879 First, to interconnect these page 475 00:17:08,880 --> 00:17:11,129 informations if we 476 00:17:11,130 --> 00:17:13,169 do not have enough concurrent addresses 477 00:17:13,170 --> 00:17:14,489 on a single page. 478 00:17:14,490 --> 00:17:16,588 And secondly, we have 479 00:17:16,589 --> 00:17:19,019 to decide whether an address is 480 00:17:19,020 --> 00:17:21,059 cached. At some point, we have to decide 481 00:17:21,060 --> 00:17:23,219 whether eviction was successful or 482 00:17:23,220 --> 00:17:25,289 it was not successful and a native 483 00:17:25,290 --> 00:17:27,598 code. This is fairly easy because 484 00:17:27,599 --> 00:17:29,669 you can just use our DTIC and you get 485 00:17:29,670 --> 00:17:32,309 a sub nanosecond accurate timestamp 486 00:17:32,310 --> 00:17:33,389 in JavaScript. 487 00:17:33,390 --> 00:17:35,309 It's a bit more complicated, but window 488 00:17:35,310 --> 00:17:36,899 performance now is just perfect. 489 00:17:36,900 --> 00:17:38,969 It works if you have 490 00:17:38,970 --> 00:17:40,559 enough accesses. 491 00:17:40,560 --> 00:17:42,479 Then there was a recent patch to prevent 492 00:17:42,480 --> 00:17:43,949 casual text in JavaScript. 493 00:17:43,950 --> 00:17:45,509 You should also check out this paper. 494 00:17:45,510 --> 00:17:47,849 It's really cool so they can track 495 00:17:47,850 --> 00:17:49,259 mouse movements and stuff like that in 496 00:17:49,260 --> 00:17:50,369 JavaScript. 497 00:17:50,370 --> 00:17:52,499 And they patched this by rounding 498 00:17:52,500 --> 00:17:53,999 the time to five microseconds. 499 00:17:54,000 --> 00:17:55,709 And this helps against some cache 500 00:17:55,710 --> 00:17:57,749 attacks. But it does not help against 501 00:17:57,750 --> 00:17:59,789 cohering because we perform like millions 502 00:17:59,790 --> 00:18:01,889 of accesses and that we consume 503 00:18:01,890 --> 00:18:04,160 more than five microseconds in time. 504 00:18:06,840 --> 00:18:09,179 We evaluated the 505 00:18:09,180 --> 00:18:11,669 bit flip rate on our Hasselblad 506 00:18:11,670 --> 00:18:14,789 test machine, and we 507 00:18:14,790 --> 00:18:16,919 during this evaluation, we 508 00:18:16,920 --> 00:18:19,109 varied the refresh interval in 509 00:18:19,110 --> 00:18:21,299 the BIOS. So the default 510 00:18:21,300 --> 00:18:23,939 is very low and the 75 511 00:18:23,940 --> 00:18:26,489 something is maximum 512 00:18:26,490 --> 00:18:27,509 refresh interval. 513 00:18:27,510 --> 00:18:29,579 We could set and what you can see 514 00:18:29,580 --> 00:18:31,649 is that there is some point where 515 00:18:31,650 --> 00:18:33,779 the bits slip a bit, flips start 516 00:18:33,780 --> 00:18:36,299 to occur, and for SEAL Flush 517 00:18:36,300 --> 00:18:38,669 and for native code eviction, it's 518 00:18:38,670 --> 00:18:39,809 approximately the same. 519 00:18:39,810 --> 00:18:42,029 We have a bit less bit flips 520 00:18:42,030 --> 00:18:44,099 in the eviction variant 521 00:18:44,100 --> 00:18:45,899 than in the variant. 522 00:18:45,900 --> 00:18:48,629 And in the JavaScript variant 523 00:18:48,630 --> 00:18:51,119 it takes a bit higher refresh 524 00:18:51,120 --> 00:18:53,039 interval because JavaScript is apparently 525 00:18:53,040 --> 00:18:55,439 a bit slower than our optimized 526 00:18:55,440 --> 00:18:56,440 native code. 527 00:18:57,510 --> 00:18:59,669 So this is a number of lives within five, 528 00:18:59,670 --> 00:19:01,769 15 minutes, you can see that in the case 529 00:19:01,770 --> 00:19:03,839 of eviction or see of 530 00:19:03,840 --> 00:19:06,239 the flush and even for the higher refresh 531 00:19:06,240 --> 00:19:08,369 intervals for JavaScript, 532 00:19:08,370 --> 00:19:11,009 we have like more than 10000 533 00:19:11,010 --> 00:19:13,139 bed flips. That's more than 10 bit flips 534 00:19:13,140 --> 00:19:14,339 per second. 535 00:19:14,340 --> 00:19:15,340 OK, 536 00:19:16,890 --> 00:19:18,929 depending on your machine, it will work 537 00:19:18,930 --> 00:19:21,149 that well or it will not work that well. 538 00:19:21,150 --> 00:19:23,249 That's totally up to the hardware 539 00:19:23,250 --> 00:19:24,250 that's in your system. 540 00:19:25,320 --> 00:19:27,599 So let's now talk about exploits. 541 00:19:27,600 --> 00:19:29,729 How can we build exploits from this from 542 00:19:29,730 --> 00:19:30,839 these boot flips? 543 00:19:30,840 --> 00:19:32,219 And the first idea we had? 544 00:19:32,220 --> 00:19:34,589 Yeah, we just part the root exploit 545 00:19:34,590 --> 00:19:36,539 by Mark Seabourne to JavaScript. 546 00:19:36,540 --> 00:19:38,279 And actually this might work. 547 00:19:38,280 --> 00:19:40,169 We haven't finished this work yet, but it 548 00:19:40,170 --> 00:19:42,599 might work. And the exploit 549 00:19:42,600 --> 00:19:44,699 by Mike Seabourne works by doing Page 550 00:19:44,700 --> 00:19:46,289 Tabit Spring. So you fill the whole 551 00:19:46,290 --> 00:19:48,059 memory with page Tabors. 552 00:19:48,060 --> 00:19:49,499 And if you have a bit flip in a page 553 00:19:49,500 --> 00:19:51,989 table, that's bad because you can 554 00:19:51,990 --> 00:19:53,789 gain access to one of your own page 555 00:19:53,790 --> 00:19:54,790 statements by that. 556 00:19:55,650 --> 00:19:57,759 So this exploit needs shared 557 00:19:57,760 --> 00:19:59,729 memory because you map all the time on 558 00:19:59,730 --> 00:20:00,959 the same page again. 559 00:20:00,960 --> 00:20:02,879 So you don't need any physical memory for 560 00:20:02,880 --> 00:20:05,189 your page, but only for the page tables. 561 00:20:05,190 --> 00:20:06,390 And we don't have 562 00:20:07,470 --> 00:20:09,419 short memory in JavaScript. 563 00:20:09,420 --> 00:20:11,519 But fortunately, we observed earlier 564 00:20:11,520 --> 00:20:13,769 this year in the when working on another 565 00:20:13,770 --> 00:20:16,079 paper that zero 566 00:20:16,080 --> 00:20:18,809 pages are usually hated. 567 00:20:18,810 --> 00:20:20,849 And this means we have some kind of 568 00:20:20,850 --> 00:20:22,949 shared memory because all zero pages will 569 00:20:22,950 --> 00:20:24,989 map to the same physical page. 570 00:20:24,990 --> 00:20:26,609 And then we have some kind of shared 571 00:20:26,610 --> 00:20:28,229 memory in JavaScript. 572 00:20:28,230 --> 00:20:29,230 That's bad. 573 00:20:30,080 --> 00:20:32,299 OK, physical 574 00:20:32,300 --> 00:20:34,759 memory access in 575 00:20:34,760 --> 00:20:36,739 native code, if we want to build the 576 00:20:36,740 --> 00:20:38,869 exploit, we just follow 577 00:20:38,870 --> 00:20:40,789 a few steps. The first is find and 578 00:20:40,790 --> 00:20:41,819 exploit a little bit flip. 579 00:20:41,820 --> 00:20:44,209 So a bit flip that in the right position 580 00:20:44,210 --> 00:20:46,099 and address it probably. 581 00:20:46,100 --> 00:20:48,229 And then we release the 582 00:20:48,230 --> 00:20:50,599 page where we have the bit flip 583 00:20:50,600 --> 00:20:52,489 and then we try to put a page table there 584 00:20:52,490 --> 00:20:55,309 by doing the page table spraying, 585 00:20:55,310 --> 00:20:57,949 allocating a lot of pages, 586 00:20:57,950 --> 00:20:59,899 and then we try to trigger the bit flip 587 00:20:59,900 --> 00:21:02,149 again and then we just check whether 588 00:21:02,150 --> 00:21:04,099 it was successful, whether we have a page 589 00:21:04,100 --> 00:21:05,619 table now mapped instead of the Shell 590 00:21:05,620 --> 00:21:07,879 page, and then we can try to modify 591 00:21:07,880 --> 00:21:09,979 the page table and see where 592 00:21:09,980 --> 00:21:12,289 in our address base something is 593 00:21:12,290 --> 00:21:13,290 changed by that. 594 00:21:14,690 --> 00:21:16,489 Now, if you want to do the same exploit 595 00:21:16,490 --> 00:21:18,559 in JavaScript, we would 596 00:21:18,560 --> 00:21:20,869 use zero pages and zero pages are 597 00:21:20,870 --> 00:21:22,009 read only. 598 00:21:22,010 --> 00:21:24,379 So we have to only to change two pieces 599 00:21:24,380 --> 00:21:27,139 here. And this is attack. 600 00:21:27,140 --> 00:21:29,359 The first is we also have to flip 601 00:21:29,360 --> 00:21:31,129 flip the right of it. 602 00:21:31,130 --> 00:21:33,409 And that's much harder because the writer 603 00:21:33,410 --> 00:21:35,479 is in a specific position and 604 00:21:35,480 --> 00:21:37,249 we only have one right a little bit and 605 00:21:37,250 --> 00:21:39,139 not many bits. 606 00:21:39,140 --> 00:21:41,389 And the 607 00:21:41,390 --> 00:21:42,389 other thing we change. 608 00:21:42,390 --> 00:21:44,509 Yeah, we use zero pages instead of the 609 00:21:44,510 --> 00:21:45,510 shared pages. 610 00:21:47,320 --> 00:21:49,389 I tried this on my machines, and it is 611 00:21:49,390 --> 00:21:52,209 possible to find such big flips, 612 00:21:52,210 --> 00:21:54,669 but they are, of course, much rarer 613 00:21:54,670 --> 00:21:56,919 than other big flips, regular flips, 614 00:21:56,920 --> 00:21:58,669 single bit flips. 615 00:21:58,670 --> 00:22:00,889 OK, code 616 00:22:00,890 --> 00:22:03,139 execution as a route, if we want to have 617 00:22:03,140 --> 00:22:05,689 that from our full memory access, 618 00:22:05,690 --> 00:22:07,939 that's also, again, rather easy 619 00:22:07,940 --> 00:22:09,679 because we can just search for a known 620 00:22:09,680 --> 00:22:11,749 binary page and modify the 621 00:22:11,750 --> 00:22:13,349 page and add some special code. 622 00:22:13,350 --> 00:22:15,759 And this page will probably not 623 00:22:15,760 --> 00:22:17,899 thrown out of the memory because 624 00:22:17,900 --> 00:22:19,309 we have a large file cache in our 625 00:22:19,310 --> 00:22:21,319 operating systems and then we can just 626 00:22:21,320 --> 00:22:23,479 wait until the root 627 00:22:23,480 --> 00:22:25,969 user executes the shell code and 628 00:22:25,970 --> 00:22:27,949 do anything on the system. 629 00:22:27,950 --> 00:22:28,950 OK. 630 00:22:29,750 --> 00:22:31,939 Now we have a nice attack, we have to 631 00:22:31,940 --> 00:22:33,769 find countermeasures against it. 632 00:22:33,770 --> 00:22:35,929 Yeah, so the 633 00:22:35,930 --> 00:22:37,819 first thing that comes to mind is that we 634 00:22:37,820 --> 00:22:40,459 should avoid the bird I 635 00:22:40,460 --> 00:22:41,809 right at the beginning. So it's a 636 00:22:41,810 --> 00:22:42,709 hardware issue. 637 00:22:42,710 --> 00:22:44,419 We should patch it in hardware. 638 00:22:44,420 --> 00:22:46,969 And actually the Windows are currently 639 00:22:46,970 --> 00:22:47,970 doing this. 640 00:22:48,620 --> 00:22:50,689 So one solution is to do some 641 00:22:50,690 --> 00:22:52,439 sort of dynamic or refreshing. 642 00:22:52,440 --> 00:22:54,529 So the idea is to refresh the 643 00:22:54,530 --> 00:22:56,929 rows before a bit flips can before 644 00:22:56,930 --> 00:22:58,759 it flips can occur. 645 00:22:58,760 --> 00:23:00,919 So sort of a smart way 646 00:23:00,920 --> 00:23:03,209 of of refreshing drops 647 00:23:03,210 --> 00:23:05,149 knows. The issue is that it can only ship 648 00:23:05,150 --> 00:23:06,079 in new hardware. 649 00:23:06,080 --> 00:23:08,089 You cannot patch your own hardware right 650 00:23:08,090 --> 00:23:10,309 now. So we have sort of huge 651 00:23:10,310 --> 00:23:13,189 issue of legacy hardware because 652 00:23:13,190 --> 00:23:15,319 the Ruhama bug, it 653 00:23:15,320 --> 00:23:17,539 basically affects all 654 00:23:17,540 --> 00:23:18,559 different vendors. 655 00:23:18,560 --> 00:23:20,029 So it's really widespread. 656 00:23:20,030 --> 00:23:22,609 And we have this hardware that will stay 657 00:23:22,610 --> 00:23:24,379 for a few years. 658 00:23:24,380 --> 00:23:26,899 The second idea is to patch the bios 659 00:23:26,900 --> 00:23:28,700 again. It is already shipped 660 00:23:29,720 --> 00:23:31,789 here. That is more simple as a sort of 661 00:23:31,790 --> 00:23:33,379 dumb way of doing this. 662 00:23:33,380 --> 00:23:35,059 We just increase the refresh rate. 663 00:23:35,060 --> 00:23:37,249 We refresh all rose 664 00:23:37,250 --> 00:23:39,379 more often, usually by doubling the 665 00:23:39,380 --> 00:23:41,599 refresh. Right now, the first issue 666 00:23:41,600 --> 00:23:43,879 is it it might not be sufficient for 667 00:23:43,880 --> 00:23:46,519 all machines, as was suggested 668 00:23:46,520 --> 00:23:48,169 by the original paper. 669 00:23:48,170 --> 00:23:50,239 Now, the second issue is a bit more 670 00:23:50,240 --> 00:23:52,309 pressing is that we need the 671 00:23:52,310 --> 00:23:54,589 BIOS updates and like who 672 00:23:54,590 --> 00:23:56,329 does that? 673 00:23:56,330 --> 00:23:57,560 Seriously? 674 00:24:00,180 --> 00:24:02,339 OK, we had another 675 00:24:02,340 --> 00:24:05,009 idea, because we want to make 676 00:24:05,010 --> 00:24:06,869 we want to find something against the 677 00:24:06,870 --> 00:24:09,149 problem, and one idea that we had was 678 00:24:09,150 --> 00:24:11,069 while we were hammering all the time and 679 00:24:11,070 --> 00:24:13,019 had no bit flip that was exploited, we 680 00:24:13,020 --> 00:24:15,329 thought, OK, life 681 00:24:15,330 --> 00:24:16,640 is not perfect. That's OK. 682 00:24:17,880 --> 00:24:20,009 What if we just say we don't care about 683 00:24:20,010 --> 00:24:21,929 these self-destructive processes that 684 00:24:21,930 --> 00:24:24,239 have been flips in their own memory? 685 00:24:24,240 --> 00:24:25,529 We just have to prevent that. 686 00:24:25,530 --> 00:24:27,629 They have bit Flip's in memory that 687 00:24:27,630 --> 00:24:29,819 has a different privilege or a memory of 688 00:24:29,820 --> 00:24:31,679 other processes. We just have to prevent 689 00:24:31,680 --> 00:24:34,709 this. And if we can prevent this, 690 00:24:34,710 --> 00:24:37,529 then we can prevent any Rosmer exploits. 691 00:24:37,530 --> 00:24:39,989 And that's OK. Let's say rumoring 692 00:24:39,990 --> 00:24:42,539 is OK as long as you cannot exploit it. 693 00:24:42,540 --> 00:24:44,609 So the idea is 694 00:24:44,610 --> 00:24:47,159 to have sort of physical memory pools 695 00:24:47,160 --> 00:24:48,209 in physical memory. 696 00:24:48,210 --> 00:24:50,639 You separate pages that have different 697 00:24:50,640 --> 00:24:52,739 privileges and have gaps 698 00:24:52,740 --> 00:24:54,869 in physical memory that prevent 699 00:24:54,870 --> 00:24:56,699 that any bit flips occur in different 700 00:24:56,700 --> 00:24:58,869 privileged memory regions. 701 00:24:58,870 --> 00:25:01,649 Now, that sounds a bit awful, but 702 00:25:01,650 --> 00:25:03,719 if you think about it a bit, it could 703 00:25:03,720 --> 00:25:05,519 work if you if your group is into 704 00:25:05,520 --> 00:25:07,889 privileges and you only only have to 705 00:25:07,890 --> 00:25:10,439 leave a small gap between these memory 706 00:25:10,440 --> 00:25:11,440 pools. 707 00:25:12,170 --> 00:25:14,779 So for the conclusions of 708 00:25:14,780 --> 00:25:17,149 cash, eviction is fast enough to replace 709 00:25:17,150 --> 00:25:19,339 sales that we have seen that and 710 00:25:19,340 --> 00:25:21,079 without still flush, our take is 711 00:25:21,080 --> 00:25:23,239 independent of programing languages and 712 00:25:23,240 --> 00:25:24,679 available instructions. 713 00:25:24,680 --> 00:25:26,839 So we could even perform it on 714 00:25:26,840 --> 00:25:29,689 our smartphones or something like that. 715 00:25:29,690 --> 00:25:32,569 It's the first hot refold attack in 716 00:25:32,570 --> 00:25:34,519 JavaScript. It's also the first half of 717 00:25:34,520 --> 00:25:36,679 tech in that is performed through 718 00:25:36,680 --> 00:25:37,939 a remote website. 719 00:25:37,940 --> 00:25:39,409 And performing this attack through 720 00:25:39,410 --> 00:25:41,419 website and through a website is actually 721 00:25:41,420 --> 00:25:43,579 a bit awful because if you say, 722 00:25:43,580 --> 00:25:45,739 OK, Rosemere, maybe one percent 723 00:25:45,740 --> 00:25:46,789 of systems is affected. 724 00:25:46,790 --> 00:25:48,559 Yeah, if I run a website and run this on 725 00:25:48,560 --> 00:25:50,569 one million users, that will still be an 726 00:25:50,570 --> 00:25:52,549 awful lot of people that are affected. 727 00:25:52,550 --> 00:25:55,009 Right. So we are not there yet. 728 00:25:55,010 --> 00:25:57,499 But look out for the Roma Jass 729 00:25:57,500 --> 00:25:58,729 JavaScript framework. 730 00:26:00,060 --> 00:26:01,060 Thank you. 731 00:26:12,160 --> 00:26:13,329 Thank you very much. 732 00:26:13,330 --> 00:26:14,919 We have about five minutes left for 733 00:26:14,920 --> 00:26:16,579 questions and the first two questions 734 00:26:16,580 --> 00:26:17,580 over the Internet. 735 00:26:22,180 --> 00:26:23,769 Hi, Daniel. 736 00:26:23,770 --> 00:26:25,899 So pretty much all of 737 00:26:25,900 --> 00:26:28,269 our U.S. wants to know, what about 738 00:26:28,270 --> 00:26:30,849 Ekrem, how is Iran vulnerable? 739 00:26:30,850 --> 00:26:33,219 Yeah, that's a great question. 740 00:26:33,220 --> 00:26:34,179 Thank you for asking. 741 00:26:34,180 --> 00:26:36,309 It is a serum basically 742 00:26:36,310 --> 00:26:37,819 works like this. You have these eight 743 00:26:37,820 --> 00:26:40,179 chips and you have a nine chip there. 744 00:26:40,180 --> 00:26:43,059 And this ninth ship also has rules. 745 00:26:43,060 --> 00:26:44,979 And if you zero here, it has to get to 746 00:26:44,980 --> 00:26:46,179 check them from here. 747 00:26:46,180 --> 00:26:47,679 And then you access this through here and 748 00:26:47,680 --> 00:26:49,029 then you access Israel here for the 749 00:26:49,030 --> 00:26:51,159 checks. Right. So you hammering both 750 00:26:51,160 --> 00:26:53,409 sides at the same time. 751 00:26:53,410 --> 00:26:55,509 What then happens is I'm sure 752 00:26:55,510 --> 00:26:57,939 there are there is a serum that is more 753 00:26:57,940 --> 00:26:59,709 resistant to Rosemary hammering, but that 754 00:26:59,710 --> 00:27:01,779 is apparently the serum that is 755 00:27:01,780 --> 00:27:03,909 less stable against 756 00:27:03,910 --> 00:27:05,789 Rosemary. And that's disturbing, right? 757 00:27:08,760 --> 00:27:11,219 And the second question for me is that 758 00:27:11,220 --> 00:27:13,469 Frank wants to know, does it work 759 00:27:13,470 --> 00:27:15,749 the other way around like no chance 760 00:27:15,750 --> 00:27:17,339 working on the server and attacking the 761 00:27:17,340 --> 00:27:19,469 server through input and 762 00:27:19,470 --> 00:27:20,429 the Web page? 763 00:27:20,430 --> 00:27:22,039 I didn't get it. 764 00:27:22,040 --> 00:27:24,119 Also notes is 765 00:27:24,120 --> 00:27:25,169 China. Yeah. 766 00:27:26,340 --> 00:27:28,429 What would you do with Noticia, exploit 767 00:27:28,430 --> 00:27:30,859 the server? Oh, yeah, yeah, probably 768 00:27:30,860 --> 00:27:31,429 that would work. 769 00:27:31,430 --> 00:27:33,499 If you can execute JavaScript code 770 00:27:33,500 --> 00:27:35,449 on the server, you could do the same. 771 00:27:35,450 --> 00:27:36,680 So on server side, yeah. 772 00:27:38,790 --> 00:27:40,929 OK, the gentleman with microphone one, 773 00:27:40,930 --> 00:27:41,819 hello. 774 00:27:41,820 --> 00:27:44,189 So the easy question 775 00:27:44,190 --> 00:27:45,869 would have been my first question, so 776 00:27:45,870 --> 00:27:47,669 could I have a second one? 777 00:27:47,670 --> 00:27:50,879 The second question is, is 778 00:27:50,880 --> 00:27:53,309 a shot nine a shot enough 779 00:27:53,310 --> 00:27:54,839 refresh rate? 780 00:27:54,840 --> 00:27:57,119 Will this always prevent 781 00:27:57,120 --> 00:27:59,699 Rosamma or is this not 782 00:27:59,700 --> 00:28:00,209 enough? 783 00:28:00,210 --> 00:28:02,399 As a fix on my 784 00:28:02,400 --> 00:28:04,529 laptop? I just have here 785 00:28:04,530 --> 00:28:06,689 the I observed one 786 00:28:06,690 --> 00:28:08,879 bit flip where I had to perform. 787 00:28:08,880 --> 00:28:11,009 Sixty five thousand 788 00:28:11,010 --> 00:28:13,619 of these double hammering 789 00:28:13,620 --> 00:28:15,719 accesses 65000 790 00:28:15,720 --> 00:28:16,909 accesses studier. 791 00:28:16,910 --> 00:28:19,229 That's only a very short 792 00:28:19,230 --> 00:28:20,249 amount of time. 793 00:28:20,250 --> 00:28:22,289 I don't think you can solve this with the 794 00:28:22,290 --> 00:28:24,509 refresh rate, but for most laptop 795 00:28:24,510 --> 00:28:26,759 it will most laptops and desktop 796 00:28:26,760 --> 00:28:28,649 PCs, it will be sufficient. 797 00:28:28,650 --> 00:28:30,869 So here the answer was the 798 00:28:30,870 --> 00:28:32,969 range you can manipulate in 799 00:28:32,970 --> 00:28:35,259 the BIOS. My question was, oh yeah, you 800 00:28:35,260 --> 00:28:37,829 range of existing biosequestration 801 00:28:37,830 --> 00:28:38,309 walls. 802 00:28:38,310 --> 00:28:40,379 If we will always be able 803 00:28:40,380 --> 00:28:42,539 to produce a bios with type of timing, 804 00:28:42,540 --> 00:28:45,139 which is enough to prevent Roraima 805 00:28:45,140 --> 00:28:47,429 not you cannot configure configure 806 00:28:47,430 --> 00:28:49,619 it in all bias's, but if you can 807 00:28:49,620 --> 00:28:51,209 configure it you can set it. 808 00:28:51,210 --> 00:28:53,609 Certainly set it low enough that you are 809 00:28:53,610 --> 00:28:55,799 resistant against Rosmer. 810 00:28:55,800 --> 00:28:58,049 OK, next. Next question, microphone two 811 00:28:58,050 --> 00:28:59,609 and also that microphone number for you. 812 00:29:00,620 --> 00:29:03,259 So you just mentioned mobile devices, 813 00:29:03,260 --> 00:29:04,669 have you ever tried it, actually? 814 00:29:04,670 --> 00:29:06,749 And how much mobile devices 815 00:29:06,750 --> 00:29:07,549 are affected? 816 00:29:07,550 --> 00:29:09,619 Yes, we tried it and we even 817 00:29:09,620 --> 00:29:10,969 put a smartphone for that in the 818 00:29:10,970 --> 00:29:12,979 refrigerator because that apparently 819 00:29:12,980 --> 00:29:14,709 changes the refresh interval. 820 00:29:18,320 --> 00:29:19,320 But we. 821 00:29:23,110 --> 00:29:24,849 To have the bit flip's, you have to 822 00:29:24,850 --> 00:29:27,609 hammer the Turow's, right, and 823 00:29:27,610 --> 00:29:29,919 right now we have not yet 824 00:29:29,920 --> 00:29:32,439 reverse engineered the mapping 825 00:29:32,440 --> 00:29:35,259 for the EP three 826 00:29:35,260 --> 00:29:37,419 on my smartphone, so 827 00:29:37,420 --> 00:29:38,949 we still have to do that. 828 00:29:38,950 --> 00:29:39,950 OK. 829 00:29:44,740 --> 00:29:46,989 If I understood correctly, 830 00:29:46,990 --> 00:29:49,209 the hammering is more 831 00:29:49,210 --> 00:29:51,669 effective in flipping beats, 832 00:29:51,670 --> 00:29:53,529 the faster it occurs. 833 00:29:53,530 --> 00:29:56,179 So did SMK 834 00:29:56,180 --> 00:29:58,359 support in paralysis make the attack 835 00:29:58,360 --> 00:30:00,720 more effective? 836 00:30:02,230 --> 00:30:05,379 To my knowledge, as MGE 837 00:30:05,380 --> 00:30:08,169 does not provide you with native 838 00:30:08,170 --> 00:30:10,359 access to native code, it just provides 839 00:30:10,360 --> 00:30:12,789 you with efficient 840 00:30:12,790 --> 00:30:15,039 ways to implement something in JavaScript 841 00:30:15,040 --> 00:30:17,139 and you can basically 842 00:30:17,140 --> 00:30:18,129 do this by hand. 843 00:30:18,130 --> 00:30:20,709 This takes like X or zero to something 844 00:30:20,710 --> 00:30:22,299 and then it will be a more efficient 845 00:30:22,300 --> 00:30:24,579 statement in the optimized code 846 00:30:24,580 --> 00:30:26,649 that is executed on the CPU. 847 00:30:26,650 --> 00:30:28,869 And we sort of 848 00:30:28,870 --> 00:30:31,329 did something like that to 849 00:30:31,330 --> 00:30:32,889 to run our attack in JavaScript. 850 00:30:32,890 --> 00:30:35,109 But it's really simple to to achieve 851 00:30:35,110 --> 00:30:36,789 this. You don't have to perform a lot of 852 00:30:36,790 --> 00:30:38,859 optimizations there because it's it's 853 00:30:38,860 --> 00:30:40,659 pointedly referencing what can you do 854 00:30:40,660 --> 00:30:41,660 wrong with it. 855 00:30:44,310 --> 00:30:45,479 OK, thank you. 856 00:30:45,480 --> 00:30:47,099 Time is up. Thanks for the excellent 857 00:30:47,100 --> 00:30:48,100 timekeeping.