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/478 Thanks! 1 00:00:11,030 --> 00:00:13,129 So thank you, so I'm Cheryl 2 00:00:13,130 --> 00:00:14,659 Hudson, and I'm going to be talking about 3 00:00:14,660 --> 00:00:17,059 Thunder Strike two, which is 4 00:00:17,060 --> 00:00:19,219 a firmware vulnerability or a set 5 00:00:19,220 --> 00:00:21,679 of firmware vulnerabilities on Mac books. 6 00:00:21,680 --> 00:00:23,929 You might have seen it in the press has, 7 00:00:23,930 --> 00:00:25,549 you know, the first firmware worm that 8 00:00:25,550 --> 00:00:27,709 affects Macs, that it's, 9 00:00:27,710 --> 00:00:30,109 you know, super stealthy in back doors 10 00:00:30,110 --> 00:00:32,449 them, that it remains 11 00:00:32,450 --> 00:00:34,549 after reformatting and it can be 12 00:00:34,550 --> 00:00:36,649 remotely installed and 13 00:00:36,650 --> 00:00:38,359 it's undetectable and it can't be 14 00:00:38,360 --> 00:00:39,360 removed. 15 00:00:40,650 --> 00:00:42,719 There's a lot of hyperbole in these sort 16 00:00:42,720 --> 00:00:44,939 of press reports, but it is true 17 00:00:44,940 --> 00:00:46,949 that firmware a malware, once it's 18 00:00:46,950 --> 00:00:49,149 installed, is very hard to detect, 19 00:00:49,150 --> 00:00:50,639 very hard to remove. 20 00:00:50,640 --> 00:00:52,889 And that's because it installs in the 21 00:00:52,890 --> 00:00:55,169 spy flash on the motherboard, 22 00:00:55,170 --> 00:00:56,639 also called the boot ram. 23 00:00:56,640 --> 00:00:59,009 And on most systems, 24 00:00:59,010 --> 00:01:00,989 the S.P.I flash is really the root of 25 00:01:00,990 --> 00:01:02,850 trust. This is where all of 26 00:01:04,260 --> 00:01:06,379 everything in 27 00:01:06,380 --> 00:01:08,459 the security of the boot process depends 28 00:01:08,460 --> 00:01:10,589 on the sanctity of the boot 29 00:01:10,590 --> 00:01:11,590 flash. 30 00:01:12,270 --> 00:01:14,819 And because this is 31 00:01:14,820 --> 00:01:16,979 boot, flash contains literally 32 00:01:16,980 --> 00:01:19,409 the first instruction the CPU executes 33 00:01:19,410 --> 00:01:21,749 when it starts up, it's possible 34 00:01:21,750 --> 00:01:24,449 to circumvent any other 35 00:01:24,450 --> 00:01:26,789 software mechanism that attempts 36 00:01:26,790 --> 00:01:29,250 to ensure security. 37 00:01:31,140 --> 00:01:33,299 So one other really important 38 00:01:33,300 --> 00:01:34,709 part about this talk is thunderstruck, 39 00:01:34,710 --> 00:01:37,169 too, is not a new vulnerability. 40 00:01:37,170 --> 00:01:39,809 It's actually built on five previously 41 00:01:39,810 --> 00:01:42,309 disclosed multi-year old 42 00:01:42,310 --> 00:01:45,299 yafai firmware vulnerabilities. 43 00:01:45,300 --> 00:01:47,699 That along with 44 00:01:47,700 --> 00:01:50,009 collaborator's Corey Kaldenberg 45 00:01:50,010 --> 00:01:52,169 and you know, Kova, we are able 46 00:01:52,170 --> 00:01:54,779 to report from commodity PCs 47 00:01:54,780 --> 00:01:56,789 to Mac systems. 48 00:01:56,790 --> 00:01:58,919 And that is the 49 00:01:58,920 --> 00:02:01,049 real key point of this talk, is that 50 00:02:01,050 --> 00:02:03,419 you I firmware vulnerabilities are 51 00:02:03,420 --> 00:02:05,669 shared between these different 52 00:02:05,670 --> 00:02:07,709 systems because they share so much in 53 00:02:07,710 --> 00:02:08,710 common. 54 00:02:09,990 --> 00:02:12,059 You might think that your shiny 55 00:02:12,060 --> 00:02:14,669 MacBook has nothing in common 56 00:02:14,670 --> 00:02:17,039 with some run of the mill commodity 57 00:02:17,040 --> 00:02:18,989 desktop PC. 58 00:02:18,990 --> 00:02:20,819 It has a different motherboard, it has 59 00:02:20,820 --> 00:02:22,800 different OS, it runs 60 00:02:24,180 --> 00:02:26,669 pretty much everything is different, but 61 00:02:26,670 --> 00:02:28,769 under the covers they look very, 62 00:02:28,770 --> 00:02:31,169 very similar that when you disassemble 63 00:02:31,170 --> 00:02:33,239 it, we see the same 64 00:02:33,240 --> 00:02:35,459 sort of code paths, we see the 65 00:02:35,460 --> 00:02:37,259 same functions being called. 66 00:02:37,260 --> 00:02:39,239 We seen the same vulnerabilities 67 00:02:39,240 --> 00:02:40,979 appearing, even though they're built with 68 00:02:40,980 --> 00:02:42,329 different compilers, different 69 00:02:42,330 --> 00:02:44,579 optimization and frequently very 70 00:02:44,580 --> 00:02:46,259 different versions. 71 00:02:46,260 --> 00:02:48,870 There's still a lot of commonality. 72 00:02:50,370 --> 00:02:52,529 And the commonality goes back 73 00:02:52,530 --> 00:02:55,439 to the earliest days of the PC. 74 00:02:55,440 --> 00:02:57,659 IBM's 16 that real 75 00:02:57,660 --> 00:02:59,789 showed bias in the early 80s, 76 00:02:59,790 --> 00:03:02,369 was cloned by Phenix and then everyone 77 00:03:02,370 --> 00:03:04,529 else reverse engineered and cloned 78 00:03:04,530 --> 00:03:05,939 that one. 79 00:03:05,940 --> 00:03:08,429 In 95, Intel started 80 00:03:08,430 --> 00:03:10,499 the Extensible Firmware Interface 81 00:03:10,500 --> 00:03:13,319 Project to try to support new CPU's, 82 00:03:13,320 --> 00:03:15,509 bigger memory, fancier hard 83 00:03:15,510 --> 00:03:16,709 drives and things. 84 00:03:16,710 --> 00:03:17,710 And 85 00:03:19,050 --> 00:03:21,179 in the early 2000s, when Apple 86 00:03:21,180 --> 00:03:23,249 switched over to the the 87 00:03:23,250 --> 00:03:25,769 Intel CPU's, they 88 00:03:25,770 --> 00:03:28,379 forked Intel's F5 standard 89 00:03:28,380 --> 00:03:30,270 and used that for their systems. 90 00:03:31,350 --> 00:03:33,539 A few years later, Intel 91 00:03:33,540 --> 00:03:35,909 transferred all ownership of EFI 92 00:03:35,910 --> 00:03:38,009 to the Unified EFI forum, and that's why 93 00:03:38,010 --> 00:03:40,169 it's called GFI now. 94 00:03:40,170 --> 00:03:43,319 And the forum has continued development, 95 00:03:43,320 --> 00:03:45,149 adding a lot of features, secure boot and 96 00:03:45,150 --> 00:03:46,469 other things. 97 00:03:46,470 --> 00:03:48,539 And they continued development 98 00:03:48,540 --> 00:03:49,769 on this. 99 00:03:49,770 --> 00:03:51,869 We can see that on Christmas Day 100 00:03:51,870 --> 00:03:53,489 there were permits being made to their 101 00:03:53,490 --> 00:03:55,589 country and some of these 102 00:03:55,590 --> 00:03:57,329 are security related. 103 00:03:57,330 --> 00:03:58,829 You know, a suspicious, no pointed 104 00:03:58,830 --> 00:04:00,929 reference could be 105 00:04:00,930 --> 00:04:01,979 a security vulnerability. 106 00:04:03,780 --> 00:04:06,059 So even after 107 00:04:06,060 --> 00:04:07,769 10 years or so of divergence, there's 108 00:04:07,770 --> 00:04:09,929 still millions of lines of code 109 00:04:09,930 --> 00:04:12,269 shared between Apple's F.I. 110 00:04:12,270 --> 00:04:14,399 and the more recent 111 00:04:14,400 --> 00:04:15,509 UAF firmware. 112 00:04:16,649 --> 00:04:18,359 What most from our vendors do is very 113 00:04:18,360 --> 00:04:19,859 similar to what Apple has done. 114 00:04:19,860 --> 00:04:22,349 They for the open source tree, 115 00:04:22,350 --> 00:04:24,059 at whatever version it is, they kind of 116 00:04:24,060 --> 00:04:25,739 freeze at that head. 117 00:04:25,740 --> 00:04:27,329 They ported to hardware platforms and 118 00:04:27,330 --> 00:04:28,649 they sell these packaged firmware. 119 00:04:30,300 --> 00:04:32,489 So when Intel fixes 120 00:04:32,490 --> 00:04:34,949 or excuse me, when the EFI 121 00:04:34,950 --> 00:04:37,019 forum fixes bugs in 122 00:04:37,020 --> 00:04:38,209 the UK to try, 123 00:04:39,360 --> 00:04:41,129 that doesn't mean that all the vendors 124 00:04:41,130 --> 00:04:43,289 have actually done a poll and 125 00:04:43,290 --> 00:04:45,239 and and patched. 126 00:04:45,240 --> 00:04:46,949 And even if they have fixed it on their 127 00:04:46,950 --> 00:04:48,479 new motherboards, they haven't 128 00:04:48,480 --> 00:04:51,059 necessarily fixed it on their decades 129 00:04:51,060 --> 00:04:53,219 of legacy systems. 130 00:04:53,220 --> 00:04:55,469 And even if they've shipped 131 00:04:55,470 --> 00:04:57,509 to firmware update, there's no guarantee 132 00:04:57,510 --> 00:04:59,549 that users install it. 133 00:04:59,550 --> 00:05:01,559 Most people don't install firmware. 134 00:05:02,580 --> 00:05:04,259 And this is an area where Apple has 135 00:05:04,260 --> 00:05:06,359 actually really excelled, that 136 00:05:06,360 --> 00:05:08,189 they are actively pushing for more 137 00:05:08,190 --> 00:05:10,439 updates for systems going back 138 00:05:10,440 --> 00:05:13,139 almost 10 years when 139 00:05:13,140 --> 00:05:14,759 from where security vulnerabilities are 140 00:05:14,760 --> 00:05:15,760 disclosed to them. 141 00:05:17,400 --> 00:05:20,129 So that's enough of the history lesson. 142 00:05:20,130 --> 00:05:21,449 Let's talk a little more about Thunder 143 00:05:21,450 --> 00:05:22,709 Strike two. 144 00:05:22,710 --> 00:05:25,109 As I mentioned, it's built on five 145 00:05:25,110 --> 00:05:27,389 previously disclosed multi-year 146 00:05:27,390 --> 00:05:29,639 old firmware vulnerabilities. 147 00:05:29,640 --> 00:05:30,640 These have been 148 00:05:32,130 --> 00:05:34,259 all the details have been published 149 00:05:34,260 --> 00:05:37,229 going back to 2014, 2013, 150 00:05:37,230 --> 00:05:39,479 some of them as late as as early 151 00:05:39,480 --> 00:05:40,480 as. 2007, 152 00:05:41,900 --> 00:05:44,959 this first one, the Speed Racer, 153 00:05:44,960 --> 00:05:47,269 was presented last year here at 31 154 00:05:47,270 --> 00:05:50,209 C3 by Corey Kahlenberg, 155 00:05:50,210 --> 00:05:52,909 and it is a hardware race condition 156 00:05:52,910 --> 00:05:55,189 that allows in 157 00:05:55,190 --> 00:05:57,259 a multithreaded in a 158 00:05:57,260 --> 00:05:59,899 multi core CPU, 159 00:05:59,900 --> 00:06:02,389 allows a second car to get right access 160 00:06:02,390 --> 00:06:03,390 to the bias. 161 00:06:04,860 --> 00:06:06,959 And the reason for this 162 00:06:06,960 --> 00:06:09,119 goes back to, again, you 163 00:06:09,120 --> 00:06:10,170 know, legacy hardware, 164 00:06:11,280 --> 00:06:13,559 the Intel Interface 165 00:06:13,560 --> 00:06:15,629 Control Hub, was designed for a 166 00:06:15,630 --> 00:06:17,149 single threaded system. 167 00:06:17,150 --> 00:06:19,409 There is the BIOS, right enable bit 168 00:06:19,410 --> 00:06:22,259 that prevents accidental writes 169 00:06:22,260 --> 00:06:23,759 to the firmware. Unless you're in ring 170 00:06:23,760 --> 00:06:24,899 zero. 171 00:06:24,900 --> 00:06:27,149 There's the bias lock enabled bit that 172 00:06:27,150 --> 00:06:29,339 allows Samim to 173 00:06:29,340 --> 00:06:31,619 arbitrate rights 174 00:06:31,620 --> 00:06:33,689 to arbitrate the bias right. 175 00:06:33,690 --> 00:06:35,759 Enable bid when the bit is when the 176 00:06:35,760 --> 00:06:37,679 right enable bid is set to one in 177 00:06:37,680 --> 00:06:39,539 estimate is generated, S.A.M. 178 00:06:39,540 --> 00:06:41,729 gets a chance to decide whether to allow 179 00:06:41,730 --> 00:06:43,919 it and if it doesn't want to allow it, 180 00:06:43,920 --> 00:06:45,929 it sets the bid back to zero. 181 00:06:45,930 --> 00:06:47,459 But that leaves a race condition where 182 00:06:47,460 --> 00:06:48,630 the second thread 183 00:06:49,740 --> 00:06:52,709 has biocide enabled and 184 00:06:52,710 --> 00:06:55,109 turned on for a few cycles. 185 00:06:55,110 --> 00:06:57,179 And he can keep trying and trying 186 00:06:57,180 --> 00:06:58,649 to to write to it 187 00:07:00,270 --> 00:07:01,829 until actually realized this was a 188 00:07:01,830 --> 00:07:04,109 problem in 2004 189 00:07:04,110 --> 00:07:05,579 when they migrated to the platform 190 00:07:05,580 --> 00:07:08,219 controller hub and they added a third 191 00:07:08,220 --> 00:07:09,299 protection bid. 192 00:07:09,300 --> 00:07:11,749 The same bios 193 00:07:11,750 --> 00:07:14,159 protect disable in which 194 00:07:14,160 --> 00:07:16,769 all threads have to be in 195 00:07:16,770 --> 00:07:19,289 the in order to be able to write 196 00:07:19,290 --> 00:07:20,729 to the firmware. 197 00:07:20,730 --> 00:07:22,680 So on a correctly configured system, 198 00:07:23,850 --> 00:07:25,919 the right access 199 00:07:25,920 --> 00:07:27,479 to the firmware is controlled 200 00:07:28,620 --> 00:07:30,689 first by the protected range registers 201 00:07:30,690 --> 00:07:33,209 and then by the seven BWP 202 00:07:33,210 --> 00:07:35,429 bit and then by the BIOS 203 00:07:35,430 --> 00:07:36,430 lock enabled bit. 204 00:07:38,730 --> 00:07:40,829 Corey and his collaborators went 205 00:07:40,830 --> 00:07:43,079 through responsible disclosure and 206 00:07:44,310 --> 00:07:47,699 disclosed all the details to start, and 207 00:07:47,700 --> 00:07:49,889 most of the former 208 00:07:49,890 --> 00:07:51,839 vendors were affected because they had 209 00:07:51,840 --> 00:07:54,269 not updated to 210 00:07:54,270 --> 00:07:55,709 use all of these hardware protection 211 00:07:55,710 --> 00:07:57,299 measures that the that Intel was 212 00:07:57,300 --> 00:07:58,679 providing. 213 00:07:58,680 --> 00:08:00,599 Apple specifically said, however, that 214 00:08:00,600 --> 00:08:01,600 they were not affected. 215 00:08:02,850 --> 00:08:06,089 So we wanted to find out if that 216 00:08:06,090 --> 00:08:07,090 was actually the case. 217 00:08:08,100 --> 00:08:10,289 Going back to the data sheet, we can 218 00:08:10,290 --> 00:08:12,629 read the BIOS control 219 00:08:12,630 --> 00:08:14,729 register, which is 220 00:08:14,730 --> 00:08:17,459 at Offset DC in the 221 00:08:17,460 --> 00:08:18,659 in the hub. 222 00:08:18,660 --> 00:08:21,029 And we can use a tool like Reed Memory, 223 00:08:21,030 --> 00:08:23,219 which is a opensource tool that lets 224 00:08:23,220 --> 00:08:25,559 you read arbitrary 225 00:08:25,560 --> 00:08:27,449 physical memory on those 10. 226 00:08:27,450 --> 00:08:29,519 And what we find is that 227 00:08:29,520 --> 00:08:31,859 it has the value of eight, 228 00:08:31,860 --> 00:08:34,319 and that means that 229 00:08:34,320 --> 00:08:36,699 neither the bios right protect 230 00:08:36,700 --> 00:08:38,969 bit nor the BIOS lock enable 231 00:08:38,970 --> 00:08:39,970 bit or set. 232 00:08:40,980 --> 00:08:43,109 This is, you know, is 233 00:08:43,110 --> 00:08:45,209 not the recommended configuration. 234 00:08:45,210 --> 00:08:47,519 And it turns out that a OS resident 235 00:08:47,520 --> 00:08:49,829 attacker is able to 236 00:08:49,830 --> 00:08:51,959 write a one 237 00:08:51,960 --> 00:08:54,149 to the BIOS. Right. Enable bit and now 238 00:08:54,150 --> 00:08:56,100 they can write to the BIOS. 239 00:08:57,720 --> 00:08:59,249 They can't write to the entire bios 240 00:08:59,250 --> 00:09:01,349 because of the protected range registers, 241 00:09:01,350 --> 00:09:03,839 but it does mean that they can write 242 00:09:03,840 --> 00:09:06,059 and arbitrarily into the invariant 243 00:09:06,060 --> 00:09:07,109 variables. 244 00:09:07,110 --> 00:09:09,299 They can also write to any region 245 00:09:09,300 --> 00:09:11,129 that's not protected by the protected 246 00:09:11,130 --> 00:09:12,329 range registers. 247 00:09:12,330 --> 00:09:14,629 And if you capture 248 00:09:14,630 --> 00:09:16,889 the that portion of the 249 00:09:16,890 --> 00:09:18,659 of the firmware, it actually breaks the 250 00:09:18,660 --> 00:09:21,000 machine so that it is unable to boot. 251 00:09:22,780 --> 00:09:24,819 We went through, again, disclosure with 252 00:09:24,820 --> 00:09:26,979 Apple and they rolled out 253 00:09:26,980 --> 00:09:29,169 a fix and it goes all the way back 254 00:09:29,170 --> 00:09:31,419 to ten, six, eight, which was released 255 00:09:31,420 --> 00:09:33,409 in 2008. 256 00:09:33,410 --> 00:09:36,489 So it's almost eight years of 257 00:09:36,490 --> 00:09:38,649 systems that are that are now protected. 258 00:09:38,650 --> 00:09:40,839 And because Apple does the automatic 259 00:09:40,840 --> 00:09:43,389 rollout, they 260 00:09:43,390 --> 00:09:45,459 these systems for 261 00:09:45,460 --> 00:09:47,229 the most part, have been updated and are 262 00:09:47,230 --> 00:09:48,230 now protected. 263 00:09:50,710 --> 00:09:53,169 One problem is that the fix was it 264 00:09:53,170 --> 00:09:54,999 was just by changing the protected range 265 00:09:55,000 --> 00:09:57,459 register, which means that the 266 00:09:57,460 --> 00:09:59,529 system biosurgery protect is still not 267 00:09:59,530 --> 00:10:01,899 set and the bias 268 00:10:01,900 --> 00:10:03,759 right enabled, it is still vulnerable to 269 00:10:03,760 --> 00:10:05,739 a US resident attacker. 270 00:10:05,740 --> 00:10:07,749 So only the protected range registers are 271 00:10:07,750 --> 00:10:08,750 preventing rights. 272 00:10:09,700 --> 00:10:10,899 Which brings us to our second 273 00:10:10,900 --> 00:10:12,069 vulnerability. 274 00:10:12,070 --> 00:10:14,169 The Darth Phenomics or dark 275 00:10:14,170 --> 00:10:17,049 git Ikoma attack also presented 276 00:10:17,050 --> 00:10:19,629 publicly for the first time last year, 277 00:10:19,630 --> 00:10:20,979 C.C.C. 278 00:10:20,980 --> 00:10:23,649 by Raphel and 279 00:10:23,650 --> 00:10:25,689 some collaborator's. 280 00:10:25,690 --> 00:10:27,639 What they realized is that when the 281 00:10:27,640 --> 00:10:30,179 system goes into a S3 282 00:10:30,180 --> 00:10:31,600 Sasfin to ram sleep, 283 00:10:33,040 --> 00:10:35,169 all of the flash protection bits get 284 00:10:35,170 --> 00:10:36,189 unlocked. 285 00:10:36,190 --> 00:10:38,709 And when the system comes out of sleep, 286 00:10:38,710 --> 00:10:40,989 there's a brief window 287 00:10:40,990 --> 00:10:42,999 that allows an attacker to have write 288 00:10:43,000 --> 00:10:44,470 access to the firmware. 289 00:10:46,150 --> 00:10:48,339 As always, they went through responsible 290 00:10:48,340 --> 00:10:50,589 disclosure and 291 00:10:50,590 --> 00:10:53,019 it turns out that Apple was not contacted 292 00:10:53,020 --> 00:10:55,209 by cert regarding this, but they were 293 00:10:55,210 --> 00:10:56,850 informed through us 294 00:10:59,290 --> 00:11:01,479 to understand how to 295 00:11:01,480 --> 00:11:03,009 take advantage of this vulnerability. 296 00:11:03,010 --> 00:11:05,169 We have to go back to the 297 00:11:05,170 --> 00:11:07,359 the boot script specification, 298 00:11:07,360 --> 00:11:09,579 which describes how 299 00:11:09,580 --> 00:11:12,009 the system, how EFI 300 00:11:12,010 --> 00:11:14,079 goes through a normal boot and then when 301 00:11:14,080 --> 00:11:17,229 it resumes during a normal boot, 302 00:11:17,230 --> 00:11:19,989 the system probes for connected devices, 303 00:11:19,990 --> 00:11:22,029 looks to see what's out there, and it 304 00:11:22,030 --> 00:11:24,129 writes a sort 305 00:11:24,130 --> 00:11:26,199 of a cheat sheet of memory 306 00:11:26,200 --> 00:11:28,809 addresses and configuration 307 00:11:28,810 --> 00:11:30,760 registers into this dispute script. 308 00:11:31,780 --> 00:11:33,759 And then on a resume, it just runs 309 00:11:33,760 --> 00:11:35,439 through the script right into the same 310 00:11:35,440 --> 00:11:36,440 addresses. 311 00:11:37,150 --> 00:11:39,129 Not everything can be expressed in just a 312 00:11:39,130 --> 00:11:40,119 simple right. 313 00:11:40,120 --> 00:11:42,429 So there's a dispatch code that 314 00:11:42,430 --> 00:11:44,079 gives you the ability to put in a 315 00:11:44,080 --> 00:11:45,080 function pointer. 316 00:11:46,790 --> 00:11:49,389 So, again, we can use the 317 00:11:49,390 --> 00:11:51,229 the Reid memory tool to read out the boot 318 00:11:51,230 --> 00:11:53,359 script, which is 319 00:11:53,360 --> 00:11:55,579 actually the pointer to it, is stored in 320 00:11:55,580 --> 00:11:57,549 a environ variable. 321 00:11:58,820 --> 00:12:00,949 And when we pass it, we see 322 00:12:00,950 --> 00:12:02,719 a bunch of those memory rates. 323 00:12:02,720 --> 00:12:04,789 And this right down here is 324 00:12:04,790 --> 00:12:07,219 the one that writes into the protected 325 00:12:07,220 --> 00:12:09,499 range registers and the flock 326 00:12:09,500 --> 00:12:11,689 down bit to to lock them. 327 00:12:11,690 --> 00:12:13,969 But that occurs to late 328 00:12:13,970 --> 00:12:15,199 in the boot script. 329 00:12:15,200 --> 00:12:16,879 We've already had a dispatch 330 00:12:17,930 --> 00:12:19,220 to a function. 331 00:12:20,540 --> 00:12:22,189 And because the Bush script lives in 332 00:12:22,190 --> 00:12:24,889 unprotected memory, we can 333 00:12:24,890 --> 00:12:27,259 use the right meme tool to poke 334 00:12:27,260 --> 00:12:29,929 our own function pointer in there. 335 00:12:29,930 --> 00:12:32,059 And then when the system goes into 336 00:12:32,060 --> 00:12:34,489 sleep, which is a user, 337 00:12:35,900 --> 00:12:38,299 a user command, the system 338 00:12:38,300 --> 00:12:40,429 wakes back up and those protective range 339 00:12:40,430 --> 00:12:42,829 registers are no longer protected, 340 00:12:42,830 --> 00:12:45,169 which allows the resident attacker 341 00:12:45,170 --> 00:12:47,329 to write pretty 342 00:12:47,330 --> 00:12:49,489 much anywhere in the firmware for 343 00:12:49,490 --> 00:12:51,589 for the the CPU, which 344 00:12:51,590 --> 00:12:53,899 again allows it to take control 345 00:12:53,900 --> 00:12:55,039 of the machine from that first 346 00:12:55,040 --> 00:12:58,009 instruction and circumvent 347 00:12:58,010 --> 00:13:00,129 any other chain of trust. 348 00:13:02,110 --> 00:13:04,149 We again went through responsible 349 00:13:04,150 --> 00:13:06,789 disclosure with Apple, and 350 00:13:06,790 --> 00:13:08,889 they, in their note said that 351 00:13:08,890 --> 00:13:11,589 a insufficient lock in the issue existed 352 00:13:11,590 --> 00:13:13,389 and it was addressed through improved 353 00:13:13,390 --> 00:13:16,509 lock in a very 354 00:13:16,510 --> 00:13:18,009 brief comment log there. 355 00:13:21,550 --> 00:13:24,519 There's an additional sleep vulnerability 356 00:13:24,520 --> 00:13:26,889 that we didn't see, but was also fixed 357 00:13:26,890 --> 00:13:29,979 in that patch OS X reverser, 358 00:13:29,980 --> 00:13:32,439 also watched the CCC 359 00:13:32,440 --> 00:13:35,289 talk last year and experimented 360 00:13:35,290 --> 00:13:37,299 on recreating it on his MacBook. 361 00:13:37,300 --> 00:13:39,849 What he found was actually much worse, 362 00:13:39,850 --> 00:13:42,039 that the the S3 363 00:13:42,040 --> 00:13:44,199 implementation left the flash 364 00:13:44,200 --> 00:13:46,339 protection completely unlocked after 365 00:13:46,340 --> 00:13:47,620 a suspended resume cycle. 366 00:13:48,980 --> 00:13:51,929 As you might imagine, that's a bad thing. 367 00:13:51,930 --> 00:13:53,949 And it turns out this is a rediscovery of 368 00:13:53,950 --> 00:13:57,609 a 2013 vulnerability called Snorlax, 369 00:13:57,610 --> 00:13:59,799 in which Dell Systems 370 00:13:59,800 --> 00:14:01,979 failed to properly set Ray 371 00:14:01,980 --> 00:14:04,719 protection after resuming from sleep. 372 00:14:04,720 --> 00:14:06,849 And that was a team ATM that 373 00:14:06,850 --> 00:14:07,850 had found that 374 00:14:09,670 --> 00:14:12,039 the reason that that 375 00:14:12,040 --> 00:14:14,349 we didn't see it in our tests 376 00:14:14,350 --> 00:14:16,449 is that our slightly 377 00:14:16,450 --> 00:14:18,609 newer Mac books had a different Intel 378 00:14:18,610 --> 00:14:19,569 chipset. 379 00:14:19,570 --> 00:14:21,969 And at some point there had been a silent 380 00:14:21,970 --> 00:14:24,399 fix that the 381 00:14:24,400 --> 00:14:26,649 either intel rolled out a 382 00:14:26,650 --> 00:14:28,809 improved reference implementation for 383 00:14:28,810 --> 00:14:30,879 that hardware or Apple fixed 384 00:14:30,880 --> 00:14:33,579 it. But it meant that new machines 385 00:14:33,580 --> 00:14:36,219 were not invulnerable to this this issue. 386 00:14:36,220 --> 00:14:38,889 But older machines were and 387 00:14:38,890 --> 00:14:40,989 no one publicly knew which were 388 00:14:40,990 --> 00:14:41,990 which. 389 00:14:42,850 --> 00:14:44,889 There's a similar silent fix that 390 00:14:44,890 --> 00:14:47,079 happened with the brand new Mac 391 00:14:47,080 --> 00:14:49,029 books, the ones with the USB see 392 00:14:50,470 --> 00:14:52,539 only that it appears to 393 00:14:52,540 --> 00:14:54,759 be using something like Samim 394 00:14:54,760 --> 00:14:55,689 lockbox. 395 00:14:55,690 --> 00:14:58,059 So they're not invulnerable to 396 00:15:00,150 --> 00:15:01,239 the script hijacking. 397 00:15:03,270 --> 00:15:05,759 So, as I mentioned, Apple addressed 398 00:15:05,760 --> 00:15:08,099 the both the 399 00:15:08,100 --> 00:15:10,649 Darth Venomous and the Snorlax 400 00:15:10,650 --> 00:15:12,449 are Prince Charming vulnerabilities 401 00:15:12,450 --> 00:15:14,369 through improved lock in. 402 00:15:14,370 --> 00:15:16,739 What they did is moved the 403 00:15:18,090 --> 00:15:20,879 the code that sets the the lakebeds 404 00:15:20,880 --> 00:15:22,979 and the texture and registers to before 405 00:15:22,980 --> 00:15:24,989 the S3 script is executed. 406 00:15:24,990 --> 00:15:27,359 But the S3 script is still 407 00:15:27,360 --> 00:15:29,849 in unprotected memory and available 408 00:15:29,850 --> 00:15:31,889 for an OS resident attacker to hijack. 409 00:15:33,170 --> 00:15:34,539 They can't use it to 410 00:15:36,110 --> 00:15:38,089 to directly turn off the flash 411 00:15:38,090 --> 00:15:40,199 protection, but there are other 412 00:15:40,200 --> 00:15:42,259 interesting things that this lets you 413 00:15:42,260 --> 00:15:44,599 do prior to the OS Colonel starting 414 00:15:44,600 --> 00:15:46,789 up possibly get into Samim. 415 00:15:46,790 --> 00:15:48,139 I'm still looking into that. 416 00:15:50,060 --> 00:15:51,060 So. 417 00:15:52,590 --> 00:15:54,779 One, you know, with with the easy 418 00:15:54,780 --> 00:15:57,689 routes to getting the flash unlocked, 419 00:15:57,690 --> 00:16:00,089 sort of taken care of, there's 420 00:16:00,090 --> 00:16:02,039 one time when the flash is deliberately 421 00:16:02,040 --> 00:16:03,539 unlocked and that's turning a firmware 422 00:16:03,540 --> 00:16:04,540 update. 423 00:16:05,300 --> 00:16:07,819 So Corey Kahlenberg found 424 00:16:07,820 --> 00:16:10,099 a class of integer overflow 425 00:16:10,100 --> 00:16:12,139 bugs that he was able to write a scanner 426 00:16:12,140 --> 00:16:14,569 for that searched through 427 00:16:14,570 --> 00:16:16,759 lots of different farmers, and he 428 00:16:16,760 --> 00:16:19,669 found a way that 429 00:16:19,670 --> 00:16:21,500 a lot of these vulnerabilities occurred 430 00:16:22,520 --> 00:16:24,859 when the Flash was in a entirely 431 00:16:24,860 --> 00:16:27,049 unlocked state, meaning during 432 00:16:27,050 --> 00:16:28,050 a our update, 433 00:16:29,360 --> 00:16:31,189 one of the machines that he showed this 434 00:16:31,190 --> 00:16:33,799 on was a laptop. 435 00:16:33,800 --> 00:16:36,109 And what's happening 436 00:16:36,110 --> 00:16:38,449 is that the the 437 00:16:38,450 --> 00:16:40,789 length there in the descriptor buffer 438 00:16:40,790 --> 00:16:41,989 is user controlled. 439 00:16:43,160 --> 00:16:45,109 So it's possible to generate an integer 440 00:16:45,110 --> 00:16:47,569 overflow in that length, which then 441 00:16:47,570 --> 00:16:50,029 gives him good execution 442 00:16:50,030 --> 00:16:52,429 while it is passing a firmer update. 443 00:16:52,430 --> 00:16:54,799 So this is this is being run 444 00:16:54,800 --> 00:16:57,169 with the flash unlocked and 445 00:16:57,170 --> 00:16:59,179 gives him full right access. 446 00:17:00,610 --> 00:17:02,709 This affected so many systems that 447 00:17:02,710 --> 00:17:04,989 he won the Tony Award for best privilege 448 00:17:04,990 --> 00:17:07,328 escalation at Black 449 00:17:07,329 --> 00:17:08,379 Hat earlier this year. 450 00:17:11,200 --> 00:17:13,479 As always, responsible disclosure 451 00:17:13,480 --> 00:17:15,669 is really important, and 452 00:17:15,670 --> 00:17:19,209 as you see, almost everyone is affected 453 00:17:19,210 --> 00:17:20,210 except Apple. 454 00:17:21,430 --> 00:17:23,919 Apple claimed 455 00:17:23,920 --> 00:17:26,828 that because they don't use the standard 456 00:17:26,829 --> 00:17:29,319 USSI firmware update routine, 457 00:17:29,320 --> 00:17:31,539 they're not invulnerable to this to this 458 00:17:31,540 --> 00:17:33,639 attack because they have their own 459 00:17:33,640 --> 00:17:34,999 firmware update routine. 460 00:17:35,000 --> 00:17:37,269 If you're interested in that, the Thunder 461 00:17:37,270 --> 00:17:39,219 strike one talk that I gave last year, 462 00:17:39,220 --> 00:17:41,499 C.C.C., goes into extensive 463 00:17:41,500 --> 00:17:43,599 detail about how how Apple does their 464 00:17:43,600 --> 00:17:44,600 firmware updates. 465 00:17:46,920 --> 00:17:49,319 The problem comes that everything 466 00:17:49,320 --> 00:17:51,449 in USA is done 467 00:17:51,450 --> 00:17:54,149 via function pointers and these 128 468 00:17:54,150 --> 00:17:56,369 G.U. IDs, so when 469 00:17:56,370 --> 00:17:58,709 you went to call a function, you 470 00:17:58,710 --> 00:18:00,809 passing this to you ID and it looks it up 471 00:18:00,810 --> 00:18:02,789 on a table and then returns a function 472 00:18:02,790 --> 00:18:04,859 pointer to you, which means that 473 00:18:04,860 --> 00:18:07,559 the linker can't remove 474 00:18:07,560 --> 00:18:09,809 a lot of dead code because 475 00:18:09,810 --> 00:18:11,909 there's a reference to it in this 476 00:18:11,910 --> 00:18:14,009 in this dispatch table. 477 00:18:14,010 --> 00:18:16,170 So the the vulnerable 478 00:18:17,400 --> 00:18:19,989 Fermor capsule update routine 479 00:18:19,990 --> 00:18:22,319 turns out is present in Apple's 480 00:18:22,320 --> 00:18:23,339 ROM. 481 00:18:23,340 --> 00:18:25,379 So even though Apple doesn't use this for 482 00:18:25,380 --> 00:18:27,329 for their firmware updates, the code is 483 00:18:27,330 --> 00:18:28,589 still there. 484 00:18:28,590 --> 00:18:30,809 And through what 485 00:18:30,810 --> 00:18:32,609 what Koreans, you know, called BIOS 486 00:18:32,610 --> 00:18:34,889 necromancy, they were able to generate 487 00:18:34,890 --> 00:18:37,229 a set of inputs that caused that code 488 00:18:37,230 --> 00:18:38,230 to get executed. 489 00:18:39,810 --> 00:18:42,119 So, you know, again, two very 490 00:18:42,120 --> 00:18:44,369 different laptops, but 491 00:18:44,370 --> 00:18:46,529 they share very similar 492 00:18:46,530 --> 00:18:48,659 code in that in that vulnerable 493 00:18:48,660 --> 00:18:50,069 routine. 494 00:18:50,070 --> 00:18:51,419 Obviously, they've been built with 495 00:18:51,420 --> 00:18:52,829 different compilers and different 496 00:18:52,830 --> 00:18:54,059 optimization levels. 497 00:18:54,060 --> 00:18:56,399 But you can see that the 498 00:18:56,400 --> 00:18:58,469 that integer overflow is still 499 00:18:58,470 --> 00:18:59,470 there. 500 00:19:00,700 --> 00:19:02,109 As the result of 501 00:19:03,430 --> 00:19:05,319 our work in proving that and disclosing 502 00:19:05,320 --> 00:19:07,179 it to Apple, they have updated their 503 00:19:07,180 --> 00:19:09,039 status with CERT. 504 00:19:09,040 --> 00:19:11,199 And now a year after it was publicly 505 00:19:11,200 --> 00:19:14,319 announced, they've they've 506 00:19:14,320 --> 00:19:16,389 admitted that they are affected and 507 00:19:16,390 --> 00:19:18,690 they have rolled out a fix. 508 00:19:21,660 --> 00:19:23,069 The particular vulnerability is actually 509 00:19:23,070 --> 00:19:25,199 kind of a very neat 510 00:19:25,200 --> 00:19:27,749 one to to look into that, 511 00:19:27,750 --> 00:19:30,149 you know, unused functions 512 00:19:30,150 --> 00:19:32,519 can contain these vulnerabilities, 513 00:19:32,520 --> 00:19:34,349 legacy functions can contain these 514 00:19:34,350 --> 00:19:35,369 vulnerabilities. 515 00:19:35,370 --> 00:19:38,549 And it becomes really important that when 516 00:19:38,550 --> 00:19:40,379 code is being audited, that both the new 517 00:19:40,380 --> 00:19:42,959 code and this legacy code 518 00:19:42,960 --> 00:19:44,430 gets reviewed and gets updated. 519 00:19:47,460 --> 00:19:49,679 So going back to another legacy 520 00:19:49,680 --> 00:19:50,700 feature, one 521 00:19:51,840 --> 00:19:54,119 that goes back again to the 1980s 522 00:19:54,120 --> 00:19:56,609 with the original IBM PC, 523 00:19:56,610 --> 00:19:58,739 the BIOS at that time 524 00:19:58,740 --> 00:20:01,289 would look on 525 00:20:01,290 --> 00:20:03,479 the motherboard to these expansion from 526 00:20:03,480 --> 00:20:05,789 sockets to see if any optional features 527 00:20:05,790 --> 00:20:07,499 were installed, things like the basic 528 00:20:07,500 --> 00:20:09,779 interpretor, a hard drive controller. 529 00:20:09,780 --> 00:20:11,939 It would also look on the expansion 530 00:20:11,940 --> 00:20:14,249 bus to see if any cards were installed, 531 00:20:15,510 --> 00:20:17,940 like a video card so that it's able to 532 00:20:19,530 --> 00:20:21,659 display the boot messages as well 533 00:20:21,660 --> 00:20:23,999 as the BIOS starts up, 534 00:20:24,000 --> 00:20:26,099 unfortunately. This code is run 535 00:20:26,100 --> 00:20:28,499 in the BIOS and ring zero before 536 00:20:28,500 --> 00:20:30,629 the kernel, and that's really 537 00:20:30,630 --> 00:20:31,969 a bad idea for security. 538 00:20:33,180 --> 00:20:35,549 John Heasman in 2007 539 00:20:35,550 --> 00:20:37,589 showed how this could be used to get 540 00:20:37,590 --> 00:20:38,820 persistance on 541 00:20:40,530 --> 00:20:43,499 on servers with certain network cards. 542 00:20:43,500 --> 00:20:45,779 Snare in 2012 543 00:20:45,780 --> 00:20:47,939 showed how Thunderbolt 544 00:20:47,940 --> 00:20:50,009 is actually Skyy and 545 00:20:50,010 --> 00:20:50,949 it Lud's option. 546 00:20:50,950 --> 00:20:52,200 Rom's off PCI. 547 00:20:53,430 --> 00:20:55,769 My talk at last year at C.C.C. 548 00:20:55,770 --> 00:20:58,019 showed how you could use an option 549 00:20:58,020 --> 00:20:59,160 rom to 550 00:21:00,330 --> 00:21:02,579 during a firmer update to get 551 00:21:02,580 --> 00:21:04,500 code execution with the unlocked 552 00:21:05,580 --> 00:21:06,629 ROM. 553 00:21:06,630 --> 00:21:08,789 And then earlier this year, as 554 00:21:08,790 --> 00:21:11,009 you know, and I presented a class 555 00:21:11,010 --> 00:21:13,469 of vulnerabilities at DEFCON 556 00:21:13,470 --> 00:21:15,569 related to 557 00:21:15,570 --> 00:21:17,699 all of these five that have been fixed. 558 00:21:20,580 --> 00:21:23,759 Following the disclosure at C.C.C., 559 00:21:23,760 --> 00:21:25,739 Apple rolled out a fix that 560 00:21:26,760 --> 00:21:28,709 partially addressed the Thunder strike. 561 00:21:28,710 --> 00:21:29,669 One issue. 562 00:21:29,670 --> 00:21:31,859 What they changed is that the 563 00:21:31,860 --> 00:21:34,229 system no longer Lud's option ROMs during 564 00:21:34,230 --> 00:21:36,509 firmware updates, which 565 00:21:36,510 --> 00:21:38,639 prevents thunder strike from getting good 566 00:21:38,640 --> 00:21:41,609 execution during 567 00:21:41,610 --> 00:21:42,629 during firmware update. 568 00:21:42,630 --> 00:21:43,799 But it still gives you a way to get 569 00:21:43,800 --> 00:21:45,479 persistance in code running on the 570 00:21:45,480 --> 00:21:46,480 system. 571 00:21:47,040 --> 00:21:49,019 There was a follow on update a little bit 572 00:21:49,020 --> 00:21:50,020 later due to 573 00:21:51,120 --> 00:21:53,250 a rollback vulnerability. 574 00:21:54,780 --> 00:21:56,909 And even with this patch applied, 575 00:21:56,910 --> 00:21:58,739 as I mentioned, you get code execution 576 00:21:58,740 --> 00:21:59,639 during the boot. 577 00:21:59,640 --> 00:22:01,349 So if you have a Thunderbolt adapter, 578 00:22:01,350 --> 00:22:03,779 these Thunderbolt Ethernet adapters 579 00:22:03,780 --> 00:22:05,879 are super popular for this 580 00:22:05,880 --> 00:22:06,880 sort of research. 581 00:22:07,890 --> 00:22:10,199 It runs before the kernel 582 00:22:10,200 --> 00:22:12,419 starts and it's able to log keystrokes 583 00:22:12,420 --> 00:22:14,879 such as the firmware and firewall 584 00:22:14,880 --> 00:22:15,880 password there. 585 00:22:18,000 --> 00:22:19,199 It also gives you a way to get 586 00:22:19,200 --> 00:22:20,249 persistance. 587 00:22:20,250 --> 00:22:23,309 So if you get a remote shell on a system, 588 00:22:23,310 --> 00:22:25,529 you can map all of 589 00:22:25,530 --> 00:22:27,719 physical memory, look for PCI 590 00:22:27,720 --> 00:22:29,909 devices, write your 591 00:22:29,910 --> 00:22:32,399 code into the option ROM on it, 592 00:22:32,400 --> 00:22:34,409 and the next time the system Boutte's 593 00:22:34,410 --> 00:22:36,389 that code is going to run. 594 00:22:36,390 --> 00:22:38,639 This is almost as good persistance as 595 00:22:38,640 --> 00:22:39,690 the API flash. 596 00:22:40,830 --> 00:22:43,049 It doesn't necessarily give you 597 00:22:45,090 --> 00:22:46,829 the ability to circumvent all of the rate 598 00:22:46,830 --> 00:22:48,929 of trust because option rooms are 599 00:22:48,930 --> 00:22:51,779 loaded much later in the boot process. 600 00:22:51,780 --> 00:22:53,879 But it still is a very dangerous 601 00:22:53,880 --> 00:22:55,650 thing to to let happen. 602 00:22:57,240 --> 00:22:59,929 Earlier today, Yohana 603 00:22:59,930 --> 00:23:02,159 Itasca presented something 604 00:23:02,160 --> 00:23:04,199 showing how much writable state there is 605 00:23:04,200 --> 00:23:06,449 in the system, and it's really 606 00:23:06,450 --> 00:23:08,579 scary how many things have 607 00:23:08,580 --> 00:23:10,200 writable firmware blob's, 608 00:23:11,550 --> 00:23:13,829 you know, your fancy Thunderbolt monitor 609 00:23:13,830 --> 00:23:14,969 has an option. 610 00:23:14,970 --> 00:23:17,189 It your 611 00:23:17,190 --> 00:23:19,409 SSD might have an option 612 00:23:19,410 --> 00:23:20,410 Ramonet. 613 00:23:21,960 --> 00:23:24,149 So Intel realized this 614 00:23:24,150 --> 00:23:26,579 was a huge problem and 615 00:23:26,580 --> 00:23:28,769 for the secure boot process, they 616 00:23:28,770 --> 00:23:29,789 required that option. 617 00:23:29,790 --> 00:23:30,839 Rom's be signed. 618 00:23:32,480 --> 00:23:34,909 Unfortunately, Apple has not updated 619 00:23:34,910 --> 00:23:36,979 to a version of you, EFI, that 620 00:23:36,980 --> 00:23:39,079 supports secure boot, so 621 00:23:39,080 --> 00:23:42,409 this is not an option on Apple Systems. 622 00:23:42,410 --> 00:23:44,509 It's also not an option 623 00:23:44,510 --> 00:23:46,969 if your system doesn't support Scherba. 624 00:23:46,970 --> 00:23:48,799 And if someone gets the ability to write 625 00:23:48,800 --> 00:23:50,509 to the firmware, flash on the 626 00:23:50,510 --> 00:23:52,489 motherboard, secure boot won't do 627 00:23:52,490 --> 00:23:53,490 anything for you. 628 00:23:54,700 --> 00:23:56,829 So but the key point 629 00:23:56,830 --> 00:23:59,559 is these are all cross platform 630 00:23:59,560 --> 00:24:01,599 vulnerabilities that were found on 631 00:24:01,600 --> 00:24:03,819 commodity pieces and we were able to port 632 00:24:03,820 --> 00:24:05,889 over to 633 00:24:05,890 --> 00:24:07,989 the to the 634 00:24:07,990 --> 00:24:08,990 Mac platform. 635 00:24:09,760 --> 00:24:12,249 You know, most of them are patched 636 00:24:12,250 --> 00:24:13,250 at this point by Apple. 637 00:24:15,250 --> 00:24:17,859 I've heard that the new IMAX 638 00:24:17,860 --> 00:24:19,989 and some of the newer systems 639 00:24:19,990 --> 00:24:21,129 are no longer an option. 640 00:24:21,130 --> 00:24:24,099 Romes, which I think is great and 641 00:24:24,100 --> 00:24:26,379 upsy C doesn't have option ROMs 642 00:24:26,380 --> 00:24:28,149 yet, but maybe Thunderbolt three will 643 00:24:28,150 --> 00:24:29,949 bring option rooms to USB. 644 00:24:29,950 --> 00:24:30,950 We'll see. 645 00:24:31,940 --> 00:24:34,399 So, you 646 00:24:34,400 --> 00:24:35,480 know, all these vulnerabilities are 647 00:24:36,710 --> 00:24:37,849 there interesting. I'm glad we've got 648 00:24:37,850 --> 00:24:39,889 them fixed, but it was really fun to 649 00:24:39,890 --> 00:24:42,169 package them together into a proof 650 00:24:42,170 --> 00:24:43,489 of concept demo. 651 00:24:43,490 --> 00:24:45,769 So let's let's see, 652 00:24:45,770 --> 00:24:47,829 how could this all come together? 653 00:24:49,520 --> 00:24:51,919 So unlike last year, it 654 00:24:51,920 --> 00:24:53,240 actually can start with a 655 00:24:54,530 --> 00:24:57,159 just a like a software exploit, maybe 656 00:24:57,160 --> 00:24:59,419 software download or a 657 00:24:59,420 --> 00:25:00,420 Adobe Flash 658 00:25:01,730 --> 00:25:03,889 sandbox escape or something that 659 00:25:03,890 --> 00:25:06,079 then can escalate to root with whatever 660 00:25:06,080 --> 00:25:08,299 the root exploit of the day is. 661 00:25:09,690 --> 00:25:12,269 And once it has root, it can 662 00:25:12,270 --> 00:25:14,429 install a kernel module to let it 663 00:25:14,430 --> 00:25:16,649 go, walk through physical memory. 664 00:25:16,650 --> 00:25:19,019 If the system is subject to 665 00:25:19,020 --> 00:25:21,209 Prince Charming, it's able to 666 00:25:21,210 --> 00:25:23,069 immediately write malware into the 667 00:25:23,070 --> 00:25:25,139 motherboard. But flash it 668 00:25:25,140 --> 00:25:27,929 can also then search the PCI 669 00:25:29,820 --> 00:25:31,889 space for devices with option rooms 670 00:25:31,890 --> 00:25:34,049 and write itself into them. 671 00:25:34,050 --> 00:25:36,269 And in this case, the you know, it 672 00:25:36,270 --> 00:25:38,649 found a Thunderbolt Ethernet adapter. 673 00:25:38,650 --> 00:25:40,049 So go ahead and flag that that one's 674 00:25:40,050 --> 00:25:41,050 infected. 675 00:25:44,530 --> 00:25:46,659 And now the next time the 676 00:25:46,660 --> 00:25:49,419 system reboots, the 677 00:25:49,420 --> 00:25:51,129 Thunder strike to prove the concept is 678 00:25:51,130 --> 00:25:53,129 going to be run from the motherboard by 679 00:25:53,130 --> 00:25:54,130 flash. 680 00:25:54,940 --> 00:25:56,529 It's not trying to be stealthy or 681 00:25:56,530 --> 00:25:58,659 anything like that to displace big splash 682 00:25:58,660 --> 00:25:59,890 screen and logo, 683 00:26:01,870 --> 00:26:04,179 and because this runs before 684 00:26:04,180 --> 00:26:07,089 the Austin Kernel has started, it can 685 00:26:07,090 --> 00:26:08,589 do pretty much arbitrary things. 686 00:26:08,590 --> 00:26:10,689 It can get into some it can hide 687 00:26:10,690 --> 00:26:11,809 in virtualization. 688 00:26:11,810 --> 00:26:13,959 It has near total control 689 00:26:13,960 --> 00:26:16,269 of the system. At this point. 690 00:26:16,270 --> 00:26:18,489 If you reinstall OS 10, 691 00:26:18,490 --> 00:26:19,509 it's still there. 692 00:26:19,510 --> 00:26:20,829 You swap out the hard drive. 693 00:26:20,830 --> 00:26:21,830 It's still there. 694 00:26:23,130 --> 00:26:24,689 Because it's it's literally in the 695 00:26:24,690 --> 00:26:25,690 motherboard. 696 00:26:27,170 --> 00:26:29,299 So, you know, if we put 697 00:26:29,300 --> 00:26:31,429 the infected system aside and 698 00:26:31,430 --> 00:26:33,559 but we unplug that infected adapter 699 00:26:33,560 --> 00:26:34,759 into a clean system, 700 00:26:36,020 --> 00:26:38,329 when this one Boutte's, it 701 00:26:38,330 --> 00:26:41,149 loads the option rom off the 702 00:26:41,150 --> 00:26:42,410 off the Thunderbolt adapter. 703 00:26:43,430 --> 00:26:45,589 This is a newer laptop that is not 704 00:26:45,590 --> 00:26:46,939 subject to Prince Charming. 705 00:26:46,940 --> 00:26:49,219 So it can't directly relate to the Flash, 706 00:26:49,220 --> 00:26:51,649 but it can use Darth Phenomenas 707 00:26:51,650 --> 00:26:54,019 to hook the S3 boot script. 708 00:26:54,020 --> 00:26:56,119 And if you can see, it also 709 00:26:56,120 --> 00:26:58,190 reports my firmware password on their. 710 00:27:00,170 --> 00:27:01,879 And then the system continues to boot 711 00:27:01,880 --> 00:27:02,880 normally. 712 00:27:06,900 --> 00:27:09,209 When the system goes into an S3 sleep, 713 00:27:09,210 --> 00:27:10,739 such as when the lid is closed, 714 00:27:11,760 --> 00:27:14,819 the CPUs are going to shut down and 715 00:27:14,820 --> 00:27:16,619 you don't have to open the machine. 716 00:27:16,620 --> 00:27:18,709 I've just done that to show that the 717 00:27:18,710 --> 00:27:19,829 the fans have turned off. 718 00:27:19,830 --> 00:27:22,049 The CPU's are completely powered down 719 00:27:23,190 --> 00:27:26,099 when the system 720 00:27:26,100 --> 00:27:27,959 wakes back up. 721 00:27:27,960 --> 00:27:30,119 The at the S3 script is 722 00:27:30,120 --> 00:27:32,339 executed prior to 723 00:27:32,340 --> 00:27:34,019 the boot being locked. 724 00:27:34,020 --> 00:27:37,169 So it's able to write itself into 725 00:27:37,170 --> 00:27:38,549 the boot flash on the motherboard. 726 00:27:38,550 --> 00:27:40,409 And again, I just flag it so I know which 727 00:27:40,410 --> 00:27:42,749 ones I've infected for clean 728 00:27:42,750 --> 00:27:43,750 up afterwards. 729 00:27:45,440 --> 00:27:47,569 So from the perspective of the the user 730 00:27:47,570 --> 00:27:49,739 of the system, it took just a couple 731 00:27:49,740 --> 00:27:51,829 of extra seconds for it to come out of 732 00:27:51,830 --> 00:27:52,830 that sleep mode. 733 00:27:54,450 --> 00:27:57,359 But nothing out of the ordinary, 734 00:27:57,360 --> 00:27:59,099 so then the next time this system 735 00:27:59,100 --> 00:28:01,379 reboots, it's going to 736 00:28:01,380 --> 00:28:03,299 also display the tabooed screen 737 00:28:04,830 --> 00:28:07,049 logo. So we've now 738 00:28:07,050 --> 00:28:09,449 possibly, you know, infected 739 00:28:09,450 --> 00:28:11,579 another machine via this sort of viral 740 00:28:11,580 --> 00:28:13,199 transmission. 741 00:28:13,200 --> 00:28:15,419 And what's interesting is this didn't 742 00:28:15,420 --> 00:28:17,049 touch the OS at all. 743 00:28:17,050 --> 00:28:19,259 This was completely at a level 744 00:28:19,260 --> 00:28:21,060 below the operating system. 745 00:28:23,870 --> 00:28:25,339 One of the other things that thunder 746 00:28:25,340 --> 00:28:27,709 strike to prove concept does 747 00:28:27,710 --> 00:28:30,559 is it watches for the PC hop plug event. 748 00:28:30,560 --> 00:28:33,019 So when a when a clean adapters 749 00:28:33,020 --> 00:28:35,149 plugged in, it detects that 750 00:28:35,150 --> 00:28:37,639 and the interrupt handler writes 751 00:28:37,640 --> 00:28:40,729 the option wrong to the device. 752 00:28:40,730 --> 00:28:43,099 So this allows it to potentially spread 753 00:28:43,100 --> 00:28:45,079 and potentially cross AACAP security 754 00:28:45,080 --> 00:28:47,629 measures. And so if you 755 00:28:47,630 --> 00:28:49,999 have a uranium centrifuge 756 00:28:50,000 --> 00:28:51,619 plant that you're trying to get into, 757 00:28:51,620 --> 00:28:53,569 this might be one of those ways to do it. 758 00:28:57,510 --> 00:28:59,579 So the 759 00:28:59,580 --> 00:29:01,439 proof of concept is is showing a really 760 00:29:01,440 --> 00:29:03,539 neat sort of life cycle for this kind of 761 00:29:03,540 --> 00:29:05,729 malware going from software 762 00:29:05,730 --> 00:29:07,859 exploit that's able to escalate 763 00:29:07,860 --> 00:29:10,259 into the flash or the option rom 764 00:29:10,260 --> 00:29:12,659 Hook S3 again, DMM, 765 00:29:12,660 --> 00:29:14,489 and then go and infect other machines in 766 00:29:14,490 --> 00:29:15,779 the booth flash. 767 00:29:15,780 --> 00:29:17,849 And once it's in that sort of boot slash 768 00:29:17,850 --> 00:29:20,189 option rom com space, 769 00:29:20,190 --> 00:29:22,769 it's completely underneath the OS. 770 00:29:22,770 --> 00:29:25,529 So most virus scanners 771 00:29:25,530 --> 00:29:27,689 aren't even looking for it and probably 772 00:29:27,690 --> 00:29:29,489 couldn't even see it because they have 773 00:29:29,490 --> 00:29:31,709 the ability to trap all 774 00:29:31,710 --> 00:29:33,809 of this memory references and hide 775 00:29:33,810 --> 00:29:36,299 from from normal scanning techniques. 776 00:29:38,130 --> 00:29:39,509 Pretty much the only way you could see if 777 00:29:39,510 --> 00:29:42,359 it's in the flash would be to 778 00:29:42,360 --> 00:29:44,549 put a chip clip on the 779 00:29:44,550 --> 00:29:46,679 on the on the 780 00:29:46,680 --> 00:29:48,869 flash there and read it out and 781 00:29:48,870 --> 00:29:50,549 hope that nothing is interfering with 782 00:29:50,550 --> 00:29:51,550 that. 783 00:29:51,990 --> 00:29:53,669 You know, any attempt to do in software 784 00:29:53,670 --> 00:29:56,059 is going to be masked by the by 785 00:29:56,060 --> 00:29:57,359 the proof of concept. 786 00:29:59,670 --> 00:30:01,919 So Johanna presented 787 00:30:01,920 --> 00:30:03,869 a lot of ideas about things we could do 788 00:30:03,870 --> 00:30:06,179 to deal 789 00:30:06,180 --> 00:30:08,969 with the inevitable inevitability 790 00:30:08,970 --> 00:30:12,039 of rootkit and firmware issues, 791 00:30:12,040 --> 00:30:13,979 you know, attempts to try to move it 792 00:30:13,980 --> 00:30:15,539 outside the system. 793 00:30:15,540 --> 00:30:17,759 But there are a lot of smaller 794 00:30:17,760 --> 00:30:19,979 steps we can take as well, 795 00:30:19,980 --> 00:30:21,569 things like checking the signatures on 796 00:30:21,570 --> 00:30:23,369 the option ROMs or not even loading 797 00:30:23,370 --> 00:30:25,589 option ROMs. This is a really big 798 00:30:25,590 --> 00:30:26,590 first step. 799 00:30:28,450 --> 00:30:30,429 Using all of the locks that the platform 800 00:30:30,430 --> 00:30:32,799 provides, you know, is 801 00:30:32,800 --> 00:30:35,229 really key, making sure that the BIOS 802 00:30:35,230 --> 00:30:37,599 is not readable to resident 803 00:30:37,600 --> 00:30:39,729 attackers, making sure that they 804 00:30:39,730 --> 00:30:41,799 can't hook these three boot script 805 00:30:41,800 --> 00:30:43,230 to get into some. 806 00:30:44,320 --> 00:30:46,329 You know, Intel has added features to 807 00:30:46,330 --> 00:30:49,149 Wi-Fi, like the SIM lockbox 808 00:30:49,150 --> 00:30:50,949 that allowed these three boot script to 809 00:30:50,950 --> 00:30:53,019 be protected from attackers. 810 00:30:54,280 --> 00:30:56,199 And there are tools like Chips and 811 00:30:56,200 --> 00:30:58,269 Copernicus that can 812 00:30:58,270 --> 00:31:00,669 help validate these configurations 813 00:31:00,670 --> 00:31:02,680 to make sure that the systems are being 814 00:31:03,880 --> 00:31:06,129 rebooted and run in a 815 00:31:06,130 --> 00:31:07,130 safe manner. 816 00:31:08,790 --> 00:31:10,919 Intel is also continuing some 817 00:31:10,920 --> 00:31:13,169 hardware attempts, some of their newer 818 00:31:13,170 --> 00:31:16,379 CPUs have a feature called Beaugard, 819 00:31:16,380 --> 00:31:18,509 and this adds actual 820 00:31:18,510 --> 00:31:20,819 ROM for the first instructions 821 00:31:20,820 --> 00:31:23,309 the CPU executes, which 822 00:31:23,310 --> 00:31:26,069 is sufficient to do a cryptographic 823 00:31:26,070 --> 00:31:28,319 verification of the boot flash 824 00:31:28,320 --> 00:31:30,200 before executing any code out of it. 825 00:31:31,450 --> 00:31:33,339 This is great for security, but 826 00:31:33,340 --> 00:31:35,559 unfortunately, this locks out 827 00:31:35,560 --> 00:31:38,439 free software developers, so 828 00:31:38,440 --> 00:31:40,149 systems with boot guard are are 829 00:31:40,150 --> 00:31:43,179 fundamentally incompatible with 830 00:31:43,180 --> 00:31:44,199 with core boot. 831 00:31:44,200 --> 00:31:46,269 And there's that's 832 00:31:46,270 --> 00:31:48,789 a really difficult move 833 00:31:48,790 --> 00:31:51,249 for for software freedom, 834 00:31:51,250 --> 00:31:53,319 even if it does provide a good 835 00:31:53,320 --> 00:31:54,369 level of protection. 836 00:31:56,400 --> 00:31:58,799 And my plea to 837 00:31:58,800 --> 00:32:00,240 system vendors is 838 00:32:01,260 --> 00:32:02,759 that when 839 00:32:03,840 --> 00:32:06,569 new vulnerabilities are disclosed, that 840 00:32:06,570 --> 00:32:08,369 you need to really work with researchers 841 00:32:08,370 --> 00:32:09,839 to try to figure out if they're 842 00:32:09,840 --> 00:32:11,219 vulnerable. 843 00:32:11,220 --> 00:32:12,959 I read a lot of proof of concepts and 844 00:32:12,960 --> 00:32:14,579 they're really difficult to get working 845 00:32:14,580 --> 00:32:16,769 on one machine, much less a 846 00:32:16,770 --> 00:32:18,309 range of machines. 847 00:32:18,310 --> 00:32:20,369 So sometimes vendors take a 848 00:32:20,370 --> 00:32:21,689 proof of concept. They run it on their 849 00:32:21,690 --> 00:32:22,599 system. 850 00:32:22,600 --> 00:32:23,759 It doesn't work. And they say, oh, we're 851 00:32:23,760 --> 00:32:26,249 not vulnerable and there's really not 852 00:32:26,250 --> 00:32:27,250 any 853 00:32:28,620 --> 00:32:29,999 risk to them for doing that. 854 00:32:31,530 --> 00:32:33,809 So, you know, it would be great if 855 00:32:33,810 --> 00:32:35,549 Endres were more proactive in working 856 00:32:35,550 --> 00:32:37,859 with researchers on helping to port 857 00:32:37,860 --> 00:32:39,989 these things and find that out, 858 00:32:42,360 --> 00:32:44,849 the legacy code, you know, as Cory found, 859 00:32:44,850 --> 00:32:46,919 there's a lot of code dead code 860 00:32:46,920 --> 00:32:49,229 in EFI that may have 861 00:32:49,230 --> 00:32:50,249 vulnerabilities. 862 00:32:50,250 --> 00:32:52,359 And even if you 863 00:32:52,360 --> 00:32:53,549 do you think that your system's not 864 00:32:53,550 --> 00:32:55,709 running it, it might be possible 865 00:32:55,710 --> 00:32:58,019 with a set of inputs to to 866 00:32:58,020 --> 00:32:59,359 get the code to jump into it. 867 00:33:01,300 --> 00:33:03,579 It's super important to test the full 868 00:33:03,580 --> 00:33:05,799 cross cross product of 869 00:33:05,800 --> 00:33:08,649 old vulnerabilities and systems 870 00:33:08,650 --> 00:33:10,769 that things like Snorlax been 871 00:33:10,770 --> 00:33:12,729 an old vulnerability that reappeared a 872 00:33:12,730 --> 00:33:14,859 few years later is actually really 873 00:33:14,860 --> 00:33:15,769 kind of scary. 874 00:33:15,770 --> 00:33:18,129 Know that there was we learned 875 00:33:18,130 --> 00:33:20,680 about a really serious bug and 876 00:33:22,030 --> 00:33:24,459 systems got fixed and then new systems 877 00:33:24,460 --> 00:33:25,959 got produced that were still vulnerable 878 00:33:25,960 --> 00:33:27,969 to that old to that old bug. 879 00:33:27,970 --> 00:33:28,970 That that's a problem. 880 00:33:30,190 --> 00:33:32,889 Likewise, new vulnerabilities 881 00:33:32,890 --> 00:33:34,749 might a lot of times they don't 882 00:33:34,750 --> 00:33:36,549 necessarily get tested against older 883 00:33:36,550 --> 00:33:39,189 systems. So we don't know 884 00:33:39,190 --> 00:33:41,499 what machines are actually vulnerable 885 00:33:41,500 --> 00:33:43,929 other than the current generation of 886 00:33:43,930 --> 00:33:45,219 machines. 887 00:33:45,220 --> 00:33:47,319 And, you know, please, if 888 00:33:47,320 --> 00:33:49,389 you're in an opportunity to to 889 00:33:49,390 --> 00:33:51,189 fix security vulnerabilities, don't just 890 00:33:51,190 --> 00:33:52,779 do it silently. Make sure that people 891 00:33:52,780 --> 00:33:55,029 know, you know, these are the 892 00:33:55,030 --> 00:33:57,189 keys that are being patched against. 893 00:33:57,190 --> 00:33:59,469 These are the things that that 894 00:33:59,470 --> 00:34:00,519 are being changed. 895 00:34:00,520 --> 00:34:02,949 And what what 896 00:34:02,950 --> 00:34:05,409 systems will actually be secure against 897 00:34:05,410 --> 00:34:07,569 is when we're in the dark with this, it's 898 00:34:07,570 --> 00:34:09,759 really dangerous. We don't know if 899 00:34:09,760 --> 00:34:10,760 we're going to 900 00:34:12,219 --> 00:34:13,959 you know, just because my machines two 901 00:34:13,960 --> 00:34:16,718 years old and you've got a newer machine, 902 00:34:16,719 --> 00:34:18,099 it's dangerous for for 903 00:34:19,429 --> 00:34:21,009 for us to not have that certainty. 904 00:34:23,380 --> 00:34:25,569 So on 905 00:34:25,570 --> 00:34:27,698 that, I'd love to open 906 00:34:27,699 --> 00:34:28,928 up for some questions. 907 00:34:28,929 --> 00:34:30,698 There's a lot more details about the 908 00:34:30,699 --> 00:34:32,709 vulnerabilities on my website. 909 00:34:32,710 --> 00:34:34,779 I'm also happy to take a 910 00:34:34,780 --> 00:34:37,149 GPG emails and 911 00:34:38,530 --> 00:34:40,599 continue the discussion on these 912 00:34:40,600 --> 00:34:41,600 Fermor topics. 913 00:34:57,480 --> 00:34:58,500 I think, you know. 914 00:35:03,470 --> 00:35:04,689 I think the battery's dead. 915 00:35:11,800 --> 00:35:13,689 OK, let's do this without the mic for a 916 00:35:13,690 --> 00:35:16,209 second. Now we're going to take you can 917 00:35:16,210 --> 00:35:17,549 try that one. 918 00:35:17,550 --> 00:35:19,109 Yes, we should be on tape. 919 00:35:20,170 --> 00:35:21,170 Thank you. 920 00:35:22,660 --> 00:35:24,879 Not for you guys, but for the people 921 00:35:24,880 --> 00:35:25,819 out there in the street. 922 00:35:25,820 --> 00:35:27,999 So we're going to do a little question 923 00:35:28,000 --> 00:35:29,000 talk 924 00:35:30,130 --> 00:35:32,349 and we'll do one question from the 925 00:35:32,350 --> 00:35:34,479 room. One question from 926 00:35:34,480 --> 00:35:35,829 the Web. And then again, the question 927 00:35:35,830 --> 00:35:37,389 from the room. So are there any questions 928 00:35:37,390 --> 00:35:38,390 out there? 929 00:35:41,840 --> 00:35:43,850 Yep, Mike, three, please. 930 00:35:45,080 --> 00:35:46,249 Yes. 931 00:35:46,250 --> 00:35:48,349 Have you seen actual spy 932 00:35:48,350 --> 00:35:50,509 flesh iRace Ackermans 933 00:35:50,510 --> 00:35:52,429 going to your flesh chips or how how is 934 00:35:52,430 --> 00:35:54,589 it actually managed on the background 935 00:35:54,590 --> 00:35:56,809 with different spy flesh 936 00:35:56,810 --> 00:35:57,810 chips? 937 00:35:59,370 --> 00:36:02,099 Are you asking does the OS 938 00:36:02,100 --> 00:36:04,949 periodically do traces of some sort? 939 00:36:04,950 --> 00:36:07,179 Well, how because to 940 00:36:07,180 --> 00:36:08,579 try to flash, you also have to erase 941 00:36:08,580 --> 00:36:10,019 Flash first before you can write it, 942 00:36:10,020 --> 00:36:11,279 right? That's right. 943 00:36:11,280 --> 00:36:13,829 So for things like the the invariant 944 00:36:13,830 --> 00:36:15,420 variables and 945 00:36:17,060 --> 00:36:19,499 there's a related question of why does 946 00:36:19,500 --> 00:36:21,599 Apple leave the flash 947 00:36:21,600 --> 00:36:23,759 rideable and they store in 948 00:36:23,760 --> 00:36:26,099 the nonvolatile variables 949 00:36:26,100 --> 00:36:27,989 in in the Flash. 950 00:36:27,990 --> 00:36:29,549 So things like what is your screen 951 00:36:29,550 --> 00:36:31,199 brightness? What it was the last Wi-Fi 952 00:36:31,200 --> 00:36:33,029 network and credentials that you logged 953 00:36:33,030 --> 00:36:35,219 into are stored in 954 00:36:35,220 --> 00:36:38,429 the in the environment and 955 00:36:38,430 --> 00:36:40,499 it's stored in a 956 00:36:40,500 --> 00:36:42,539 in a log, a pin structure. 957 00:36:42,540 --> 00:36:44,639 So you can add items 958 00:36:44,640 --> 00:36:46,829 to it and then they can 959 00:36:46,830 --> 00:36:48,600 set individual bits to mark 960 00:36:50,160 --> 00:36:52,049 to tombstone old values. 961 00:36:52,050 --> 00:36:54,829 And once they fill up a block then they 962 00:36:54,830 --> 00:36:56,969 they will do a full race rewrite cycle. 963 00:36:56,970 --> 00:36:58,830 But typically they just do 964 00:37:00,600 --> 00:37:02,940 append and then tombstone marking. 965 00:37:06,290 --> 00:37:08,509 OK, do we have a question 966 00:37:08,510 --> 00:37:09,530 from the Internet? 967 00:37:11,060 --> 00:37:12,449 Is there anybody out there? 968 00:37:12,450 --> 00:37:14,269 Yeah, yeah, go ahead. 969 00:37:14,270 --> 00:37:17,179 Um, how is Boogaard 970 00:37:17,180 --> 00:37:19,369 related or different to the trusted 971 00:37:19,370 --> 00:37:20,370 platform module? 972 00:37:21,330 --> 00:37:23,369 So the trusted platform module is 973 00:37:23,370 --> 00:37:24,510 unfortunately not. 974 00:37:25,980 --> 00:37:28,469 It assumes that the Flash 975 00:37:28,470 --> 00:37:30,989 is protected, that 976 00:37:30,990 --> 00:37:32,639 the trusted platform module is outside 977 00:37:32,640 --> 00:37:35,309 the CPU, so 978 00:37:35,310 --> 00:37:38,189 and it only signs 979 00:37:38,190 --> 00:37:40,259 or it only generates hashes 980 00:37:40,260 --> 00:37:42,479 based on what the CPU has asked 981 00:37:42,480 --> 00:37:43,480 it to do. 982 00:37:44,070 --> 00:37:46,379 So if you have malware that 983 00:37:46,380 --> 00:37:48,689 has taken over the spy flash, 984 00:37:48,690 --> 00:37:50,070 it is able to 985 00:37:51,780 --> 00:37:54,659 send whatever values it wants to the TPM 986 00:37:54,660 --> 00:37:56,369 that the TPM can't look at memory. 987 00:37:56,370 --> 00:37:57,839 The TPM can't look at the state of the 988 00:37:57,840 --> 00:37:58,739 CPU. 989 00:37:58,740 --> 00:38:00,989 The TPM only hashes what's 990 00:38:00,990 --> 00:38:01,990 given to it. 991 00:38:03,060 --> 00:38:05,999 So Buchard moves the trust inside 992 00:38:06,000 --> 00:38:08,099 the CPU, so it's no longer having to 993 00:38:08,100 --> 00:38:09,719 go to this outside device. 994 00:38:11,430 --> 00:38:13,709 And because boot guard doesn't 995 00:38:13,710 --> 00:38:15,839 even start executing code from 996 00:38:15,840 --> 00:38:18,089 the flash until it verifies it. 997 00:38:18,090 --> 00:38:20,189 This means that a 998 00:38:20,190 --> 00:38:22,199 malicious attempt to modify the flash 999 00:38:22,200 --> 00:38:24,419 will be detected or will 1000 00:38:24,420 --> 00:38:26,669 be detected on the next boot, 1001 00:38:28,470 --> 00:38:30,749 you know for sure. 1002 00:38:30,750 --> 00:38:32,849 I don't remember if they have the sort 1003 00:38:32,850 --> 00:38:35,489 of soft feel versus hard fail in 1004 00:38:35,490 --> 00:38:37,199 the Boukhari implementation. 1005 00:38:38,610 --> 00:38:40,739 But yet the 1006 00:38:40,740 --> 00:38:43,169 TPM unfortunately, was a 1007 00:38:43,170 --> 00:38:44,519 an interesting idea. 1008 00:38:44,520 --> 00:38:46,739 But there's probably a dozen 1009 00:38:46,740 --> 00:38:48,749 or two dozen papers on how to defeat it 1010 00:38:48,750 --> 00:38:50,479 and get around it in different ways. 1011 00:38:52,400 --> 00:38:54,320 OK, then a question from Mike three, 1012 00:38:55,340 --> 00:38:58,309 I am I 1013 00:38:58,310 --> 00:39:00,589 have had my own share, was 1014 00:39:00,590 --> 00:39:02,779 reporting back to Apple and getting 1015 00:39:02,780 --> 00:39:04,879 some feedback and making sure that 1016 00:39:04,880 --> 00:39:06,409 they actually fix it the way that I 1017 00:39:06,410 --> 00:39:07,999 thought it should be fixed. 1018 00:39:08,000 --> 00:39:10,129 But I see that you 1019 00:39:10,130 --> 00:39:12,889 seem to have that in a repetitive 1020 00:39:12,890 --> 00:39:14,989 pattern, that they 1021 00:39:14,990 --> 00:39:17,539 thought they fixed it, they didn't 1022 00:39:17,540 --> 00:39:19,639 consult with you, and they 1023 00:39:19,640 --> 00:39:21,319 released a fix. And then you found out, 1024 00:39:21,320 --> 00:39:22,829 oh, no, it didn't work. 1025 00:39:22,830 --> 00:39:24,350 Is that kind of I mean, 1026 00:39:25,760 --> 00:39:27,859 is I would expect 1027 00:39:27,860 --> 00:39:30,139 that this is such a sensitive area 1028 00:39:30,140 --> 00:39:32,179 where what Apple would really want to 1029 00:39:32,180 --> 00:39:34,549 have a dialog with you that never happen 1030 00:39:34,550 --> 00:39:36,829 or what a miscommunication. 1031 00:39:36,830 --> 00:39:39,019 It's happened on some of the bugs. 1032 00:39:39,020 --> 00:39:40,819 They there has been a good dialog. 1033 00:39:40,820 --> 00:39:43,249 And we've had they have sent mediators 1034 00:39:43,250 --> 00:39:46,219 to test and we've had back and forth 1035 00:39:46,220 --> 00:39:48,469 occasionally things have 1036 00:39:48,470 --> 00:39:50,419 been put out before. 1037 00:39:50,420 --> 00:39:52,339 We've had a chance to do that. 1038 00:39:52,340 --> 00:39:53,340 And sometimes. 1039 00:39:55,770 --> 00:39:57,479 Yes, sometimes the dialog takes takes 1040 00:39:57,480 --> 00:40:00,399 longer than they want to 1041 00:40:00,400 --> 00:40:02,189 wait for the fix, although I do have 1042 00:40:02,190 --> 00:40:04,479 really good hopes, they 1043 00:40:04,480 --> 00:40:06,819 just acquired 1044 00:40:06,820 --> 00:40:08,889 Zino Inquiries, a company like 1045 00:40:08,890 --> 00:40:09,890 Bacau. 1046 00:40:10,440 --> 00:40:12,449 So I'm really hoping that this means that 1047 00:40:12,450 --> 00:40:14,669 Apple's former security is going to go 1048 00:40:14,670 --> 00:40:16,709 even better than than it's been in the 1049 00:40:16,710 --> 00:40:17,929 past few years. 1050 00:40:21,160 --> 00:40:23,019 One more question from the net 1051 00:40:24,850 --> 00:40:27,069 note, do you have a tool to check 1052 00:40:27,070 --> 00:40:29,249 the current state of the the MacBook, 1053 00:40:29,250 --> 00:40:31,030 like if it's vulnerable or not? 1054 00:40:34,590 --> 00:40:36,669 The the difficulty 1055 00:40:36,670 --> 00:40:38,589 with ascertaining if the system is 1056 00:40:38,590 --> 00:40:40,239 currently vulnerable or currently 1057 00:40:40,240 --> 00:40:41,840 infected is that a 1058 00:40:43,880 --> 00:40:45,969 a a sufficiently 1059 00:40:45,970 --> 00:40:48,639 stealthy malware can trap 1060 00:40:48,640 --> 00:40:50,919 all attempts to read the ROM and read 1061 00:40:50,920 --> 00:40:52,029 the state of things. 1062 00:40:52,030 --> 00:40:54,069 So if it's been able to infect the 1063 00:40:54,070 --> 00:40:56,589 system, it's very, very difficult 1064 00:40:56,590 --> 00:40:59,169 to even tell if that's happened. 1065 00:40:59,170 --> 00:41:01,269 Tools like Chip Sech will 1066 00:41:01,270 --> 00:41:03,819 attempt to tell you if the system is 1067 00:41:03,820 --> 00:41:05,349 in a vulnerable state. 1068 00:41:05,350 --> 00:41:07,539 And that's one way to say 1069 00:41:07,540 --> 00:41:09,609 if you with a clean system, you 1070 00:41:09,610 --> 00:41:10,639 can check to see if it's 1071 00:41:12,880 --> 00:41:14,949 whether or not it looks like it's good. 1072 00:41:14,950 --> 00:41:16,449 But if you've had a system that you think 1073 00:41:16,450 --> 00:41:18,609 has been infected, it's 1074 00:41:18,610 --> 00:41:20,079 very difficult to say. 1075 00:41:23,780 --> 00:41:26,009 OK, is there one more 1076 00:41:26,010 --> 00:41:28,019 question from the net, otherwise we're 1077 00:41:28,020 --> 00:41:29,759 going to call this a baby. 1078 00:41:29,760 --> 00:41:31,679 OK, there's one more question from the 1079 00:41:31,680 --> 00:41:32,680 net. 1080 00:41:33,300 --> 00:41:35,519 What platform which 1081 00:41:35,520 --> 00:41:37,699 would you recommend to avoid if 1082 00:41:39,050 --> 00:41:41,459 you if I both systems 1083 00:41:41,460 --> 00:41:43,739 and which are nearly as compatible 1084 00:41:43,740 --> 00:41:46,409 to our normal computers? 1085 00:41:46,410 --> 00:41:48,599 Well, you EFI is making 1086 00:41:48,600 --> 00:41:51,149 its way into the arm world now, so 1087 00:41:51,150 --> 00:41:54,019 I'm not sure if it's possible to avoid 1088 00:41:54,020 --> 00:41:56,399 you efi in its entirety, 1089 00:41:56,400 --> 00:41:58,869 the UBI itself 1090 00:41:58,870 --> 00:42:00,089 that somewhat of a good thing. 1091 00:42:00,090 --> 00:42:02,339 It is extensible. It is nice to have 1092 00:42:02,340 --> 00:42:04,409 a lot of that functionality, but it is 1093 00:42:04,410 --> 00:42:06,269 a huge amount of code and the trusted 1094 00:42:06,270 --> 00:42:07,709 computing base. 1095 00:42:07,710 --> 00:42:09,839 And, you know, as most 1096 00:42:09,840 --> 00:42:11,819 security researchers will tell you, that 1097 00:42:11,820 --> 00:42:13,320 that is problematic. 1098 00:42:14,790 --> 00:42:16,739 But at this point, it looks like all the 1099 00:42:16,740 --> 00:42:19,289 hardware is going to be you F.I. 1100 00:42:19,290 --> 00:42:20,969 in the foreseeable future. 1101 00:42:22,280 --> 00:42:24,149 I do have good hopes for things like 1102 00:42:24,150 --> 00:42:25,150 Bunyan's laptop, 1103 00:42:26,520 --> 00:42:28,049 open source hardware, a laptop with 1104 00:42:28,050 --> 00:42:30,510 entirely open source firmware, 1105 00:42:31,590 --> 00:42:33,539 because that at least means that we're 1106 00:42:33,540 --> 00:42:35,789 not running a bunch of 1107 00:42:35,790 --> 00:42:37,859 proprietary binary blob's 1108 00:42:37,860 --> 00:42:39,599 things like the intel management engine 1109 00:42:39,600 --> 00:42:41,010 are, you know, certainly, 1110 00:42:42,280 --> 00:42:44,489 you know, it's 1111 00:42:44,490 --> 00:42:46,109 we just don't know anything about what's 1112 00:42:46,110 --> 00:42:48,329 going on inside of it and what it might 1113 00:42:48,330 --> 00:42:49,289 be doing. 1114 00:42:49,290 --> 00:42:51,359 So even if you 1115 00:42:51,360 --> 00:42:53,429 have secure firmware, you've got 1116 00:42:53,430 --> 00:42:55,109 a binary blob running that might be doing 1117 00:42:55,110 --> 00:42:56,549 something that you don't want. 1118 00:42:56,550 --> 00:42:58,769 And that's a somewhat 1119 00:42:58,770 --> 00:43:00,329 of a difficult situation to be in. 1120 00:43:03,500 --> 00:43:05,599 OK, let's have a 1121 00:43:05,600 --> 00:43:07,010 final hand for trommel.