Designing and Writing Secure Application Code Outline General

Total Page:16

File Type:pdf, Size:1020Kb

Designing and Writing Secure Application Code Outline General Outline Designing and Writing General principles Secure Application Code • Least privilege, defense in depth, … Example • Sendmail vs qmail John Mitchell Tools for secure coding • Type-safe programming languages • Purify • Perl tainting • Code analysis algorithms • Run-time monitoring (another lecture) General topics in this course Before you start building … Vulnerabilities What are the security requirements? • How hackers break into systems • Confidentiality (secrets remain secret) – Circumvent security mechanisms (e.g., dictionary attack) • Integrity (meaning preserved) – Use code for purpose it was not intended (buffer overflow) • Availability Defensive programming • Accountability • Build all software with security in mind This What threats are possible? • Make sure video game is not a boot loader lecture Who do you trust / not trust? Security Mechanisms • Authentication • Access control Security = preserve properties against attack • Network protocols General advice Compartmentalization Compartmentalization Divide system into modules • Principle of least privilege • Each module serves a specific purpose • Minimize trust relationships • Assign different access rights to different modules Defense in depth – Read/write access to files • Use more than one security mechanism – Read user or network input • Secure the weakest link – Execute privileged instructions (e.g., Unix root) • Fail securely Principle of least privilege Keep it simple • Give each module only the rights it needs Consult experts • Don’t build what you can easily borrow/steal • Open review is effective and informative 1 Compartmentalization (II) Example: .NET Example class NativeMethods { • Sendmail runs as root // This is a call to unmanaged code. Executing this method requires – Root privilege needed to bind port 25 // the UnmanagedCode security permission. Without this permission, – No longer needed after port bind established // an attempt to call this method will throw a SecurityException: • But most systems keep running as root [DllImport("msvcrt.dll")] – Root privileges needed later to write to user mailboxes public static extern int puts(string str); • Will look at qmail for better security design [DllImport("msvcrt.dll")] Minimize trust relationships internal static extern int _flushall(); • Clients, servers should not trust each other } – Both can get hacked • Trusted code should not call untrusted code Code denies permission not needed Defense in Depth [SecurityPermission(SecurityAction.Deny, Flags = Failure is unavoidable – plan for it SecurityPermissionFlag.UnmanagedCode)] Have a series of defenses private static void MethodToDoSomething() • If an error or attack is not caught by one { try mechanism, it should be caught by another { Console.WriteLine(“ … "); Examples SomeOtherClass.method(); • Firewall + network intrusion detection } • SSH + Tripwire catch (SecurityException) Fail securely { • Many, many vulnerabilities are related to error … handling, debugging or testing features, error } messages } Secure the weakest link Keep It Simple Think about possible attacks Use standard, tested components • How would someone try to attack this? • Don’t implement your own cryptography • What would they want to accomplish? Don’t add unnecessary features Find weakest link(s) • Extra functionality ⇒ more ways to attack • Crypto library is probably pretty good Use simple algorithms that are easy to verify • Is there a way to work around crypto? • A trick that may save a few instructions may – Data stored in encrypted form; where is key stored? – Make it harder to get the code right Main point – Make it harder to modify and maintain code • Do security analysis of the whole system • Spend your time where it matters 2 Promote Privacy Don’t reinvent the wheel Discard information when no longer needed Consult experts • No one can attack system to get information Allow public review Examples Use software, designs that other have used • Don’t keep log of old session keys • Delete firewall logs • Don’t run unnecessary services (fingerd) Examples Hiding sensitive information is hard • Bad use of crypto: 802.11b • Information in compiled binaries can be found • Protocols without expert review: 802.11i • Insider attacks are common • Use standard url parser, crypto library, good • Security by obscurity doesn’t work!!! random number generater, … Example: Mail Transport Agents Market share Sendmail Year Sendmail Qmail • Complicated system • Source of many vulnerabilities 1996 80% Qmail 1997 76% • Simpler system designed with security in mind 1998 63% • Gaining popularity 2000 55% 2001 47% 9% 2002 42% 17% Qmail was written by Dan Bernstein, starting 1995 $500 reward for successful attack; no one has collected Simplified Mail Transactions Stanford Sendmail Vulnerability Sent: Tuesday, March 04, 2003 1:12 PM Mail Mail To: [email protected] Mail User Mail User Transport Transport Agent Agent Subject: Stanford ITSS Security Alert: sendmail Header Agent Agent Processing Vulnerability sendmail is the most popular Mail Transfer Agent (MTA) Mail Mail program in use on the Internet, … mbox Delivery Delivery mbox Agent Agent sendmail contains an error in one of the security checks it employs on addresses in its headers, which may allow an Message composed using an MUA attacker to execute malicious code within the sendmail security context, usually root… MUA gives message to MTA for delivery • If local, the MTA gives it to the local MDA All users of sendmail should patch immediately … • If remote, transfer to another MTA 3 Example: qmail Structure of qmail Least privilege qmail-smtpd qmail-inject • Each module uses least privileges necessary • Only one setuid program qmail-queue – setuid to one of the other qmail user IDs, not root Incoming SMTP mail Other incoming mail – No setuid root binaries • Only one run as root qmail-send – Spawns the local delivery program under the UID and GID of the user being delivered to – No delivery to root qmail-rspawn qmail-lspawn – Always changes effective uid to recipient before running user-specified program Other secure coding ideas qmail-remote qmail-local Structure of qmail Structure of qmail qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue Splits mail msg into 3 files qmail-send signals • Message contents • qmail-lspawn if local • 2 copies of header, etc. • qmail-remote if remote qmail-send qmail-send Signals qmail-send qmail-rspawn qmail-lspawn qmail-rspawn qmail-lspawn qmail-remote qmail-local qmail-remote qmail-local Structure of qmail Structure of qmail qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue qmail-send qmail-send qmail-lspawn qmail-lspawn qmail-lspawn qmail-local • Spawns qmail-local • Handles alias expansion • qmail-local runs with ID of • Delivers local mail user receiving local mail • Calls qmail-queue if needed qmail-local qmail-local 4 Structure of qmail Least privilege qmail-smtpd qmail-inject qmail-smtpd qmail-inject qmail-queue qmail-queue setuid qmail-send qmail-send qmail-rspawn qmail-rspawn qmail-lspawn root qmail-remote • Delivers message to remote MTA qmail-remote qmail-remote qmail-local qmailq – user who is allowed to read/write mail queue UIDs Principles, sendmail vs qmail qmaild user Do as little as possible in setuid programs qmail-smtpd qmailq qmail-inject • Of 20 recent sendmail security holes, 11 worked qmail-queue only because the entire sendmail system is setuid setuid • Only qmail-queue is setuid – Its only function is add a new message to the queue qmail-send Do as little as possible as root qmailr qmails root • The entire sendmail system runs as root qmail-rspawn qmail-lspawn root – Operating system protection has no effect • Only qmail-start and qmail-lspawn run as root. setuid user qmailr user qmail-remote qmail-local Principles, sendmail vs qmail Keep it simple Programs and files are not addresses Parsing • sendmail treats programs and files as addresses • Limited parsing of strings – “sendmail goes through horrendous contortions trying to – Minimizes risk of security holes from configuration errors keep track of whether a local user was responsible for an address. This has proven to be an unmitigated disaster” Libraries (DJB) • Avoid standard C library, stdio • qmail programs and files are not addresses – “Write bug-free code” (DJB) – “The local delivery agent, qmail-local, can run programs Don’t repeat functionality or write to files as directed by ~user/.qmail, but it's always running as that user. Security impact: .qmail, like • One simple mechanism handles forwarding, .cshrc and .exrc and various other files, means that aliasing, and mailing lists (instead of 3) anyone who can write arbitrary files as a user can • Single delivery mode instead of a selection execute arbitrary programs as that user. That's it.” (DJB) 5 Comparison Additional general advice [Wheeler] Program Component Lines Words Chars Files qmail-1.01 16028 44331 370123 288 • Avoid buffer overflow • Secure software design sendmail-8.8.8 52830 179608 1218116 53 Validate input Respond • Language-specific problems judiciously zmailer-2.2e10 57595 205524 1423624 227 • Application-specific issues smail-3.2 62331 246140 1701112 151 Call other code exim-1.90 67778 272084 2092351 127 carefully See Wheeler’s book on web Summary from [Wheeler] Additional reading Validate all your inputs Contents • Command line inputs, environment variables, CGI inputs, … • Contemporary security • Don't just reject “bad” input, define “good” and reject all else – Need for secure systems,
Recommended publications
  • Defensive Programming Is Sometimes Referred to A
    Defensive Programming Is Sometimes Referred To A Is Muhammad cubical or giddier after all-star Clarke initiating so selflessly? Urethritic Weider dispersing else while Stefan always will his cassoulet solaces full, he decarbonise so aerobiologically. Reversed and lady-killer Neville never huts his chakra! The defensive programming is sometimes referred to defensive programming a developer to the max, the same approach can create a new and comments without affecting the demilitarization of As defensive programming are sometimes referred to discover which suggests that programs are crucial to break them? Like other codes, is then betatested in a simulated production environment. Throw argument is sometimes referred to refer to. Unexpected errors require interactive debugging to figure out what went wrong. You program is defensive programming in programs based on every type to. How rare you mind what note request is singing? Defensive Programming Assigning NULL to Dangling Pointers. Earth destroyed an Indian satellite in orbit three hundred kilometres away. Summary of defense is sometimes referred to refer to fail from inevitable bugs is! Making the software itself in a predictable manner despite unexpected inputs or user actions. Sign Up For Free! Ruby today, and States not easily agreeing on busy, and confirmed. Pseudocode is sometimes referred to refer to keep in programs stable after a program directly with errors that is often ripple back to contain it! Chapter 4 Defensive Programming NanoPDF. It is likely to internet, namely the rights, sometimes referred to. And now, it is important should be problem of their limitations and liabilities. When getting rid of other with little by the two problems in defensive programming is sometimes to a given me exactly mean that makes a debugging code avoid syntactic one.
    [Show full text]
  • Linux Administrators Security Guide LASG - 0.1.1
    Linux Administrators Security Guide LASG - 0.1.1 By Kurt Seifried ([email protected]) copyright 1999, All rights reserved. Available at: https://www.seifried.org/lasg/. This document is free for most non commercial uses, the license follows the table of contents, please read it if you have any concerns. If you have any questions email [email protected]. A mailing list is available, send an email to [email protected], with "subscribe lasg-announce" in the body (no quotes) and you will be automatically added. 1 Table of contents License Preface Forward by the author Contributing What this guide is and isn't How to determine what to secure and how to secure it Safe installation of Linux Choosing your install media It ain't over 'til... General concepts, server verses workstations, etc Physical / Boot security Physical access The computer BIOS LILO The Linux kernel Upgrading and compiling the kernel Kernel versions Administrative tools Access Telnet SSH LSH REXEC NSH Slush SSL Telnet Fsh secsh Local YaST sudo Super Remote Webmin Linuxconf COAS 2 System Files /etc/passwd /etc/shadow /etc/groups /etc/gshadow /etc/login.defs /etc/shells /etc/securetty Log files and other forms of monitoring General log security sysklogd / klogd secure-syslog next generation syslog Log monitoring logcheck colorlogs WOTS swatch Kernel logging auditd Shell logging bash Shadow passwords Cracking passwords John the ripper Crack Saltine cracker VCU PAM Software Management RPM dpkg tarballs / tgz Checking file integrity RPM dpkg PGP MD5 Automatic
    [Show full text]
  • Buffer Overflow Attack Samanvay Gupta 4Th Year 1St Semester (Computer Science Department) Visvesvaraya College of Engineering & Technology
    IOSR Journal of Computer Engineering (IOSRJCE) ISSN : 2278-0661 Volume 1, Issue 1 (May-June 2012), PP 10-23 www.iosrjournals.org Buffer Overflow Attack Samanvay Gupta 4th year 1st semester (Computer Science Department) Visvesvaraya College of Engineering & Technology Abstract -- Exploits, vulnerabilities, and buffer-overflow techniques have been used by malicious hackers and virus writers for a long time. In order to attack and get the remote root privilege, using buffer overflow and suidprogram has become the commonly used method for hackers. This paper include vast idea and information regarding the buffer overflow as history of Vulnerabilities, buffers, stack, registers, Buffer Overflow Vulnerabilities and Attacks, current buffer over flow, Shell code, Buffer Overflow Issues, the Source of the Problem, prevention/detection of Buffer Overflow attacks and Finally how to react towards Buffer Overflows. The objective of this study is to take one inside the buffer overflow attack and bridge the gap between the “descriptive account” and the “technically intensive account” Introduction Buffer overflows have been documented and understood as early as 1972[23]. In computer security and programming, a buffer overflow is an anomaly where a program, while writing data to a buffer, overruns the buffer's boundary and overwrites adjacent memory. This is a special case of violation of memory safety. Buffer overflows can be triggered by inputs that are designed to execute code, or alter the way the program operates. This may result in erratic program behavior, including memory access errors, incorrect results, a crash, or a breach of system security. Thus, they are the basis of many software vulnerabilities and can be maliciously exploited.
    [Show full text]
  • Open Source Software Used in the Product the Software in This Product Contains Parts Licensed Under Various Open Source Licenses
    Open Source Software used in the product The software in this product contains parts licensed under various Open Source licenses. Please refer to the below list for further information on the software and its respective licensing requirements and copyright notices. OS license applicable Name of the software IEEE 802.1d ethernet bridging GNU General Public License v2.0 bridge-utils version:0.9.7 or later siproxd - SIP proxy/masquerading GNU General Public License v2.0 daemon version:0.5.10 or later zlib zlib/libpng License version:1.2.3 WIDE-DHCPv6 BSD 3-clause “New” or “Revised” version:20080615 License OSIP Library LGPL V2.1 version:2.0.9 MiniUPnP Project Daemon BSD 3-clause “New” or “Revised” version:1.0-RC12 License Linux IPv6 Router Advertisement BSD 3-clause “New” or “Revised” Daemon – radvd version:1.4 License Filesystem in Userspace GPL V2.0 Version:2.8.4 Curl and Libcurl MIT License v2.0 Version: 7.21.3 Curl License wpa_supplicant GPL V2.0 Version: master-20110109 log4javascript Apache License 2.0 Version: V1.4.1 jQuery JavaScript Library MIT License v2.0 Version: 1.8.3 GPL V2.0 jQuery JavaScript Library MIT License v2.0 Version: 1.7.2 GPL V2.0 Jqueryjs MIT License v2.0 Version: 1.4.4 theWall - pc_pppoe BSD 3-clause license Version: 0.2 Endian Firewall Community GPL V2.0 Version: EFW-2.3 Struts EJB LGPL V2.1 Version: 1.3 Linux Kernel GPL V2.0 version:2.6.35 Free BSD BSD 2-clause license Version: 5.0 ssltunnel BSD 2-clause license Version: 1.16.0.3 ZMailer BSD 2-clause license Version: 2.99.57 kakaxi-project trunk-20120909-svn: Apache License 2.0 Android - platform - bootable - BSD 2-clause license bootloader – legacy 2.2_r1 Android – platform – bionic BSD 2-clause license Version: 2.3_r1 Android - platform - system - core Apache License 2.0 2.3_r1 Android – platform – external – GPL V2.0 wpa_supplicant Version: 2.2_r1 You may obtain the most recent version of the source for free by downloading it from the supplier`s website http://download- c.huawei.com/download/downloadCenter?downloadId=20841&version=35510&siteCode=worldwide .
    [Show full text]
  • Linux Administrators Security Guide LASG - 0.1.0
    Linux Administrators Security Guide LASG - 0.1.0 By Kurt Seifried ([email protected]) copyright 1999, All rights reserved. Available at: https://www.seifried.org/lasg/ This document is free for most non commercial uses, the license follows the table of contents, please read it if you have any concerns. If you have any questions email [email protected]. If you want to receive announcements of new versions of the LASG please send a blank email with the subject line “subscribe” (no quotes) to [email protected]. 1 Table of contents License Preface Forward by the author Contributing What this guide is and isn't How to determine what to secure and how to secure it Safe installation of Linux Choosing your install media It ain't over 'til... General concepts, server verses workstations, etc Physical / Boot security Physical access The computer BIOS LILO The Linux kernel Upgrading and compiling the kernel Kernel versions Administrative tools Access Telnet SSH LSH REXEC NSH Slush SSL Telnet Fsh secsh Local YaST sudo Super Remote Webmin Linuxconf COAS 2 System Files /etc/passwd /etc/shadow /etc/groups /etc/gshadow /etc/login.defs /etc/shells /etc/securetty Log files and other forms of monitoring sysklogd / klogd secure-syslog next generation syslog Log monitoring logcheck colorlogs WOTS swatch Kernel logging auditd Shell logging bash Shadow passwords Cracking passwords Jack the ripper Crack Saltine cracker VCU PAM Software Management RPM dpkg tarballs / tgz Checking file integrity RPM dpkg PGP MD5 Automatic updates RPM AutoRPM
    [Show full text]
  • An Efficient and Scalable Platform for Java Source Code Analysis Using Overlaid Graph Representations
    Received March 10, 2020, accepted April 7, 2020, date of publication April 13, 2020, date of current version April 29, 2020. Digital Object Identifier 10.1109/ACCESS.2020.2987631 An Efficient and Scalable Platform for Java Source Code Analysis Using Overlaid Graph Representations OSCAR RODRIGUEZ-PRIETO1, ALAN MYCROFT2, AND FRANCISCO ORTIN 1,3 1Department of Computer Science, University of Oviedo, 33007 Oviedo, Spain 2Department of Computer Science and Technology, University of Cambridge, Cambridge CB2 1TN, U.K. 3Department of Computer Science, Cork Institute of Technology, Cork 021, T12 P928 Ireland Corresponding author: Francisco Ortin ([email protected]) This work was supported in part by the Spanish Department of Science, Innovation and Universities under Project RTI2018-099235-B-I00. The work of Oscar Rodriguez-Prieto and Francisco Ortin was supported by the University of Oviedo through its support to official research groups under Grant GR-2011-0040. ABSTRACT Although source code programs are commonly written as textual information, they enclose syntactic and semantic information that is usually represented as graphs. This information is used for many different purposes, such as static program analysis, advanced code search, coding guideline checking, software metrics computation, and extraction of semantic and syntactic information to create predictive models. Most of the existing systems that provide these kinds of services are designed ad hoc for the particular purpose they are aimed at. For this reason, we created ProgQuery, a platform to allow users to write their own Java program analyses in a declarative fashion, using graph representations. We modify the Java compiler to compute seven syntactic and semantic representations, and store them in a Neo4j graph database.
    [Show full text]
  • Practice, Practice, Practice... Secure Programmer!
    Practice, Practice, Practice... Secure Programmer! Melissa Dark: Purdue University Stephen Belcher: National Security Agency Ida Ngambeki: Purdue University Matt Bishop: University of California Davis I. Abstract One of the major weaknesses in software today is the failure to practice defensive or secure programming. Most training programs include only a shallow introduction to secure programming, and fail to integrate and emphasize its importance throughout the curriculum. The addition of an ongoing, practical, mentored "clinic" or Secure Programming Clinic (SPC) is one way of addressing this lack without adding significantly to an already stretched curriculum. In order to properly design this clinic, it is important to identify the knowledge, skills and abilities (KSAs) needed to develop effective programmers. This paper describes the results of a Delphi Study undertaken to determine the primary knowledge areas in secure programming. II. Background The current state of software today is generally poor. The quality of the software in most systems does not support the trust placed in that software. Software security failures are common, and the effects range from inconvenience to severe problems. For example, failing to properly handle an error condition made Facebook inaccessible for a few hours [John10]; the iPhone failed to ring in the New Year in 2010 [Bilt11]; a flaw in an election system used to count votes resulted in some votes from a precinct not being counted [Zett08]; a 2010 FDA study of recalled infusion pumps reported that one of the most common reported problems was software defects [FDA10]; and scientists analyzing on-board computers that control automobiles were able to exploit software vulnerabilities to control the car without physical access [CCK+11].
    [Show full text]
  • Name Synopsis Description
    SMTPSERVER(8zm) SMTPSERVER(8zm) NAME smtpserver − zmailer SMTP server SYNOPSIS smtpserver [-46aBhigntVvw][-p port][-l SYSLOG][-l logfile][-s[ftveRSDh]] [-s strict] [-s sloppy][-I pidfile][-L maxloadaver][-M SMTPmaxsize][-P postoffice][-R router] [-C cfgfile][-Z zenvfile][-T '[1.2.3.4]'] DESCRIPTION This program implements the server side of the SMTP protocol as defined in RFC-2821, and knows about the common extensions to the protocol expected by sendmail and BSMTP clients. By default the program will kill the previous smtpserver (8zm) daemon, if any, then detach and lis- ten for SMTP connections. Incoming messages will be submitted for processing using the zmailer (3zm) interface to ZMailer. Non-trivial address checking is done asynchronously, although this behaviour can be changed by a command line option if you cannot afford to transfer data just to bounce it back. Complex routing analysis checking is done by executing the router (8zm) program in interactive mode, and executing a well-known shell function with well-known parameters for each request. Traditionally this task has needed starting router process (and some other processes) underneath each incoming SMTP session, which is not a very lightweight thing. Current version has prestarted farm of auxiliary server processes that can be used to handle com- plex things, and they can amortize e.g. router startup cost among lots of actual users making the use of routing in reception time very cheap in terms of resources. Presently system starts a master process that starts a set of auxiliary processes, and keeps inter- nal nameless rendezvous sockets for each of them.
    [Show full text]
  • The Qmail Handbook by Dave Sill ISBN:1893115402 Apress 2002 (492 Pages)
    < Free Open Study > The qmail Handbook by Dave Sill ISBN:1893115402 Apress 2002 (492 pages) This guide begins with a discussion of qmail s history, architecture and features, and then goes into a thorough investigation of the installation and configuration process. Table of Contents The qmail Handbook Introduction Ch apt - Introducing qmail er 1 Ch apt - Installing qmail er 2 Ch apt - Configuring qmail: The Basics er 3 Ch apt - Using qmail er 4 Ch apt - Managing qmail er 5 Ch apt - Troubleshooting qmail er 6 Ch apt - Configuring qmail: Advanced Options er 7 Ch apt - Controlling Junk Mail er 8 Ch apt - Managing Mailing Lists er 9 Ch apt - Serving Mailboxes er 10 Ch apt - Hosting Virtual Domain and Users er 11 Ch apt - Understanding Advanced Topics er 12 Ap pe ndi - How qmail Works x A Ap pe ndi - Related Packages x B Ap pe ndi - How Internet Mail Works x C Ap pe ndi - qmail Features x D Ap pe - Error Messages ndi x E Ap pe - Gotchas ndi x F Index List of Figures List of Tables List of Listings < Free Open Study > < Free Open Study > Back Cover • Provides thorough instruction for installing, configuring, and optimizing qmail • Includes coverage of secure networking, troubleshooting issues, and mailing list administration • Covers what system administrators want to know by concentrating on qmail issues relevant to daily operation • Includes instructions on how to filter spam before it reaches the client The qmail Handbook will guide system and mail administrators of all skill levels through installing, configuring, and maintaining the qmail server.
    [Show full text]
  • Defensive Programming
    Defensive Programming Gang Tan Penn State University Spring 2019 CMPSC 447, Software Security * Some slides adapted from those by Erik Poll and David Wheeler Defense We can take countermeasures at different points in time before we even begin programming during development when testing when code is running Next we will discuss mostly two kinds Detection and mitigation at runtime Prevention during code development • Defensive programming • Testing and program analysis will be discussed later 2 Prevention: Use Safer Programming Languages Some commonly‐used languages are not safe C, C++, Objective‐C Use a high‐level language with some built‐in safety Algol 60 proposed automatic bounds checking back in 1960 Ada, Perl, Python, Java, C#, and even Visual Basic have automatic bounds checking Ada unbounded_string: auto‐resize Some recent safer systems programming languages: Go, Rust Comes with runtime cost 3 Prevention: Use Safer Programming Languages However, even for safer languages Their implementations are in C/C++ Their libraries may be implemented in C/C++ They allow interaction with unsafe code through an FFI (Foreign Function Interface) • E.g., the Java Native Interface 4 Prevention: Code Review Manual code reviews for finding vulnerabilities Can be done by self, fellow programmers, or by an independent team with security expertise E.g., Google does intensive internal code security review before any code is publicly released 5 (Fagan) inspection Team with ~4 members, with specific roles: moderator: organization,
    [Show full text]
  • Programming by Contract Vs. Defensive Programming: a Comparison of Run-Time Performance and Complexity
    Department of Computer Science Roger Andersson Patrick Jungner Programming by Contract vs. Defensive Programming: A Comparison of Run-time Performance and Complexity Master's Thesis 2003:03 Programming by Contract vs. Defensive Programming: A Comparison of Run-time Performance and Complexity Roger Andersson Patrick Jungner c 2003 The authors and Karlstad University This thesis is submitted in partial fulfillment of the requirements for the Masters degree in Computer Science. All material in this thesis which is not my own work has been identified and no mate- rial is included for which a degree has previously been conferred. Roger Andersson Patrick Jungner Approved, June 17, 2003 Advisor: Donald F. Ross Examiner: Anna Brunnstr¨om iii Abstract We have used two known principles in todays software development scene, namely: contract based programming, advocated by Bertrand Meyer as the creator of Design by ContractTM, and Defensive Programming, described by Barbara Liskov et al. We compared two com- pilers implemented by using Programming by Contract, a contract based programming principle, and Defensive Programming. The size of each compiler is in the region of 4500 lines of code. The comparison is made by performing measurements on the code. After completion of the experiment we found no discernible difference in the size or complexity of the source code of the two compilers. We did however come to the con- clusion that contract based programming should not be used without automated support. Neither of the two principles could be said to be part of the solution for creating reliable software systems unless the programmers have the discipline to follow the ideas behind the principles.
    [Show full text]
  • Defensive Programming for Smart Home Cybersecurity
    2020 IEEE European Symposium on Security and Privacy Workshops (EuroS&PW) Defensive Programming for Smart Home Cybersecurity Maria Teresa Rossi∗, Renan Greca∗†, Ludovico Iovino∗, Giorgio Giacinto‡ and Antonia Bertolino† ∗ Gran Sasso Science Institute – L’Aquila, Italy, Email: {firstname.lastname}@gssi.it † ISTI - CNR – Pisa, Italy, Email: [email protected] ‡ University of Cagliari – Cagliari, Italy, Email: [email protected] Abstract—Cybersecurity has become a real issue in the the connected devices and systems. Indeed, along with development of smart services in the smart home domain, enhancing our quality of life, smart homes also increase which is formed by a System of Systems where several smart our risk surface, in particular concerning cybersecurity. objects are connected to each other and to the Internet. If a single constituent system within an SoS is affected However, these connections expose the devices to possible by a vulnerability, this can serve as an entry point for attackers inside or outside the network, who may exploit soft- the whole network, thus putting the entire SoS at risk ware or hardware vulnerabilities to achieve malicious goals. of being compromised. Cybersecurity vulnerabilities can To alleviate this issue, the use of defensive programming have several root causes [5], such as: software, as bugs or assertions can allow the behaviour of smart objects to be design flaws; hardware issues, such as faulty components monitored and checked for correctness. Furthermore, open or sensitivity to certain kinds of interference; unneces- source intelligence tools, such as the Shodan search engine, sarily open networking ports; inadequate authentication provide features that could be leveraged to detect potential and insufficient access management mechanisms including vulnerabilities.
    [Show full text]