Hey all,
As my exams are now over I will hopefully be having more free time available to put into ReactOS security. I would like to perform a security audit of the code base. I've jotted down a few thoughts and suggestions of mine below and would appreciate feedback on them.
Methodology
I hope to work on the kernel mode code first, working up through the layers up to application API level code. I feel this is the best method because, as it has been mentioned before to me on IRC / email , some functions canot check the parameters that are passed down to lower functions.
I understand the following code to run in kernel mode:
/lib/rtl/ /lib/string/ /lib/kjs/ /lib/freetype/ /lib/pseh/ /hal/ /drivers/ /subsys/win32k/ /ntoskrnl/
If you know of any more please let me know.
I was thinking of checking out an entire svn revision and updating only after I had checked an entire library. What do other people think on this?
I will predominatly be working just from the code source, but after playing around with Doxygen I have found it to be incredibly useful for quick referencing typedefs and function parameter calls.
What am I looking for?
I am only a single person, so code auditing will be a slow process at the moment. I wish to check for the following vulnerabilities:
Incorrect null termination. Buffer overflows. Premature termination. Lack of input validation. Bad calculations. Off by one / few.
Personally I feel this list of six common vulnerability types should be enough to thwart the most common of attacks, but if anyone else feels some other class of vulnerability is missing from the list please let me know. Obviously if I find any other bugs then they will be reported as well.
Reporting of errors?
How should I go about reporting the errors? I was previously told to report all occasions of the incorrect uses of the RtlAllocateHeap function under the same bug number (no 1110, some still unfixed). Is this the preferred method for my code auditing results? I would like to submit the bugs as quickly as possible, so I can keep my working tree as close to possible to head, but this may mean submitting multiple bug reports for the same problem. I think that the best option is to submit similar bugs in the same module under the same report, but open a new bug if the same vulnerability occurs in another module. Thoughts?
These are just some of my ideas that are floating around in my head at the moment. I would welcome all feedback on this matter and I think I may create a wiki page with the same information on. Again, thoughts on this would be nice as I haven't really used wiki's before.
Cheers, Martin