25
SECURE PROGRAMMING Chapter 1

SECURE PROGRAMMING Chapter 1

  • Upload
    kasen

  • View
    30

  • Download
    0

Embed Size (px)

DESCRIPTION

SECURE PROGRAMMING Chapter 1. C and C++ Brief History What is the problem? Legacy code Other languages Development platforms Operating Systems Compilers Summary. Overview. What is the problem Cost? Threat? Software Security Concepts Policy Flaws Vulnerabilities Exploits - PowerPoint PPT Presentation

Citation preview

Page 1: SECURE PROGRAMMING Chapter 1

SECURE PROGRAMMING

Chapter 1

Page 2: SECURE PROGRAMMING Chapter 1

Overview

What is the problem

Cost?

Threat?

Software Security

Concepts

Policy

Flaws

Vulnerabilities

Exploits

Mitigations

C and C++

Brief History

What is the problem?

Legacy code

Other languages

Development platforms

Operating Systems

Compilers

Summary

Page 3: SECURE PROGRAMMING Chapter 1

Conficker, aka Downup, Downadup, Kido

First detected 2008

Uses software flaws and dictionary attacks

Forms a big botnet (over 1.5 million and counting)

Reached 9-15 Million in 2009 Discovered in November 2008

Exploited MS08-067, patched on October 23 2008.

Problem example/Description

Page 4: SECURE PROGRAMMING Chapter 1

Is all malware bad?

Welchia worm, aka Nachia worm exploits another Microsoft RPC service vulnerability.

Vulnerability in TFTPD.EXE, on ports 666-765, buffer overflow on port 135.

Payload:

Patch the vulnerability.

Run a series of Microsoft patches.

Try to remove W32/Lovsan.worm.a (MSBLAST.EXE

Self removes on January 1, 2004 or after 120 days of processing, whichever comes first.

Page 5: SECURE PROGRAMMING Chapter 1

Cost?

Variable per worm: Welchia: probably minimal Blaster (estimated at more than $525 million) Conficker? ?????

Page 6: SECURE PROGRAMMING Chapter 1

Cost (2)?

Difficult to gauge, due to underreporting Indirect costs are also difficult to gauge Indirect costs (loss of trust) are also difficult to

gauge. Lines are blurred. Some estimates (table 1.1)

Page 7: SECURE PROGRAMMING Chapter 1

Threat?

It is only increasing; malware is on the rise! More and more malware is appearing out there.

I have heard (forgot where) about a marked increase in the first half of this year.

Page 8: SECURE PROGRAMMING Chapter 1

Who is the threat?

Crackers/hackers Insiders Criminals Competitive Intelligence Professionals (aka

Corporate spies) Terrorists Information warriors

Page 9: SECURE PROGRAMMING Chapter 1

Software Security

Page 10: SECURE PROGRAMMING Chapter 1

Security Concepts

Page 11: SECURE PROGRAMMING Chapter 1

Security Concepts

Programmer

System Integrator

System Administrator

Network Administrator

Security Flaw

Security Analyst

Vulnerability=flaw + access + capability

Vulnerability Analyst

Security researcher

Attacker aka adversary, malicious user, hacker, cracker, etc....

Page 12: SECURE PROGRAMMING Chapter 1

Security Policy

“A set of rules and practices that specify or regulate how a system or organization provides security services to protect sensitive and critical system resources.”

RFC 2828 Internet Security Glossary [2000]

Rules and practices can be either explicit or implicit.

Explicit = documented + well known + visibly enforced

Implicit does not mean that they are less useful.

Page 13: SECURE PROGRAMMING Chapter 1

Flaws

Software defects (bugs) → security flaws

Thus, the relation between Software Engineering and Secure Programming.

However

Software Engineers are seldom concerned about attackers. They usually check for “reasonable inputs”, when attackers will try anything but...

Identifying and prioritizing security flaws is needed, which mandates expanded tools.

Page 14: SECURE PROGRAMMING Chapter 1

Vulnerabilities

“A set of conditions that allows an attacker to violate an explicit or implicit security policy.”

ISO/IEC TS 17961 (C Secure Coding Rules)

A flaw alone is not sufficient to cause a vulnerability.

However, sometimes software designers may choose to leave a product vulnerable. (Is it no longer a flaw because it is documented?)

Programs contain vulnerabilities or are vulnerable, systems/networks possess vulnerabilities.

Page 15: SECURE PROGRAMMING Chapter 1

Exploits

A technique that takes advantage of a security vulnerability to violate an explicit or implicit security policy.

Many forms:

Malware: worms, viruses, trojans.

Proof of concept

Page 16: SECURE PROGRAMMING Chapter 1

Mitigations

Methods, techniques, processes, tools, runtime libraries that can prevent or limit exploits against vulnerabilities.

Source code correction

Turning off a port or filtering traffic.

Alerting users

Preferred way:

Find and correct the actual defect.

(Cheaper?) Alternative: stop malicious inputs

Page 17: SECURE PROGRAMMING Chapter 1

C and C++

Why C/C++

Most popular languages, most legacy code, biggest amount of vulnerabilities

Page 18: SECURE PROGRAMMING Chapter 1

Brief History

● Early 1970's Creation of C based on B, which in turn was based on BCPL

● 1966 “The Development of the C Language” (Dennis Ritchie)

● K&R “C Programming Language” published in 1978

● 1983 ANSI – X3J11 → 1989 ISO/IEC 9899-1990 Known as C89

● Corrected and amended 1994-95 again 99

● Descendants

● Concurrent C (Gehani 1989)● Objective-C (Fox 1991)● Thinking (1990● C++ (Stroustrup 1983-1986)

Page 19: SECURE PROGRAMMING Chapter 1

C++ Evolution

● C with Classes (before 1983)● C++ (1983-..● 1990 exceptions and templates● ISO runtime type identification, namespaces,

standard library● Most recent version is C++ 11

Page 20: SECURE PROGRAMMING Chapter 1

What is the problem with C?

● Flexible, lightweight, high level language, small footprint.

● Very little handled by the system, e.g:● Array bound checking● Checking integer overflows/truncations, ● calling functions with incorrect number of

arguments,

Page 21: SECURE PROGRAMMING Chapter 1

What is the problem with C? (2)

C design philosophy: C design charter, point 6:

a) Trust the programmer (Trust with verification?)

b) Don't prevent the programmer from doing what needs to be done

c) Keep the language small and simple

d) Provide only one way to do an operation.

e) Make it fast, even if it is not guaranteed to be portable.

Page 22: SECURE PROGRAMMING Chapter 1

What is the Problem with C? (3)

Different kinds of behaviors:● Locale specific● Unspecified behavior● Implementation defined behavior● Undefined behavior

Another problem: lack of type safety:● Lack of preservation● Lack of progress

Yet another problem: legacy code

Page 23: SECURE PROGRAMMING Chapter 1

Other languages?

Java: Not a perfect solution:

Still vulnerable to design and implementation level security flaws.

Can mix in C/C++

Legacy code??

Legacy programmers?

Other solutions: Cyclone, D

Page 24: SECURE PROGRAMMING Chapter 1

Development Platforms

For the textbook and course, emphasis will be on:

Languages: C C++

Operating Systems: Microsoft Windows, Linux, sometimes Unix/MAC

Compilers: Visual C++, GCC

Page 25: SECURE PROGRAMMING Chapter 1

Summary

● Most software vulnerabilities caused by common programming errors.

● Patches (too many)● Defective software is a fact of life; at best every

1000 LOC have 1-2 defects; since an OS has several million.... even application software has its problems. If only 1-2% is a vulnerability...

● Purpose of this course is learning to program securely.