1 17-DefensiveProgramming

Previous: 16-Databases.html

or at least go find more existing problems…

1.1 Screencasts

1.2 Introduction

Software security is not all memory issues and buffer overflows, despite what some older textbooks may cover.

1.2.1 Extra reading

1.2.2 Software security issues

1.2.3 Software error super-categories:

  1. Insecure interaction between components
  2. Risky resource management
  3. Porous defenses 1) Component interaction

17-DefensiveProgramming/image5a.png 2) Resource management

17-DefensiveProgramming/image5b.png 3) Porous defenses


1.2.4 Quality vs. Security

To what extent are these the same?

1.2.5 Defensive programming

1.2.6 What are all the program inputs?


Neat/atypical example:

attacking deep learning vision models, model-stealing


Sometimes poisoning is better than hiding.
For example, web browsers that crawl random sites to pollute your internet history.

1.2.7 Defensive programming

1.2.8 Security by design

1.3 Program input

Handling program input safely

1.3.1 Input size

Input size and buffer overflow

1.3.2 Input interpretation

A broad problem, one example of which is the SQLi attack we covered last time. Interpretation of program input Command injection attacks

(do this in lecture)


bash injection of perl
Attack: xxx; echo attack ­success; ls -l finger*
Bash command injection attack on finger command (display user)

SQL injection
An input such as "Bobby'; drop table suppliers" results in the specified record being retrieved, followed by deletion of the entire table!
But, the safer version below uses a function to sanitize the input before building a string (sanitization function not shown).

PHP code injection
* (a) script below was not intended to be called directly.
* Rather, it is a component of a larger, multi-file program.
* The main script set the value of the $path variable to refer to the main directory containing the program, and all its code and data files.
* $path can be set maliciously
* Fix: block assignment of form field values to global variables
* Another defense is to only use constant values in include (and require) commands

Cross Site Scripting (XSS) Attacks
Do this exercise in lecture: https://www.hacksplaining.com/exercises/xss-stored

+++++++++++++++++ Cahoot-17.1 Validating input syntax Alternate encodings

A means to avoid sanitization and input-validation in the arms race.

Example in SQLi defense
attempting to exclude some characters may not work if you miss one of the encodings! Validating numerical input

1.3.3 Input fuzzing

1.3.4 Unexpected executable sources

* JavaScript on most websites can escape sand-boxing with relative ease
* Importing libraries relies on the integrity of those libraries, and their imports!
* Python pickle file reading:
* A pickle file can contain essentially any python objects.
* Pickle files can thus include malicious payloads.
* Don’t just import any random pickle you find on the internet!
* It could have harmful code in it, that would run arbitrary commands when you try to import it.
* If you really really want to handle suspect code (i.e., a pickle), opening it in a contained environment is one way to mitigate risks…

++++++++++++++++++++++ Cahoot-17.2

1.4 Safe coding

Writing safe program code

1.4.1 Correct algorithm implementation

Algorithm problem: TCP/IP exploit
* Initial sequence numbers used by many TCP/IP implementations were too predictable
* Combination of the sequence number as an identifier and authenticator of packets and the failure to make them sufficiently unpredictable enables the attack to occur.

Algorithm problem: Deep learning
* Fun example: Vulnerable to inputs optimized to be terrible for learning.

Artifactual debugging code (backdoor)
* Another variant is when the programmers deliberately include additional code in a program to help test and debug it
* Often code remains in production release of a program and could inappropriately release information
* May permit a user to bypass security checks and perform actions they would not otherwise be allowed to perform
* This vulnerability was exploited by the Morris Internet Worm

1.4.2 Binary matches algorithm?

Might you have a malicious compiler?

1.4.3 Interpretation of data values?

Correct data interpretation

1.4.4 Use of memory

1.4.5 Race conditions with shared memory

1.5 OS-program, program-program

Operating system interaction

1.5.1 Environment variables

Example (do in class)
* $ printenv lists these variables in Linux
* $ env let’s you pre-modify the environment that programs run in by passing a set of variable definitions into a command like this:
env VAR1="blahblah" command_to_run command_options

Decent tutorial:

Compiled programs are also vulnerable
* Programs can be vulnerable to $PATH variable manipulation
* Must reset to “safe” values
* If dynamically linked may be vulnerable to manipulation of LD_LIBRARY_PATH
* Used to locate suitable dynamic library
* Must either statically link privileged programs or prevent use of this variable

Mention: fixed env vulnerability in a popular program here…

In general, try not to rely on environment variables!

1.5.2 Least privilege

Principle of least privilege
* Privilege escalation:
* Exploit of flaws may give attacker greater privileges
* Least privilege:
* Run programs with least privilege needed to complete their function
* Determine appropriate user and group privileges required:
* Decide whether to grant extra user or just group privileges
* Ensure that privileged program can modify only those files and directories necessary

Admin privilege
* Programs with root/administrator privileges are a major target of attackers
* They provide highest levels of system access and control
* Are needed to manage access to protected system resources
* Often privilege is only needed at start
* Can then run as normal user
* Good design should partition complex programs in smaller modules with needed privileges
* Provides a greater degree of isolation between the components
* Reduces the consequences of a security breach in one component
* Easier to test and verify

1.5.3 System calls and standard libraries Secure file deletion

* Secure delete operations don’t make it to the disk as expected because of “efficient” OS procedures
chattr +s filetosecurelydelete
Not universally reliable thought — better off just encrypting the full disk.

1.5.4 Race conditions with system resources Preventing race conditions

Lockfile creation should happen as one event
* Rather than as a check for existence and then creation. Why?

1.5.5 Temporary files

Safe temporary files

stat /tmp
ll /tmp

1.5.6 Other programs

Interaction with other programs

1.6 Program output

Handling program output safely

Next: 18-Authentication.html