SECURE SYSTEMS ENGINEERING
ERIK TEWS <E.TEWS@UTWENTEL.NL>
SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL> - - PowerPoint PPT Presentation
SECURE SYSTEMS ENGINEERING ERIK TEWS <E.TEWS@UTWENTEL.NL> HOUSEKEEPING The covert channel traces are online You get always 5 traces from the unmodified app 5 traces from Other student submissions My own implementation
ERIK TEWS <E.TEWS@UTWENTEL.NL>
▪ The covert channel traces are online ▪ You get always ▪ 5 traces from the unmodified app ▪ 5 traces from ▪ Other student submissions ▪ My own implementation
2
11.06.2018 Systems Security – Secure Systems Engineering
▪ Feel free to submit questions ▪ When you missed a lab session, you can catch up with it next week right after the lecture in Twente
3
11.06.2018 Systems Security – Secure Systems Engineering
▪ Choose a good architecture ▪ Use methods from secure programming ▪ Run everything with the least privilege possible ▪ Have permanent monitoring and updates
4
HOW TO BUILD SECURE SYSTEMS
11.06.2018 Systems Security – Secure Systems Engineering
5
11.06.2018 Systems Security – Secure Systems Engineering
6
11.06.2018 Systems Security – Secure Systems Engineering
Database Web server Application
7
11.06.2018 Systems Security – Secure Systems Engineering
Database Web server Application User accounts
8
11.06.2018 Systems Security – Secure Systems Engineering
Database Web server Application Database Web server Application Database Web server Application Common services Database
9
11.06.2018 Systems Security – Secure Systems Engineering
Robot control Web frontend Sensors and validation
▪ Split your application into individual modules/layers ▪ Put either very insecure or highly privileged stuff into modules ▪ Have a clear separation between them ▪ Have a clear way of communication between them
11.06.2018 10
Systems Security – Secure Systems Engineering
▪ For each of the modules try to drop privileges ▪ Do we need to write files? ▪ Do we need write access to the database? ▪ Should we be able to see all fields in a table?
11.06.2018 11
Systems Security – Secure Systems Engineering
▪ By default, a web application can ▪ Load all kinds of resources from everywhere ▪ Use inline JavaScript ▪ Send form data everywhere ▪ Load content from insecure sources ▪ Read all cookies for this specific host
11.06.2018 13
Systems Security – Secure Systems Engineering
▪ Content-Security-Policy: default-src 'self‘ ▪ Content-Security-Policy: default-src 'self' *.trusted.com ▪ Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com ▪ Delivered in an HTTP header
11.06.2018 14
Systems Security – Secure Systems Engineering
▪ There is a (poorly written) python app that allows you to search for US presidents ▪ Add a CSP for the app
11.06.2018 15
Systems Security – Secure Systems Engineering
▪ Limiting the attack surface can be helpful ▪ An application running on Linux has acces to the entire system ▪ Entire filesystem ▪ Bind to all network interfaces ▪ See all processes ▪ We would like to limit that
16
11.06.2018 Systems Security – Secure Systems Engineering
▪ Namespaces ▪ Network ▪ IPC ▪ Mount (filesystem) ▪ Process ID ▪ UTS (Hostname) ▪ Control group
11.06.2018 17
Systems Security – Secure Systems Engineering
▪ Try to run unshare
11.06.2018 18
Systems Security – Secure Systems Engineering
▪ Uses namespaces (as well as some other technologies) ▪ Creates isolated containers on Linux ▪ For processes running inside a container, it looks like a standalone Linux system ▪ In fact, they share a common kernel ▪ Pro ▪ Very efficient ▪ Con ▪ A kernel bug will compromise all containers
11.06.2018 19
Systems Security – Secure Systems Engineering
11.06.2018 20
Systems Security – Secure Systems Engineering
Kernel Application 1 Application 2 Application 3
11.06.2018 21
Systems Security – Secure Systems Engineering
Kernel Application 1 Application 2 Application 3 Web container Database container
11.06.2018 22
Systems Security – Secure Systems Engineering
Kernel Dom0 Management tools Application 1 App 2 Xen Hypervisor Kernel DomU App 3 Kernel DomU
11.06.2018 23
Systems Security – Secure Systems Engineering
Kernel Application 1 Kernel Guest Kernel Guest Application 2 App 3 App 4
▪ Pro ▪ A kernel bug will (hopefully) only compromise the specific VM ▪ Running different kernels is possible ▪ Some things are hard to put into containers ▪ Cons ▪ In general, this needs way more ressources
11.06.2018 24
Systems Security – Secure Systems Engineering
▪ We would still like to run apps with the least priviledge possible ▪ Reduces impact on everything in the same container/system when a single app is compromised ▪ May also reduce the attack surface against the currently running Linux kernel
11.06.2018 25
Systems Security – Secure Systems Engineering
14.05.2018
1 2
1 2 Posting messages is anonymous
The text on this slide will instruct your audience on how to post. This text will only appear once you start a free or a credit session. Please note that the text and appearance of this slide (font, size, color, etc.) cannot be changed.
audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow.
audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow.
audience's responses will appear here. Please feel free to change the font, color etc. This text disappears after starting your session and slideshow. # Messages: 0
Internet This text box will be used to describe the different message sending methods. TXT TXT The applicable explanations will be inserted after you have started a session.
▪ When you like to, get a Linux vm up and running ▪ Download the seccomp-examples.zip from canvas
▪ Interface for applications to request services by the operating systems ▪ Opening files (open) ▪ Writing to files (write) ▪ Reading from files (read) ▪ Establish network connections (socket/connect) ▪ Attach a debugger (ptrace) ▪ Allocate memory (brk) ▪ Operating system specific
#include <stdio.h> #include <stdlib.h> int main(int argc, char ** argv) { FILE * f = fopen("logs/myapp.log", "w+"); if (f == NULL) { fprintf(stderr, "Cannot open the logfile\n"); return 1; } fprintf(f, "App started!\n"); return 0; }
11.06.2018 30
Systems Security – Secure Systems Engineering
▪ Usually not used directly (libc wrapper) ▪ Arguments depend on the individual call ▪ Often an integer to specify ▪ Length ▪ Flag/Enum ▪ Resource/File handle ▪ Or a pointer to the program memory ▪ Data structure/buffer to be used by the syscall ▪ Memory to transfer results to ▪ Can be shown using strace <program>
11.06.2018 31
Systems Security – Secure Systems Engineering
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "App started!\n", 13) = 13
11.06.2018 32
Systems Security – Secure Systems Engineering
fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 write(3, "App started!\n", 13) = 13
11.06.2018 33
Systems Security – Secure Systems Engineering
Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace
▪ Linux provides 300+ syscalls ▪ Probably no application that needs all of them ▪ They can be used by adversaries who exploit a weakness in your code ▪ socket/connect to establish network connections ▪ openat/getdents/open/read to read local files ▪ execve to launch another program ▪ Seccomp helps you to prevent that
11.06.2018 35
Systems Security – Secure Systems Engineering
▪ Application compiles a filter for syscalls ▪ List of allowed syscalls ▪ Optionally with restrictions in the arguments ▪ Action to be executed for forbidden syscalls ▪ Usually terminate the application immediately ▪ Alternatively a debugger can be attached ▪ The filter is transferred to the kernel space ▪ Every syscall is checked before it is executed ▪ Filters cannot be removed
11.06.2018 36
Systems Security – Secure Systems Engineering
Userspace Kernelspace Syscall handler Application Standard C library seccomp filter Call to prctl Call to prctl prctl handler Seccomp handler
Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace seccomp filter
#include <stdio.h> void calcloop() { int a,b; int matched; while(1) { matched = scanf("%d %d", &a, &b); if(matched != 2) { printf("Bye!\n"); return; } printf("%d + %d = %d\n", a, b, a+b); } } int main(int argc, char ** argv) { printf("My tiny calculator\n"); calcloop(); return 0; } 39
11.06.2018 Systems Security – Secure Systems Engineering
My tiny calculator 1 + 1 = 2 2 + 5 = 7 Bye!
40
echo -e "1 1\n2 5\n" | ./calc
11.06.2018 Systems Security – Secure Systems Engineering
… write(1, "My tiny calculator\n", 19My tiny calculator ) = 19 fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 read(0, "1 1\n2 5\n\n", 4096) = 9 write(1, "1 + 1 = 2\n", 101 + 1 = 2 ) = 10 write(1, "2 + 5 = 7\n", 102 + 5 = 7 ) = 10 read(0, "", 4096) = 0 write(1, "Bye!\n", 5Bye! ) = 5 exit_group(0) = ? +++ exited with 0 +++
41
echo -e "1 1\n2 5\n" | strace ./calc
11.06.2018 Systems Security – Secure Systems Engineering
▪ read ▪ Read from stdin ▪ write ▪ Write to stdout ▪ fstat ▪ Retrieve information about stdin and stdout ▪ exit_group ▪ Terminate
11.06.2018 42
Systems Security – Secure Systems Engineering
int setup_seccomp() { scmp_filter_ctx ctx; ctx = seccomp_init(SCMP_ACT_KILL); int calls[] = { SCMP_SYS(read), SCMP_SYS(write), SCMP_SYS(exit_group), SCMP_SYS(fstat) }; int calls_length = sizeof(calls)/sizeof(calls[0]); int i; if (ctx == NULL) { return -1; } for (i = 0; i < calls_length; i++) { if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, calls[i], 0) < 0) { seccomp_release(ctx); fprintf(stderr, "adding rule %d failed\n", i); return -1; } } if (seccomp_load(ctx) < 0) { seccomp_release(ctx); fprintf(stderr, "loading seccomp failed\n"); return -1; } return 0; }
11.06.2018 43
Systems Security – Secure Systems Engineering
Compile with: ▪ gcc –o calc-seccomp calc-seccomp.c –lseccomp
11.06.2018 44
Systems Security – Secure Systems Engineering
▪ We may also restrict the arguments of the Syscall ▪ Read only from stdin ▪ Write only to stdout ▪ Fstat only on stdin ▪ Exit_group only with return code 0
11.06.2018 45
Systems Security – Secure Systems Engineering
if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(read), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDIN_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for read\n"); return -1; }
11.06.2018 46
Systems Security – Secure Systems Engineering
if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(write), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDOUT_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for write\n"); return -1; }
11.06.2018 47
Systems Security – Secure Systems Engineering
if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(fstat), 1, SCMP_CMP(0, SCMP_CMP_EQ, STDIN_FILENO)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for fstat\n"); return -1; }
11.06.2018 48
Systems Security – Secure Systems Engineering
if (seccomp_rule_add(ctx, SCMP_ACT_ALLOW, SCMP_SYS(exit_group), 1, SCMP_CMP(0, SCMP_CMP_EQ, 0)) < 0) { seccomp_release(ctx); fprintf(stderr, "could not setup rule for exit_group\n"); return -1; }
11.06.2018 49
Systems Security – Secure Systems Engineering
11.06.2018 50
Systems Security – Secure Systems Engineering
▪ Only works on Linux ▪ You need to know which syscalls your application requires ▪ Might break with a libc upgrade ▪ Only filtering on the syscalls and their direct arguments ▪ Dereferencing of pointers not possible
11.06.2018 51
Systems Security – Secure Systems Engineering
Userspace Kernelspace Syscall handler Application Standard C library Call fprintf(…) write syscall trap into kernel space write handler Device driver Copy from userspace seccomp filter inspect Application 2
Modify memory
▪ Very handy tool to implement sandboxes ▪ Rules can be generated dynamically ▪ However syscalls used by a program depend on the exact libc version
▪ Might easily break when libraries are updated
11.06.2018 53
Systems Security – Secure Systems Engineering
▪ There is a random cat picture serving web server in the files sectin, written in (poor, ugly, unsafe) C ▪ Write a Seccomp patch for it ▪ Make sure only the currently used syscalls are allowed ▪ Rewrite the application to work with a minimal set of syscalls (Bonus) ▪ read, write, shutdown, close, exit* ▪ And add a corresponding seccomp patch
11.06.2018 54
Systems Security – Secure Systems Engineering
▪ https://www.chromium.org/developers/design-documents/sandbox
11.06.2018 55
Systems Security – Secure Systems Engineering
▪ Windows update in a nutshell ▪ Software downloads new software packages from a P2P network ▪ Packages are verified ▪ Packages are then installed ▪ They might overwrite every file on the system including the
▪ How may we use the isolation and access control features from the lecture here?
56
11.06.2018 Systems Security – Secure Systems Engineering
▪ I don't need to explain what a webbrowser does ▪ Where does a webbrowser need to write to?
11.06.2018 57
Systems Security – Secure Systems Engineering
▪ Split different functionality with different access permissions into different modules ▪ Isolate those modules in different processes ▪ Apply different security policies to those processes ▪ Have clear and simple communication paths between those processes
11.06.2018 58
Systems Security – Secure Systems Engineering
11.06.2018 59
Systems Security – Secure Systems Engineering
▪ Application to view pictures and videos on the local harddisk ▪ Easy browsing through all files in a directory ▪ How may we apply the pattern here?
11.06.2018 60
Systems Security – Secure Systems Engineering
▪ Supports chatting with friends ▪ Allows you to send and receive files
11.06.2018 61
Systems Security – Secure Systems Engineering
▪ Needs access to your webcam when you would like to have a video conference ▪ Should not have access to your webcam when you are getting dressed in your room and you feel unwatched
11.06.2018 62
Systems Security – Secure Systems Engineering
▪ Split your application into individual modules/layers ▪ Put either very insecure or highly privileged stuff into modules ▪ Have a clear separation between them ▪ Have a clear way of communication between them
11.06.2018 63
Systems Security – Secure Systems Engineering