Lab: Software without Security Holes

1 Overview

ShellShock:: Refresh your hold on bash syntax and usage.
Coding Guides:: For C and C++: Part of this course. For Java: Not part of this course. Become familiar with CERT Coding Guide on C.
System Programs: mount, fusermount, sudo, su, passwd, chsh, … We expect these to be free of security holes.
Ordinary/ non-system programs/ utilities: cat, ls, date, make, and even login, bash, ash, dash, csh, zsh and other shells.
Background: Study FUSE documentation from within the kernel source tree: https://www.kernel.org/doc/Documentation/filesystems/fuse.txt,

sudo is a standard command present in all Linux distros already. In this lab, we will DIY build it. Download the source code of the latest stable release of sudo from http://www.sudo.ws/sudo/.
Install sudo apt install splint Visit https://splint.org/
Install sudo apt install valgrind Visit http://valgrind.org/

Download the source code of sudo Build it. Read the included man page, not man sudo. Check that it "works." Submit details of how you checked.
Run splint, with no flags (except for include-related), collectively on all the source code files of sudo. No need to insert its messages into the lab report.
Select three interesting messages regarding source code errors generated by splint, and explain the messages and the causes for their generation.

Holzmann's paper (see the References of ../SecSoftware) presents "Ten Rules for Writing Safety Critical Code":
1. Restrict to simple control flow constructs.
2. Give all loops a fixed upper-bound.
3. Do not use dynamic memory allocation after initialization.
4. Limit functions to no more than 60 lines of text.
5. Use minimally two assertions per function on average.
6. Declare data objects at the smallest possible level of scope.
7. Check the return value of non-void functions, and check the validity of function parameters.
8. Limit the use of the preprocessor to file inclusion and simple macros.
9. Limit the use of pointers. Use no more than two levels of dereferencing per expression.
10. Compile with all warnings enabled, and use one or more source code analyzers.
List all violations of these rules that sudo makes. Do this by manual inspection. Or, write a script.

Background: Learn about ShellShock 2014 bug in bash. Older versions of Bash can be tricked into executing arbitrary commands. Study these:
1. https://en.wikipedia.org/wiki/Shellshock_(software_bug)
2. https://www.sophos.com/hu-hu/lp/bash-shellshock.aspx
Check if bash, as is, in a modern Linux has this vulnerability. Include details of the bash version. Describe in detail how you checked. Develop a detection script.
Download a version claimed in the articles above as being vulnerable from http://ftp.gnu.org/gnu/bash/, which has older and current versions of bash. Build it. Rename the current /bin/bash as /bin/bash-orig . Install the one you built as /bin/bash. Verify that this version of bash has the vulnerability. Include details of the bash version you installed. Describe in detail how you verified. Develop a script that demonstrates.

Download from https://github.com/libfuse/libfuse. Build it, following the Installation guide. Become familiar with its files. Understand security-implications.
Check that the just built fusermount works. Describe in detail how you verified. Develop a script that demonstrates.

Understand the following rules of CERT Coding Guide on C.
1. EXP39-C. Do not access a variable through a pointer of an incompatible type
2. EXP45-C. Do not perform assignments in selection statements
Analyze, manually, the source code of fusermount.c for any violations of the above rules. Discover and explain at least two violations.

You must follow the Lab Report Template. There should be a section on each of the tasks. A couple of lines of an answer to each (implied/ explicit) question/ discussion item.
Submit a PDF file named exactly Report-L3.pdf. (Scripts are used to check various things – so file names should obey such "rules".)