Nắm bắt an ninh của phần mềm tự do nguồn mở một cách nghiêm túc

TakingFOSS Security Seriously

By Jack M. Germain

LinuxInsider
08/07/094:00 AM PT

Theo:http://www.linuxinsider.com/story/Taking-FOSS-Security-Seriously-67802.html

Bài được đưa lênInternet ngày: 07/08/2009

Lờingười dịch: Người ta vẫn cứ tranh cãi mãi không dứtvề việc phần mềm nguồn mở hay sở hữu độc quyềnthì an ninh hơn. Trong số vô vàn các lời giải thích, cómột cái như sau: “Một lập trình viên nguồn mở giốngnhư một nhà điêu khắc mà được thuê để tạo ra mộtbức tượng để được đặt ở giữa thành phố. Vì aicũng nhìn thấy nó, nên nó cần phải là thứ gì đó màanh hoặc chị ta có thể tự hào về nó. Quan điểm nàyvề chất lượng mã nguồn làm giảm những chỗ có thểbị tổn thương đầy tràn theo truyền thống một cáchđột ngột”. Có lẽ, điểm mấu chốt là nằm ở tínhmở nên nhiều con mắt lúc nào cũng có thể soi để làmcho phần mềm nguồn mở sáng hơn chăng?

Các lập trình viêncủa các dự án phần mềm nguồn mở cũng phải quan tâmtới an ninh như bất kỳ ai phát triển một ứng dụng sởhữu độc quyền. Tuy nhiên, bản chất tự nhiên của 2quá trình phát triển này có thể rất khác nhau ở thờigian, và tranh luận vẫn dữ dội về cái nào vốn là anninh hơn – một mã nguồn bí mật được giữ bởi mộtcông ty, hay một mã nguồn công khai mà tất cả mọi conmắt có thể thấy. Chỉ quan trọng là cách mà mỗi cộngđồng phản ứng một khi có vấn đề xảy ra.

Những người sănlùng đang chủ tâm vào với tần suất lớn hơn đối vớiviệc lập trình có lỗi mà có thể mở ra các lỗ hổngvề an ninh trong các phần mềm tự do nguồn mở (FOSS).

Báo cáo Nguồn Mở2008 và Báo cáo Thư viện Kiến trúc, được thực hiệnbởi Coverity cho Dự Án Tăng cường Nguồn mở cho An ninhKhông gian mạng của Bộ An ninh Quốc nội Mỹ, chỉ ra hơn10,000 lỗi được sửa kể từ khi dự án này được khởiđộng vào tháng 03/2006.

Báo cáo này, đượcphân phối vào tháng 07 tại OSCON 2009 (Hội nghị Nguồnmở) tập hợp, được sử dụng cùng các công cụ phântích và cấu trúc khuôn dạng như Scan Benchmark 2006. Nhữngkết quả dựa trên các phân tích của hơn 55 triệu dòngmã lệnh từ hơn 250 dự án nguồn mở mà chúng đại diệncho 14,238 phân tích dự án riêng rẽ độc lập cùng chạy.Tổng cộng tất cả, gần 10 triệu dòng mã lệnh đã đượcphân tích.

Bằng những đườngthực thi mã nguồn có thể hiểu được, các lỗi sẽđược xác định và được hạn chế bởi các lập trìnhviên nguồn mở, theo tác giả của báo cáo, David Maxwell,Nhà chiến lược Nguồn mở cho Coverity. Sự phân tích mãnguồn đã sử dụng Coverity Prevent, một công cụ phântích mã nguồn tĩnh mà nó đưa ra các mô phỏng đường,phân tích dòng chảy của dữ liệu và việc lược tỉađường lỗi.

“Đây là trách nhiệmcủa mỗi người mà làm việc trong hệ thống phần mềmđể điều tra việc thử nghiệm và các vấn đề về anninh. Mọi người với một trí tuệ của các kỹ sư muốnphân rã vấn đề an ninh. An ninh là một vấn đề vật lývề mặt bản chất tự nhiên. Bạn phải phân tích toànbộ sự việc”, Maxwell nói với LinuxInsider.

Developersof open source software projects should be just as concerned aboutsecurity as anyone developing a proprietary app. However, the natureof the two development processes can be very different at times, anddebate still rages about which is inherently more secure -- a secretcode kept by a company, or a public one that all eyes can see. Justas important is how each community reacts once a problem is spotted.

Codehunters are spotting with greater frequency defective coding thatcould open security holes in freeand open source (FOSS) software.

TheOpenSource Report 2008 and the Architecture Library Report, conductedby Coverityfor the U.S. Department Homeland Security Cybersecurity Open SourceHardening Project, shows more than 10,000 defects fixed since projectlaunch in March 2006.

Thereport, delivered in July at the OSCON 2009 (Open source Convention)gathering, used the same analysis tools and configurations as theScan Benchmark 2006. The results are based on analysis of over 55million lines of code f-rom more than 250 open source projects thatrepresent 14,238 individual project analysis runs. All totaled,nearly 10 billion lines of code were analyzed.

Byunderstanding possible code execution paths, defects are identifiedand eliminated by open source developers, according to the report'sauthor, David Maxwell, Open Source Strategist for Coverity. The codeanalysis used Coverity Prevent, a static code analysis tool thatdelivers path simulation, data flow analysis and false path pruning.

"Itis the responsibility of everyone who works in software system toinvestigate testing and security issues. People with an engineer'smindset want to break down security. Security is a physical problemby nature. You have to analyze the whole thing," Maxwell toldLinuxInsider.

Về tổng thể, nhữngngười kiểm lỗi cho mã nguồn mà tìm ra được mật độở vào 16% trong 2 năm vừa qua. Mật độ lỗi là số lượngcác lỗi cho 1,000 dòng mã lệnh. Ví dụ, một mật độlỗi 1.0 nghĩa là một lỗi trong 1,000 dòng mã lệnh. Mộtmật độ 0.5 có nghĩa là một lỗi trong 2,000 dòng mãlệnh.

Nhiều cho tơi 314 lỗiđã được tìm ra trong một cơ sở mã nguồn cụ thể.Lỗi mã nguồn y như vậy có thường xảy ra hay không sẽcó liên quan trực tiếp tới tần suất của dạng vậnhành mà mã nguồn đó chạy. Ví dụ, Sự tôn trọng Contrỏ KHÔNG (NULL Pointer Deference) đã được theo dõi trong6,448 trường hợp cho 27,95% tần suất. Một sự rò rỉtài nguyên đã xảy ra trong 5,852 lỗi cho một tần suất25,73%.

Lỗi tích cực cóliên quan tới một số phần trăm nhỏ hợp lý của cáckết quả. Hiện hành, lỗi tích cực là dưới 14%.

Việcxem xét về an ninh là khác nhau

Không có bất kỳ aicó liên quan trong việc xây dựng phần mềm cân đo đượcyếu tố an ninh với cùng mật độ. Trên thực tế, thựcsự có một loạt cách mà an ninh nghiêm túc được thừanhận, theo Maxwell.

Ví dụ, một số lãnhđạo dựa án hạn chế việc truy cập tới chỉ các nhânviên an ninh. Những người khác có một quá trình xem xétlại rộng mở. Một số dự án sử dụng những bài thửkhổng lồ về phần mềm trước khi tung nó ra, ông giảithích.

“Khi làm việc vớicác dự án nguồn mở, một số vấn đề về an ninh làmẫu tự do quản lý. Những dựa án khác lại dựa trênviệc duy trì một uy tín cộng đồng được xây dựnglên”, Maxwell nói.

Overall,code testers found that defect density d-ropped 16 percent over thepast two years. Defect density is the number of defects per 1,000lines of code. For example, a defect density of 1.0 means one defectin 1,000 lines of code. A defect density of 0.5 means one defect in2,000 lines of code.

Asmany as 314 defects were found in one particular code base. How oftenthe same code defect occurs may be directly related to the frequencyof the type of operations the code runs. For example, a NULL PointerDeference was tracked in 6,448 incidents for 27.95 percent frequency.A resource leak occurred in 5,852 defects for a frequency of 25.73percent.

Falsepositives involved a reasonably small percentage of the results.Currently, false positives are below 14 percent.

SecurityView Varied

Noteveryone involved in building software weighs security factors withthe same intensity. In fact, there is quite a variety of howseriously security is received, according to Maxwell.

Forinstance, some project leaders restrict access to security staffonly. Others have a wide-open review process. Some projects use hugetests of the software before releasing, he explained.

"Whendealing with open source projects, some security issues are handledfree-form. Others are based on maintaining a built-up communityreputation," said Maxwell.

Cáctiêu chuẩn hay thay đổi

Để phát hiện ra mãnguồn có lỗi mà có thể dẫn tới các vấn đề an ninh,những người kiểm tra mã nguồn đó phải có mục đíchtìm kiếm một vấn đề. Nhiều thứ tương tự trong anninh tồn tại với cả các sản phẩm phần mềm nguồn mởvà sở hữu độc quyền.

Các kỹ sư mà đitheo một tập hợp các tiêu chuẩn trong ngày làm việc củahọ đối với các hãng sở hữu độc quyền có thể theocùng các nguyên lý đó vào buổi tối khi phát triển cácphần mềm của riêng họ. Sự khác biệt chủ yếu phátsinh từ trường hợp người quản lý mà phải tuân theomột tập hợp mà công ty đặt ra, Maxwell nói.

“Lý thuyết 'nhiềucon mắt hơn' thường đúng. Nhiều người hơn có thểtham gia, nhưng không phải tất cả đều làm nó. Cần đủngười với một mức độ quan tâm nào đó để tìm kiếmnhững sai sót về an ninh”, Maxwell nói.

Khoá kiểm lỗi chăng?

Vấn đề về an ninhcủa phần mềm hiện diện trên cả 2 phía của côngnghiệp phần mềm – sở hữu độc quyền và nguồn mở.

Tuy nhiên, số lượngviệc kiểm thử được hoàn tất và ai làm nó có xu hướngrõ ràng hơn trong cộng đồng nguồn mở.

“[Việc kiểm lỗi]rõ ràng là sống còn, và tầm quan trọng ngày một giatăng. Những gì đã thay đổi là việc kiểm thử đượcsử dụng sẽ hầu hết là khu vực chuyên biệt của nhữngngười kiểm thử mà, theo định nghĩa, sẽ không gần gũivới mã nguồn đó. Bây giờ, các lập trình viên đượcthấy sẽ có trách nhiệm ngang nhau về an ninh và đượcmong đợi thuyết phục được sự thẩm định nghiêm khắcvề mã nguồn của họ trước khi nó có thể được đưara cho một nhóm thử nghiệm. Đó là một sự chuyển biếntiến hoá lớn cho nhiều đội phát triển, nhưng dứtkhoát là một thay đổi lành mạnh ở nơi mà an ninh trởnên là một trách nhiệm của tổ chức và không chỉ cótầm ảnh hưởng đối với đội kiểm thử”, GwynFisher, CTO của Klocwork, đã nói với LinuxInsider. Klocworkphát triển công nghệ phân tích mã nguồn tĩnh được sửdụng bởi các lập trình viên phần mềm và các tổ chứcđảm bảo chất lượng (QA).

Kiểm thử an ninh phảikhông là tiếp cận duy nhất để có được việc viếtmã nguồn tốt hơn. Trên thực tế, việc kiểm thử mãnguồn sẽ không xảy ra các kỹ thuật thiết kế tốt tậptrung vào an ninh, Dave Robert, phó chủ tịch về chiến lượccho Vyatta, lưu ý. Hãng này phát triển bộ định tuyếnnguồn mở và các sản phẩm về an ninh.

“Dễ dàng hơn đểthiết kế phần mềm an ninh hơn bằng việc sử dụng mộtphương pháp thiết kế tốt hơn so với việc phải tránhnghĩ về an ninh trước và cố tìm các vấn đề thông quakiểm thử. Có một loạt các thư viện và công vụ sửdụng thông thường mà làm dễ dàng hơn cho các lập trìnhviên để viết phần mềm an ninh từ đầu và tránh cácvấn đề cùng một lúc. Tuy nhiên, những thư viện vàcông cụ này không là tuyệt vời, và vì thế bạn vẫncần tìm kiếm các vấn đề khó thấy một khi phần mềmđã hoàn thiện, nhưng chúng phải tránh những sai lầmhiển nhiên”, Roberts nói với LinuxInsider.

FluidStandards

Inorder to spot defective code that can lead to security issues, thosechecking the code have to be intent on finding a problem. Manysimilarities in security exist with both open source and proprietarysoftware products.

Engineerswho follow one set of standards during their day jobs for proprietaryfirms might follow those same principles at night while developingtheir own software. The major difference stems f-rom the case managerwho has to follow a set company line, said Maxwell.

"The'more eyes' theory is often valid. More people can participate, butnot all do it. There needs to be enough people with a level ofinterest to look for security flaws," said Maxwell.

TestingKey?

Theissue of software security is present on both sides of the softwareindustry -- proprietary and open source. However, the amount oftesting done and who does it tends to be more manifest in the opensource community.

"[Testing's]obviously critical, and it's growing in importance. What's changed isthat testing used to be almost exclusively the domain of testers who,by definition, aren't that close to the code. Now, developers areseen to have equal responsibility for security and are expected topursue rigorous verification of their code before it's ever given toa test team. That's a big paradigm shift for many development teams,but definitely a healthy change whe-re security becomes anorganizational responsibility and not just the purview of the testteam," Gwyn Fisher, CTO of Klocwork,told LinuxInsider. Klocwork develops static code analysis technologyused by software developers and quality assurance (QA) organizations

Securitytesting should not be the sole approach to getting better codewriting. In fact, security testing should not take the place of goodsecurity-focused design techniques, noted Dave Roberts, vicepresident of strategy for Vyatta.The company develops open source router and security products.

"It'seasier to design more secure software using a better designmethodology than it is to avoid thinking about security up front andtry to find problems through testing. There are a variety oflibraries and tools in common use that make it easier for developersto write secure software f-rom the start and avoid issues altogether.The libraries and tools are not perfect, however, and so you stillneed to look for subtle problems once the software is complete, butthey do avoid the blatant gaffes," Roberts told LinuxInsider.

Nhữngquả táo đối nghịch với những quả cam chăng?

Các chuyên gia an ninhvẫn còn cãi nhau về việc liệu mã nguồn của nguồn mởhay sở hữu độc quyền là an ninh hơn. Câu trả lời phụthuộc vào một số công việc ước đoán, cũng như ướclượng về sự nóng bỏng manh màu sắc tôn giáo.

“Câu trả lời chânthành là việc không ai biết, và nếu ai đó nói bạn khácđi, họ chỉ phỏng đoán. Đã từng có một số nghiêncứu mà mong muốn đặc tả một thứ an ninh hơn thứ kia.Nhưng hầu hết những thứ đó được cung cấp bởi cácnhà cung cấp về an ninh với một nghị trình”, Fisher đãgợi ý.

Tất nhiên, an ninh làquan trọng cho cả phần mềm nguồn mở và sở hữu độcquyền. Nhưng với phần mềm sở hữu độc quyền, có thểít hơn sự kiểm soát vì mọi người có thể phải chịutrách nhiệm, Mandeep Khera, CMO cho nhà cung cấp về an ninhcho ứng dụng Web Cenzic, nói.

“Bạn cũng có thểcung cấp việc đào tạo về an ninh cho các lập trình viêncủa bạn, nhưng đối với nguồn mở, đây là một tròchơi hoang dã. Bạn phải rất cẩn thận”, Khera đã nóicho LinuxInsider.

Tuy nhiên, lý co nhiềumắt soi mã nguồn mang tầm ảnh hưởng đáng kể trong sựtranh cãi. Nguồn mở sản xuất ra nhiều phần mềm an ninhhơn so với sự phát triển sở hữu độc quyền, ChanderKant, CEO của Zmanda, nói. Zmanda là một lập trình viênphần mềm sao lưu và phục hồi nguồn mở.

“Thực tế rằng bấtkỳ vấn đề an ninh nào cũng có thể được xem bởi hàngngàn con mắt, trong thực tế, làm cho nó dễ dàng tìm mravà sửa các vấn đề về an ninh. Nếu bạn có phần mềmsở hữu độc quyền, chỉ vì chỗ có thể bị tổnthương về an ninh có thể không được nhìn thấy trong sựmở sẽ không làm cho mã nguồn an ninh hơn”, Kant đã nóivới LinuxInsider.

ApplesVs. Oranges?

Securityexperts still bicker over whether open source or proprietary code ismore secure. The answer depends on some guess work, as well as ameasure of religious fervor.

"Thehonest answer is that nobody knows, and if anybody tells youotherwise, they're just guessing. There have been some studies thatattempt to c-haracterize one being more secure than another. But mostof those are provided by security vendors with an agenda,"suggested Fisher.

Ofcourse, security is important for both open source and proprietarysoftware. But with proprietary software, there may be a little morecontrol because people can be held accountable, noted Mandeep Khera,CMO for Web application security vendor Cenzic.

"Youcan also provide security training for your developers, but for opensource, it's a wild game. You have to be extra careful," Kheratold LinuxInsider.

However,the more-eyes-on-the-code reasoning carries considerable influence inthe debate. Open source produces more secure software thanproprietary development, proffers Chander Kant, the CEO of Zmanda.Zmanda is an open source backup and recovery software developer.

"Thefact that any security issue can be seen by thousands of eyes, infact, makes it easy to find and fix security issues. If you gotproprietary software, just because the security vulnerability may notbe seen in the open doesn't make the code more secure," Kanttold LinuxInsider.

Câuhỏi sai

Việc hỏi các chuyêngia về an ninh để tranh cãi giá trị của an ninh giữa cácchủng loại có lẽ là lạc lối. Trên thực tế, Robertsnghĩ việc hỏi cái nào là an ninh hơn là câu hỏi sai,chấm hết. Một câu hỏi tốt hơn sẽ hỏi, ông nói, làcộng đồng quản lý mọi thứ như thế nào một khi mộtvấn đề được phát hiện. Trên một điểm đó bạn sẽthấy một sự khách biệt lớn giữa cộng đồng nguồnmở và các công ty sở hữu độc quyền.

“Không có lý do đểnghĩ rằng hoặc phần mềm nguồn mở hoặc phần mềm sởhữu độc quyền cái này là tốt hơn cái kia khi liên quantới quá trình phát triển cơ bản. Trong khi mọi ngườithích động vào các vấn đề về an ninh của Microsoft ởphía những thứ sở hữu độc quyền, thực tế là việccác lập trình viên có hiểu biết giống như một đườngcong của quả chuông. Các lập trình viên làm việc vềnguồn mở là không thông minh hơn, nói chung, so với cáclập trình viên của sở hữu độc quyền, và cả 2 tậphợp các lập trình viên sẽ giới thiệu những sai sót vềan ninh không được mong đợi trong các cơ sở mã nguồntương ứng”, Roberts nói.

Câuchuyện khác biệt

Tiêu chí phân biệtđầu tiên giữa các phần mềm sở hữu độc quyền vànguồn mở là cam kết của thứ sau (phần mềm nguồn mở)đối với việc tìm kiếm, việc sửa lỗi và việc thảoluận các vấn đề về an ninh với cơ sở những ngườisử dụng của mình, Roberts nói. Có một ý nghĩa rằngkhông có gì để dấu. Các vấn đề xảy ra, bạn sửachúng, bạn làm cho những người sử dụng nhận thứcđược rằng một sự sửa lỗi tồn tại, và sau đó bạnđi tiếp, ông nói. Không như thế đối với mã nguồn củasở hữu độc quyền.

“Thư y như vậykhông thể được nói về các nhà sản xuất phần mềmsở hữu độc quyền, nói chung. Trong khi các công ty sởhữu độc quyền đang thấy rằng họ phải làm tốt hơnvới các vấn đề về an ninh, thì có nhiều trường hợpchúng ta đã thấy những nơi mà các công ty này sẽ chờđợi hàng tháng trời sau một sự khai thác được họchú ý tới để phát triển và sửa lỗi đầy đủ”,ông nói.

Khác với thứ đó,chủ đề về phần mềm nào là an ninh hơn là đủ thườngxảy ra để bắt đầu một viện lý hoàn toàn nóng bỏng,Sampo Nurmentaus, giám đốc kỹ thuật tại Movial, đồng ý.Hãng này phát triển các thiết bị di động dựa trênLinux.

Với ông, tính mởcủa nguồn mở dẫn tới việc phần mềm tốt hơn và anninh hơn. Các lập trình viên nguồn mở có một quan điểmkhác hoàn toàn đối với mã nguồn của chương trình.

“Mộtlập trình viên nguồn mở giống như một nhà điêu khắcmà được thuê để tạo ra một bức tượng để đượcđặt ở giữa thành phố. Vì ai cũng nhìn thấy nó, nênnó cần phải là thứ gì đó mà anh hoặc chị ta có thểtự hào về nó. Quan điểm này về chất lượng mã nguồnlàm giảm những chỗ có thể bị tổn thương đầy tràntheo truyền thống một cách đột ngột”, Nurmentausđã nói với LinuxInsider.

WrongQuestion

Askingsecurity experts to debate the merits of security between the speciesmay be missing the point. In fact, Roberts thinks asking which one ismore secure is the wrong question, period. A better question to ask,he said, is how the community handles things once a problem isdiscovered. On that one point you see a big difference between theopen source community and proprietary companies.

"Thereis no reason to think that either open source software or proprietarysoftware is better than the other when it comes to the fundamentaldevelopment process. While everybody likes to pick on Microsoft's(Nasdaq: MSFT) security problems on the proprietary side of things,the reality is that developers have intellects that look like a bellcurve. The developers working on open source are no smarter, onaverage, than the proprietary developers, and both sets of developerswill introduce unintended security flaws into the respective codebases," said Roberts.

Tell-TaleDifference

Theprimary distinguishing criteria between proprietary and open sourcesoftware is the latter's commitment to finding, fixing and discussingsecurity issues with its user base, Roberts said. There is a sensethat there is nothing to hide. Problems happen, you fix them, youmake users aware that a fix exists, and then you move on, he said.Not so for proprietary code.

"Thesame thing can't be said of proprietary software manufacturers, onaverage. While proprietary companies are finding that they must getbetter about dealing with security issues, there are many cases wehave seen whe-re the companies will wait months after an exploit isbrought to their attention to develop and adequate fix," hesaid.

Otherthan that, the topic of which software flavor is more secure isoftentimes enough to start quite a heated argument, agreed SampoNurmentaus, technical director at Movial.The company develops Linux-based mobile devices.

Forhim, the openness of open source leads to better, more securesoftware. Open source developers have a totally different attitudetoward the program code.

"Anopen source developer is like a sculptor that is hired to cre-ate astatue to be placed the middle of the city. Since everybody will seeit, it needs to be something he or she can be proud of. This attitudetoward code quality reduces the traditional overflow vulnerabilitiesdramatically," Nurmentaus told LinuxInsider.

Dịch tài liệu: LêTrung Nghĩa

letrungnghia.foss@gmail.com