I can't think of any sort of C-program crash that would result in the source program being dumped to stdout or stderr, which would be required if it were to show up in the CodeRunner result table. However, if it did happen, you should be able to see it in the student's submission history for that question. Have you checked all the student's submissions?
More generally, yes there is a vulnerability there. A student could enter code to open the working directory and list its contents. Then, once they'd figured out how it all worked, they could dump the main program to stdout, and find all the tests, including the hidden ones (subject to a few conditions - see below). BUT, everything a student does in this way has to be done through CodeRunner, and all their submissions are recorded and available for you to inspect. So it's a dangerous strategy for a student to try. Also, they still have to be able to figure out what the expected output is from each test, since that's not present in the program (except with template graders).
In our in-house Python custom question type we've got some extra protection against these sorts of things, e.g. by replacing the open function with one that disallows access to the CodeRunner system files. That's much harder to do in C, though you could if you were keen enough add your own C function library, to be searched by the linker before the system one, with a restricted implementation of open.
Another way to prevent students cheating in that way would be to add some dummy text to one of the test's stdin fields. If CodeRunner discovers any of the tests have stdin, it switches to doing a separate Jobe run for each test case, rather than wrapping them all into a single run. [It has to do that, at least with the built-in question types, because a new stdin needs to be set up for each test.] Any attempt by a student to dump files to stdout would then not expose the tests for hidden test cases.
Other strategies are to inspect the student's code before compiling and running it, looking for certain regular expressions that you might disallow, such as "open *\(". This is most easily done by a Python preprocess, e.g. by adapting the "
c_via_python" question type. This is inelegant and might give false positives, but it's easier than rewriting library modules.
Yet another ploy (again using c_via_python or equivalent) would be to delete the source file after compiling and before running. That might break some types of questions, such as questions using valgrind to check students' submissions for memory leaks.
