Case Study: Safe programming issues
Related outcomes from the unit outline:
1. Analyse software for common security programming errors and be able to correct those errors
2. Analyse the existence of vulnerabilities inherent in insecure software products
3. Assure quality by using elements of a secure framework
4. Judge the effectiveness of mitigation strategies for security vulnerabilities
Marks allocation: Worth 35% of the total mark for this unit
Due date: 22nd of May at 5:00pm WST
To be submitted electronically via Blackboard.
• Provide a zip file containing your assignment as a Word document. No other compression formats
accepted. No other document formats accepted.
• Include digital copies (in the zip file) of all non-web based references you cite in your assignment
(excluding the textbook) otherwise your assignment will not be accepted or assessed. Examples of digital
content are: book chapters, journal articles and conference proceedings.
• Provide the MD5 hash value of your assignment (Word) document (separately, not embedded in the zip
file). Submissions without a hash value will not be accepted or assessed.
4/9/2020 54505 – Case Study: Safe programming issuesRelated outcomes from
Please ensure that you have read and understood the information on academic integrity provided by the
University. By submitting the assignment you are confirming sole ownership of the work and that any
material drawn from other sources has been correctly acknowledged. Further, you are certifying that this
work has not previously been submitted for assessment in any other unit or course.
Case Description: Vulnerability Detection, Analysis and Mitigation The problem space is HTTP server
and client software. You don’t need to be experienced in either the HTTP protocol or socket connections,
but if you are unfamiliar with socket programming, you may wish to browse the socket(2) man page or
look at examples of socket programming. You will be provided with some code samples to evaluate. You
• Clearly identify vulnerabilities in the code samples. Include the code samples with prefixed line numbers
as appendices to your assignment, so that you can refer to the specific area where a vulnerability exists. In
your assignment, describe the type of vulnerability (see: https://cwe.mitre.org/data/index.html for the list)
and its effect in the code. See figure 1 for an example. Instances of bad code are also to be counted as such
code may lead to a vulnerability. (10 marks)
• Describe and implement (i.e., modify the code) appropriate mitigations (20 marks)
• Ensure that your report meets expected academic standards with regard to presentation, document style
(see below) , spelling and grammar (5 marks)
Marks will be allocated for each detected vulnerability, based on the
visibility/difficulty/complexity of the vulnerability and associated mitigation. For example, an unsafe
library call which results in a well-known vulnerability would attract less marks than a de-referenced
locally-allocated variable passed back through the stack. You should ask questions on the unit discussion
board about the assignment in order to clarify ambiguities.
All sources of references must be cited (in text citation) and listed (end reference list). For details about
referencing and the required format, please refer to the ECU Referencing Guide.
• Your document must be in MS-Word format (.doc/.docx), body text 11-point Arial font, single spaced
and include page numbers.
• The document must include a title page and table of contents with page number one (1) starting after the
table of contents.
• The document must include a three-column table, captioned “Vulnerability Mitigation List” with column
labels “Line(s)”, “Vulnerability Type” and “Mitigation Code”. Use this table to specify the file/LOC for
each vulnerability you find as well as the replacement mitigating code. See Table 1 for an example.
• The title page should not be numbered but the pages between the title page and the main body of the
document should be numbered with lower case roman numerals.
• Any code should be 10 point Courier New font, single spaced.
• No executive summary or abstract required.
Marks will be deducted if you do not adhere to this style.
Server.c: Lines 185 – 189 (CWE-120, 2020)
The set_nick function uses a hard-coded local char array of fixed size (512 bytes) and then uses the
sprint() library function to format and copy the contents of the nick array into the nick_packet array. This
is a problem because: a) sprint() does not bounds check; b) the size of the target array is hard-coded; and
c) the function does not check the size of any of these inputs, thus there is the potential to cause a buffer
overflow (CWE-120, 2020). Removing the reliance on a hard-coded array by dynamically allocating the
space will mitigate this vulnerability.
Figure 1: Sample Explanatory Paragraph.
Table 1: Vulnerability Mitigation List
Line(s) Vulnerability Type Mitigation Code
Case Study: Safe programming issues