天下没有完美的事物，软件会有bug，就跟一般人会说错话、写错字一样，在所难免。然而，随着当前行动应用与大数据技术蓬勃发展，我们对于应用程序与云端服务的依赖程度日渐提升，对于系统的可靠度与软件质量的要求也连带水涨船高。

　　不论是硬件或硬件的因素，系统只要出一次包，就可能影响成千上万使用者。不过，若是一般的硬设备故障或网络服务停摆，我们尚且能搭配各种高可用性与备援机制，将受影响的程度降至最低，但其中执行的程序一旦有功能性的失误，甚至有安全漏洞，想要修正就没那么简单，因为可能要先找到问题所在的程序原始码、提出解决方法、重新发布调整过的程序或安装修补程序，甚至有时必须要先让应用系统脱机，才能套用修正的方式，若是牵涉到服务器端与客户端程序或设定的重新部署，来来回回之间，往往又要耗费许多时间和人力进行。

　　对于软件质量的判断，通常我们分为功能性与安全性等两大层面，一般应用程序或系统上线之前，多多少少都会检核程序是否符合这两种性质的需求，但比较偏重功能性的验证，因为要判断程序执行时是否能满足需求，相对容易，至于安全性的部份，若开发时没有考虑到功能遭到滥用的可能性，而刻意限缩特定程序执行的条件，之后若被人发现有这样的漏洞，可能会让人乘虚而入。

　　软件重大安全漏洞越演越烈

　　对许多it人员来说，持续关注系统资安弱点信息、定期执行漏洞修补，已经成为例行公事之一。从2001到2003年之间，开始有许多恶意软件利用windows、ie、outlook express、outlook的安全性弱点发动攻击，肆虐全球个人计算机与服务器，像是code red、nimda、blaster、sasser等蠕虫，也是在那段时期，微软强化了windows xp更新机制与系统防护，并决定在每月第二周的周二定期发布系统更新。

　　除了微软，在个人计算机使用率相当高的数字内容格式adobe pdf和flash在2009年之后，也因为漏洞而频频遭到攻击，到了2012年、2013年，java成为新的苦主，2013年1月，美国国土安全部计算机紧急应变小组甚至呼吁使用者，在甲骨文公司推出稳定java版本前，应继续停用浏览器上的java功能，然而在2月时，几家知名的网站和it公司也都纷纷中招，包括推特(twitter)、脸书(facebook)、苹果和微软都宣布内部计算机因此遭骇的状况。

　　到了今年4月，提供ssl/tls加密传输功能的开放源码套件openssl，发布heartbleed臭虫的重大安全通告，这套应用上相当普及的函式库，在tls/dtls 传输安全层的heartbeat(心跳)扩充功能之中，有程序臭虫，若该漏洞遭黑客利用来发动攻击，会造成内存存放数据外泄，有可能从服务器端外泄到客户端，或者由客户端外泄到服务器端。

　　受到该漏洞影响的openssl版本，包含1.0.1到1.0.1f，以及1.0.2-beta，而目前有许多linux和freebsd操作系统都内建openssl，这些版本的openssl已整合其中，因此debian、ubuntu、centos、fedora、openbsd、freebsd及netbsd当中一些版本，也都遭到波及。此外，因为许多系统与软硬件产品也采用openssl，或是内建整合openssl的软件平台，例如开源的网站服务器平台apache和nginx，所以牵涉到的范围更广泛。

　　例如，就连google、amazon的网站服务，以及cisco、juniper的网络设备都深陷安全漏洞的风暴，还有vmware的虚拟化平台与管理软件、mysql、mariadb和postgresql等数据库系统，以及symantec、mcafee、kaspersky、f-secure、sophos旗下一些资安软件的特定版本，也受到影响。

　　由上面的例子来看，应用程序的安全漏洞所引发的效应越来越大，而且日益复杂，要在短时间内修复，都需要时间，所牵涉到的软件性质也日益多元化──从一开始针对个人端计算机的微软windows操作系统、ie浏览器与office应用程序，以及pdf、flash及java，现在许多网站服务器、云端服务运作时所仰赖的重要组件，也被踢爆有软件安全漏洞的问题，除了事后要有完善的机制，尽速亡羊补牢，更重要的是记取教训，做到事前预防，才能够降低漏洞出现的机率，连带地，后续黑客如果想要用漏洞来发动攻击，也会越来越困难。但若要达到这样的目标，从软件还没有释出、正式上线之前的开发过程中，就要采取对应的作法，目前像是微软、adobe、cisco等公司，都已经发展或导入了所谓的软件安全开发生命周期(security development lifecycle，sdlc)，由于安全性也是软件质量的一部分，因此，通常都会透过测试的方式，在软件正式发布前，执行相关的功能与安全性检验。

　　行动装置成为市场宠儿，也成为恶意软件横行的新战场

　　除了个人计算机和服务器端会有应用程序安全漏洞，行动装置的操作系统平台和app也都是由开发人员所写出来的软件，同样不可能做到100%无漏洞，而两个主要平台android和ios，当然也是有心人士锁定的目标。

　　以市占比例最大的android装置数量来说，市调分析机构gartner和idc均预测今年底将突破10亿个，因为太过普及，所以，在这个平台所发展的恶意、高风险或扰人app也是最多。根据趋势科技全球技术支持与研发中心所发布的《2013年trendlabs信息安全总评》来看，2013年底已累积140万个，单就2013这一年就出现了1百万个新的app威胁，2014年底预估将突破300万个，不过在趋势科技最新公布的《2014年第一季trendlabs信息安全总评》当中，他们发现相关的app威胁现在就已经突破2百万个。

　　除了app威胁，过去我们所熟悉的网络钓鱼网站、垃圾邮件诈骗威胁，行动装置同样会面临，值得注意的是，针对行动装置平台的漏洞攻击也开始增多，例如去年android平台爆出masterkey漏洞(cve-2013-4787)，已经安装的正常app可能在不知情的状况下被偷换成恶意软件；另一个攻击是叫做backdoor.androidos.obad的恶意软件，运用类似后门程序与rootkits的手法，透过操作系统漏洞──root与装置管理者的权限，取得整台android装置的权限；而苹果的行动装置平台ios6也传出安全漏洞，若iphone或ipad接上黑客所改造、特制的充电座，这个弱点将会授与对方完整存取这个设备的权限。

　　有些漏洞则可以影响任何行动装置操作系统平台，因为问题出在跟所连接的周边装置有关，例如行动装置搭配的sim卡，当中所采用的旧型加密系统有程序臭虫，黑客只需传送sms简讯到这台装置，即可触发装置错误，进而释出56位长度的安全密钥，而这把密钥可以触发下载恶意的java applet，以便散播简讯和位置监控等恶意行为。

　　到了今年3月，趋势科技发现了一个针对android 4.0以上版本的系统漏洞，它要是遭到有心人士滥用，可能会造成系统不断重新启动的状态，如此等于让行动装置应提供的各种功能处于失效状态，无法操作、通话。同月，又出现了另一个自定权限漏洞，它让app能够读取其他app所保护的数据，而这可能会导致机密外泄。

　　ios和mac os x今年初也出现安全漏洞cve-2014-1266，这是跟ssl/tls加密联机有关的弱点，攻击者可能撷取或修改联机过程中所传输的数据，问题在于传输时并未验证联机的真实性。若未修补这项漏洞，苹果的行动装置在连上因特网时，有可能因此受到监听及联机挟持。

　　该漏洞影响的操作系统版本算是不少，包括ios 6到6.1.4、ios 7到7.0.5、mac os x 10.9和10.9.1，以及apple tv 6.0和6.0.1。后来，苹果为此陆续发出ios 7.0.6、mac os x 10.9.2和apple tv6.0.2的安全更新檔。

　　程序代码少了括号，系统安全性竟然就破功？

　　从上述来看，应用程序的安全漏洞太多了，从个人计算机、服务器，现在连云端服务、行动装置也都遭殃，简直是野火烧不尽，春风吹又生，然而真的每一个问题都无法事先预防吗？不能在软件开发的过程中，就及早发现问题并解决掉吗？

　　其实这是可以做到的，有的程序臭虫之所以产生，甚至只是因为一些小疏忽所造成，前面提到的ios和mac os x漏洞cve-2014-1266，就是典型的例子，一些专家追本溯源后发现，原本的程序代码只是少了一个括号，若加上去，程序运作就安全了。

　　这个操作系统的安全性弱点很特别，很多人都叫它「goto fail」漏洞，因为，关键在这两种操作系统数据安全组件securetransport安全传输功能的sslkeyexchange.c程序代码当中，一支sslverifysignedserverkeyexchange函式写错了，里面有两行的goto fail叙述紧接着执行，第一个goto fail是正确的，它对应到if叙述，但第二个goto fail就不是条件式，不论前面的if条件式是否成立，程序代码总是会执行到第二个goto fail，也就是回传err，而且也不会执行sslrawverify函式。

　　接下来会发生什么事？google资深软件工程师adam langley在他的部落格《imperialviolet》上，透过〈apple's ssl/tls bug〉这篇文章，提出了进一步解释。他认为，这里的err将会包含1个值，因为sha1更新作业会顺利完成，所以，验证签署的作业永远不会失败。

　　此外，这个验证签署的作业会检查serverkey exchange传输讯息的签名，这会用在dhe和ecdhe的ciphersuites加密演算集，让联机能与临时密钥(ephemeral key)沟通，服务器可以藉由自身凭证的暂时密钥和签署，让客户端知道联机是从这边而来的。然而，如果临时密钥和凭证炼(certificate chain)之间的连结断了，一切的验证和信任关系将会面临崩坏。因为，在这样的环境下，服务器端有可能送出一个正确的凭证炼给客户端，却是以错误的私钥来签署交握，或者根本就不用签署就可验证联机，服务器无法证明它的凭证里面拥有与公钥匹配的私钥。

　　基本上，这个安全漏洞会影响任何使用securetransport的系统，但不包括chrome和firefox，因为它们都使用nss for ssl/tls，然而，这意义不大，因为更底层的操作系统软件更新机制仍然是用securetransport来进行。同时，这个程序臭虫，也会影响任何使用dhe或ecdhe的cipher suites加密算法的站台。

　　该漏洞倒是不会影响tls 1.2，因为在当中负责验证serverkeyexchange讯息的函式是不同的，然而，为了让客户端能接受该讯息，攻击者还是可以自行挑选任何的tls版本。一旦客户端只启用tls 1.2，就会解决这个问题，同样地，如果客户端只选择完全以简单的rsa演算集，也就等于没有进行serverkeyexchange的作业，此时，也可以解决该漏洞。

　　这类的臭虫一旦出现，要如何侦测出来呢？adam langley说，若在苹果的软件开发工具平台xcode编译这段程序代码时，可以加上-wall的参数来启用所有警示，可以隐约看见出问题的程序代码段落(即便不是使用2013年发布的gcc 4.8.2或clang 3.3)。因此，他认为若有更明显的警示，将有助于及时发现这个问题，但这么一来，对于整体程序代码也会产生误报率太高的状况。

　　相较于每隔一阵子就扑天盖地而来的各种应用程序安全漏洞信息，苹果爆出这个严重危害ssl安全传输功能的操作系统漏洞，虽然只是沧海一粟，乍看之下，它似乎是个离谱的微小错误，却能让网络传输不再安全，同时，这个纰漏可能有许多开发人员就算用人工方式逐行检查，未必能一眼识出，而且，就算透过整合式开发工具，或是程序代码安全检测工具，也不一定能侦测出来。

　　此外，也幸好有苹果愿意开放部分版本的系统程序代码，还有发掘出该问题的资安专家，外界才有机会更全面地了解这样的问题何以发生，并进行充分的讨论，从而学到教训，不再重蹈覆辙。虽然类似这样的漏洞、甚至更难以发现的漏洞，未来可能还是会出现，但认真研究过这种问题的开发人员，想必将更有机会消弭掉这类漏洞。

　　除此之外，我们也必须意识到应用程序漏洞遭到滥用的方式，也在转变。

　　例如，让许多网站管理者都相当头痛的目标式攻击，黑客通常会设法寻找、利用网站的漏洞，以便取得系统控制权，并在站内植入恶意软件，以便感染浏览网站的用户计算机。

　　而根据赛门铁克4月发布的最近一期全球网络安全威胁研究报告(internet security threat report，istr)，就2013这一整年而言，最常被有心人士利用的网站弱点是ssl与tls网络安全传输协议的会谈重建程序漏洞(ssl and tls protocol renogotiation)，这几年以来，有不少攻击事件都跟这有关，例如diginotar的数字证书外泄、beast攻击(browser exploit against ssl/tls attack)、ssl会谈重建程序攻击(ssl renegotiation attack)、crime攻击，以及lucky 13攻击。

　　这跟今年爆出的ios、mac os x的ssl漏洞，以及openssl的heartbleed漏洞陆续被揭露，似乎都有一些关联性，这样的发展趋势，软件开发人员和资安人员需多加留意。