mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/rop-return-oriented-programing/srop
This commit is contained in:
parent
3613ab9fa7
commit
eea10ced97
@ -130,7 +130,7 @@ char* b = gen_stack();
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
## Exploit
|
||||
## 利用
|
||||
|
||||
在**`vdso`**部分,可以在偏移量**`0x7b0`**找到对**`sigreturn`**的调用:
|
||||
|
||||
@ -193,9 +193,9 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret
|
||||
|
||||
> 注意:当二进制文件使用 **BTI** 编译时,每个有效间接分支目标的第一条指令是 `bti c`。链接器放置的 `sigreturn` 跳板已经包含正确的 BTI 着陆垫,因此该 gadget 可以从非特权代码中使用。
|
||||
|
||||
## 使用 ROP 链接 SROP(通过 `mprotect` 进行 pivot)
|
||||
## 通过 `mprotect` 链接 SROP 和 ROP(枢轴)
|
||||
|
||||
`rt_sigreturn` 让我们控制 *所有* 通用寄存器和 `pstate`。在 x86 上的一个常见模式是:1) 使用 SROP 调用 `mprotect`,2) pivot 到一个包含 shell-code 的新可执行栈。相同的想法在 ARM64 上也适用:
|
||||
`rt_sigreturn` 让我们控制 *所有* 通用寄存器和 `pstate`。在 x86 上的一个常见模式是:1) 使用 SROP 调用 `mprotect`,2) 转向一个包含 shell-code 的新可执行栈。相同的想法在 ARM64 上也适用:
|
||||
```python
|
||||
frame = SigreturnFrame()
|
||||
frame.x8 = constants.SYS_mprotect # 226
|
||||
@ -219,7 +219,7 @@ Linux 5.16 引入了对用户空间信号帧的更严格验证(提交 `36f5a6c
|
||||
|
||||
从主流 Android 14 和 Fedora 38 开始,用户空间默认编译时启用 **PAC** (*Pointer Authentication*) 和 **BTI**(`-mbranch-protection=standard`)。 *SROP* 本身不受影响,因为内核直接从构造的帧中覆盖 `PC`,绕过保存在栈上的经过认证的 LR;然而,任何 **后续的 ROP 链** 执行间接分支时必须跳转到启用 BTI 的指令或 PAC 地址。在选择小工具时请记住这一点。
|
||||
|
||||
在 ARMv8.9 中引入的 Shadow-Call-Stacks(并且在 ChromeOS 1.27+ 上已启用)是一种编译器级的缓解措施,并且 *不* 干扰 SROP,因为没有执行返回指令——控制流由内核转移。
|
||||
在 ARMv8.9 中引入的 Shadow-Call-Stacks(并且在 ChromeOS 1.27+ 中已启用)是一种编译器级的缓解措施,并且 *不* 干扰 SROP,因为没有执行返回指令——控制流由内核转移。
|
||||
|
||||
## 参考文献
|
||||
|
||||
|
@ -45,13 +45,13 @@ var secret = "child secret"
|
||||
alert(parent.secret)
|
||||
</script>
|
||||
```
|
||||
如果您通过 HTTP 服务器(如 `python3 -m http.server`)访问之前的 HTML,您会注意到所有脚本都会被执行(因为没有 CSP 阻止它)。**父级将无法访问任何 iframe 内部的 `secret` 变量**,**只有 if2 和 if3(被视为同站)可以访问原始窗口中的 secret**。\
|
||||
如果您通过 HTTP 服务器(如 `python3 -m http.server`)访问之前的 HTML,您会注意到所有脚本都会被执行(因为没有 CSP 阻止它)。**父级将无法访问任何 iframe 内部的 `secret` 变量**,**只有 if2 和 if3(被视为同源)可以访问原始窗口中的 secret**。\
|
||||
请注意 if4 被认为具有 `null` 来源。
|
||||
|
||||
### 带 CSP 的 Iframes <a href="#iframes_with_csp_40" id="iframes_with_csp_40"></a>
|
||||
|
||||
> [!TIP]
|
||||
> 请注意,在以下绕过中,响应的 iframed 页面不包含任何阻止 JS 执行的 CSP 头。
|
||||
> 请注意,在以下绕过中,iframe 页面响应不包含任何阻止 JS 执行的 CSP 头。
|
||||
|
||||
`script-src` 的 `self` 值将不允许使用 `data:` 协议或 `srcdoc` 属性执行 JS 代码。\
|
||||
然而,即使 CSP 的 `none` 值也将允许执行在 `src` 属性中放置 URL(完整或仅路径)的 iframes。\
|
||||
@ -105,7 +105,7 @@ app.run()
|
||||
```
|
||||
#### 新的(2023-2025)CSP 绕过技术与 iframes
|
||||
|
||||
研究社区继续发现创造性的方法来利用 iframes 以击败限制性政策。以下是过去几年发布的最显著的技术:
|
||||
研究社区继续发现创造性的方法来利用 iframes 以击败限制性政策。以下是过去几年发布的最显著技术:
|
||||
|
||||
* **悬挂标记 / 命名 iframe 数据外泄 (PortSwigger 2023)** – 当一个应用程序反射 HTML 但强 CSP 阻止脚本执行时,您仍然可以通过注入一个 *悬挂* `<iframe name>` 属性来泄露敏感令牌。一旦部分标记被解析,运行在不同源的攻击者脚本导航框架到 `about:blank` 并读取 `window.name`,此时包含了直到下一个引号字符的所有内容(例如 CSRF 令牌)。由于没有 JavaScript 在受害者上下文中运行,攻击通常会避开 `script-src 'none'`。一个最小的 PoC 是:
|
||||
|
||||
@ -120,7 +120,7 @@ victim.location = 'about:blank';
|
||||
console.log(victim.name); // → 泄露的值
|
||||
```
|
||||
|
||||
* **通过同源 iframe 窃取 nonce (2024)** – CSP nonce 并未从 DOM 中移除;它们仅在 DevTools 中被隐藏。如果攻击者可以注入一个 *同源* iframe(例如通过上传 HTML 到网站),子框架可以简单地查询 `document.querySelector('[nonce]').nonce` 并创建新的 `<script nonce>` 节点以满足政策,从而在 `strict-dynamic` 的情况下实现完全的 JavaScript 执行。以下小工具将标记注入升级为 XSS:
|
||||
* **通过同源 iframe 窃取 nonce (2024)** – CSP nonce 并未从 DOM 中移除;它们仅在 DevTools 中被隐藏。如果攻击者能够注入一个 *同源* iframe(例如通过上传 HTML 到网站),子框架可以简单地查询 `document.querySelector('[nonce]').nonce` 并创建新的 `<script nonce>` 节点以满足政策,从而在 `strict-dynamic` 的情况下实现完全的 JavaScript 执行。以下小工具将标记注入升级为 XSS:
|
||||
|
||||
```javascript
|
||||
const n = top.document.querySelector('[nonce]').nonce;
|
||||
@ -153,31 +153,31 @@ src='data:text/html,<script defer="true" src="data:text/javascript,document.body
|
||||
```
|
||||
### Iframe sandbox
|
||||
|
||||
iframe中的内容可以通过使用`sandbox`属性受到额外限制。默认情况下,此属性不被应用,这意味着没有限制。
|
||||
iframe 内的内容可以通过使用 `sandbox` 属性受到额外限制。默认情况下,此属性不被应用,这意味着没有限制。
|
||||
|
||||
当使用时,`sandbox`属性施加了几个限制:
|
||||
当使用时,`sandbox` 属性施加了几个限制:
|
||||
|
||||
- 内容被视为来自一个独特的源。
|
||||
- 内容被视为来自唯一来源。
|
||||
- 任何提交表单的尝试都被阻止。
|
||||
- 禁止执行脚本。
|
||||
- 禁用对某些API的访问。
|
||||
- 禁用对某些 API 的访问。
|
||||
- 防止链接与其他浏览上下文交互。
|
||||
- 不允许通过`<embed>`、`<object>`、`<applet>`或类似标签使用插件。
|
||||
- 禁止通过 `<embed>`、`<object>`、`<applet>` 或类似标签使用插件。
|
||||
- 防止内容自身导航到其顶级浏览上下文。
|
||||
- 自动触发的功能,如视频播放或表单控件的自动聚焦,被阻止。
|
||||
|
||||
提示:现代浏览器支持细粒度标志,如`allow-scripts`、`allow-same-origin`、`allow-top-navigation-by-user-activation`、`allow-downloads-without-user-activation`等。将它们组合以仅授予嵌入应用所需的最低能力。
|
||||
提示:现代浏览器支持细粒度标志,如 `allow-scripts`、`allow-same-origin`、`allow-top-navigation-by-user-activation`、`allow-downloads-without-user-activation` 等。将它们组合以仅授予嵌入应用所需的最小能力。
|
||||
|
||||
属性的值可以留空(`sandbox=""`)以应用上述所有限制。或者,可以设置为一个以空格分隔的特定值列表,以使iframe免于某些限制。
|
||||
属性的值可以留空(`sandbox=""`)以应用上述所有限制。或者,可以设置为特定值的空格分隔列表,以使 iframe 免于某些限制。
|
||||
```html
|
||||
<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
|
||||
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
|
||||
```
|
||||
### Credentialless iframes
|
||||
|
||||
正如在 [this article](https://blog.slonser.info/posts/make-self-xss-great-again/) 中所解释的,iframe 中的 `credentialless` 标志用于在不发送凭据的请求的情况下加载页面,同时保持 iframe 中加载页面的同源策略 (SOP)。
|
||||
正如在 [this article](https://blog.slonser.info/posts/make-self-xss-great-again/) 中所解释的,iframe 中的 `credentialless` 标志用于在不发送凭据的请求的情况下加载页面,同时保持加载页面的同源政策 (SOP)。
|
||||
|
||||
自 **Chrome 110 (2023年2月) 起,该功能默认启用**,并且该规范正在以 *anonymous iframe* 的名称在各个浏览器中标准化。MDN 将其描述为:“一种机制,用于在全新的、短暂的存储分区中加载第三方 iframe,以便不与真实来源共享任何 cookies、localStorage 或 IndexedDB”。对攻击者和防御者的影响:
|
||||
自 **Chrome 110(2023年2月)起,该功能默认启用**,并且该规范正在以 *anonymous iframe* 的名称在各个浏览器中标准化。MDN 将其描述为:“一种机制,用于在全新的、短暂的存储分区中加载第三方 iframe,以便不与真实来源共享任何 cookies、localStorage 或 IndexedDB”。对攻击者和防御者的影响:
|
||||
|
||||
* 不同的 credentialless iframes 中的脚本 **仍然共享相同的顶级来源**,并可以通过 DOM 自由交互,使多 iframe 自我 XSS 攻击成为可能(见下面的 PoC)。
|
||||
* 由于网络是 **去凭据化的**,iframe 内的任何请求实际上表现为未认证会话 – CSRF 保护的端点通常会失败,但通过 DOM 泄露的公共页面仍在范围内。
|
||||
@ -209,7 +209,7 @@ document.forms[0].submit();
|
||||
|
||||
- 另一个 iframe 实际上已经登录用户(没有 `credentialless` 标志)。
|
||||
|
||||
然后,从 XSS 中可以访问另一个 iframe,因为它们具有相同的 SOP,并通过执行来窃取 cookie:
|
||||
然后,从 XSS 中可以访问另一个 iframe,因为它们具有相同的 SOP,并通过执行来窃取 cookie,例如:
|
||||
```javascript
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
|
Loading…
x
Reference in New Issue
Block a user