Security Of Open Source

Softwares
M.Shafi Tokhi

TU-Berlin 2009
 Proprietary Softwares

 Source code is closed and not available

 Can not be read ( seen) , modify and written by
public.
 Free bug corrections are pretty rare
 Supplied by commercial firms
 Cost effective
 You need to pay for the license of any software
 You need to accept the license in term of using.
 Open Source Software

 Source code is open and available under GPL

license
 Can be read (seen) , modified and written by
every one.
 Example of open source softwares: popular
Appache web srever, Sendmail the domain messaging
service program, Linux famous operating system and
a lot more.
Is Open Source Good for Security?
 View of various experts

 Smart engineers should "demand open source code for

anything related to security'' [Schneier 1999,well-known
expert on computer security and cryptography]
(preconditions for making it secure)
 open source nature of Linux provides a superior vehicle to
making security vulnerabilities easier to spot and fix,"Not
only because more people can look at it, but, more
importantly, because the model forces people to write
more clear code, and to adhere to standards. This in turn
facilitates security review” [Rijmen 2000, a developer of
the winning Advanced Encryption Standard (AES)
encryption algorithm.
 View of various experts
 John Viega's article "The Myth of Open Source Security"
also summarizes things in this way open source software
projects can be more secure than closed source projects.
However, the very things that can make open source
programs secure -- the availability of the source code, and
the fact that large numbers of users are available to look
for and fix security holes -- can also lull people into a false
sense of security.
 Some of the Experts claimed that open source is no
guarantee of security. because (1) release of code benefits
attackers more than anyone else because a lot of hostile
eyes can also look at open-source code, and that (2) a few
expert eyes are better than several random ones. He first
notes that while giving programmers access to a piece of
software doesn't guarantee they will study it carefully.
Why Closing the Source Doesn't
Halt Attacks ?
 It's been argued that a system without source
code is more secure because, since there's
less information available for an attacker, it
should be harder for an attacker to find the
vulnerabilities.
 Discussion:
What do you think? Do you agree?
Why Closing the Source Doesn't
Halt Attacks ?
 Source code is important for adding new
capabilities.
 Program attackers don't need source code to
find vulnerabilities.
 Think of “destructive and constructive'' acts in
real world.
 it takes less information to attack a program
than to modify one.
 Developers need the sour code !
 How attackers find
vulnerabilities?
 Attackers are against both open and closed
programs.
 Start knowing general security problems in
programs.
 there's no point in hiding vulnerabilities.
 Attackers use techniques for finding problems.
 Attackers Techniques

 Attackers use two kinds of techniques for

finding vulnerabilities in general:
 Dynamic Techniques
 Static Techniques
 Dynamic Techniques

 Finding problems via running the program.

 Sending problematic data to the program,
checking for response.
 No difference between close source and open
source softwares.
 No necessity for looking the code.
 Static Techniques

 Examining program's code be it source code or

machine code.
 Searching for vulnerable patterns.
 For close source searching the machine code
( assembly )
 Decompilers: tools for turning the machine code
back to the source code.
 Disassemblers (Flake [2001])
 a computer program that translates machine
language into assembly language
 Discussion

 if decompilers can create source code from

machine code, then why do developers say
they need source code instead of just machine
code?
 Continue...

 developers don't need source code to find

security problems.
 developers do need source code to make
substantial improvements to the program.
 Decompilers turn the machine code to source
code , but resulting source code is extremely
hard to modify.
 Most understanding names are lost.
 Instead of variable like general_total you get
"x123123'
 The same with method names.
 You get spatterings of assembly in the code.
 No comment and design information.
 Source code is extremely hard to modify.
 Discussion

Then why attackers use decompilers, if the code

is not understandable?
 Continue...

 Decompilers useful for finding ways to attack.

 Not for internal variable or method names.
 Source code is vital for adding functionalities
“developers say”.
 Then close source programs doesn't protect
programs very much.
 Is it good if people post warnings about
vulnerabilities and discuss them in public forums
and blogs?
 programmers won't fix vulnerabilities until they
are not widely known for users.
 The more widely vulnerabilities become known,
the more quickly they get fixed.
this is another security advantage that can not
be found in close source.
 Unknown Vulnerabilities in
programs
 Exist in the program , but unknown , can't be
exploited.
 But if founded may be exploited instead of
fixing.
 vulnerabilities are time bombs.
 Not predictable when they will be exploited.
 Vulnerability assessment
scanners
 Source code open extends vulnerability
assessment scanners
 look for vulnerabilities in configured systems
 doesn't just find vulnerabilities, but helps fix them.
 delegate and disseminate security data.
 Best scanner: Nessus, an open source scanner
[Forristal 2001].
 Discussion

Does open code grantee security?

 Hints

 Just making a program open source doesn't

suddenly make a program secure.
 People have to review the code
 More reviews cause less flaws
 No review in close source.
 Discovering Bugs and Security
Flaws
 Open source software is more heavily tested than commercial
counterparts
 A commercial software vendor might employ one, maybe two,
testers per programmer, they follow pre-written test scripts and
address a finite range of use cases.
 An open source project, however, might have tens or even
hundreds of thousands of downloaders around the world.
 Each one of the downloaders may subject the software to a
different use or operating environment.
 Any one of them can discover a bug or security flaw and submit
those reports back to the project.
 Security fixes

 Open Source projects respond with security fixes within

http://news.com.com/2100-7344-5117271.html?tag=nefd_hed
days to weeks.
 Microsoft has taken
http://www.silicon.com/software/security/0,39024655,39118331
six months to respond to a major security hole in
Windows, and has a number of known but unresolved
security issues with Windows.
 What happen when flaws are
found?
 Developers side
 A patch suggested and posted on the Internet
 Community members start writing the required
patch.
 Hard to prove bugs and security flaws in
commercial softwares, no source code is available.
 References

 http://www.networkcomputing.com/showitem.jhtml?
 http://www.dwheeler.com/secure-programs/Secure-