月度归档:2014年08月

Google的9行代码

The 9 lines of code of Google

 sonic0002    Date : 2014-08-15 20:29:52  


Are you still remembering the then hot debated news about Oracle suing Google allegedly copying a small portion of codes from Oracle’s Java in 2010. At that time, Oracle experts estimated that Google owes Oracle between $1.4 billion and $6 billion in damages if liable. But the court thought Oracle was eligible only for statutory damages for that copying, which were not expected to exceed a few hundred thousand dollars. At last, Oracle agreed the zero damage result.

Are you curious about which portion of codes Oracle claimed were stolen? Actually, it’s only a really small portion of it, around 9 lines of codes. These codes are for range check, it’s really a common implementation which a general programmer can write.

Joshua Bloch is the developer who wrote this piece of code. Joshua Bloch was a Sun developer(then acquired by Oracle) for the development of Java APIs. Later he joined Google in 2004 and worked on Android in 2008.  While working for Google, he still contributed to the OpenJDK One of the things he contributed was a much faster implementation for sorting arrays, based on the algorithm TimSort used in Python. Both the old and new algorithm had the rangeCheck method in common, so he just copied it from the old implementation, as “a temporary measure”. But later somehow this temporary measure ended up in Android.

Below are the 9 lines of codes copied:

1
2
3
4
5
6
7
8
9
private static void rangeCheck(int arrayLen, int fromIndex, int toIndex) {
     if (fromIndex > toIndex)
          throw new IllegalArgumentException("fromIndex(" + fromIndex +
               ") > toIndex(" + toIndex+")");
     if (fromIndex < 0)
          throw new ArrayIndexOutOfBoundsException(fromIndex);
     if (toIndex > arrayLen)
          throw new ArrayIndexOutOfBoundsException(toIndex);
}

Easy enough so that most programmers can write in just a few minutes or less. But the thing is not about the codes, it’s about the attitude and incentive. Nowadays many API developers are not allowed to read other companies’ similar APIs before implementing their own because the management fears that the developers may be interfered by the source codes they read and write the same without noticing it. They would be able to refer to the source code after they complete implementing their own API however.

Be careful when you are using open source codes especially when you are working for a company which gains its profit by selling commercial software.

Black Hat USA安全隐患盘点及黑客奥斯卡颁奖

摘要:Black Hat USA 2014已落下帷幕,这里带大家回顾会议中最值得关注的安全隐患,以及黑客奥斯卡奖Pwnie Awards的颁奖结果。

【编者按】Black Hat USA 2014已于8月2-7日在拉斯维加斯举行,会议汇聚了大量的全球知名安全专家。Black Hat安全技术大会是世界上最能够了解未来安全趋势的信息峰会,每届会议都可以称得上安全解决方案提供商前行的指引。本年度重点关注的安全领域又有什么不同?一年一度的黑客奥斯卡奖项又花落谁家,这里一起盘点。

以下为译文:

作为业内知名的信息安全会议,Black Hat 2014为各类解决方案提供商定义了一个明确的方向。 资深安全专家,Beyond Trust CTO Marc Maiffret指出,新兴技术一般是安全研究员关注的重点,会议上,大量利用新服务(或产品)漏洞窃取资源或进行其他危险攻击的途径被揭发,产业因此可以尽早的进行调整。本文着重盘点第十八届Black Hat上被揭露的安全漏洞,其中十个足以改变当下安全解决方案提供商的产品布局,并产生深远影响。

1. 数据库安全隐患——历时长久的攻防战

 

David Litchfield,一位英国的安全研究员,知名于揭露Oracle、微软等公司RDBMS软件中的巨大漏洞和结构缺陷。在Black Hat 2014上,David展示了Oracle旗舰数据库管理系统中存在的新漏洞。

该漏洞基于Oracle新版数据库12c中大肆宣扬的功能“数据校订(data redaction)”,这个功能被设计用于保护敏感数据。演讲中,David表示数据校订功能内含有大量安全漏洞,攻击者可以利用这些漏洞来绕过安全特性,并查看社会保险号、信用卡号等敏感信息。David表示,除下虚假的安全感,这个功能对企业没有任何帮助。

2. 云安全隐患——影响的不只是可用性

 

阿根廷顾问公司Bonsai Information Security创始人Andres Riancho通过详细研究指出,配置错误和基本漏洞都可能泄露托管于云上的应用程序数据、账户凭证等信息。Andres演示了AWS云基础设施可能被利用访问账户凭证、日志文件,并最终窃取用户账号。他还开发了一个专门的工具,这个工具可以自动浏览元数据,为攻击者访问敏感资源提供重要线索。他提倡安全专家与开发者共同审视当下的架构,及做好未来项目使用IaaS资源时的准备。

3. 医疗设备隐患——需要重点对待的领域

 

随着微型、强大的嵌入式系统投入到胰岛素泵、心脏起搏器等医疗设备,这个领域的安全就必须得到重点关注,因为这些设备越来越多的连接到互联网,在Black Hat 2014上漏洞管理厂商Rapid7研究员Jay Radcliffe指出。

Jay认为,漏洞可能被用于针对高风险个体,如政治领袖等。Jay专注于医疗设备安全,并成功黑了自己的胰岛素泵。Jay认为,这些设备面对一个非常普遍的问题——安全软件更新,因此无法更好地防御数据泄露。

4. POS系统隐患——Chip-And-PIN漏洞

 

Crowdome安全研究员兼NCR Retail企业安全架构师Nir Valtman表示,零售终端系统正面临内存搜读(memory-scraping)恶意软件的威胁,他表示可以在当下POS系统上运行的内存搜读恶意软件已非常普遍,其中更有许多已在大量目标数据窃取行动中得以验证,这些软件涉及身份认证、信息检索等多个功能。Nir研究过市面上大多数的付费安全系统,致力降低它们对系统性能的影响,他表示,取代只从技术方面着手,为零售商提供更多的信息服务同样重要。

期间,在另一个Black Hat会话上,剑桥大学密码学专家Ross Anderson表示,美国零售商最终将全部使用Chip-And-PIN,但是这项技术同样拥有漏洞和局限性。

5. Email安全隐患——雅虎加入谷歌行列

 

低等级数据加密或者无力及过时的安全协议在会议上被研究员多次提起,但其中影响力最大的报告无疑来自雅虎,该公司宣布将为用户提供一种终端到终端的加密技术。Google于今年6月发布了这项技术,提供了一个浏览器插件来加密数据。

世界范围内的雅虎和谷歌云服务用户都将享受到该技术带来的隐私和安全保障,其主要针对Edward Snowden揭秘的美国政府监控行为。雅虎CIO Alex Stamos表示,这项技术将在2015年放出。

6. 汽车软件隐患——岌岌可危的产业

 

Charlie Miller及Chris Valasek指出,当下,汽车制造厂商为敏感软件添加越来越多的监视及触发器,导致了愈来愈多的安全隐患。同时,他们还公布了关于汽车网络数据的分析,并确认了20个风险最高的模型。

车辆正在增加愈来愈多的无线能力,这无疑让远程攻击变为可能。Charlie当下是Twitter的安全工程师,他表示,他们正在寻找安全防御最好的汽车厂商。他们发现,2014 Jeep Cherokee和2015 Cadillac Escalade的风险最高,而2006 Ford Fusion和2010 Range Rover Sport看起来最为安全。

除此之外,Qualsys的研究员Silvio Cesare还展示了智能钥匙安全系统的缺陷,只使用一个简单的工具就可以锁车、开车,或者打开汽车的后备箱。

7. OTA升级导致了一系列的安全隐患


 

Accuvant Labs研究员Mathew Solnik和Marc Blanchou指出,网络运营商和设备制造商在更新手机、平板等无线设备时,无线机制中往往存在安全漏洞。该实验室研究员表示攻击者可以劫持运营商的远程控制能力,并在广泛的设备管理协议中利用。

此外,研究人员还指出运营商管理网络性能工具Carrier IQ可以监控手机上的所有流量。同时,这个设备管理工具让手机更容易被攻击。该应用可以用于运行远程代码,并绕过操作系统的本地防御。在全球范围内,70%到90%的手机内部都存在这个设备管理软件,由于这个易受攻击的OMA-DM协议,其他的设备,如笔记本、无线热点、物联网设备等也都存在风险。

8. USB安全隐患——威胁指数直线上升

USB一直是大量恶意软件的传播媒介,但是安全研究员Karsten Nohl和Jakob Lell指出USB隐患当下已经更加危险,未来借助USB的攻击将更具威胁。研究员演示了如何借助攻击监视网络流量,以及恶意软件在启动过程中如何夺取控制权。USB攻击非常难以察觉,因为当其被连接到笔记本或台式机时,它通常会被作为一个新设备,而恶意软件设计者可以轻易利用窃取来的证书欺骗设备制造商。

鉴于大多数的驱动硬件制造商都不会采取任何措施保护固件,同时恶意软件解决方案也不会扫描驱动固件以检查恶意行为,USB给了好事者无限可能。幸运的是,目前这种类型攻击在现实中尚未出现。

9. 能源管理平台——更大的威胁产生


来自德国IT安全公司ERNW的研究员揭露了Cisco Systems EnergyWise套件中的安全漏洞,他指出攻击者可以利用这些漏洞破坏机构的电力系统。该信息同样可以被恶意攻击者用来窃取数据,Cisco EnergyWise被设计用于读取每台机架的电压、功率、电流及每小时用电数,同时也会读一些温度、湿度、气流等数据。

10. 机场和飞机上的安全设备存在重大隐患


Qualys漏洞研究主管Billy Rios表示,机场中大量使用的扫描设备存在高危漏洞,攻击者可以利用这些漏洞访问和控制一些关键功能。Billy指出了Transportation Security Administration批准的两个设备,并要求厂商对底层软件做重大调整。Billy表示,在一个制造商的箱包扫描设备中,身份验证证书以纯文本格式存储,并缺少远程控制管理,其默认密码同样是一个非常大的隐患。

同时,IOI研究员Ruben Santamarta表示,攻击者可以通过飞机上提供的Wi-Fi和空中娱乐系统黑进飞机卫星通讯系统,从而控制飞机航线和安全系统。

在上述十个领域之外,监控录像机、Tor网络、路由器、NSA、酒店系统等也是研究员重点关注领域。

除此之外,2014黑客奥斯卡奖Pwnie Awards同样值得关注。本次Pwnie Awards共分8个类别,下面我们一起看各个类别漏洞提名以及最终得奖者(白色为提名,红色标注为最终获奖者),其中Heartbleed可以说是臭名昭著了:

最佳服务器端漏洞:

 

  • Abusing JSONP with Rosetta Flash (CVE-2014-4671)
  • Heartbleed (CVE-2014-0160)
  • IPMI: Sold Down the River
  • Embedded Device Hacking

 

最佳客户端漏洞:

 

  • Google Chrome Arbitrary Memory Read Write Vulnerability (CVE-2014-1705)
  • Heartbleed (CVE-2014-0160)
  • Pwn4Fun Safari vulnerability (CVE-2014-1300)
  • Goto Fail (CVE-2014-1266)

 

最佳提权漏洞

 

  • AFD.sys Dangling Pointer Vulnerability (CVE-2014-1767)
  • VirtualBox VM Breakout using 3D Acceleration (CVE-2014-0981)
  • Linux Futex Bug (CVE-2014-3153)
  • evasi0n iOS 7.0 jailbreak
  • Pangu iOS 7.1 Jailbreak

 

最具创新性研究

 

  • Hardware-assisted Memory Corruptions
  • Bypassing Windows 8.1 Mitigations using Unsafe COM Objects
  • RSA Key Extraction via Low-Bandwidth Acoustic Cryptanalysis
  • Windows 8 UEFI Secure Boot Bypasses
  • Hacking Blind

 

响应最烂的厂商

 

  • OpenCart PHP Object Injection Vulnerability
  • Fired, I?
  • AVG Remote Administration Insecure “By Design”
  • General Motors

 

最佳歌曲奖

 

  • “I’m a C I Double S P”
  • “Memory Corruption”
  • “Expect Us (We Are Anonymous)”
  • “Security Kate”
  • “The SSL Smiley Song”

 

最经典输家

 

  • Goto Fail
  • Heartbleed
  • Target Breach
  • (ISC)2 Optional Membership Fee

 

最经典破坏

 

  • Heartbleed (CVE-2014-0160)
  • Target Breach
  • Inputs.io
  • Mt. Gox

Javascript 匿名函数与封装

迷惑了一会儿不同JS库的封装后,终于有了点头绪。大致就是:

创建一个自调用匿名函数,设计参数window,并传入window对象。

而这个过和的目的则是,

使得自身的代码不会被其他代码污染,同时也可以不污染其他代码。

jQuery 封装

于是找了个早期版本的jQuery,版本号是1.7.1里面的封装代码大致是下面这样的

(function( window, undefined ) {
var jQuery = (function() {console.log('hello');});
window.jQuery = window.$ = jQuery;
if ( typeof define === "function" && define.amd && define.amd.jQuery ) {
    define( "jquery", [], function () { return jQuery; } );
}
})( window );

其中的

console.log('hello');

是用以验证是否按开头说的这样工作,于是我们就可以在window中调用jQuery

window.$

或者是

window.jQuery

于是我们就可以创建一个类似的封装

(function(window, undefined) {
    var PH = function() {

    }
})(window)

相比于上面只是少了两步

  • 定义jQuery的符号及全局调用
  • 异步支持

于是找了下更早期的jQuery的封装,方法上大致是一样的, 除了。。

if (typeof window.jQuery == "undefined") {
    var jQuery = function() {};
    if (typeof $ != "undefined")
        jQuery._$ = $;

    var $ = jQuery;
};

很神奇的判断方法,以致于我们没有办法重写上一步的jQuery。于是只好看看最新的jQuery的封装是怎样的。于是就打开了2.1.1,发现除了加了很多功能以外,基本上思想还是不变的

(function(global, factory) {

    if (typeof module === "object" && typeof module.exports === "object") {
        module.exports = global.document ?
            factory(global, true) :
            function(w) {
                if (!w.document) {
                    throw new Error("jQuery requires a window with a document");
                }
                return factory(w);
        };
    } else {
        factory(global);
    }

}(typeof window !== "undefined" ? window : this, function(window, noGlobal) {
    var jQuery = function() {
        console.log('jQuery');
    };
    if (typeof define === "function" && define.amd) {
        define("jquery", [], function() {
            return jQuery;
        });
    };
    strundefined = typeof undefined;
    if (typeof noGlobal === strundefined) {
        window.jQuery = window.$ = jQuery;
    };
    return jQuery;
}));

在使用浏览器的情况下

typeof module ="undefined"

所以上面的情况是针对于使用Node.js等的情况下判断的,这也表明jQuery正在变得臃肿。

Backbone 封装

打开了Backbone看了一下

(function(root, factory) {

    if (typeof define === 'function' && define.amd) {
        define(['underscore', 'jquery', 'exports'], function(_, $, exports) {
            root.Backbone = factory(root, exports, _, $);
        });

    } else if (typeof exports !== 'undefined') {
        var _ = require('underscore');
        factory(root, exports, _);

    } else {
        root.Backbone = factory(root, {}, root._, (root.jQuery || root.Zepto || root.ender || root.$));
    }

}(this, function(root, Backbone, _, $) {
    Backbone.$ = $;
    return Backbone;

}));

除了异步支持,也体现了其对于jQuery和underscore的依赖,百

        define(['underscore', 'jquery', 'exports'], function(_, $, exports) {
            root.Backbone = factory(root, exports, _, $);
        });

表明backbone是原生支持requirejs的。

Underscore 封装

于是,又看了看Underscore,发现这个库又占领了一个符号 _

(function() {
    var root = this;
    var _ = function(obj) {
        if (obj instanceof _) return obj;
        if (!(this instanceof _)) return new _(obj);
        this._wrapped = obj;
    };

    if (typeof exports !== 'undefined') {
        if (typeof module !== 'undefined' && module.exports) {
            exports = module.exports = _;
        }
        exports._ = _;
    } else {
        root._ = _;
    }

    if (typeof define === 'function' && define.amd) {
        define('underscore', [], function() {
            return _;
        });
    }
}.call(this));

总体上也和差不多都是匿名函数,除了最后用的是call()方法。

http://www.phodal.com/blog/javascript-anonymous-function-encapsulation/

如何看待自己写的烂代码

如果你不是入行不久的新程序员,你很可能会遇到一些你曾经写过的老代码,看到它们,你可能会有这样的反应:

哦,shit!这是什么?当时我脑袋进水了?

我就这样过。我的朋友和同事们都经历过。你很可能也发生过这样的事情。

最近我的一些前同事联系到我,问我是否能帮助他们做一些前端开发工作。我想着挣一些外快也不错,而且,这个公司里我曾经工作过两年半,他们都是优秀的程序员。

昨晚,我遇到了一些之前在那个公司里任职时自己写的JavaScript老代码,下面是我的反应:

  1. 怀旧追思: 哇塞!这是当年我写的啊!
  2. 羞耻: 我靠,怎么写成这样。应该使用更好的方法。真惭愧,当时怎么会把这样的代码放到产品中。
  3. 困:不早了,我该睡觉了。
  4. 骄傲:这段代码运行的良好——虽然不是最佳算法。更妙的是,我是5年前写的它,计算一下,它至少被成功的执行了70亿次!

早上醒来时我感觉好多了,不再为我那不是很完美的代码而忧愁。写代码不是为了美,是为了价值。所以,下次,当你再看到自己的一年前、5年前、甚至更多年前写的让人难为情的“烂代码”时,如果它们还在产品库中,还在生产着价值,你应该为它们骄傲!

程序员经典幽默之恶搞对联

看了文章的标题,各位程序员千万别误会,程序员这种死板的生物怎么可能会写对联。下面的这些对联都非常有趣,看到别人这样恶搞自己也不免会淡淡的一笑,哎,苦逼的程序员。

对联一

上联:受苦受累起得比鸡还早。

下联:累死累活干得比驴还多。

横批:禽兽不如。

对联二

上联:一个项目两部电脑三餐盒饭之为四千工资搞得五脏俱损六神无主仍然七点起床八点开会处理九个漏洞十分辛苦。

下联:十年编码九年加班八面无光忙的七窍生烟到头六亲不认五体投地依旧四肢酸软三更加班只为两个臭钱一身孤苦。

横批:苦逼程序员。

对联三

上联:为系统而生,为框架而死,为debug奋斗一辈子!

下联:吃符号的亏,上大小写的当,最后死在需求上!

横批:杯具程序员。

对联四

上联:这个其实很简单。

下联:原理细节我不管。

横批:立马上线。

对联五

上联:我这儿没干啥它自己就好了。网络这事吧不明觉厉。

下联:你那儿不行吗我运行正常呀!需求想改呀十动然拒。

横批:细思恐极

对联六

上联:足不出户一台电脑打天下

下联:窝宅在家两只巧手定乾坤

横批:我最碉堡