提纲：
阿丽亚娜火箭的解体
阿波罗飞船的P01模式
德勤的Google+
麻省理工的500英里邮件
又到了扶额兴叹的节气。
作者：旁观者
原文： http://www.cnblogs.com/zhengyun_ustc/p/disaster2.html
0x00 阿丽亚娜火箭的解体
1996年6月4日，阿里亚娜五号火箭首次测试发射。
37秒后，火箭水平翻滚，解体爆炸。
WHY？
Ariane 的开发语言是 Ada，美国军方软件开发强制语言，。
设计 Ariane4 火箭的时候，设计师们坚信水平速率是不会超过一个16-bit signed integer 的。
但 Ariane5 火箭的水平速率比 Ariane4 高出了5倍，code review 时，大家都没有注意到这一点。
16位整型的范围是 -32768 到 32767。
出错的代码是：
horizontal_veloc_bias := integer(horizontal_veloc_sensor);
昀哥查了查事故报告，引发问题的是 BH, Horizontal Bias。
这个值与时间有关，还不是纯水平速度。
因为 Ariane5 的早期轨道与 Ariane4 不同，所以这个 BH 比预想的高了很多。
结果导致数据转换时溢出。
控制惯性导航系统的计算机向控制引擎喷嘴的计算机发送了一个无效数据。
于是火箭偏离它的飞行路径，解体并爆炸。
嗯哼，所以有一个段子说，如果阿丽亚娜火箭的开发语是 JavaScript，就不会发生这个惨案。
推荐下我的web前端学习群：571019044，不管你是小白还是大牛，小编我都挺欢迎，不定期分享干货，包括我自己整理的一份前端资料和零基础入门教程，欢迎初学和进阶中的小伙伴。
0x01 阿波罗飞船的P01模式
话说史上最牛的女程序员玛格丽特·希菲尔德·汉密尔顿（Margaret Heafield Hamilton）在1965年担任 NASA 软件编程部的部长。
软件工程（Software Engineering）这个词就是玛格丽特·汉密尔顿发明的，不过那已经是阿波罗11号飞船期间的事情了。
下面我们要讲的是阿波罗8号飞船的故事。
那个时候她没日没夜地工作，女儿劳伦就在她的实验室玩耍，累了就在地板上睡觉。
这一天，劳伦在指令舱模拟器里按来按去，居然启动了一个叫 P01 的预处理程序。
顿时模拟器就崩溃了。
玛格丽特发现后，就建议加段代码防止此情况出现。
但是大家都觉得航天员不可能这么操作，这个异常处理完全没必要。
主要是因为当年的计算机存储空间和运算能力十分有限，螺蛳壳里做道场，斤斤计较的领导不愿意浪费这个空间。
所以玛格丽特只好加了一个备注：不要在飞行中选择P01模式。
但是，想啥就来啥。
1968年12月26日，人类首次绕月飞行的阿波罗8号飞船上，航天员还是成功地进入了 P01 模式。
这个模式启动的直接结果就是：所有导航数据都会被清空。
航天员再也别想回家了。
玛格丽特带着人奋战了9个小时，终于上传了新的导航数据，一切又回到正常的轨道，阿波罗8号也顺利载着宇航员返航。
这事儿没完，在阿波罗11号飞船即将登陆月球前的几分钟，又一个更大的危机发生了。
欲知详情，请在搜索引擎搜索关键词“ 程序员永恒的女神 ”。
0x02 德勤的Goolge+
昀哥以前在《安全基础教育第一季》里说过，当公司做得越来越大的时候，总会出现那么几个安全意识薄弱的人员（俗称猪一样的队友），他们往往会做出一些让人无法理解的事情，比如：他会毫不犹豫地双击运行邮件内的 EXE 附件，或者使用跟用户名一样的密码，或者用户名+当前年份的密码。
而且每家知名公司都有这么几个没心没肺的人，在开源社区泄露源码或敏感信息，在乌云网里随便一划拉就能找到好多：
盛大某开发人员意识不足泄漏内部邮箱帐号密码（github）
迅雷某开发人员意识不足泄漏内部邮箱帐号密码（github）
一次成功的漫游京东内部网络的过程（由一个开发人员失误导致）（github）
新浪开发人员安全意识不足导致部分源码泄漏（googlecode）
腾讯多组内部邮箱账号密码泄漏（github）
……
为什么要刻意强调这一点？
因为 github 支持强大的搜索语法，可以很方便地搜索到一些常规搜索引擎无法搜索到的内容，如搜索内部项目、密码、密钥等。
你可以通过 github 来查找代码安全问题，如输入规则：extension:php mysql_query $_GET，可以搜索到大量包含 mysql_query $_GET 的请求，可以有针对性地进行代码审计。
当你把自己的项目代码上传到 github 时，看看配置文件里是不是有不能说的秘密，思量一下后果。
这不，一位德勤员工据信在2016年Q4或更早将公司代理登录凭证上传至他的 Google+ 上，从而引发了2016年年底到2017年年初的德勤全球电子邮件服务器及其他内部系统被入侵。
有时候你很难理解人们的想法。
在中国，有位官员甚至把微博当成是私密日记本，发布了不少他的私下里的勾当，还配了图……
这位德勤员工可能也以为别人看不到他的 Google+ 信息吧。有图为证：
以及
Google+ 页面上的信息是 public 的，所以有心人已经收集到了德勤内部遍及全球的大量服务器信息，这些信息足以让有心人对德勤发起一次攻击。
这也就是为什么新员工报到之后，我先做一次安全基础教育培训的缘故。
0x03 麻省理工的500英里邮件
这个故事不知道发生于何年何月，发帖人是一位拥有丰富 Unix/Linux/Perl 经验的系统工程师 Trey Harris，据信是上世纪90年代的事情了。
麻省理工的一位统计系主任打电话给 Trey：“我们的邮件系统存在一个问题， 我相信我们不能发送超过500英里距离的邮件 。”
WTF？！
Email？不能超过500英里？！
“真的，哪怕再远一点点，只能到520英里了，不能再远了。”
Trey 几乎不敢相信自己的耳朵。
这是麻省理工的系主任该说的话吗？
“是什么让你这么认为？”
“实际上已经好几天了。你看，直到刚才，我们才收集到足够多的证据。我让一名地理统计人员去调查了这件事情。”
这回听上去像是一名统计系系主任该说的话了。
“还有。她制作了一张地图，地图上显示我们能发送邮件的区域半径比500英里多那么一点点。即便如此，这个区域内，有些地方也不能发送，或者偶发性地能发送，但是在区域之外从来没有发送成功过。”
是的，作为一名丰富经验的系统工程师，Trey 不假思索地问：“这段时间内系统发生了什么改变吗？”（因为下一句话就一定是请你重启系统吧，XD）
“没错，一位技术支持来过，给系统打过补丁并且重启，之后就发生了这一切。”
Trey 决定自己试一试，今天并不是愚人节。
千真万确，纽约（420英里）就可以发送，但是普罗维登斯（580英里）就失败了。
Trey 证实了这个问题现象跟收件人的位置有关系，与收件人的 ISP 关系不大。
Trey 看了一下 sendmail 的配置文件，毫无意外地，它们正常得不能再正常了。
见鬼了。
于是 Trey 远程登录到 SMTP 端口，握了握手。
对端用一个 SunOS sendmail 标识愉快地做出了响应。
SunOS sendmail 标识？！
突然之间，水落石出。
这个水落石出有点出人意料，下面这段话估计只有系统工程师才能理解：
技术支持工程师打补丁的时候，还连带升级了 SunOS 的版本。
因为在那个年代，Sun 仍然随同操作系统捆绑发布 Sendmail 5 版本，尽管 Sendmail 8 已经相当成熟了。
这样一来，他等于把原来的 sendmail 8 “降级”为 sendmail 5 了。
但升级程序将 sendmail.cf 配置文件单独保留了下来。
注意这可是 sendmail 8 的配置文件喔。
一般来说，较低版本的程序看到不认识的配置项，通常都会选择忽略。
推荐下我的web前端学习群：571019044，不管你是小白还是大牛，小编我都挺欢迎，不定期分享干货，包括我自己整理的一份前端资料和零基础入门教程，欢迎初学和进阶中的小伙伴。
而 sendmail 的二进制安装包对大多数选项没有提供默认值，因此，如果在 sendmail.cf 中找不到相应的设置，它们就会被默认设置为0！
就这样， 有那么一个重要的参数：连接远程 SMTP 服务器的超时时间，也被默认设置为零 。
经过实验证明，在一个具有典型负载的特定机器上，零超时意味着如果连接时间稍微超过3毫秒，服务器就会终止 socket 连接。
在当年，麻省理工的校园网络它是百分之百交换型网络（it was 100%
switched）。
这意味着，它没有那么多的 router，也就没那么多网络延迟。
发送出去的数据包，在遇到 POP 服务器和远端路由器之前，就不会出现路由器延迟。
所以 连接一个远端主机的时间，很大程度上就是光所需的时间。
那么，3毫秒，光能跑多远呢：
=299792458米/秒×0.003秒×0.001×0.6213712（注：公里折合英里）
=558英里。