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
Submission instructions:
To be submitted electronically via Blackboard.
You must:
• 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.
Plagiarism:
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 must:
• 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.
Referencing
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.
Document Style
• 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.
Length: Unspecified.
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
Server.c:
185 - 189 Classic Buffer
Overflow (CWE-
120: Buffer
Copy without Checking Size of Input) Replace lines 185-189 with: void set_nick(int sock, char nick[])
{
int size = (strlen(nick) + 1); char*nick_packet = (char *)malloc(size); if (nick_packet){
sprintf(nick_packet, size, -NICK %s -, nick); send(sock, nick_packet, strlen(nick_packet), 0); free(nick_packet);
}
}