Ubuntu Wiki

Dev Week -- Writing secure software -- kees -- Wed Sep 2nd, 2009

UTC

(03:05:31 PM) kees: so, if I understand correctly, discussion and questions are in #ubuntu-classroom-chat
(03:05:51 PM) kees: I'll be watching in there for stuff marked with QUESTION:  so feel free to ask away.  :)
(03:06:16 PM) kees: this session is a relatively quick overview on ways to try to keep software more secure.
(03:06:26 PM) kees: I kind of think of it as a "best-pratices" review.
(03:06:59 PM) kees: given that there is a lot of material in this area, I try to talor my topics to langauges people are familiar with.
(03:07:44 PM) kees: as a kind of "show of hands", out of HTML, JavaScript, C, C++, Perl, Python, SQL, what are people familiar with?  (just shout out on the -chat channel)
(03:07:57 PM) kees: (oh, and Ruby)
(03:08:33 PM) kees: okay, cool, looks like a pretty wide variety.  :)
(03:09:04 PM) kees: I'm adapting this overview from some slides I used to give at talk at the Oregon State University.
(03:09:20 PM) kees: you can find that here: http://outflux.net/osu/oss-security.odp
(03:09:48 PM) kees: the main thing about secure coding is to take an "offensive" attitude when testing your software.
(03:10:03 PM) kees: if you think to yourself "the user would never type _that_", then you probably want to rethink it.  :)
(03:10:59 PM) kees: I have two opposing quotes: "given enough eyeballs all bugs are shallow" - Eric Raymond, and "most people ... don't explicitly look for security bugs" - John Viega
(03:11:30 PM) kees: I think both are true -- if enough people start thinking about how their code could be abused by some bad-guy, we'll be better able to stop them.
(03:11:52 PM) kees: so, when I say "security", what do I mean?
(03:11:55 PM) kees: basically...
(03:12:19 PM) kees: I mean a bug with how the program functions that allows another person to change the behavior against the desire of the main user
(03:12:29 PM) kees: if someone can read all my cookies out of firefox, that's bad.
(03:12:38 PM) kees: if someone can become root on my server, that's bad, etc.
(03:13:07 PM) kees: so, I tend to limit this overview to stuff like gaining access, reading or writing someone else's data, causing outages, etc.
(03:13:21 PM) kees: I'll start with programming for the web.
(03:13:46 PM) kees: when handling input in CGIs, etc, it needs to be carefully handled.
(03:14:09 PM) kees: the first example of mis-handling input is "Cross Site Scripting" ("XSS").
(03:14:53 PM) kees: if someone puts <b>hi</b> in some form data, and the application returns exactly that, then the bad-guy can send arbitrary HTML
(03:15:02 PM) kees: output needs to be filtered for html entites.
(03:15:30 PM) kees: luckily, a lot of frameworks exist for doing the right thing: Catalyst (Perl), Smarty (PHP), Django (Python), Rail (Ruby).
(03:16:02 PM) kees: another issue is Cross Site Request Forgery (CSRF).
(03:16:30 PM) kees: the issue here is that HTTP was designed so that "GET" (urls) would be for reading data, and "POST" (forms) would be used for changing data.
(03:16:44 PM) kees: if back-end data changes as a result of a "GET", you may have a CSRF.
(03:16:54 PM) kees: I have a demo of this here: http://research.outflux.net/demo/csrf.html
(03:17:15 PM) kees: imdb.com lets users add "favorite" movies to their lists.
(03:17:29 PM) kees: but it operates via a URL http://imdb.com/rg/title-gold/mymovies/mymovies/list?pending&add=0113243
(03:17:52 PM) kees: so, if I put that URL on my website, and you're logged into imdb, I can make changes to your imdb account.
(03:18:09 PM) kees: so, use forms.  :)
(03:18:20 PM) kees: (or "nonces", though I won't go into that for the moment)
(03:18:34 PM) kees: another form of input validation is SQL.
(03:19:13 PM) kees: if SQL queries aren't escaped, you can end up in odd situations
(03:19:15 PM) kees: SELECT secret FROM users
(03:19:23 PM) kees: WHERE password = '$password'
(03:19:39 PM) kees: with that SQL, what happens if the supplied password is    ' OR 1=1 --
(03:19:51 PM) kees: it'll be true and will allow logging in.
(03:20:15 PM) kees: my rule of thumb is to _always_ use the SQL bindings that exist for your language, and to never attempt to manually escape strings.
(03:20:32 PM) kees: so, for perl
(03:20:34 PM) kees:     my $query = $self->{'dbh'}->prepare(
(03:20:34 PM) kees:         "SELECT secret FROM users
(03:20:34 PM) kees:          WHERE password = ?");
(03:20:35 PM) kees:     $query->execute($password);
(03:21:03 PM) kees: this lets the SQL library you're using do the escaping.  it's easier to maintain, and it's much safer in the long-run.
(03:21:37 PM) kees: some examples of SQL and XSS are seen here:  http://research.outflux.net/demo/sql-bad.cgi
(03:22:07 PM) kees: If I put: <blink>oh my eyes</blink>   in the form, it'll pass through
(03:22:42 PM) kees: if I put:   ' OR 1=1 --     in the form, I log in, etc
(03:23:08 PM) kees: http://research.outflux.net/demo/sql-better.cgi   seeks to solve these problems.
(03:23:32 PM) kees: another thing about web coding is to think about where files live
(03:23:59 PM) kees: yet another way around the sql-bad.cgi example is to just download the SQLite database it's using.
(03:24:22 PM) kees: so, either keeping files out the documentroot, or protecting them: http://research.outflux.net/demo/htaccess-better
(03:25:11 PM) kees: so, moving from web to more language agnostic stuff
(03:25:28 PM) kees: when your need to use "system()", go find a better method.
(03:25:57 PM) kees: if you're constructing a system()-like call with a string, you'll run into problems.  you always want to implement this with an array.
(03:26:06 PM) kees: python's subprocess.call() for example.
(03:26:30 PM) kees: this stops the program from being run in a shell (where arguments may be processes or split up)
(03:26:52 PM) kees: for example, http://research.outflux.net/demo/progs/system.pl
(03:26:59 PM) kees: no good: system("ls -la $ARGV[0]");
(03:27:05 PM) kees: better: system("ls","-la",$ARGV[0]);
(03:27:10 PM) kees: best: system("ls","-la","--",$ARGV[0]);
(03:27:35 PM) kees: in array context, the arguments are passed directly.  in string context, the first argument may be processed in other ways.
(03:28:15 PM) kees: handling temporary files is another area.
(03:28:37 PM) kees: static files or files based on process id, etc, shouldn't be used since they are easily guessed.
(03:28:54 PM) kees: all languages have some kind of reasonable safe temp-file-creation method.
(03:29:12 PM) kees: File::Temp in perl, tempfile in python, "mktemp" in shell, etc
(03:29:40 PM) kees: i.e. bad:  TEMPFILE="/tmp/kees.$$"
(03:29:52 PM) kees: good: TEMPFILE=$(mktemp -t kees-XXXXXX)
(03:30:11 PM) kees: examples of this as well as a pid-racer are in http://research.outflux.net/demo/progs/
(03:30:31 PM) kees: keep data that is normally encrypted out of memory.
(03:30:53 PM) kees: so things like passwords should be erased from memory (rather than just freed) once they're done being used
(03:31:19 PM) kees: example of this is http://research.outflux.net/demo/progs/readpass.c
(03:31:25 PM) kees: once the password is done being used:
(03:31:29 PM) kees:     fclose(stdin);               // drop system buffers
(03:31:29 PM) kees:     memset(password,0,PASS_LEN); // clear out password storage memory
(03:31:44 PM) kees: then you don't have to worry about leaving it in core-dump files, etc
(03:32:02 PM) kees: for encrypted communications, using SSL should actually check certificates.
(03:32:33 PM) kees: clients should use a Certificate Authority list (apt-get install ca-cerificates, and use /etc/ssl/certs)
(03:32:44 PM) kees: servers should get a certificate authority.
(03:33:14 PM) kees: the various SSL bindings will let you define a "check cert" option, which is, unfortunately, not on by default.  :(
(03:33:47 PM) kees: one item I mentioned early on as a security issue is blocking access to a service, usually through a denial of service.
(03:34:07 PM) kees: one accidental way to make a server program vulnerable to this is to use "assert()" or "abort()" in the code.
(03:34:22 PM) kees: normally, using asserts is a great habit to catch errors in client software.
(03:34:43 PM) kees: unfortunately, if an assert can be reached while you're processing network traffic, it'll take out the entire service.
(03:35:13 PM) kees: those kinds of programs should abort on if absolutely unable to continue (and should gracefully handle unexpected situations)
(03:35:57 PM) kees: switching over to C/C++ specific issues for a bit...
(03:36:37 PM) kees: one of C's weaknesses is its handling of arrays (and therefore strings).  since it doesn't have built-in boundary checking, it's up to the programmer to do it right.
(03:36:59 PM) kees: as a result, lengths of buffers should always be used when performing buffer operations.
(03:37:18 PM) kees: functions like strcpy, sprintf, gets, strcat should not be used, because they don't know how big a buffer might be
(03:37:34 PM) kees: using strncpy, snprintf, fgets, etc is much safer.
(03:37:58 PM) kees: though be careful you're measureing the right buffer.  :)
(03:38:08 PM) kees: char buf[80];
(03:38:30 PM) kees: strncpy(buf,argv[1],strlen(argv[1]))    is no good
(03:38:44 PM) kees: you need to use buf's len, not the source string.
(03:38:58 PM) kees: it's not "how much do I want to copy" but rather "how much space can I use?"
(03:39:49 PM) kees: another tiny glitch is with format strings.  printf(buffer);  should be done with  printf("%s", buffer);  otherwise, whatever is in buffer would be processes for format strings
(03:40:05 PM) kees: instead of "hello %x"  you'd get  "hello 258347dad"
(03:40:24 PM) kees: I actually have a user on my system named %x%x%n%n just so I can catch format string issues in Gnome more easily.  :)
(03:40:56 PM) kees: the last bit to go over for C in this overview is calculating memory usage.
(03:41:16 PM) kees: if you're about to allocate memory for something, where did the size come from?
(03:41:49 PM) kees: malloc(x * y)  could wrap around an "int" value and result in less than x * y being allocated.
(03:42:20 PM) kees: this one is less obvious, but the example is here: http://research.outflux.net/demo/progs/alloc.c
(03:42:43 PM) kees: malloc(5 * 15) will be safe, but what about malloc (1294967000 * 10)
(03:43:57 PM) kees: using MAX_INT to get it right helps
(03:44:21 PM) kees: (I need to get an example of _good_ math )
(03:45:00 PM) kees: so, the biggest thing to help defend against these various glitches is testing.
(03:45:10 PM) kees: try putting HTML into form data, URLs, etc
(03:45:19 PM) kees: see what kinds of files are written in /tmp
(03:45:33 PM) kees: try putting giant numbers through allocations
(03:45:40 PM) kees: put format strings as inputs
(03:46:08 PM) kees: try to think about how information is entering a program, and how that data is formulated.
(03:46:28 PM) kees: there are a lot of unit-test frameworks (python-unit, Test::More, CxxTest, check)
(03:46:34 PM) kees: give them a try.  :)
(03:47:06 PM) kees: as for projects in general, it's great if a few days during a development cycle can be dedicated to looking for security issues.
(03:47:57 PM) kees: that's about all I've got for this quick overview.  I've left some time for questions, if there are any?
(03:48:56 PM) kees: 19:48 < AntoineLeclair> QUESTION: how could the malloc thing be a security problem?
(03:49:25 PM) kees: so, the example I tried to use (http://research.outflux.net/demo/progs/alloc.c) is like a tool that processes an image
(03:49:31 PM) kees: in the example, it starts by reading the size
(03:49:35 PM) kees: then allocates space for it
(03:49:43 PM) kees: and then starts filling it in, one row at a time.
(03:50:00 PM) kees: if we ended up allocating 10 bytes where we're reading 100, we end up with a buffer overflow.
(03:50:08 PM) kees: in some situations, those can be exploitable.
(03:50:39 PM) kees: 19:50 < bas89> QUESTION: what security issues are there with streams?
(03:50:46 PM) kees: (in C++)
(03:51:27 PM) kees: I'm not aware of anything to shy away from that implementation.
(03:51:41 PM) kees: obviously, where the stream is attached (/tmp/prog.$$) should be examined
(03:52:01 PM) kees: but I haven't seen issues with streams before.  (maybe I'm missing something in how C++ handles formatting)
(03:53:08 PM) kees: as it happens, Ubuntu's compiler will try to block a lot of the more common C buffer mistakes, including stack overflows.  glibc will block heap overflows, and the kernel is set up to block execution of heap or stack memory.
(03:53:41 PM) kees: so a lot of programs that would have had security issues are just crashes instead.
(03:53:48 PM) kees: this can't really help design failures, though.
(03:55:05 PM) kees: well, that's about it, so I'll clear out of the way.  Thanks for listening, and if other questions pop to mind, feel free to catch me on freenode or via email @ubuntu.com
(03:55:53 PM) kees: 19:56 < henkjan> kees: QUESTION: wil ubuntu stay with apparmor or wil it move to Selinux?
(03:56:21 PM) kees: both are available in Ubuntu (and will remain available).  There hasn't been a good reason to leave AppArmor as a default yet, so we're sticking with that.