PHP2Shell explained in 10 minutes (A technical analysis) — Transcript

Full transcript

1. 0:00PHP to shell almost broke the internet.
2. 0:04PHP was vulnerable in such a critical
3. 0:07way that almost every site running an
4. 0:10unpatched version of PHP dating back to
5. 0:135.4 is vulnerable. That version was
6. 0:17released in 2012, [music]
7. 0:1914 years ago. So, what are these
8. 0:22critical bugs all about? Well, in this
9. 0:25video, I'll break them down for you.
10. 0:34If you're running PHP, you need to
11. 0:37patch. If you haven't yet, then stop
12. 0:39watching this video and check out our
13. 0:41blog post with the actions that you need
14. 0:44to take right away. The link is in the
15. 0:47description. But to understand how a PHP
16. 0:50bug could lead to remote code execution
17. 0:53almost anywhere, we first need to look
18. 0:56at how PHP workers manage requests and
19. 1:00memory. A PHP worker usually handles a
20. 1:04ton of HTTP requests. And each one of
21. 1:07those requests gets some memory
22. 1:10allocated to it for storing things like
23. 1:13form fields, uploaded files, variables,
24. 1:16all that kind of stuff. Now, of course,
25. 1:18once a request is fully handled, then
26. 1:20that memory needs to be freed, which
27. 1:23means that it becomes available to be
28. 1:25used by the next request, for example.
29. 1:28And that cleanup mechanism is what PHP
30. 1:30to shell targets. With the first
31. 1:33vulnerability, the exploit makes a
32. 1:35memory allocation fail while PHP is
33. 1:38building a data structure. And to do
34. 1:41that, the exploit drives PHP to its
35. 1:44memory limits. So PHP detects that and
36. 1:47aborts the operation to not exceed its
37. 1:49memory. And that means that the data
38. 1:51structure it was creating never fully
39. 1:54gets created. But afterwards, its
40. 1:56cleanup code still behaves as if that
41. 1:59data structure was fully created. And at
42. 2:02that point a mismatch happens. PHP
43. 2:05starts treating this unfinished memory
44. 2:08as a valid data structure. And that's
45. 2:10kind of the basic primitive of this
46. 2:12vulnerability. Because for this exploit
47. 2:15to work, it needs to make sure that PHP
48. 2:18is out of memory at the perfect moment.
49. 2:21So you cannot just do this by performing
50. 2:23a denial of service attack and
51. 2:25exhausting the memory by sending a ton
52. 2:27of requests. You need to do it at the
53. 2:29perfect moment. And PHP does not make
54. 2:32this simple because it has many limits
55. 2:35that should stop you from causing PHP to
56. 2:38run out of memory within a single
57. 2:40request. There's for example the postmax
58. 2:43size which limits the size of a post
59. 2:46request. So you can't send gigabytes of
60. 2:49data in a single request. Then there's
61. 2:52also the max file uploads which limits
62. 2:56the number of files you can upload in a
63. 2:58single request and combined these should
64. 3:01make it really difficult to exceed that
65. 3:03memory at the perfect timing. But this
66. 3:06exploit found a gap between those two
67. 3:08limits and it is really really
68. 3:11interesting. So one way to do this is
69. 3:13with a request that looks like this. The
70. 3:17server sees this as receiving a file.
71. 3:20Granted, it's quite a special file
72. 3:22because it doesn't have any contents and
73. 3:24its file name is empty. And that's on
74. 3:28purpose because when the file name is
75. 3:30empty, it just so happens not to count
76. 3:33towards the limit of files you can
77. 3:35upload. So using this technique, you can
78. 3:38upload a ton of files way past the usual
79. 3:41limit. But under the hood, PHP still
80. 3:44processes all of these files and stores
81. 3:47their metadata in memory like the name,
82. 3:50the full path, the type, and so on. And
83. 3:52in this case, you'll also notice that
84. 3:54the name contains this weird structure.
85. 3:57Now, these are nested arrays, and they
86. 3:59cause PHP to have to allocate multiple
87. 4:02large objects in memory for each fake
88. 4:05uploaded file. One of these files is
89. 4:08okay. PHP can handle that. But once you
90. 4:11start sending a request with hundreds or
91. 4:14thousands of these fake files, then you
92. 4:16can easily reach PHP's default 128 mgby
93. 4:21memory limit. And this also explains why
94. 4:24the first advice we got to potentially
95. 4:26mitigate these vulnerabilities is to
96. 4:28change the memory limit to minus1 making
97. 4:31it much more difficult to exploit this
98. 4:34vulnerability because as an attacker you
99. 4:36now cannot easily predict how much
100. 4:39memory is left. But of course that
101. 4:41doesn't fix the root cause. It's not a
102. 4:43complete fix. But that's not the only
103. 4:45vulnerability in this story. there is a
104. 4:48second one and the second bug is totally
105. 4:51different from the first one and both
106. 4:53can lead to remote code execution. Now
107. 4:55in the case of the second bug, PHP keeps
108. 4:58some information for the entire lifetime
109. 5:00of a worker in memory and during a
110. 5:03request that's long lived information
111. 5:06can contain pointers to the memory of
112. 5:09that request. And a pointer is simply an
113. 5:12address telling PHP where some data
114. 5:16lives. The exploit then tries to kill or
115. 5:19cause the request to die at the exact
116. 5:21moment where PHP would still free the
117. 5:24request's temporary memory but fail to
118. 5:27clear that pointer to that memory. And
119. 5:30this means that at that point the worker
120. 5:32is effectively poisoned in a way where
121. 5:35it still has an address to memory that
122. 5:38no longer contains valid data. And then
123. 5:41when another request from the attacker
124. 5:43comes into that same worker, the memory
125. 5:45that this address is pointing to can be
126. 5:48filled again with new and in this case
127. 5:50attacker controlled data while PHP still
128. 5:53thinks it contains trusted internal
129. 5:56objects. And at this point the attacker
130. 5:59has a stale pointer in memory that they
131. 6:02may be able to influence but it's
132. 6:04definitely not yet code execution. Now
133. 6:07imagine that this stale pointer contains
134. 6:10the address ox1234.
135. 6:13When the attacker sends their first
136. 6:14request, ox1234
137. 6:16contains valid PHP data. But when that
138. 6:20request ends, PHP frees the memory at
139. 6:23that address, but the stale pointer
140. 6:25survives, and that's the base primitive.
141. 6:28The attacker then sends another request
142. 6:30that makes PHP create many values of
143. 6:33roughly the same size as the data that
144. 6:36was stored at ox1234.
145. 6:39And by carefully crafting requests that
146. 6:41contain data that just so happens to end
147. 6:44up having the same size in memory of the
148. 6:46original data, the attacker can increase
149. 6:49the chances that their data from the new
150. 6:51request will be placed at ox1234.
151. 6:55And this process is called heap
152. 6:58grooming. When PHP then later follows
153. 7:01that pointer, it does not know that the
154. 7:03memory was freed and already reused
155. 7:06again by something else. And I'm going
156. 7:08to try not to further complicate things
157. 7:10here, but I also need to tell you about
158. 7:12another important internal structure,
159. 7:15the ZV val, which is something PHP uses
160. 7:18to represent values. val contains a
161. 7:21value itself and then also the type
162. 7:24information telling PHP whether that
163. 7:26value is an integer, a string, an array,
164. 7:29an object and so on. If the type says
165. 7:31integer, then PHP treats ox1234
166. 7:35as the number 4,660.
167. 7:39But if the type says string or object,
168. 7:42then PHP treats the same ox1234
169. 7:45as a pointer to a memory address and
170. 7:48goes there to find the string object.
171. 7:51Now if the exploit can control both
172. 7:53fields of a zval, then it can give PHP a
173. 7:57memory address and label it as a string.
174. 8:01Now if you ask PHP to read that fake
175. 8:03string, that can expose memory from the
176. 8:06process. And that's useful because
177. 8:08modern operating systems have something
178. 8:10called ASLR,
179. 8:13address space layout randomization. And
180. 8:16that pretty much means that all
181. 8:17processes have their memory layouts
182. 8:20randomized. So an attacker can know
183. 8:23where things in memory are. And that's
184. 8:25knowledge you need to make a working
185. 8:27exploit. But by leaking process memory,
186. 8:30the attackers can reveal where certain
187. 8:32things live in memory and reverse
188. 8:35engineer the entire memory layout for
189. 8:37that process. Of course, this whole
190. 8:39story is still developing and we don't
191. 8:41yet have all of the information. But I
192. 8:44wanted to make this video to show what
193. 8:47minute little details you need to get
194. 8:49right to have an exploit that works and
195. 8:53works reliably. These bugs are
196. 8:55incredibly complex. So many things had
197. 8:58to align for them to work. And what I've
198. 9:00shown here is only just the beginning.
199. 9:03This is also why we're seeing so many
200. 9:05vibecoded exploits being created right
201. 9:07now that don't work or only work in very
202. 9:10contrived lab environments. But it's
203. 9:12very scary because who knows what other
204. 9:15bugs are still hiding in code we've
205. 9:17already tested a 100 times. and maybe
206. 9:20with AI models, we'll now be able to
207. 9:22find all of those bugs. But with that,
208. 9:24we've also reached the end of this
209. 9:26video. If you're still looking for more
210. 9:28information on how to contain all of
211. 9:31this, then check out the links in the
212. 9:33description to our blog post and video
213. 9:35detailing the actions you need to take
214. 9:38right now. If you're looking for an even
215. 9:40more technical breakdown of this bug and
216. 9:42the continuation of how this leads to an
217. 9:44RCE, then definitely check out Khalif's
218. 9:47blog post. They originally identified
219. 9:49the vulnerabilities and did a great deep
220. 9:52dive on it as well. Thanks for watching
221. 9:54and I'll see you in another video.