2008.1.18

Michael Howard刚刚宣布我们已经聘请了Crispin Cowan。Crispin是AppArmor的作者，它为Linux添加了沙盒功能。显然，他将在Windows安全团队工作，太酷了。

2008.2.20

Raymond昨天发邮件让我确认一句旧的Lan Manager口号。

Brian Valentine主持Lan Manager 2.0开发时，为团队成员整了一批T恤，胸前印有

Lan Manager... We're back and we're BAD

至今我还保存有一些这种T恤。如果你的母语不是英语，可能有些困惑，"BAD"是美国俚语，意为"nasty, in a really good way"

Raymond发邮件问我，起因是微软在其他国家的子公司也在整T恤，但他们想整成当地的母语版本，呃，有时结果不尽人意。某人说，瑞典人很难意译"BAD"，最后只好直译，直译版本用英语表示出来是这个味道

Lan Manager...  We are here again and we're not very good

2008.3.7

Steve Lipner创造了一个术语"Giblets"，指从第三方实现中引入的一大段代码。

2008年1月，Michael Howard撰文称Google Android SDK中有一些Giblets存在已知安全漏洞。比如libpng 1.2.7，2004年9月12日Google安全专家Travis Ormandy披露了该库的漏洞，而Apple去年发布的iPhone干了同样的挫事。

2008.4.8

俄亥俄州的安提阿大学的ERP服务跑在一台Solaris上，由于未及时修补前些时候披露的FTP漏洞，被搞了，至少可以回溯至2008年2月13日。此次入侵导致60000多名在校生、往届生及教职员工的社会安全号码、其他个人数据泄露。入侵者在Solaris中安装了一个"IRC Bot"，使之成为僵尸网络的一员。

过去Slashdot的人嘲讽说，只有Windows才存在这些安全漏洞。什么时候这些沙雕才会明白，安全漏洞与补丁是全行业的问题，而不是某个特定OS的问题。上月Pwn2Own比赛中，有人展示了一个Flash漏洞，ZDNet报道下方的评论区绝大多数评论认为该洞只适用于Windows，Ubuntu甚至吹牛说它们赢了。恕我直言，它们没有赢，Shane说他没有搞Ubuntu的唯一原因是，他更熟悉Windows。现实情况是，除了最后得到一台新电脑的安全研究人员，没人"赢得"比赛，任何主机被搞都只是时间问题。忽略这些事实只会让人们相信安全漏洞仅存于某些特定平台上，这反过来使他们容易遭受黑客攻击。大家最好承认整个IT行业都存在安全问题并寻求解决之道。

scz:

2008年对微软仍然是灾难性的，比如MS08-067。看上去LO在此期间还负责和别的门派打嘴仗。不过，我承认，LO说的没错。事实上，上个世纪90年代由于SunOS、Solaris太过成功，它们是第一批被广泛地打成筛子的OS代表，尤其是ONC/Sun RPC漏洞进入黑客视野后。与之相比，Windows被打成筛子是本世纪初的事儿了，这与Windows进入服务器领域较晚也有些关系。tt是当时大陆地区少有的擅长编写SPARC/Solaris Exploit的安全爱好者之一，90年代末，在一台Solaris上tt认识了眼圈。打住，不在LO系列里扯tt、眼圈们的八卦了，以后另扯。

2008.4.16

LO盛赞了Thomas Ptacek发表的一篇Flash漏洞文章，允许跨OS平台、跨浏览器攻击，该文展示了一名意志坚定的攻击者如何化不可能为可能。过去，认为空指针引用不可利用，或者说无法进行有效攻击，但Thomas做到了。Thomas克服了4个技术难点，最终得已控制victim。

2008.5.1

LO在这篇吐槽了Windows的结构化异常处理机制，这是一种技术哲学层面的吐槽，见仁见智。

我对应用程序捕获异常并尝试纠正它们充满困惑。根据我的经验，处理异常并尝试继续是灾难之源。理想情况下，它将一个易于调试的问题变成一个需要数小时调试才能解决的问题。最坏的情况下，异常处理可能会引入安全漏洞或使安全缓解措施失效。

Vista内置了"Restart Manager"，应用程序调用RegisterApplicationRestart后，当进程崩溃或失去响应时，OS会自动重启应用程序。Windows Service编程时有个类似功能的ChangeServiceConfig2，服务崩溃时OS会自动重启服务，在services.msc中可以看到这种配置项。

我同意Eric的评论，在产品中用assert产生崩溃并记录日志没有意义，除非有人真地会看日志并理解日志在说啥，此时另说，否则日志只会消耗硬盘空间。但我无法理解try/catch/continue。Windows 3.1时，这样做可能是对的，但我们经历过2000年初的安全灾难期，抛出异常后可以继续运行的任何想法都应该被永远摒弃。

抛出异常时，进程处于未知状态。试图以这种未知状态继续，毫无意义，而且可能非常危险，你并不知道进程空间到底发生了什么。最佳选择是让OS转储进程，由客户提交给微软，然后由微软工程师来"验尸"。任何其他继续的尝试都不可取。

需要说明的是，此处我说的是OS的SEH、VEH机制，并不涉及C++的try/catch。在C++或C#编程中，当你明确了解异常起因时，可以进行捕获并继续，如果你不了解异常起因，务必不要继续。举些例子，二叉树的类抛出"Tree Corrupt"异常，就别骚包地继续了，打开文件时抛出异常提示"找不到文件"，可以根据上下文继续。对于结构化异常，我认为任何时候都不应该继续。

scz:

LO说的2000年初的安全灾难期，正是Windows安全专家们逐一登场的时代，yuange是当时顶尖者中的一员，他开创性地在Exploit中利用了SEH机制。