A Look at. Open Source Security. By Ivan Ristic

Transcription

1 A Look at Open Source Security By Ivan Ristic

2 This talk is about open source, software security and the challenges of developing secure open source software; from 2 / 33 experience and a very personal perspective. 2 / 45

3 I will also discuss how to assess the security of an open source project 3 / 33 with only a modest time investment. 3 / 45

4 What do I mean by Open Source?

5 Open Source means different things to different 5 / 33 people. 5 / 45

6 Today I will assume open source refers to products whose source code is 6 / 33 freely available or products that are written by a community. Often both. 6 / 45

7 Commercial versus open source security comparisons 7 / 33 are meaningless. Generalisation does not work. 7 / 45

8 At best, you can determine which project was more 8 / 33 secure in a period of time. Maybe. 8 / 45

9 It is true, however, that open source 9 / 33 projects have a potential to be more secure. 9 / 45

10 Source code access gives you the ability to: 1) assess security, 10 / 33 2) fix problems, and 3) compile programs yourself. 10 / 45

11 It also keeps honest developers honest by making 11 / 33 it easier for others to find flaws. 11 / 45

12 Easier for others to find flaws? Doesn t 12 / 33 that help the bad guys too? 12 / 45

13 Kerckhoff s principle: A secure military system 13 / 33 must not depend on secrecy. 13 / 45

14 Open Source Security Myths

15 Myth: It is easy to plant a backdoor 15 / 33 into an open source project. 15 / 45

16 In November 2003, an attempt to create a backdoor 16 / 33 in Linux was discovered. 16 / 45

17 17 / / 33 Myth: Given enough eyeballs all bugs are shallow. 17 / 45

18 In January 2009, an OpenSSL signature verification API misuse problem 18 / 33 was reported; it was there for more than 10 years. 18 / 45

19 A line of code removed from Debian made it 19 vulnerable / 33 from September 2006 until May / 45

20 Myth: Open source developers 20 / 33 care about security (and vendors don t). 20 / 45

21 Open Source Development Challenges

22 Open source development is about one or more of these: freedom, passion, money, 22 / 33 fame and software commons. (Not necessarily in that order.) 22 / 45

23 Starting and running an open source project is a job. In fact, 23 / 33 it is like starting a business, but without the money. 23 / 45

24 24 / / 33 Most open source projects start as one-man efforts. 24 / 45

25 Producing Open Source Software: 300 pages 25 / 33 of hard work. ( 25 / 45

26 Why is software so insecure?

27 The security of a product largely depends on the people 27 / 33 who build it and the people who use it. 27 / 45

28 To build secure software you need awareness, 28 / 33 motivation, expertise and resources. 28 / 45

29 You also need secure technology, 29 / 33 but, sadly, we don t always have a choice. 29 / 45

30 30 / 33 Software is a market for lemons. 30 / 45

31 George A. Akerlof The Market for Lemons : 31 / 33 Quality Uncertainty and the Market Mechanism 31 / 45

32 [ ] the presence of people who wish to pawn bad wares as 32 / 33 good wares tends to drive out the legitimate business. 32 / 45

33 Geekonomics: The Real Cost of Insecure Software (interesting book; terrible name) 33 / / 45

34 The result? Not only is software not secure, but the adoption of 34 / 33 (more) secure programming languages and platforms is slow. 34 / 45

35 Common issues with software are in the areas of: 35 / 33 usability, safety, security and appearance. 35 / 45

36 When a security bug in djbdns was discovered, D.J. Bernstein 36 / 33 paid the researcher $1000 and apologised to his users. 36 / 45

37 What if we make software publishers 37 / 33 liable? 37 / 45

38 Self-certification, on the other hand, 38 / seems quite feasible. 33 (The Software Facts label taken from Jeff Williams s talk at AppSec Europe 2005.) 38 / 45

39 Case study: ModSecurity

40 Security issues in ModSecurity v1.1b v2.0 (rewrite) v1.4.2 v1.7 v1.8 v1.9 v2.1 v / DoS DoS (x2) Evasion Evasion Evasion Buffer overflow 40 / 45

41 Assessing Open Source Project Security

42 Project Status 1 1) Project age, release frequency and status 2) Web site & publicly available information 3) Popularity (community) - blog posts, articles, 42 / 33 talks, books, tools, add-ons, mailing list activity 4) Developer attitude / tone 5) Commercial activities 42 / 45

43 Development Practices 2 1) Size of team; skill and experience 2) Secure development methodology 3) Source code repository 43 / 33 4) Issue tracking 5) Regression testing 6) Source code quality 7) Quality of documentation 43 / 45

44 Treatment of Security 3 1) Clear security statement 2) Security page lists all known issues 3) Security address 44 / 33 4) History of security problems 5) Response times 6) Own advisories 44 / 45

45 Thank you! Download this talk from