Presentation on theme: "Detection, Prevention, and Containment: A Study of grsecurity"— Presentation transcript:

3 The Problem Bugs in software cause unexpected resultsUnexpected functionality can result from errors in design, implementation, or configurationBugs can often be wielded for malicious purposes by an attacker

4 Problems With the Current SolutionAvoid / Identify / FixCurrent state of security is a never ending rat raceEndless cycle of vulnerability discovery and fixing

5 Problems With the Current SolutionUltimate goal of today’s security – removal of software bugs through auditingSecurity utopia – greatest result, though impossible to achieve

6 Problems With the Current SolutionAuditing is expensive, slow, and requires a great deal of knowledgeAuditing provides no guarantees about the security of the softwareAuditing cannot be fully automatedEXAMPLE: format-string vulnerabilities

9 Advantages of the (Attainable) SolutionInexpensiveCan be mostly automatedWorks for known and unknown bugsAllows administrators to focus more on administration (checking logs..etc) instead of rushing for the newest patch

14 Features of grsecurityA robust ACL system with an intelligent userspace administration toolExtensive auditing capabilitiesMeasures to stop the most common methods of exploiting a system:Address space modificationRaces (specifically filesystem races, most common of which are /tmp races)Breaking a chroot(2) jail

15 Features of grsecuritySupports sysctl so that it can be included with Linux distributions and allow the user to modify the options to his/her likingNetfilter module that drops connections to unserved TCP and UDP portsMany of the same randomness features as OpenBSDAn enhanced implementation of Trusted Path Execution (TPE)

21 Prevention in grsecurityPrevention is implemented through PaX and hardening certain sections of the kernelHardened syscalls include:Chroot(2)Ptrace(2)Mmap(2)Link(2)/symlink(2)Sysctl(2)

22 Prevention in grsecurity - PaXWhat is PaX?PaX implements non-executable VM pages on architectures that do not support the non-executable bit (currently only ia-32, more to come)PaX makes use of hardware-supported non-executable bits (still to be tested, but should work for alpha, parisc, and ia-64)PaX provides full address space layout randomization (ASLR) for ELF binaries

23 Prevention in grsecurity - PaXHow does PaX accomplish this?Include/asm-<arch>/processor.h is modified to support executable and non-executable pages (if they don’t already exist)Rest of kernel is modified to use the non-executable pages, applied to ELF and a.out binaries if they carry the required PaX flags (enabled by default)

24 Prevention in grsecurity - PaXNon-executable pages are made supervisor in the TLB; executable pages are left as userIf CPU is in user mode, access to the non-executable pages causes a page-fault which PaX handlesMakes up the core logic of how PaX worksMakes PaX ineffective against kernel overflowsMmap(2) and mprotect(2) restrictions/featuresDisallows anonymous mappings with PROT_EXEC present – stops one method of arbitrary code execution (another method, mapping a file with PROT_EXEC, is handled by ACL system)

25 Prevention in grsecurity - PaXCauses mmaps (applies to libraries) to be mapped at random locations below 0x until it’s full, then above 0xCauses exploits to have to guess the library function addressMakes the address contain a NULL byte, which stops ASCII shellcode from calling a library functionKeeps non-executable pages from being mprotected to executableNo performance impact

28 Prevention in grsecurity - PaXFull ASLR can only be bypassed in the case of information leak. While there’s nothing that can be done about software vulnerabilities that allow information leaking without crashing, we’ve implemented the following features to stop local users from obtaining information about the random base addresses:Ptrace(2) restrictions in ACL systemRestricted /procFor 64-bit architectures, the randomness provided by full ASLR could be increased to 48/64/80 bits (the amount the attacker has to overcome is determined by the type of exploit)

29 Prevention in grsecurity - PaXWhat’s in it for me?No more arbitrary code executionNo more stack smashing, heap or bss overflow exploitationNo more return-to-libc exploitation(Soon) no more arbitrary execution flow redirection

33 Prevention in grsecurityRandom RPC XIDsUses same random IP ID codeUseful for preventing RPC connection hijackingRandom PIDsProperties of returned values make the function almost always return an unused PID even on heavily loaded servers

34 Prevention in grsecurityPrevents filesystem races since getpid() is sometimes used as part of a temporary filenameAdds additional randomness to programs that use getpid(2) for srandom(3) seeding

35 Prevention in grsecurityStealth netfilter moduleBased on the fact that OS fingerprinting relies greatly on the packets sent in reply to those sent to unserved TCP or UDP portsMatches unserved ports dynamically, so it can be used in shell-server environmentsSlows down blocking port-scanners

36 Prevention in grsecurityProblems with chroot(2)Easy to use it insecurelyGenerally only filesystem-related functions care if a process is chrootedEasy for a root user in chroot to break out

42 Containment in grsecurityCapability support (including inheritance)Hardened against ACL evasion and privilege leakingPtrace restriction – user can only ptrace a process if the default ACL allows writing to itGlibc environment variable handlingPerforms correct handling, not just a denied exec if LD_ is foundChecks each path in glibc environment to see if the default ACL allows writing to it; if so, deny the exec and log pathname and environment variable usedApplies executable restrictions in mmap(2), not just execve

44 Containment in grsecurityWhat’s coming for the ACL system?Redesign to become more modular and allow quicker implementation of new featuresIntelligent learning mode resulting in a least-privilege system with little or no configuration necessarySupport of fine-grained resource restrictions and something similar to nergal’s segvguardTime-based ACLsMerging of GID-based grsecurity featuresRole-Based Access Control (RBAC)

47 Performance of ACL systemCompleted 150 runs of 16 dbench processesAverage throughput with ACL system was larger than a clean kernelStandard deviation was 5MB/s, which was larger than the difference of throughputRESULT: The ACL system causes no noticeable performance hit on filesystem access

48 Performance of ACL systemResults of kernel compile benchmark:Total time with ACL system – secondsTotal time w/o ACL system – seconds.4% performance hitPerformance hit only due to execs in compiling and making – search is called twice, acl label is copied, acl label is set, checks are performed on the environment

52 Performance with PaXAthlons encounter less performance hit partially due to their 256 entry DTLB (4KB page x 256 = 1MB)PaX starts showing its performance impact when the DTLB is full and expired entries are replacedPerformance with PaX can only be determined by the size and type of memory accesses performed by an application

56 Performance with PaXA result weighted according to an actual system’s load shows that for MySQL, PaX caused an overall performance hit of 13%Since the memory access patterns of each test were different, the performance hits for each test ranged from 3% - 20%