Säkerhetspodcasten avs.76 - In The Zone OS X Heap Exploitation med Tyler Bohan
Lyssna
Innehåll
Spelades in under Sec-T 2016. Intervju med Tyler Bohan angående hans talk In The Zone OS X Heap Exploitation.
Inspelat: 2016-09-08. Längd: 00:05:17.
AI transkribering
AI försöker förstå oss… Ha överseende med galna feltranskriberingar.
1 00:00:00,960 --> 00:00:10,040
Så det här är Säkerhetspodcasten, jag heter Peter och tillsammans med mig har jag en av språkarna från Säkerhetskonferensen, Mr. Taylor.
2 00:00:10,540 --> 00:00:17,120
Ja, jag gav en tal om OSX-heap och OSX-heap-exploitation.
3 00:00:17,760 --> 00:00:22,680
Så vår tal fokuserade främst på att förändra hela heap-invitationen.
4 00:00:22,960 --> 00:00:26,440
Vi har gått till en av de mest in-deptha förändringarna av den här heap-invitationen alls.
5 00:00:26,440 --> 00:00:30,800
Vi gick så långt som Chris Valasek gick med Windows-heap, vilket är väldigt djupt.
6 00:00:31,260 --> 00:00:38,300
Vi försökte förstå allt vi kunde om heap-invitationen, så att vi kunde förändra några buggar som jag hittade i iOS och OSX mer effektivt.
7 00:00:38,480 --> 00:00:42,920
Så vi förändrade hur mycket vi kunde och gav så mycket information till människor som vi kunde om OSX-heap.
8 00:00:43,040 --> 00:00:46,000
Den senaste forskningen som kom ut var 2009 med MacHackers handbok.
9 00:00:46,300 --> 00:00:51,360
Den är extremt utdaterad. Den senaste heap-invitationen är mycket mer sofistikerad, mycket mer framgångsrik.
10 00:00:51,360 --> 00:00:56,420
Vi försökte förändra lite så att folk kunde få en bättre idé av vad OSX är, vad man är uppe med.
11 00:00:56,440 --> 00:00:59,280
Faktum är att OSX är en förmånlig försäkring.
12 00:00:59,800 --> 00:01:04,640
Kanske är den inte så stark som Windows 10, kanske har inte en kontrollförsäkring, kanske är inte så framgångsrik.
13 00:01:04,880 --> 00:01:07,700
Men den är ändå en 2016-komponering, en väldigt framgångsrik komponering.
14 00:01:07,800 --> 00:01:09,560
Så det är väldigt svårt att förändra en heap-invitation.
15 00:01:09,740 --> 00:01:13,940
Vi är inte i dagarna när OSX var superlätt, när heap-invitationen var redan förändrad.
16 00:01:14,360 --> 00:01:19,080
I 2016 var OSX en hård plattform. Det är väldigt svårt att förändra, och det var det jag ville komma till.
17 00:01:19,380 --> 00:01:26,420
Ja, så om vi går väldigt dumt här och tänker på någon som kanske inte är så bra,
18 00:01:26,440 --> 00:01:32,300
eller som inte ens vet om exploater, eller som bäst vet lite om att göra en liten stack-exploat.
19 00:01:32,940 --> 00:01:40,220
Så heap, där du visar memory-allokationer, som du gör i mallock.
20 00:01:41,300 --> 00:01:48,280
Och lite mer, jag menar, allt du pratade om, de olika strukturerna på memory,
21 00:01:48,280 --> 00:01:55,240
och hur du pratade om att det finns bak- och för-punkter, och hur memory måste vara korrekt
22 00:01:55,240 --> 00:01:56,280
efter att du har dömt ditt…
23 00:01:56,440 --> 00:01:56,940
Ja.
24 00:01:57,200 --> 00:01:59,780
...säkert tillbaka till…
25 00:01:59,780 --> 00:02:00,280
Ja.
26 00:02:00,280 --> 00:02:04,880
Så det är en idé om när man exploaterar heap, att man behöver en väldigt, väldigt precis kontroll.
27 00:02:04,880 --> 00:02:08,400
En stack-baserad exploat är mer av en smash and grab.
28 00:02:08,400 --> 00:02:11,660
Du kan föreställa dig att jag går i e-storan och hittar en kambis i e-storan, och jag går och flyttar.
29 00:02:12,500 --> 00:02:15,980
En hepoverflöde är att jag rör en bank. Jag måste sitta här, jag måste veta allt om banken.
30 00:02:15,980 --> 00:02:18,860
Jag måste veta exakt om säkerheten i banken. Jag måste veta allt jag kan.
31 00:02:18,860 --> 00:02:21,420
Så när jag kommer till banken kommer jag inte att få bort av kvinnorna när jag flyttar.
32 00:02:21,420 --> 00:02:25,600
Hepoverflöden är ett sådant framövergående algoritma, och det är så svårt att…
33 00:02:26,440 --> 00:02:28,080
av software
34 00:02:28,080 --> 00:02:30,220
that you need to know so much more about it
35 00:02:30,220 --> 00:02:31,720
than for instance a stack based overflow
36 00:02:31,720 --> 00:02:33,900
so you really need to understand the heap
37 00:02:33,900 --> 00:02:36,220
precisely if you want to be able to exploit
38 00:02:36,220 --> 00:02:38,140
something reliably, especially something
39 00:02:38,140 --> 00:02:39,920
like my exploit which was actually
40 00:02:39,920 --> 00:02:42,180
targeting two separate heaps, I’m actually trying to
41 00:02:42,180 --> 00:02:43,560
hit heap one
42 00:02:43,560 --> 00:02:45,160
and interact with it with heap two
43 00:02:45,160 --> 00:02:48,000
so I’m trying to interact with two separate heaps to get this exploit going
44 00:02:48,000 --> 00:02:49,800
which as you can tell is extreme complexity
45 00:02:49,800 --> 00:02:50,900
it’s very very difficult
46 00:02:50,900 --> 00:02:53,320
yeah so I mean
47 00:02:53,320 --> 00:02:58,140
it seems very complicated
48 00:02:58,140 --> 00:02:59,100
like
49 00:02:59,100 --> 00:03:01,200
it was a month worth of research
50 00:03:01,200 --> 00:03:03,900
before I started this
51 00:03:03,900 --> 00:03:05,520
probably around June
52 00:03:05,520 --> 00:03:08,260
it’s now September so it’s been months and months of research
53 00:03:08,260 --> 00:03:10,060
to do this and that’s why I said when the guy
54 00:03:10,060 --> 00:03:12,220
asked the question, oh you said heap overflows
55 00:03:12,220 --> 00:03:13,820
are obsolete, heap overflows are not obsolete
56 00:03:13,820 --> 00:03:16,060
you can definitely exploit heap overflows, they’re just a lot more difficult
57 00:03:16,060 --> 00:03:18,040
than many other styles of bugs
58 00:03:18,040 --> 00:03:20,020
and that’s what I was trying to say, when I said heap overflows
59 00:03:20,020 --> 00:03:22,140
are obsolete, I obviously didn’t mean that, I meant that they’re just difficult
60 00:03:22,140 --> 00:03:23,300
they’re very very difficult and you have to
61 00:03:23,320 --> 00:03:24,340
have a lot of understanding
62 00:03:24,340 --> 00:03:26,640
and that’s what makes them very hard
63 00:03:27,160 --> 00:03:28,900
bok misses x-y-br푼
64 00:03:28,900 --> 00:03:31,520
you talked a little bit about one thing which
65 00:03:31,760 --> 00:03:34,580
wasn’t maybe obvious to people before, that
66 00:03:35,080 --> 00:03:40,120
the heap were kind of different heaps per core in the macus
67 00:03:40,480 --> 00:03:41,760
and that you really need
68 00:03:42,260 --> 00:03:43,540
one of the problems was
69 00:03:43,800 --> 00:03:47,040
for actually debugging the things but it might also be a problem
70 00:03:47,040 --> 00:03:48,280
for some expoочкуists that
71 00:03:48,520 --> 00:03:51,900
almost every exploit you have if you’re trying if you’re trying to exploit it with a default heap
72 00:03:52,140 --> 00:03:52,500
that core problem is gonna be too hard for you if you try to exploit it with the default heap
73 00:03:52,500 --> 00:03:52,820
That core problem is gonna be too hard for you if you try to exploit it with a default heap
74 00:03:52,820 --> 00:03:56,100
problem is going to be a huge problem. That’s why most exploiters you see nowadays
75 00:03:56,100 --> 00:04:00,800
are going to be strictly with WebKit or strictly on one malloc. You just exploit
76 00:04:00,800 --> 00:04:05,040
default malloc or you just exploit WebKit malloc. What I try to do is
77 00:04:05,040 --> 00:04:08,900
a dual exploit there and the problem is I’m having this core problem with my default
78 00:04:08,900 --> 00:04:12,900
system malloc. I don’t have the core problem with WebKit malloc so obviously WebKit malloc is a little
79 00:04:12,900 --> 00:04:16,840
easier to deal with. So if you can get a bug in WebKit malloc it’s obviously the easier
80 00:04:16,840 --> 00:04:20,600
approach but the core issue almost makes it almost makes it impossible
81 00:04:20,600 --> 00:04:24,900
to hit bugs on the core system malloc because
82 00:04:24,900 --> 00:04:27,880
of that thread migration issue. You have to find a way around that or it’s nearly impossible.
83 00:04:29,060 --> 00:04:33,180
Alright, so if someone would like to know
84 00:04:33,180 --> 00:04:37,320
more about your research and your presentations
85 00:04:37,320 --> 00:04:40,620
and your companies, what are some of the places
86 00:04:40,620 --> 00:04:44,960
your best, most interesting places to learn about
87 00:04:44,960 --> 00:04:49,960
what you and your colleagues are doing? So we have blog.talosintel.com
88 00:04:49,960 --> 00:04:50,580
which is going to be a link to the blog.talosintel.com
89 00:04:50,580 --> 00:04:55,080
I’m going to give you all of the reports and things that I’ve written on github.com
90 00:04:55,080 --> 00:04:58,840
slash blank wall. Common spelling that is where I have all my information
91 00:04:58,840 --> 00:05:03,020
where all this stuff is. That’s where all the slides are. And if you do between those two things
92 00:05:03,020 --> 00:05:06,640
I’ve done extensive write-ups on all of this work I’ve done including the bugs
93 00:05:06,640 --> 00:05:10,820
which was left out of the presentation. So if anybody’s interested that’s where you can find it on my github.
94 00:05:11,880 --> 00:05:12,820
Thank you very much.
95 00:05:13,880 --> 00:05:14,280
Bye!