1. Secure Programming Lai Zit Seng November 2012

2. A Simple Program int main() { char name[100]; printf("What is your name?\n"); gets(name); printf("Hello, "); printf(name); printf("!\n"); return 0; }

3. Buffer Overflow Example #include void foo (char *bar) { char c[12]; strcpy(c, bar); // no bounds checking... } int main (int argc, char **argv) { foo(argv[1]); } Source: Wikipedia

4. C Functions That Should Be Banned This is badUse this instead gets()fgets() sprintf()snprintf() strcpy()strncpy() strcat()strncat(), strlcat() printf() – needs caution

5. Race Conditions E.g.: How to create a temporary file in /tmp? – Use a static filename – Dynamically generate a filename – Check, then create the file $ ls –l /tmp total 8 lrwxr-xr-x 1 lzs wheel 11 Nov 12 11:20 tmpXNg2i9 -> /etc/passwd Suppose attacker knows program wants to create this file /tmp/tmpXNg2i9. What can attacker try to do?

6. Random Number Generation How do you generate random numbers? How do you seed the generator? #include main () { srand(0); printf("Num #1: %d\n", rand()); printf("Num #2: %d\n", rand()); printf("Num #3: %d\n", rand()); } Num #1: 520932930 Num #2: 28925691 Num #3: 822784415 This sequence is fixed. If the seed is known, the random sequence can be entirely pre-determined.

7. Encryption vs Encoding How do you store secrets? – E.g. if your app needs to store passwords or credentials If you encrypt secrets with a password, then where do you store that password?

8. Use Standard Libraries and Protocols Make use of whatever is already available: – Glib – D-Bus IPC – SSL/OpenSSL for secure communications Don’t reinvent the wheel

9. Security by Obscurity Although in some circumstances it can be adopted as part of a defense-in-depth strategy Security through minority Don’t count on the unlikely

10. Principles Least privilege Economy of mechanism/Simplicity Open design Complete mediation Fail-safe defaults Least common mechanisms Separation of privilege Psychological acceptability/Easy to use Source: The Protection of Information in Computer Systems (http://www.cs.virginia.edu/~evans/cs551/saltzer/)http://www.cs.virginia.edu/~evans/cs551/saltzer/

11. Secure by Design Security needs to be designed from the start

13. Borrowing from Perl’s Taint Mode You may not use data derived from outside your program to affect something else outside your program – at least, not by accident. $arg = shift; # $arg is tainted $hid = $arg, 'bar'; # $hid is also tainted $line = <>; # Tainted $line = ; # Also tainted open FOO, "/home/me/bar" or die $!; $line = ; # Still tainted $path = $ENV{'PATH'}; # Tainted, but see below $data = 'abc'; # Not tainted system "echo $arg”; # Insecure http://perldoc.perl.org/perlsec.html

14. 2. Avoid buffer overflow 3. Program internals/Design approach 6. Language-specific issues 7. Special topics 2. Avoid buffer overflow 3. Program internals/Design approach 6. Language-specific issues 7. Special topics 1. Validate all input 5. Send info back judiciously 4. Carefully call out to other resources Source: http://www.dwheeler.com/secure-programs/secure-programming.pdfhttp://www.dwheeler.com/secure-programs/secure-programming.pdf A Program

15. Multi Facets of Information Security Access control Telecommunications & network security Software development security Cryptography Information security governance & risk management Security architecture & design Business continuity & disaster recovery Operation s security Physical security Legal, regulations, investigations & compliance

16. Resources https://www.securecoding.cert.org/confluence/disp lay/seccode/CERT+C+Secure+Coding+Standard http://www.tldp.org/HOWTO/Secure-Programs- HOWTO/index.html

17. What’s more dangerous than knowing nothing, is knowing something…

18. Questions? Lai Zit Seng http://www.facebook.com/zitseng