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
I noticed that the implimentation of NdisReadConfiguration() is slightly
off, so I fixed it. The reason why this was so is located in the diff as
a comment.
Thanks.
Index: drivers/net/ndis/ndis/config.c
===================================================================
--- drivers/net/ndis/ndis/config.c (revision 20999)
+++ drivers/net/ndis/ndis/config.c (working copy)
@@ -493,8 +493,17 @@
str.Buffer = (PWCHAR)KeyInformation->Data;
(*ParameterValue)->ParameterType = ParameterType;
- *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
+
+ /*
+ If ParameterType is NdisParameterInteger then the base of str is decimal.
+ If ParameterType is NdisParameterHexInteger then the base of str is hexadecimal.
+ */
+ if (ParameterType == NdisParameterInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 10, &(*ParameterValue)->ParameterData.IntegerData);
+ else if (ParameterType == NdisParameterHexInteger)
+ *Status = RtlUnicodeStringToInteger(&str, 16, &(*ParameterValue)->ParameterData.IntegerData);
ExFreePool(KeyInformation);
if(*Status != STATUS_SUCCESS)
Hi folks,
> Delete libjpeg because sedwards and greatlord thought we should wait
with jpeg support until the patent expired. If someone got a different
opinion please take the issue to ros-dev.
>
>
> Deleted files:
> vendor/libjpeg/
I hereby "take the issue to ros-dev", because I have a different
opinion. ReactOS is filled with patented (to more and lesser extent,
ranging from SEH to scrollbars, I kid you not) features, and I believe
it is hypocritical to simply remove one of them. I don't know the
details on the libjpeg patent, but I do know that linux distributions
use libjpeg as well, and I haven't seen them remove it yet. I officially
request a vote to revert this commit.
Thanks for reading,
mf.
Does this mean the ROS is going to die a violent death?
No hope for a real alternative to M$ Windoze?
I am really looking forward to Version # 1.0.0 of ROS in both x86 and PPC.
People we (you devs) need to stick togather. Become a team! People are
counting on YOU!
ROS-PPC + Open Workstation Computing platform. = Power to the People!
If you have to become 90% WinOS compatable then so be it! 90% is better than
0%
XP apps can be ported to ROS.
Maybe GvG and WD will come back if ROS went in this direction.
Port Linux GNU code if you have to. Lets get a new GUI and a Integrated
sound system.
Use a open file system not FAT. Write a translator for FAT.
--
David Johnson
Voice Talent
http://www.davefilms.us
DaveFilms Digital Media - Audio [TM]
Producer , Writer,
Production Director/ Designer
The solution is quite easy, is Harmut believes the
code could have implemented another way, unrelated to
the microsoft way, i propouse that Alex gives him the
documentation and Harmut does write the code.
Either if Harmut manages to make a quite diferent code
for that piece of reactos, or is proved that there is
no other way of writing the code Reactos developers
can be safe about that particular code.
And just an advice, it seems you MUST meet each other
face to face, to know each other (a few beers would
help) and get a working relationship.I believe there
is no need of theatral posts and the such,
disagreements is habitual when there is more that one
person, but flaming, bashing or threatening is not the
solution. Talking is.
Take it easy,
Lucio Diaz.
______________________________________________
LLama Gratis a cualquier PC del Mundo.
Llamadas a fijos y móviles desde 1 céntimo por minuto.
http://es.voice.yahoo.com
Gentlemen,
I'd never thought I'd take part in such a debate. Let me comment from a
position of someone who's been folowing this project with great
anticipation and high hopes.
First of all I must say Alex's work and commitment to the project is
outstanding. Maybe it is that he somehow makes his work most visible (I'm
not trying to diminish the great work that all contributors have done).
However the discussion here is about something else. I do not think the
discussion should be going along the lines if things can be done any other
way or not. Also I wouldn't think that what someone called 'intent' is the
most important thing (it maybe would be if it saved lives of people). The
thing here is not about whether Alex understands the code he put into SVN
(extensively) commented.
Let me provide an example here on a bit different level: suppose I like
what a commercial(!) Java (or any other decompilable language) program does
and decide to implement an open-source implementation. Would it be
acceptable if I used decompiler to produce a readable code, study it,
understand it, copy and paste those decompiled sources into my project and
comment it extensively? I do not think so. The argument of understanding
the code is irrelevant in this case as it is irrelevant in ReactOS's case.
Is there so much difference between decompiled Java source code and
disassembled binary (especially when the source has been assembly
probably)?
The issue here is about the method and I believe (and that makes me sad)
the method Alex used was against the law and no good intent can change
that. I think copy-and-paste is illegal under any circumstances (I am
strong oponnent of American patent law). I wish very much that Alex and
Hartmut as well continue to work on this project and we see a day when it
becomes an alternative to Windows. But this case puts the project into big
danger in my opinion.
Just my 2cents.
Best regards
Radovan Skolnik