Hi,
First of all I would like to introduce myself. My name is Martin and I am
currently attempting to go through and audit the ReactOS source code for
security vulnerabilities. I've been keeping an eye on the project for
about a year now and I think as development is now rapidly increasing,
security must take more and more of a priority.
I started with the kernel32 library on Friday (9th) and have found a
number of possible security vulnerabilies. These have been filed with
bugzilla and i'm very impressed with the rate that these were fixed. So
well done on that count!
However, after submitting bugs #1102 and #1103 (now fixed by
BrandonTurner) it became apparent that incorrect usage of the
RtlAllocateHeap function (and its alias HeapAlloc) is quite common. It
may return NULL if memory cannot be allocated and in some parts of the
code this is not checked. This would lead to a segmentation fault on
reading / writing.
Through some judicious use of grep I went through the source code and
extracted calls to this function with their context. After going through
each one and investigating it I have now found another twenty occurances
of the same bug (This is just in the kernel32 library).
I am writing this to let all developers know that they must check their
return values. Errors can exist, resources may be starved and the call
may fail. Make sure your code can cope with this.
Finally, as I am fairly new to bugzilla, should I submit each of these
twenty bugs individually or should I submit them all as one bug?
Cheers,
Martin
Can't we include Mozilla Control in ReactOS? So that we build it with
our ROS Build Environment or whatever is used to compile ReactOS, put it
on bootcd and install it with ReactOS?
Greets,
David Hinz
gvg(a)svn.reactos.com schrieb:
> Files to create Mozilla Control installer with correct DLL
>
>
>
> Added files:
> trunk/tools/
> trunk/tools/MozillaControl/
> trunk/tools/MozillaControl/README.txt
> trunk/tools/MozillaControl/control-ros.nsi
> trunk/tools/MozillaControl/files.nsh
> trunk/tools/MozillaControl/local.nsh
> trunk/tools/MozillaControl/redist/
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
> From: gvg(a)svn.reactos.com
>
> Files to create Mozilla Control installer with correct DLL
I've created a "fixed" version of the Mozilla Control installer which
includes the correct MSVCP60.DLL and put it in our SourceForge download
area. shdocvw.dll will now download/install that fixed version.
GvG
We don't have the REVISIONS section anymore and a copyright notice is missing.
Casper
_____
From: ros-diffs-bounces(a)reactos.org [mailto:ros-diffs-bounces@reactos.org] On Behalf Of arty(a)svn.reactos.com
Sent: 11. december 2005 09:26
To: ros-diffs(a)reactos.com
Subject: [ros-diffs] [arty] 20055: A little library for making it easier toget to PASSIVE_LEVEL. Just contains
_____
Added: trunk/reactos/drivers/lib/chew/workqueue.c
--- trunk/reactos/drivers/lib/chew/workqueue.c 2005-12-11 08:11:21 UTC (rev 20054)
+++ trunk/reactos/drivers/lib/chew/workqueue.c 2005-12-11 08:26:16 UTC (rev 20055)
@@ -0,0 +1,101 @@
+/*
+ * COPYRIGHT: See COPYING in the top level directory
+ * PROJECT: ReactOS TCP/IP protocol driver
+ * FILE: tcpip/main.c
+ * PURPOSE: Common Highlevel Executive Worker
+ * PROGRAMMERS: Art Yerkes
+ * REVISIONS:
+ * CSH 10/12-2005 Created
+ */
With r20024 I can get ibrowser to actually download the Mozilla webbrowser
control. It usually takes a few tries, often the download hangs halfway
through. I have the feeling that it helps if you move the mouse constantly
during download, but that could just be my imagination.
To install the control, you will need a copy of MSVCP60.DLL, which the
author forgot to include in the install image (Wine has the same problem).
So first copy MSVCP60.DLL from your Windows installation to
\ReactOS\System32, then start ibrowser, download the control and install it.
After that ibrowser (and the "Web" button in ROSExplorer) becomes
functional.
GvG
When I first throw in the idea, that we could try to get some big
companys supporting us, I was amazed by the huge response.
A lot of people seem to be very interested in this, but after some days,
I noticed that there are nearly no devs who replied to my mail, or the
numerous replies on it.
So what I'm asking for is how the devs and especially our PC Steven
Edwards think about asking some companys like IBM, Intel, AMD, nVIDIA,
ATI, Dell,... to support our project.
There are a lot of ways, they could support us, either by money, or by
developers, or by knowledge/documentations.
Every of the mentioned companys would be able to support us, but I think
the only person who has the right to ask any of them is our PC, or maybe
somebody he authorized to do so.
I'm waiting for your replies.
Greets,
David Hinz
BTW, the mail I mentioned above is
http://www.reactos.org/archives/public/ros-dev/2005-December/006645.html
Does this fix the reference to 'reactos.com' with the 'ver' command,
in the Command Interpreter?
On 12/9/05, gvg(a)svn.reactos.com <gvg(a)svn.reactos.com> wrote:
> reactos.org is the preferred name these days
>
>
>
> Updated files:
> trunk/reactos/subsys/system/explorer/shell/mainframe.cpp
>
> _______________________________________________
> Ros-svn mailing list
> Ros-svn(a)reactos.org
> http://www.reactos.org/mailman/listinfo/ros-svn
>
--
"I had a handle on life, but then it broke"
When I try to compile ReactOS on Windows, I get the following error:
./subsys/win32k/objects/path.c: In function `PATH_PathToRegion':
./subsys/win32k/objects/path.c:1024: warning: 'hrgn' might be used
uninitialized
in this function
mingw32-make[1]: *** [obj-i386\subsys\win32k\objects.o] Error 1
Important: I'm compiling with optimisations for amd64 and dbg and kdbg=0.
Revision is 20025
If I'm not the only one with these problems, I hope you get that fixed
soon, I don't think this is because if my platform optimizations.
Greets,
David Hinz
Hi,
after compiling ros on ros, I see over 45000 memory blocks with the tags
TOKd, TOKp, TOKu and TOKp. It seems, something is wrong with the
referencing/dereferencing of tokens. I've add some debug code in
SeDeassignPrimaryToken (only called by PspDeleteProcess), which prints
the ref count of the token object. It is always greater than 1. The
process token is never deleted.
- Hartmut