• <ul id="mayc0"></ul>
    <ul id="mayc0"><center id="mayc0"></center></ul>
    <strike id="mayc0"><input id="mayc0"></input></strike>
    <ul id="mayc0"></ul>
  • 始創于2000年 股票代碼:831685
    咨詢熱線:0371-60135900 注冊有禮 登錄
    • 掛牌上市企業
    • 60秒人工響應
    • 99.99%連通率
    • 7*24h人工
    • 故障100倍補償
    您的位置: 網站首頁 > 幫助中心>文章內容

    黑客已勝?哥倫比亞大學教授談計算機安全問題

    發布時間:  2012/9/24 17:09:40

    2009年,哥倫比亞大學計算機科學教授Steven Bellovin說:“任何人……找到解決計算機安全問題靈丹妙藥的可能性恰好是零。問題大部分出自有缺陷的代碼,造成缺陷的原因各異、也沒有單一的解決方案。事實上,我很懷疑會有真正的解決方案;有缺陷的代碼是計算機科學最古老的未解難題,我認為這不會改變”。

    本月出任聯邦貿易專署(FTC)首席技術專家的Bellovin,在IT領域服務多年,包括在新澤西州Florham Park的美國電話電報公司(AT&T)實驗室從事研究二十余年。他在其生平中解釋說:“我研究網絡和安全,以及二者間的沖突”。

    對計算機安全問題,未來會有徹底的解決方案嗎?《政府技術》(GT)雜志向Belllovin問了這個問題和其他問題。他謹慎地指出,這些僅是他個人的意見,不一定是FTC的意見。

    GT: 三年前,您說過有缺陷的代碼是計算機科學最古老的未解難題,并預期不會改變。現在您的觀點有無變化?看來,隨著基礎架構變得 “更聰明”,我們將成為壞人更大的靶子,而潛在危險的后果也嚴重得多。例如,一個交叉路口的交通燈故障,可以讓車輛堵塞若干公里。

    Bellovin: 是的,我的觀點沒有變。到底該做什么仍屬研究領域;即使我有些想法,但都極不成熟。我認為我們需要采用不同的架構來建立系統,這些架構在設計時就考慮到將會有安全失誤。身份認證做不到這一點,在大多數破壞中,壞人繞過了強身份認證、而不是攻破了認證。

    我自己的實用哲學是:程序將有安全缺陷,其后果呢?但這是個研究課題,不是給程序員的指南,更不用說用于最終場合了。您剛才提到交通燈出毛病,您問得太對了:一個部件出故障,系統的退路是什么?

    GT: 為什么缺陷代碼問題這么棘手呢?

    Bellovin: 根本問題在于,智力難以掌控程序的復雜性。舉例來說,雷鳥(Thunderbird)電子郵件程序。幾年前我檢查時,該軟件約有六百萬行代碼。(這是很粗的估算值;我只對準確到“百萬”有信心,但到底是六百萬、還是三百萬或一千二百萬行,我說不準)。

    假定我想寫些在總結行里顯示附件數的代碼。該代碼部分將必須利用極其復雜的已有代碼部分,來掃描并解析整個郵件以確定每個附件開始和結束的位置。(因為規格說明書特別復雜,代碼本身復雜得可怕。)我對現有代碼的理解不會錯吧?不懂會闖禍嗎?能有多少個附件呢?假定我今天讀現有代碼、覺得它不可能處理多于99個附件,因而用了兩位數來顯示。爾后,其他人在不了解我那些代碼的情況下修改了代碼以便允許9,999個附件。我那些代碼就處理不了了,因而產生了一個缺陷。該缺陷會被黑客利用嗎?可能會、也可能不會,但問題有可能從這里發生。

    更好的設計也許是,讓處理附件的代碼有辦法告訴程序的其他部分附件的上限數;但這意味著大量的前瞻性。有時,程序員具備足夠的前瞻性,有時又會缺乏;或許過去程序員曾有過,但經過多年需求已經變更了。

    除此之外,還有粗心大意。我想回顧一件35年前的事,那時我在研究院、教一門編程入門課。出于復雜但可以理解的原因,某學生在操作系統指令中用了一個分號。(用的是IBM主機、那是打孔卡片時代。)

    分號在程序里是必須的,但在命令行語言中則是禁止的。然而,負責命令行部分的程序員沒有預見到分號,結果在處理該指令時(即每當系統試圖運行該學生的那組卡片時),整臺主機崩潰。學生遭人白眼,但實際上應歸咎于程序員,因為他理應把代碼寫得更好:當有人提交分號等垃圾時系統不至于崩潰。

    當今的程序改善了很多,但離完美還很遠。您也許聽說過“SQL注入攻擊”,問題的發生,在于程序員未曾處理意想不到的輸入。(這一點,http://xkcd.com/327/ 有幽默闡述。)

    困難在于,除了“把代碼寫得更好”(Write Better Code)之外,對復雜性難題我們沒有什么好辦法。(“我忘記了”是相對容易解決的。)如今,“把代碼寫得更好”可能極有幫助。微軟公司過去十年里在此方面大筆投資,用于程序員教育、自動檢查工具、代碼復審團隊等。確實有幫助,可謂獲益良多,然而,從微軟公司的關鍵缺陷修復率來看,這與他們的目標距離還很遠。也有很多“把代碼寫得更好”的想法,從上世紀七十年代初起,我一直在關注著各種百靈藥上市。不用說,問題尚未解決。

    GT: 新一代互聯網標準IPv6是不是弱點少一些呢?

    Bellovin: 它有一些小改進,但沒有根本性的。當初設計該標準時,我們曾寄予厚望。實際上,在1994年前后,有人曾宣稱它會更安全。不幸的是,如他們所說,該聲明是“無效的”,有幾個原因:首先,我們所說的“更安全”實際上是“內置了加密”,即現在被稱作IPsec的虛擬專用網(VPN)協議。

    這有幾個問題。其一,如今我們對不安全性有了更深刻的理解。密碼學是好東西,但解決不了缺陷代碼問題。(1998年,作為National Academies研究的一部分,我分析了當時已經發出的每條CERT建議,85%描述的都是加密無法解決的問題:代碼問題、配置錯誤等等。)其次,我們當時假定IPv6會很快得到實行,但事實并不如愿。在過渡期間,每個推出的操作系統都在IPv4代碼中加入IPsec支持。這沖淡了IPv6原有的優勢。

    但IPv6仍有一些好東西,例如增強私密地址(privacy-enhanced addressing)、純v6網對掃描蠕蟲(那些通過在某個IP地址范圍找到所有宿主傳播的惡意軟件)的相對免疫性等。但這些不過是小優點,需要與互聯網服務供應商及其網管對IPv6運行與跟蹤經驗相對不足來綜合考量。(跟蹤是指當機器使用增強私密地址、需要其他措施才能辨別時,回答“哪臺機器干了那件壞事?”的問題。)

    GT: 那么,假如缺陷代碼和您提到的問題繼續存在,我們該何去何從?

    Bellovin: 不存在完美的事物,并不意味著不存在“較好”或“較壞”的區別。良好實踐會令我們受益匪淺,但別以為這樣能徹底解決問題。


    本文出自:億恩科技【www.vbseamall.com】

    服務器租用/服務器托管中國五強!虛擬主機域名注冊頂級提供商!15年品質保障!--億恩科技[ENKJ.COM]

  • 您可能在找
  • 億恩北京公司:
  • 經營性ICP/ISP證:京B2-20150015
  • 億恩鄭州公司:
  • 經營性ICP/ISP/IDC證:豫B1.B2-20060070
  • 億恩南昌公司:
  • 經營性ICP/ISP證:贛B2-20080012
  • 服務器/云主機 24小時售后服務電話:0371-60135900
  • 虛擬主機/智能建站 24小時售后服務電話:0371-60135900
  • 專注服務器托管17年
    掃掃關注-微信公眾號
    0371-60135900
    Copyright© 1999-2019 ENKJ All Rights Reserved 億恩科技 版權所有  地址:鄭州市高新區翠竹街1號總部企業基地億恩大廈  法律顧問:河南亞太人律師事務所郝建鋒、杜慧月律師   京公網安備41019702002023號
      0
     
     
     
     

    0371-60135900
    7*24小時客服服務熱線