<em id="pn7p8"><acronym id="pn7p8"><u id="pn7p8"></u></acronym></em>

    <th id="pn7p8"></th>

    <button id="pn7p8"></button>

      <dd id="pn7p8"></dd>
      <progress id="pn7p8"><track id="pn7p8"></track></progress>

      Linux培訓
      達內IT學院

      400-111-8989

      Linux內核社區是數字軍火商

      • 發布:佚名
      • 來源:網絡
      • 時間:2015-07-16 13:42

      Linux內核社區是數字軍火商、斯拉夫兵工廠甚至NSA的最愛

      編者按:

      Grsecurity/PaX的應用十分廣泛,特別是具有高安全性的環境。Gnu/Linux發行版里Gentoo提供PaX作為加固選項,最近半年Debian社區發起的對抗大規模監控的加固項目Mempo在內核中也使用了Grsecurity/PaX。因此說普通的GNU/Linux安全是相對于Windows而言。不得不說,在這個一天云計算、一天霧計算、今天框計算、明天網格計算的年代,作為一個10多年前的設計和實現,PaX的思路的確令人震撼。

      譯者Shawn the R0ck:

      Grsecurity/PaX是在OS安全上的一個開創性的貢獻,沒有PaX/Grsecurity的GNU/Linux的安全性只能防御腳本小子,過去的14年里Pax/Grsecurity為Linux內核做出了巨大出貢獻的貢獻,但到今天Linux內核社區都不愿意承認,這可能的確是受商業廠商控制了主流媒體的后果,在后棱鏡時代,這種現象有極端的陰謀論甚至認為NSA也是推手,當然這也并非完全沒有道理,畢竟SELinux項目早已成為Five-Eyes國家的標配。

      我嘗試翻譯這篇5年前的訪談是為了讓更多的人了解到歷史,因為反觀今天的Linux內核社區對于安全的態度相比5年前可能是更糟糕,offset2lib的遠程利用方式輕松繞過了GNU/Linux廠商們宣稱的完美防御,相信就算是智商只有85的人也能明白“抗爆破”機制只能抗不到1秒的時間是在扯淡;-)。即使 offset2lib所帶來的風險巨大,Linux內核社區的態度也是極度傲慢,他們也不認為這個PaX/Grsecurity在2001年就已經加固的攻擊平面而他們在2015年還存在有什么問題,而BadiRET漏洞里我們更能清晰的看到SMEP雖然被繞過,但SMAP依然有效,而這兩個Intel CPU的特性也是源于2007年PaX/Grsecurity的其中一個特性UDEREF的啟發。自從有了OS的攻防歷史,就有了PaX/Grsecurity,如果Linux內核社區繼續傲慢自大,最終的受害者是企業用戶和個人用戶。

      在Anarchist看來,這樣的Linux內核社區正是數字軍火商,斯拉夫兵工廠甚至NSA所喜歡的。

      Slo-Tech:向我們的讀者介紹一下你自己(工作,教育背景以及興趣),也請你解釋一下你的真名是Spender還是Spengler;-)請問Brad是否是任何黑帽組織的成員?

      Brad Spengler:Brad Spengler(不是Brad Spender),雖然相似的名字并非偶然,我改了改姓氏作為別名。我畢業于Bucknell大學,獲得了計算機與工程(混雜了計算機科學和電子硬件的課程)學士學位和一個應用數學的學士學位。數學/物理學/經濟學/哲學都是我最有興趣的課程。我在學習操作系統課程之前就已經有4年的學習Linux內核和編程的經歷,所以計算機科學課程并不是那么的有趣。我從來沒有參加過任何黑帽組織。自從高中開始我總是對創造有趣的事物有興趣。…………………(未翻譯)

      Slo-Tech:你能用簡單描述一下什么是PaX和GRSecurity以及有多少人參與這些項目嗎?

      Brad Spengler:PaX是一頭戲劇性的改變了整個安全的形態的野獸,而且對未來安全的影響甚至會更多。PaX專注于一次性的解決一堆各種類型的漏洞利用,有一些工作還沒有完成,但希望能有所改變,也希望8年后(Shawn:現在已經是5年后了,愚蠢的大眾還是寧愿相信商業廠商和NSA;-))所有人都能明白PaX的前瞻性。PaX 完全專注于內存的漏洞利用,Grsecurity則增加了主機層的防御和基于現有的PaX特性進行了一系列的改進,包括抗爆破,ASLR的抗信息泄漏,不允許文件系統級別的任意代碼執行等。Grsecurity包括了很多簡單的自動化特性,比如RBAC系統可以通過學習模式(你可以選擇基于進程/用戶或者整個系統)來自動化創建規則,這些規則都是人類可讀的純文本格式(Shawn:SELinux是使用難以審計的二進制的格式),報錯信息有助于根據攻擊類型來制定相應的規則。

      PaX項目的參與人數是未知的!因此PaX Team至少有一個人:),對于Grsecurity這邊就我一個人。偶爾我也收到一些Patch提交(比如來自Zbyniu Krzystolik),贊助者和朋友有時也會告訴我他們想要加入一些新功能。

      Slo-Tech:只有一些人真正了解PaX Team開發了一些安全機制(比如ASLR)后來被用于Linux內核里,至少目前來看主要的Linux內核社區開發者和參與者并不打算承認PaX所帶來的貢獻,你認為這些機制對于Linux安全貢獻最大的是什么。

      Brad Spengler:好吧,對我而言很搞笑的是聰明的Ingo Molnar多年前對于paxtest測試(包括檢查不同區域的地址空間是否有能力執行任意代碼)非常不爽,因為第2組測試中mprotect用于標記一些內存為可寫和可執行。Ingo稱這個測試是“破壞”–mprotect檢測多少有些不公平(因為exec-shield完全失效了)。往前看幾年你會發現 SELinux基本上把PaX的MPROTECT加入了它的規則語言。在Windows的世界里你能找到所有人都在嘗試日等價于Linux上的mprotect,glibc曾經有一個make_stack_executable()函數也是ret2libc攻擊的對象,Windows上也有類似的函數。PaX team早在很多年前就認識到攻擊者會找最薄弱的環節下手,而這正是今天正在發生的事情。

      我不能說哪一個特性是對Linux安全貢獻最大,因為這些特性都是疊加式的讓Linux內核更安全。同樣,我認為下一個最具革命性的貢獻將同樣來自PaX team。

      Slo-Tech:看起來Brad和Linux內核開發者的“口水戰”還在繼續。什么是主要原因導致了這種不愉快的情況?你不認為其實GNU/Linux的終端用戶才是遭受損失的嗎?

      Brad Spengler:我從來都沒有發過一封郵件到LKML(Linux內核郵件列表),所以我并沒有參與任何“口水戰”。PaX Team曾經發過郵件到LKML(比如讓Linux內核開發者承認他們的不愿意讓外界關注的不披露漏洞的官方政策和安全漏洞信息模糊化以及Linus為此多次贏得pwnie獎項的”a bug is bug”的安全哲學)。8個公開的空指針引用的漏洞利用才被作為提權威脅來處理,在第一個公開漏洞利用后幾個月,mmap_min_addr被引入,但并不懂安全的Linux開發者開發的這個安全機制導致了至少6個不同的繞過。Linux內核的ASLR有大量的弱點。SSP被攻破了多次最終導致他們強行限制其工作范圍。所有這些破事都來自于一個商業源頭:Red Hat——對于公司重要的是為了賺錢你要說你有X特性(比如反病毒廠商會宣稱:“我們將會保護你不受病毒的侵害。”),至于這個特性是否有用并不是公司關心的(但有些人會去驗證廠商的宣傳—安全研究人員或者黑帽)。

      Slo-Tech:誰是你尊重的Linux內核開發者?或者說,你不覺得在安全問題上Linux需要重新組織一下關于處理安全事件和安全開發的流程(很多回歸測試代碼)。比如微軟的SDL……你覺得SDL怎么樣?

      Brad Spengler:基于有很多公司和個人用戶使用微軟的產品,我很尊重微軟對安全的態度。Windows在大量的二進制軟件的生態系統的基礎上,去實現安全功能的同時還要保證應用程序的兼容性。這些工程的真實難度很容易被誤認為是簡單的事情。

      Linux確實需要一些集中的領導者或者組織來處理安全。Linux開發者就算知道他們在修復安全漏洞,但他們也不會通知任何人(包括廠商)。選擇性的通知廠商特定的安全問題,而不通知小的廠商和GNU/Linux發行版社區。Upstream基本上讓廠商難受,每個廠商都必須去做重復的勞動,因為沒有標準化流程。Linux內核社區官方的”a bug is just a bug”政策是在傷害所有的GNU/Linux用戶。一些很優秀的加固補丁很少被內核社區接受,因為他們過度看中安全機制造成的性能影響。

      Slo-Tech:你覺得Linux Torvalds能勝任Linux的安全工作嗎?我的意思是,他是一個優秀的開發者,但不是一個安全研究人員。那其他的著名Linux內核開發者呢?他們有相關的技能嗎?

      Brad Spengler:我不認為他能,他沒有安全思維,也無法理解安全。我不確定為什么很多人都感覺在安全問題上Linus是否參與很重要。一些開發者“理解”安全,但通常他們只修復bug。Upstream通常不關心系統加固方面的內容。

      Slo-Tech:Dave Aitel寫了一封名為“需要中心平臺讓多廠商合作來改善Linux內核安全問題”的郵件到他的郵件列表。你同意他的觀點嗎?這是正確的一步嗎?你愿意為這樣的中心平臺工作嗎?

      Brad Spengler:這點上Dave是對的,但我并沒看到這種事情在發生。最重要的是Linus對安全的態度必須改變才行。只要一天他還是upstream內核的看門人,不論他的觀點對還是錯都會直接影響Linux的安全。同時,PaX Team和我只能繼續做我們一直在做的事情,改善Linux的安全只有一條路:單干。

      Slo-Tech:內核維護者悄然無聲的修復一些內核bug是真的嗎?“悄然無聲的修復”是否意味著不正確的BUG分類和低估安全風險或者其他什么的?

      Brad Spengler:是的,他們已經承認這么干過。如果你回去讀讀LWN上我的文章有一堆這樣的例子。廠商在漏洞分類的問題上也非常糟糕——所有都是DoS。我認為這個事情現在有所改善是因為他們被曝光和受到了公眾的批評。部分的問題原因是沒有統一的 bug管理造成了對于同一個bug有不同的解釋。通常不同的廠商的bug分析也不一樣,而現在有一些廠商發的安全公告并不是安全漏洞(比如NOMMU是用于嵌入式系統,由于用戶空間和內核空間沒有隔離所以根本沒有安全的設計,但至少有2個CVE是有關這種系統的BUG)。這些事情可能會促使商業公司更愿意招聘軟件開發人員而不是安全人員來完成安全有關的工作。在每天都會報無數漏洞的年代,集中處理平臺和管理流程是能減輕很多工作量的。

      Slo-Tech:這是個惡心的問題,所以你不愿意的話你可以不回答。你愿意為微軟(像Crispin Cowan)或者Red Hat工作嗎?

      Brad Spengler:在我大學的最后一年微軟曾經邀請我去面試,但我拒絕了,因為HR在弄丟了我的簡歷1年后他們才想起我,而我那時已經失去去那里工作的興趣。為Red Hat工作?我確定你知道答案的;)

      Slo-Tech:眾所周知你使用Windows Vista作為你的主要操作系統。這對于一個Linux內核安全研究者很奇怪。你為什么會這樣選擇呢?你嘗試去找過Windows的bug嗎?

      Brad Spengler:事實上我使用的是Windows 7–Cheddar Bay的視頻里應該是RC版。因為Linux對我而言只是用來測試和改進Grsecurity的。在高中和大學的時候,我曾經使用GNU/Linux作為我的主要桌面系統,但現在GNU/Linux都是在虛擬機里。以前的Linux的內核和用戶態都簡單很多。你知道那些眾所周知的配置文件,如果你修改他們,一些“智能”的進程會背著你把配置改回去,你不會因為想要不同的默認配置而一定要修改SELinux規則。那更多的是感受到GNU/Linux的自由(Shawn:個人認為Brad說的問題應該是針對RedHat/CentOS/Fedora的,至少目前來看Debian和Gentoo是享有高度的自由),而自由的缺失我認為是因為商業化造成的。而游戲是我用Windows的主要原因。如果Pidgin通知我有一個新版本更新,我只是下載一個去執行,而不需要強制的更新另外100+個包,那樣會增加系統的風險的。

      Slo-Tech:為什么你會公布漏洞利用而不是把它們賣給像iDefense、ZDI、Immunity這樣的公司……類似像本地root提權漏洞像cheddarbay、ingom0wnar、wundebar的市場價值是什么?

      Brad Spengler:我不確定他們是否關心Linux的本地提權漏洞——首先,這些漏洞已經在某些版本的Linux內核開發分支上被修復了。其次這些漏洞利用太容易編寫了。所以這些漏洞利用是用于提醒大家安全的重要性的(以前的一堆討論無法改善Linux 內核社區的看法,但那8個漏洞利用做到了)。第1個成果是幫助到了人們去理解風險的等級(有一些人聯系我說那些漏洞利用幫助他們說服了他們的老板更關注安全),因為Linux內核公開的漏洞利用并不是那么多,不是因為漏洞不存在,而是因為黑帽們都用于自己的目的了。第二個成果是讓所有主要的的 GNU/Linux廠商和發行版都把空指針引用的攻擊平面給默認防御住了,SELinux的漏洞也修復了,廠商更注重關于mmap_min_addr的問題。用戶也注意到了這個特性和開啟它的重要性(Shawn:mmap_min_addr成為今天的標準安全基線),很多人也都升級了Linux內核。這些都是好事。我想整件事情唯一的“創新”應該是Enlightenment框架了(下一個問題跟這個有關)。

      Slo-Tech:最近你發布的針對Linux內核漏洞利用的框架叫Englightenment。你是否有計劃繼續改進這個框架并且希望它成為像Metasploit一樣?

      Brad Spengler:我一直在改進這個框架因為她讓我以攻擊者的方式來思考,這會幫助我有多種思路去考慮針對特定攻擊的防御機制(我最近在Grsecurity里實現的加固就是來源于此)。我也想讓她變得盡量通用:她已經支持x86和x86_64平臺的所有2.4和2.6內核上關閉所有LSM模塊。我最近也增加了Xen特性的支持,這個特性會更恰當的讓hyppercall去修改內核代碼。我也在考慮關于 amespace/container(Shawn:就是lxc,以及后來Docker用的底層模塊),這些都在TODO list上。Enlightenment會僅僅針對Linux內核漏洞利用。

      Slo-Tech:大多數人都不把本地漏洞利用提權當成真正的威脅。我知道SuSE的Sebastian Krahmer寫過相關的觀點而我也同意他的觀點,但事實上現在已經沒有任何公開的遠程漏洞利用了(Sgrakkyu是最后一名勇士),遠程漏洞利用標準 Linux內核真的已經是不可能還是在不遠的將來會有所改變?

      Brad Spengler:遠程內核漏洞利用非常困難,特別是針對運行PaX的內核和定制過的內核。只要讀讀sgrakkyu/twiz在Phrack上的論文《Attacking the core:Kernel exploitation notes》(Shawn:發表于Phrack Issue 64,2007年)就知道所涉及的復雜性。他們都是熱衷于挑戰高難度的人,而其他大部分人會選擇更簡單的方式,比如從Web進入然后使用本地內核提權漏洞的方式。如果系統運行了最新的PaX,漏洞利用會變得極度困難,而不是更簡單。我仍然能看到現有的威脅會在可預見的未來存在下去,因為GNU/Linux 發行版都把時間浪費在了不太可能出現嚴重bug的SUID程序上,而新的內核提權漏洞幾乎每個禮拜都在曝光。還有就是Web開發人員(那些編寫的第三方代碼運行在公共的服務器上,讓遠程用戶能進入“非信任的本地用戶”)并沒有變得更聰明。

      Slo-Tech:GNU/Linux能依然被認為是安全的操作系統嗎?你覺得政府或者其他對安全性要求高的基礎架構應該使用GNU/Linux嗎?

      Brad Spengler:我希望在高安全要求的環境中有其他的系統可以使用(Shawn:經過加固的GNU/Linux或者Quebes OS/Mirage OS?)。作為建議,一個安全的操作系統可能會犯下非常不安全愚蠢的錯誤,而一個不安全的操作系統可以變得安全如果不跑任何業務的話。

      Slo-Tech:你有任何私人的0-day漏洞利用在你的硬盤上嗎;)

      Brad Spengler:有的,ext4_own.tgz,它小于1000bytes。

      感謝Brad Spengler的訪談。

      預約申請免費試聽課

      填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

      上一篇:程序員"偷懶"給軟件帶來安全隱患
      下一篇:針對HTTPS的理論攻擊正變得實用
      • 掃碼領取資料

        回復關鍵字:視頻資料

        免費領取 達內課程視頻學習資料

      • 視頻學習QQ群

        添加QQ群:1143617948

        免費領取達內課程視頻學習資料

      Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

      選擇城市和中心
      黑龍江省

      吉林省

      河北省

      湖南省

      貴州省

      云南省

      廣西省

      海南省

      高清特黄a大片,日本真人真做爰,特级做人爱C级,免费a级毛片 百度 好搜 搜狗
      <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>