Vulnerability Assessment and Secure Coding Practices 1 Secure Coding Practices for Grid and Cloud Middleware and Services Who We
Total Page：16
File Type：pdf, Size：1020Kb
Vulnerability Assessment and Secure Coding Practices Secure Coding Practices for Who we are Grid and Cloud Middleware and Services Barton P. Miller Elisa Heymann Bart Miller Elisa Heymann Jim Kupsch Eduardo Cesar James A. Kupsch Computer Architecture and Computer Sciences Department Operating Systems Department Vamshi Basupalli Manuel Brugnoli University of Wisconsin Universitat Autònoma de Barcelona Salini Kowsalya Max Frydman [email protected] [email protected] XSEDE13 San Diego July 2013 http://www.cs.wisc.edu/mist/ This research funded in part by Department of Homeland Security grant FA8750-10-2-0030 (funded through AFRL). 2 Past funding has been provided by NATO grant CLG 983049, National Science Foundation grant OCI-0844219, the National Science Foundation under contract with San Diego Supercomputing Center, and National Science Foundation grants1 CNS-0627501 and CNS-0716460. What do we do Our experience Condor, University of Wisconsin Batch queuing workload management system • Assess Middleware: Make cloud/grid 15 vulnerabilities 600 KLOC of C and C++ SRB, SDSC software more secure Storage Resource Broker - data grid 5 vulnerabilities 280 KLOC of C •Train:We teach tutorials for users, MyProxy, NCSA Credential Management System developers, sys admins, and managers 5 vulnerabilities 25 KLOC of C glExec, Nikhef • Research: Make in-depth assessments Identity mapping service more automated and improve quality of 5 vulnerabilities 48 KLOC of C Gratia Condor Probe, FNAL and Open Science Grid automated code analysis Feeds Condor Usage into Gratia Accounting System 3 vulnerabilities 1.7 KLOC of Perl and Bash Condor Quill, University of Wisconsin http://www.cs.wisc.edu/mist/papers/VAshort.pdf DBMS Storage of Condor Operational and Historical Data 6 vulnerabilities 7.9 KLOC of C and C++ 3 4 Our experience Our experience VOMS Core INFN Wireshark, wireshark.org Virtual Organization Management System Network Protocol Analyzer 1 vulnerability 161 KLOC of Bourne Shell, C++ and C 2 vulnerabilities 2400 KLOC of C iRODS, DICE Condor Privilege Separation, Univ. of Wisconsin Data-management System Restricted Identity Switching Module 9 vulnerabilities (and counting) 285 KLOC of C and C++ 2 vulnerabilities 21 KLOC of C and C++ Google Chrome, Google VOMS Admin, INFN Web browser Web management interface to VOMS data 1 vulnerability 2396 KLOC of C and C++ 4 vulnerabilities 35 KLOC of Java and PHP CrossBroker, Universitat Autònoma de Barcelona WMS, INFN Resource Mgr for Parallel & Interactive Applications Workload Management System 4 vulnerabilities 97 KLOC of C++ in progress 728 KLOC of Bourne Shell, C++, C, Python, Java, and Perl ARGUS 1.2, HIP, INFN, NIKHEF, SWITCH gLite Authorization Service CREAM, INFN 0 vulnerabilities 42 KLOC of Java and C Computing Resource Execution And Management 5 vulnerabilities (and counting) 216 KLOC of Bourne Shell, Java, and C++ 5 6 1 Vulnerability Assessment and Secure Coding Practices Who funds us Roadmap • United States – Introduction –DHS – Handling errors –NSF – Pointers and Strings – Numeric Errors • European Commission – Race Conditions – EGI – Exceptions –EMI – Privilege, Sandboxing and Environment • Spanish Government – Injection Attacks – Web Attacks •NATO –Bad things 7 8 Discussion of the Practices Roadmap – Introduction • Description of vulnerability – Handling errors • Signs of presence in the code – Pointers and Strings • Mitigations – Numeric Errors – Race Conditions • Safer alternatives – Exceptions – Privilege, Sandboxing and Environment – Injection Attacks – Web Attacks –Bad things 26 27 Buffer Overflows http://cwe.mitre.org/top25/archive/2011/2011_cwe_sans_top25.html#Listing 1. Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') 2. Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') 3. Buffer Copy without Checking Size of Input ('Classic Buffer Pointers and Strings Overflow') 4. Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') 5. Missing Authentication for Critical Function 6. Missing Authorization 7. Use of Hard-coded Credentials 8. Missing Encryption of Sensitive Data 9. Unrestricted Upload of File with Dangerous Type 10. Reliance on Untrusted Inputs in a Security Decision 29 30 2 Vulnerability Assessment and Secure Coding Practices Why Buffer Overflows Buffer Overflows are Dangerous • Description • An overflow overwrites memory adjacent – Accessing locations of a buffer outside the boundaries to a buffer of the buffer • Common causes • This memory could be –C-style strings – Unused – Array access and pointer arithmetic in languages –Code without bounds checking – Program data that can affect operations – Off by one errors – Internal data used by the runtime system – Fixed large buffer sizes (make it big and hope) – Decoupled buffer pointer and its size • Common result is a crash • If size unknown overflows are impossible to detect • Specially crafted values can be used for an • Require synchronization between the two attack • Ok if size is implicitly known and every use knows it (hard) 31 32 Buffer Overflow of User Data Buffer Overflow Danger Signs: Affecting Flow of Control Missing Buffer Size char id[8]; int validId = 0; /* not valid */ • gets, getpass, getwd, and scanf family %s %[ ] id validId (with or … specifiers without width) \0 \0 \0 \0 – Impossible to use correctly: size comes solely from user input gets(id); /* reads "evillogin"*/ – Source of the first (1987) stack smash attack. id validId – Alternatives: evillogi110 \0 \0 \0 ‘n’ Unsafe Safer /* validId is now 110 decimal */ gets(s) fgets(s, sLen, stdin) if (IsValid(id)) validId = 1; /* not true */ if (validId) /* is true */ getcwd(s) getwd(s, sLen) {DoPrivilegedOp();} /* gets executed */ scanf("%s", s) scanf("%100s", s) 33 34 strcat, strcpy, sprintf, Buffer Overflow Danger Signs: vsprintf Difficult to Use and Truncation – Impossible for function to detect overflow • strncat(dst, src, n) • Destination buffer size not passed – n is the maximum number of chars of src to append – Difficult to use safely w/o pre-checks (trailing null also appended) – can overflow if n >=(dstSize-strlen(dst)) • Checks require destination buffer size • Length of data formatted by printf • strncpy(dst, src, n) • Difficult & error prone –Writes n chars into dst, if strlen(src)<n, it fills the other n-strlen(src) chars with 0’s • Best incorporated in a safe replacement function –If strlen(src)>=n, dst is not null terminated Proper usage: concat s1, s2 into dst If (dstSize < strlen(s1) + strlen(s2) + 1) • Truncation detection not provided {ERROR("buffer overflow");} • Deceptively insecure strcpy(dst, s1); – Feels safer but requires same careful use as strcat strcat(dst, s2); 35 36 3 Vulnerability Assessment and Secure Coding Practices Safer String Handling: C11 and ISO/IEC TR 24731 C-library functions • snprintf(buf, bufSize, fmt, …) and Extensions for the C library: vsnprintf Part 1, Bounds Checking Interface – Returns number of bytes, not including \0 that • Functions to make the C library safer would’ve been written. • Meant to easily replace existing library – Truncation detection possible calls with little or no other changes (result >= bufSize implies truncation) – Use as safer version of strcpy and strcat • Aborts on error or optionally reports error Proper usage: concat s1, s2 into dst • Very few unspecified behaviors r = snprintf(dst, dstSize, "%s%s",s1, s2); • All updated buffers require a size param If (r >= dstSize) {ERROR("truncation");} • http://www.open-std.org/jtc1/sc22/wg14 37 38 ISO/IEC 24731: string and memory functions Attacks on Code Pointers • strcpy_s strncpy_s memcpy_s • Stack Smashing is an example strcat_s strncat_s memmove_s • There are many more pointers to functions or • Like standard counterpart, except all addresses in code include an additional parameter for the – Dispatch tables for libraries length of the destination buffer – Return addresses • Run-time constraint failure if destination – Function pointers in code • If error – C++ vtables – jmp_buf – Null-terminates destination buffer, null fills – atexit buffer for mem functions – Exception handling run-time – Internal heap run-time data structures 39 42 Buffer Overflow of a User Pointer { char id[8]; int (*logFunc)(char*) = MyLogger; id logFunc Ptr to MyLogger Numeric Errors gets(id); /* reads "evilguyxPtr to system “ */ id logFunc evi l guyx Ptr to system /* equivalent to system(userMsg) */ logFunc(userMsg); 43 44 4 Vulnerability Assessment and Secure Coding Practices Integer Vulnerabilities • Description – Many programming languages allow silent loss of integer data without warning due to •Overflow • Truncation • Signed vs. unsigned representations – Code may be secure on one platform, but silently vulnerable on another, due to different underlying integer types. • General causes – Not checking for overflow – Mixing integer types of different ranges – Mixing unsigned and signed integers 45 46 Integer Danger Signs Numeric Parsing Unreported Errors • Mixing signed and unsigned integers • atoi, atol, atof, scanf family (with %u, • Converting to a smaller integer %i, %d, %x and %o specifiers) • Using a built-in type instead of the API’s – Out of range values results in unspecified typedef type behavior • However built-ins can be problematic too: – Non-numeric input returns 0 size_t is unsigned, ptrdiff_t is signed –Use strtol, strtoul, strtoll, strtoull, strtof, strtod, strtold which allow error • Assigning values to a variable of the detection correct type