郑允创立于2017/9/29,并于2017/10/6最后更新
概述:
阿里安火箭解体
阿波罗飞船的P01模式
德勤的谷歌
麻省理工学院的500英里邮件
富液叹息的节气又来了。
0x00阿丽亚娜火箭解体
1996年6月4日首次试射阿里亚娜5号火箭。
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,就不会发生这场惨案。
0x01阿波罗飞船P01模式
据说,历史上最牛的女程序员玛格丽特希菲尔德汉密尔顿于1965年担任NASA软件编程部部长。(威廉莎士比亚,斯图尔特,Northern Exposure,Northern Exposure)。
软件工程(Software Engineering)一词是玛格丽特汉密尔顿发明的,但这是阿波罗11号宇宙飞船时的事。
下面是阿波罗8号飞船的故事。
那时她没日没夜地工作,女儿劳伦在她的实验室玩累了,睡在地板上。
当天,劳伦按下命令室模拟器,启动了名为P01的预处理程序。
突然模拟器崩溃了。
玛格丽特发现后,为了避免这种情况发生,最好添加代码。
但是完全没有必要认为宇航员不能这样做。
因为当年的计算机存储空间和计算能力非常有限,在海螺壳上盖印章,斤斤计较的领导不想浪费这个空间。(莎士比亚)。
因此,玛格丽特不得不在飞行中添加不要选择P01模式的备忘录。
玛格丽特在飞行室。
但是你想怎么来就怎么来。
1968年12月26日,在人类首次绕月飞行的阿波罗8号宇宙飞船上,宇航员们成功进入P01模式。
此模式的直接结果是所有导航数据都将被清空。
宇航员不想再回家了。
玛格丽特带着人们奋斗了9个小时,终于上传了新的导航数据,一切回到了正轨,阿波罗8号也顺利搭载宇航员返航。
阿波罗11号宇宙飞船在月球着陆前几分钟发生了另一场更大的危机。
玛格丽特正回到舱外。
详情请在搜索引擎中搜索关键词“程序员永恒女神”。
0x02德勤的谷歌
哥哥说,以前在《安全基础教育第一季》,公司越来越大的时候,安全意识薄弱的人(被称为猪一样的队友)经常出现,做不可理解的事情。例如,他毫不犹豫地双击电子邮件中的EXE附件,或使用与用户名相同的密码。
而且所有知名公司都有这么几个没有肺的人,如果在开源社区泄露源或敏感信息,在乌云网上随便拉一下,就能找到很多东西。
盛大的一位开发者意识不足,泄露了内部邮箱账号密码(github)。
信任某开发者认识不足,泄露了内部邮箱账户密码(github)。
漫游成功的京东内部网络的过程(一个开发人员的失误造成的)(github)
新浪开发者缺乏安全意识,导致部分源代码泄露(谷歌代码)
腾讯集团内部邮箱账户密码泄露(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 8 的配置文件喔。
一般来说,较低版本的程序看到不认识的配置项,通常都会选择忽略。
而 sendmail 的二进制安装包对大多数选项没有提供默认值,因此,如果在 中找不到相应的设置,它们就会被默认设置为0!
就这样,有那么一个重要的参数:连接远程 SMTP 服务器的超时时间,也被默认设置为零。
经过实验证明,在一个具有典型负载的特定机器上,零超时意味着如果连接时间稍微超过3毫秒,服务器就会终止 socket 连接。
在当年,麻省理工的校园网络它是百分之百交换型网络(it was 100% switched)。
这意味着,它没有那么多的 router,也就没那么多网络延迟。
发送出去的数据包,在遇到 POP 服务器和远端路由器之前,就不会出现路由器延迟。
所以连接一个远端主机的时间,很大程度上就是光所需的时间。
那么,3毫秒,光能跑多远呢:
=299792458米/秒×0.003秒×0.001×0.6213712(注:公里折合英里)
=558英里。
XDD……
-EOF-
赠图两枚:
寡姐的痛击
国庆快乐
语录若干:
互联网公司以后还是别随随便便高调宣布几千万与网红、奇女子、奇男子签约了,前有某酱,今有某闯。也许是有些flag,平凡人消受不起。也许是怀璧其罪吧。
为什么搞力学的擅长经络和针灸呢?我猜想是因为有一个方向叫“生物力学”吧?生物力学是采用力学理论来研究生物体内物质运动的学科,人体力学是其中的一个分支。
“团购”->“共享”->“无人”,人越来越少,人越来越贵,下一步只能是“AI”了…………
-END-