> Hi,
>
> As some of you already know I'm a computer science teacher at a Dutch
> university. Currently I'm giving a course about security.
>
> For my next practical lesson I want my students todo an audit of a small
> piece of C-code. Nothing fancy really just looking for sprintf instead
> of snprintf, gets instead of fgets, etc. And formatstring vulnerabilities.
>
> Does anyone know of some (small!) piece of software in Fedora (Extras)
> that could benefit from this?
>
> And are there any other simple checks my students could do?
Checking for programs that call open(2) with O_CREAT and don't specify a
mode. It's a terribly easy thing to look for and can be an annoying bug.
As for having students do it, it has the advantage of making them do some
code analysis since not all botched open calls are security issues.
If I call open as such
open("/tmp/feh", O_CREAT);
I end with a file called /tmp/feh with nearly random permissions (bits are
sucked off the stack to set the permissions). It's possible the file could
be written as world writable (or many other permissions, I'll let you think
about the possibilities).
I should have called open like this
open("/tmp/feh", O_CREAT, 0);
Or if I don't want to change the permissions later, I can supply a non zero
mode.
It's also a fine idea to look for improper usage of temporary files. Using
mktemp(3) instead of mkstemp(3).
If I could suggest part of your class teaches responsible and sane
disclosure. A while back another CS teacher did a similar thing with a
class, and at the end of the class dumped a big email to full-disclosure
detailing the problems. Luckily none of them were that terribly critical,
but there was much scrambling since triaging 30+ issues is painful. Part
of finding and fixing security issues is communicating the fixes upstream
and deciding what to do about disclosure.
I love hearing about classes such as this, good luck :)
--
JB
--
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list
