Ros-dev

ros-dev@reactos.org

5788 discussions

by M Bealby

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

18 years, 12 months

New patch for NDIS:config.c

by Jerry

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)

18 years, 12 months

Re: [ros-svn] [weiden] 20972: fixed compiling

by James Tabor

weiden(a)svn.reactos.org wrote: > fixed compiling > > > Updated files: > trunk/reactos/lib/gdi32/objects/font.c > Oops, sorry about that, thanks, James

18 years, 12 months

Re: [ros-diffs] [greatlrd] 20960: corret a member name in DD_SURFACECALLBACKS so it is same as ddk

by Royce Mitchell III

greatlrd(a)svn.reactos.org wrote: >corret a member name in DD_SURFACECALLBACKS so it is same as ddk > >Modified: trunk/reactos/w32api/include/ddk/ddrawint.h > > > ------------------------------------------------------------------------ > *Modified: trunk/reactos/w32api/include/ddk/ddrawint.h* > >--- trunk/reactos/w32api/include/ddk/ddrawint.h 2006-01-21 02:19:27 UTC (rev 20959) >+++ trunk/reactos/w32api/include/ddk/ddrawint.h 2006-01-21 14:22:17 UTC (rev 20960) >@@ -421,7 +421,7 @@ > > PDD_SURFCB_GETFLIPSTATUS GetFlipStatus; > PDD_SURFCB_UPDATEOVERLAY UpdateOverlay; > PDD_SURFCB_SETOVERLAYPOSITION SetOverlayPosition; > > >- PVOID Reserved; > > >+ PVOID reserved4; > > > PDD_SURFCB_SETPALETTE SetPalette; > } DD_SURFACECALLBACKS, *PDD_SURFACECALLBACKS; > > > why is this necessary?

18 years, 12 months

Re: [ros-svn] [mbosma] 20952: 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.

by mf

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.

18 years, 12 months

So long and thanks for all the code ing

by David Johnson

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

18 years, 12 months

Re: Bye bye (Lucio Diaz)

by Lucio Diaz

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

18 years, 12 months

Bye bye

by Hartmut Birr

Hi, I'm leaving the ReactOS project. The goals of some developers don't match my goals. Bye bye Hartmut

18 years, 12 months

Re: [ros-dev] Bye bye

by Radovan Skolnik

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

18 years, 12 months

Recent Developments

by M Bealby

Recent developments have been quite heated recently, and I would just like to add in some of my own opinions. If code was directly copied from Windows then it should be removed. Period. This is against the aims and charter of this project. If Windows was only disassembled to gain information on how it works then I think this falls under fair use. Whether a spec should have been written and another person implement the spec is a topic which I'm sure will be discussed for a while to come. This is my point of view on the matter and I will not discuss it further. It is unfortunate that WaxDragon is also leaving the project, I'm sure he will be missed. But people do have lives to lead as well. I'm sure that in the future I will have to leave the ReactOS project too, and probably for the same reasons, such as family and work. Ideally I would like all developers / testers and other contributers to stay with the project, but I understand that this isn't feasible and I respect them for what they have contributed during their lifetime with the project. I devote some of my spare time to the ReactOS project for two main reasons: 1. I wish to learn more about operating system development. 2. I wanted to practice my code auditing and security skills on a project that was of a size that was not too large and mature (e.g. Linux), while not being so small to be insignificant (various other home-brew OSs). Number one is coming along nicely as I'm learning about various topics such as memory management and how drivers work. Number two is coming along as well, although much slowly as code auditing a fast moving project such as this is very time consuming and I have been very busy lately. I currently see ReactOS at the same stage of Linux in the mid nineties. People run it, play with it and contribute to it. The size of this group of people is not large, but they are usually technically minded and their number is sufficient for the project to grow and continue. Development is happening at a fast pace and keeping up can be time consuming at the moment. Lets not try and loose our drive and ambition here. You have implemented a fairly significant amount of the Windows operating system in a relatively short amount of time. You have contributed code to other projects such as WINE. You have a large number of applications that can already run on the system. You have achieved a lot, don't stop now. I think that ReactOS is at a critical stage in development and once is becomes a little more stable we will see a large increase in the number of users beta testing and trying it out. I wish the ReactOS project to succeed and it is something that I think will occur eventually. To all of ReactOS' developers, testers and supporters: You are doing a great job, don't stop now. Cheers, Martin

18 years, 12 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Ros-dev