#1 楼
默认情况下,只有管理员才能创建符号链接,因为它们是唯一具有在SeCreateSymbolicLinkPrivilege
授予下找到的Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment\
特权的管理员。来自Microsoft TechNet:Windows Vista的安全策略设置新增功能:
符号链接(symlinks)可以暴露并非设计用于处理符号链接的应用程序中的安全漏洞。
评论
@ ripper234也许像这样。
– ordag
2011-12-29 11:53
我想知道人们如何购买“不允许这样做,因为不允许这样做”作为对“为什么不允许这样做?”的回答。当您说SeCreateSymbolicLinkPrivilege规则禁止这样做时,您给出的正是这个愚蠢的答案。这可能是“法治”的心态:当人们听到规则时,他们就会停止思考。
–Val
2013年8月8日19:23
@Val完全同意。 “ SeCreateSymbolicLinkPrivilege”部分说明了如何强制执行该规则,而没有说明为什么该规则首先存在。现在,“安全漏洞”部分确实解释了为什么管理员权限被视为必要的原因,对我而言,这是此答案的唯一相关部分。
– Pedro Rodrigues
2014年12月12日17:21
据我了解,Symlink Racing是一个漏洞,它是Linux以前在内核级别修补的:security.stackexchange.com/a/83977/29865 Windows仍然容易受到攻击吗?这就是为什么只有管理员用户才具有此特权吗?如果是这样,为什么不解决问题而不是引入愚蠢的限制呢?
– Ajedi32
2015年10月30日15:34
甚至“符号链接……也可能暴露出那些并非旨在处理符号链接的应用程序中的安全漏洞”。解释并不能解决问题。例子?这是security.stackexchange.com,这是一个由安全专家组成的问答网站,但是没有人可以提供此问题的具体答案吗?这似乎在说明。
–詹姆士林
16-6-10 7:00
#2 楼
从Windows 10 Insiders内部版本14972开始(Windows 10创建者更新至1703),情况不再完全(请参见下文)。但是,从博客文章下面的评论中,我们对提到的问题表示关注其他答案仍然存在,并且要利用此新行为,您需要:
在计算机上启用开发人员模式
将
SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE
标志传递给CreateSymbolicLink
API 评论
叹。再次,该博客文章仅引用了未指定的“安全要求”作为默认情况下未启用此要求的原因。然后,当人们在评论中对此提出疑问时,作者在回答时再次说“它们引入了非常真实的安全风险”和“存在一些带有符号链接的有据可查的安全问题”,而没有解释这些风险是什么。这是荒唐的。
– Ajedi32
18年5月9日在15:19
#3 楼
我找到了启动Vista的原因。给管理员的原因很简单。这不是不确定的安全问题,它必须升级成千上万的软件才能使用在添加之前实际上并不存在的API调用,以避免在遍历符号链接时造成安全漏洞。Windows是极易受到符号链接竞赛的伤害;有种方法可以避免这种情况,但实际上根本没有应用程序以这种方式使用API。甚至Microsoft也不接受涉及符号链接竞赛的安全错误。我只是想在三个月前举报。
评论
有趣。知道Windows为什么不能像Linux那样在内核级别对此进行修补吗? (github.com/torvalds/linux/commit/…)另外,为什么硬链接不容易受到攻击?
– Ajedi32
19年1月3日,14:22
@ Ajedi32:因为Windows没有直接的root根,并且在路径遍历时查找组成员身份是愚蠢的,并且驱动器的根目录等同于sticky tmp
–约书亚
19年1月3日,14:53
@ Ajedi32另外,在处理沙箱而不是完全不同的用户时,Linux补丁无法完全解决问题。我在著名程序的沙箱的代理程序过程中发现了TOCTOU错误,您可以在其中使用符号链接(或结点或硬链接)来打破代理程序对沙箱可以“创建”的文件的沙箱状态的假设。 ”,这一切都没有破坏Linux保护的条件。这是通过沙盒竞赛从沙盒内部进行的任意写入。我在安装程序/更新程序中发现了类似的问题。
– CBHacking
20-10-22在8:43
#4 楼
Linux具有分隔的文件/用户结构。这意味着“程序A”不能执行“任务B”,除非它与“磁盘空间C”有关。因此,从风险渗透的角度来看,符号链接实际上并不会从逻辑上影响任何东西,因为整个OS都是基于action-> permission的假设。或者换句话说,如果您是一个只有低级权限的黑客,那么建立一个庞大的符号链接对您没有帮助。因此,在Linux或MacOS上,它无济于事。
但是,在Windows上,您没有“程序A”来运行除登录人员以外的程序...因此登录的人可以根据需要执行“任务B”。因此,它绝对可以帮助您渗透到符号链接级别,因为您可以使用病毒有效负载覆盖常见的真实文件,并隐藏已做到的事情。
因此,如果没有
symlink
保护级别,病毒可能会感染您,并以大量符号链接作为其负载运行,例如,将“ explorer.exe
”重定向到假的“ exactly-as-windows-made-it-except-with-a-payload explorer.exe
”。 为什么要这么做?老实说,这是通往王国的钥匙。您可以将计算机可靠地招募到机器人中,从理论上讲它会激活其将来的发展之路。有100万种方法使之优于“感染”,因为大多数人在看到它们后便将其删除,并且这可能是隐藏的。
评论
评论不作进一步讨论;此对话已移至聊天。
–Rory Alsop♦
20-10-24在11:56
#5 楼
硬链接和目录连接仅在一个分区内(不能存在从一个驱动器到另一驱动器甚至是网络位置的硬链接)。另一方面,SymLink也可以从系统上的某个位置链接对网络位置来说似乎“安全”。评论
这是一个问题,因为...?
–詹姆士林
17年11月1日在2:46
目录连接(mklink / J)必须是本地的,但允许它们指向另一个磁盘。您可以mklink / J C:\ mylink D:\ mydir没有问题。
–马丁
20年1月22日在12:54
Unix系统可以很好地解决这个问题。为什么NTFS这么烂?
– Ti Strga
20-10-21在22:49
@TiStrga有点OT,但是什么意思“处理得很好”呢?您无法在任何操作系统上硬链接不同卷上的文件,这与硬链接是什么概念完全相反。在NTFS和* nix文件系统上,卷之间的符号链接都可以正常工作。连接点之间是一个奇怪的遗留物(它们不是完全的目录硬链接,但它们比符号链接更近,并且大多数只是从NTFS在Vista之前的日子中没有真正的符号链接以来的遗留物)。
– CBHacking
20-10-22在8:35
@CBHacking是的,我知道。我指的是所谓的“危险”,即创建与将来可能存在或可能不存在的远程系统上的内容的符号链接。 Windows吓坏了,Unix却做到了,然后躲开了。
– Ti Strga
20-10-23在17:45
评论
确实,为什么呢?可能是默认情况下以MS C#等编程语言启用的引用是否存在漏洞?!更糟糕的是,普通用户AFAIK可以创建硬链接和目录连接,而不能创建符号链接。这个限制似乎真的是任意的。
另请参阅:superuser.com/questions/10727/…
一个好的答案应该给出一个示例,说明如何利用或滥用SeCreateSymbolicLinkPrivilege。有什么风险?如何软化安全性?举一个具体的利用示例。
@ user643011,很可能是某些****在应用程序尝试通过symlink访问数据时根本没有实现权限检查。微软由于某种原因不能聘请有能力的开发人员。