Lab on Buffer Overflow Exploits

1 Background Knowledge

Bash: What is the "prompt string"? How do you change it? What is the "environment"? How does one process pass it to the next? What does system("/bin/bash") do? What else can we substitute instead of "/bin/bash"? Why do exploit[34].c run system("/bin/bash") at the end of main()?
Learn gcc -ansi -pedantic -Wall flags.
Your revised src code must be properly indented. Learn to use indent -kr. You may need to do sudo apt install indent.
Understand thoroughly ../C-intricacies.html. Look over the latest C language standard.
Look up what "work journal" writing is. https://www.google.com/search?q=writing+a+journal

Objective: Understand the stack smashing buffer exploit thoroughly.
[Study Guide] Look at past exams. Several questions are based on this lab.
Even though the sentences "Interpret the results.", "Report your findings." and "Document your effort." are explicitly stated a few times below, it is implicit in all of this lab.
The C src code files from AlephOne's article are collected here: ../AlephOne/

Improve the source code of exploit4.c of AlephOne so that there are no warning messages from gcc even after using the gcc -ansi -pedantic -Wall flags. This implies replacing asm-coding of get_sp() with plain C code. Name the revised source code exploit4revised1.c. Explain in a exploit4revised1.txt file the changes you made.
Reduce the size of their exploit4.c compiled and linked binaries by at least 5% as seen by the size command when exactly the same flags are used in the compilation. Make sure no functionality is lost. E.g., do not just remove printf's. [Not easy. Do your best.] Document your effort. Name the revised source code exploit4revised2.c. Explain in a exploit4revised2.txt file the changes you made.
Thoroughly describe your changes in the above two steps, and how you verified that there was no loss of functionality.

For exploit4.c of Aleph One, give the (an?) (example) strongest assertion that is valid just above the second for-loop.
Run splint on exploit4.c of Aleph One. Revise the code of exploit4.c, and adjust the flags of splint so that all errors and warnings shown by splint are gone. Name the revised source code exploit4revised3.c. Explain in a exploit4revised3.txt file the changes you made.
Objective: Real goal of the above tasks is to study the code thoroughly.

Background: The term "A modern Linux" used below refers to a Linux installation from a distribution released in the last 12 months.
Background: There are now (201x) many preventive measures in place that the AlephOne's exploit[34] no longer works in modern Linux installations. But, you can run an older distro, such as Auditor 2008, and experience the exploit. ../Auditor/vm-setup.html describes a setup using from the same group that develops Kali Linux. This is not easy because Auditor uses IDE HDD, not SATA.
Background: modReturnAddress-acer602-20080507.html is a record of notes taken during 2008, in a pre-Kali distro named Auditor, running on an Acer TravelMate 602TER laptop.
Background: Only the above, as-was, depends on Auditor. All other tasks can be done under a modern 64-bit or 32-but distro.

[10 points] Identify the details of the modern Linux in the equipment used section of the Lab Report. Produce a (similar) record of notes of running modret.c on a modern Linux. Interpret (the differences in) the results. Can we "somehow" make testsc.c work in a modern Linux? Report your findings.
[2*5 points] See if the exploit4 works on two suid-root programs found within a modern Linux. [Most likely you will not succeed. Nevertheless, …] Report your findings. Interpret the results. [After ASLR, ROP lectures, we will try to return to this topic of "experiencing a buffer overflow exploit".]

Report on two buffer overflow exploits/ attacks within the last 24 months. Recall that there are alternate names for this exploit. The report should be technically deeper than what you may find on CNN, or https://www.cnet.com/, etc. Aim for the level at least that of typical articles of CVE.

[25 points] Take an exploit reported above. Study its CVE. Demo that the exploit works on a modern Linux.
[20 points] Improve exploit4.c to meet the latest C language standard.

Lookup the number x on the Course Home Page. Point assignments are shown in brackets. There are bonus points for a "job well done" even if you skipped the Bonus Tasks.
[10 points] You must follow the Lab Report Template. There should be a section on each of the tasks, and subsections on sub-tasks. Include a couple of lines of an answer to each (implied/ explicit) question/ discussion item. Must number it as in this document.
Use good judgement and do not make the report way longer than, say, 20 pages. Submit explanations and code that verifies your answers.
[10 points] Include a journal. By the hour.
This lab requires revisions of a few given source code files and explanations. Include these in Lx.tbz.
Submit a PDF file named exactly Report-Lx.pdf, and a tarball Lx.tbz [use tar cfjvv Lx.tbz source-files* ]. (Scripts are used to check various things – so file names should obey such "rules".)