知乎、UAC 和 Windows 安全

0TSH60F7J2rVkg8t

2017-04-30 16:29:51 +08:00

@mozutaba 我能理解你这个疑问。但“因为安全证书显示网站不安全而又不能解决，我岂不是很没用”这个结论不是很赞同。全家桶保护的是用户的安全，那么网站故意忽视用户的安全，这个全家桶的责任就是“告知用户风险”，如果用户决定忽略风险继续，那是用户自己的责任，但不能把这个责任改成“那个网站有风险，但我觉得我不能阻挡用户访问，那我就说这是安全的，让用户继续访问好了”这样。因为告知风险的前者是个“安全软件”应尽的义务；后者不是一个“安全软件”应该做的事情。

换个例子来解释下我的观点，假设用户买了一台跑车，这跑车性能好，在出现危险的时候会弹出安全气囊，进入车门开车的时候会语音提示用户绑上安全带。那么这是一辆以“安全为重”，又兼顾了功能性的合格的跑车；而另外一辆，标榜自己是安全的，但安全气囊偷工减料，出事的时候，可能弹出也可能不弹出，上车也不要用户绑安全带，甚至还对零件老化可能产生的风险忽略不计。那么后一辆我们不能说他是以“安全为重”的跑车。他只是一辆跑车，在某些方面来说甚至还是一辆不合格的跑车。那对用户来说，哪辆更好呢？

当然，你的例子里提到，要普及这不是“我的锅”很难，但这并不是把锅揽到自己头上的理由。就证书而言，提示过期的证书错误，禁止访问才是甩锅，因为那锅本来就是对方网站的；而允许访问造成用户浏览到虚假网站——使用中间人攻击的黑客的虚假证书——锅就揽到自身上来了。当然，无耻一点不承认就好了，反正用户没有技术能力能判断出来锅到底是谁的。但这是后话了。

0TSH60F7J2rVkg8t

2017-04-30 16:31:42 +08:00

@mozutaba 这点我赞同，UAC 确实太尴尬了。但是假设一下，如果微软来决定，直接弹出拒绝运行，用户恐怕也会怒砸键盘的。其实确实左右为难，尴尬的不得了。

acess

2017-04-30 16:39:01 +08:00

@ahhui 我说 UAC “做得更多”确实可能产生歧义……我的意思并不是让 Windows 收窄未提权管理员用户的权限，而是说正规的开发者应该好好利用 UAC，在执行敏感操作时提醒用户，而不是像某些软件一样一双击就弹 UAC，不点“是”不给用。
我只是吐槽现在 UAC，正规软件弹，流氓也弹，加在一起，用户能感觉到的就是各种弹，弹个不停……所以很多用户最后只能麻木地点“是”，让 UAC 真的变成没用的东西了……

至于诱导用户关闭杀软之类的，UAC 和杀软都管不了那么宽……

@mozutaba 我觉得很多情况下程序确实不需要弹 UAC 也可以正常安装、运行，但可能是因为抄代码、偷懒等原因，再加上关闭 UAC 实在太容易，所以 UAC 才因为弹得太多而在用户眼中变成了没用的东西。

LZ 认为 UAC 有用的理由：如果恶意代码没有管理员特权，那在补丁打全的情况下，它也很难钻进 ring0、很难提升权限。
这样一来，安全软件依靠自己的高权限就可以轻松秒杀各种恶意代码，只要它能正确检测到恶意代码就可以了。但现在，ring0 的驱动木马、Bootkit 都泛滥了，杀软即使能和它们对抗，也是没完没了的……
至于用户自己的数据和隐私问题，也许可以举这个例子：UAC 虽然管不了一般的键盘记录器，但它可以挡住比较危险的内核级键盘记录器。

mozutaba

2017-04-30 16:40:48 +08:00

@ahhui 提示不安全，却不能解决，这点就会导致用户不相信这个产品，更可能走人了。
那不如默默的装不知道。要是能有用户肯定选我们的底气，debug 给你看都行。

出事的话，哪种解决方法用户都会认为是我们的锅。

UAC 我认为就是甩锅行为，不然就是特殊条件下才起到用处。比如前面提到的，关了软件，却背着给我刷软件的安装量，这时候 UAC 就有用了。

acess

2017-04-30 16:41:31 +08:00

@ahhui 微软的理想状况是用户看到软件乱弹 UAC 就各种吐槽软件开发商，然后开发商受不了就去改进，适应 UAC。
但实际状况是大家一起吐槽微软的 UAC 就是个逗逼机制，纷纷把它完全关掉。

wevsty

2017-04-30 16:43:33 +08:00

@acess
@ahhui
我解释一下 open \\.\PhysicalDrive0 这种行为。
对于 File System Filter Drivers 来说，open \\.\PhysicalDrive0 这样的行为 Filter Drivers 会收到一个 IRP_MJ_CREATE 的请求，如果 Filter Driver 在针对这个请求直接拒绝，那么直接打开设备的操作明显会失败。这里不存在所谓绕过这么一说。只是取决于驱动怎么处理直接访问设备的请求，如果驱动对此没有拒绝，后续的操作因为直接是针对设备块的读写（其实就是直接向磁盘驱动发起了 IRP ）并不涉及文件系统，所以 File System Filter Drivers 无法拦截后续的读写操作，这看起来就像是，绕过了，但是实际上只是驱动不想粗暴的拒绝而已。
如果要拦截底层的磁盘访问的 IRP 请求当然也是有办法的，不过这又是另外一个话题了。

0TSH60F7J2rVkg8t

2017-04-30 16:45:53 +08:00

@acess 我的观点和你一样，只是期待开发商自己好好利用 UAC，在需要的时候才弹，这根本不现实。因为微软没有强制力，而对于开发商来说，他又有用户不得不用的粘合度，仰仗着这些，他完全不屌微软的规范是完全有可能的。所以归根结底还是系统太开放（从另一个角度说，用户也受益于这样的开放，也受害于这样的开放）导致的。

对了，说个你可能没想到的情况。杀毒软件通常有自我保护，也自身运行在很高的系统权限等级之上。但是这不意味着杀毒软件本身是无懈可击的，有很多入侵甚至可以利用杀毒软件本身的漏洞。而恰恰由于杀毒软件本身是要和病毒做对抗的，保护严密，一旦被利用，后果也十分严重。比如我知道的，Avira XP 版本（老版本了，新的不知道）经常有开机弹广告的情况。这个广告是 http 访问的，使用的是 IE 内核。细思一下，可怕不可怕？还有以前老版本的杀毒软件，自动更新都不校验数字签名的，下载的文件直接 load，或者 run 的。是不是更可怕了？

acess

2017-04-30 16:46:30 +08:00

@mozutaba
LZ 觉得，UAC 管不了“刷量”，这压根不是它的职责范围。

按 LZ 的理解，UAC 的职责范围差不多就是“一个标准用户中毒后系统仍然毫发无损，删除中毒账户就可以重新开始”，至于用户自己作死导致数据丢失、被盗等，那不是 UAC 要管的事儿。
但 UAC 可以帮助用户把关系统管理员特权，可能确实能帮助用户阻挡最危险的内核 rootkit 等威胁。

至于刷量问题，如果软件支持 per user install，那安装的时候其实可以不弹 UAC。
如果不是现在的流氓安装起来都需要管理员特权，我觉得刷安装量是可以完全不打搅 UAC 的……
而且，那个灰色软件可以不刷安装量，只刷点击量啊，这样就不会触发 UAC 了吧……

acess

2017-04-30 16:51:28 +08:00

@wevsty
我自认为大概理解你说的……能“绕过”，说明那个 filter driver 考虑不严谨。
好比一个柜子上有好几个抽屉，其中一个抽屉上锁了，但其实只要抽掉上面没上锁的抽屉，就会发现里面是相通的……

那个 minifilter 是一个恶意 rootkit 驱动，它的目的大概也只是躲过 360 等杀软的扫描而已吧……它还触发了 PatchGuard。
可能写这个 rootkit 驱动的家伙不知道从哪里扒来了代码，只是抱着能跑就好的态度草草了事的。

mozutaba

2017-04-30 16:52:07 +08:00

@acess 我以为 UAC 的职责就是告诉你这个非正常运行的软件威胁到了本系统，怎么处理自己看着办，UAC 反正没办法。

0TSH60F7J2rVkg8t

2017-04-30 16:55:31 +08:00

@mozutaba 你这个说法我能理解的，只是我觉得这问题如果要这么看的话，那这个并不是一个合格的安全软件，因为他的首要目标不是安全，而是要让用户觉得自己好用。既然定了这样的目标，那与他谈安全就对牛弹琴了。这样的软件好不好？不懂的用户肯定觉得好，你看，别人都打不开的网站我能打开。那么我们再继续假设下去，这样的软件对用户来说是利大于弊还是弊大于利呢？这就值得讨论了。如果利大于弊，那就是劣币驱逐良币的问题了。因为这样的软件越普及，就越意味着更多的用户不需要安全。整体上看，都是有害的。隐藏的弊迟早要爆发出来的，后果可能很严重的。

acess

2017-04-30 16:55:58 +08:00

@wevsty
其实还是怪我没说明白……
我说被绕过的是文件系统过滤驱动，不是磁盘设备过滤驱动。它可能拦截不到打开磁盘设备的 IRP 吧？

0TSH60F7J2rVkg8t

2017-04-30 16:58:52 +08:00

@acess 哈哈，吐槽这个结果你想的太理想了。事实上可能是，微软吐槽开发商，然后开发商说，这是微软最垃圾的一代系统，兼容性不好，建议大家换系统（比如从 Win10 换到 Win7 ）。小白哪里分得清到底谁说的是真的呢？然而老系统运行的好好的，新系统不让用了，嗯，即使笔记本是正版，我也要换成盗版老系统用这个软件——小白们如是说道。

wevsty

2017-04-30 16:59:08 +08:00

@acess
这完全取决于开发者希望产生什么样的效果，比如我要开发一个文件透明加密的驱动，那么我就没有必要防程序直接读取或者写入磁盘的这种行为，因为不会影响到我的程序功能。
一般安全产品在这方面的处理方法也是简单粗暴的，可能有些 HIPS 会直接弹个窗，警告一下，如果允许了剩下的事情 HIPS 也不管。
这个是开发难度与产品功能之间做出的妥协，安全产品当然也可以直接接管更加底层的 IRP 请求，但是那又会面对一堆乱七八糟的问题，比如稳定性方面的问题。

0TSH60F7J2rVkg8t

2017-04-30 17:00:43 +08:00

@acess 其实我说小白用户换系统喷新系统兼容性不好的例子，还真的发生过。大名鼎鼎的 Vista 系统就是这样的下场。

mozutaba

2017-04-30 17:06:32 +08:00

@ahhui 首先他是一个公司，首要目标就是盈利，就看他们选择是保护 1%用户的 99%安全，还是保护 99%用户的 90%安全。选择后者要想办法甩锅，选择前者要想办法接锅。

0TSH60F7J2rVkg8t

2017-04-30 17:08:47 +08:00

@acess 对了，最近还有个例子很有代表性。苹果的系统算是很封闭吧，他对 AppStore 上的软件控制力够严格吧。不符合要求直接下架。嗯，这种情况下，该说他控制力很强了。可是，苹果要求微信的公众号打赏功能接入 IAP 系统架构里的时候，微信表示了拒绝，不改为 IAP，即使从 iOS 上撤下打赏功能也不改。此举赢得了很多微信网友的称赞和支持。当然，这不是个安全问题，这是另外一个涉及到经济利益的问题。但这个例子也能证明，开发商有底气不鸟你操作系统的！

0TSH60F7J2rVkg8t

2017-04-30 17:09:46 +08:00

@mozutaba 我觉得我俩都无法说服对方了，这个问题就此打住吧。

wevsty

2017-04-30 17:12:42 +08:00

@acess
应该是可以拦截到的
从调用链就可以看出来。
CreateFileW （\\.\PhysicalDrive0 ）—》 ZwCreateFile->NtCreateFile
NtCreateFile 会向驱动层的最上级驱动发起 IRP_MJ_CREATE，然后 IRP_MJ_CREATE 这个 IRP 会依次按照顺序发送到下级驱动中，直到最后发送到磁盘驱动。
File System Filter Drivers 想拦截拦截文件的打开就一定会在这个调用链中，所以 File System Filter Drivers 有能力拒绝这样的行为。
而对于直接向磁盘写入这种行为来说。
WriteFile-》 ZwWriteFile-》 NtWriteFile
NtWriteFile 产生的 IRP_MJ_WRITE 不会交给 File System Filter Drivers，因为要写入的并不是一个文件系统的对象，所以 File System Filter Drivers 并不会接收到这个 IRP_MJ_WRITE。

wevsty

2017-04-30 17:56:51 +08:00

接楼上，做个更正 NtCreateFile 是调用 IoCreateFile，由 IoCreateFile 来发起 IRP 的。这个是我疏忽了。