 |
| ReactOS fanboys warning |
Prologue
About year ago I’ve published “Making ReactOS great again, part 1” (brief MRGA, posted at kernelmode.info) where described a current state of this meme project (tl;dr homemade Windows NT clone with massive masqueraded copy-paste and borrowings from Microsoft OS as results of it reverse-engineering/leaked source usage). I didn't use “academic project” here, because ReactOS is rather anti-academic than something, that one can study for good. ReactOS code and its developing methods is a monument of anti-patterns, and it seems that it exists only for fun and profit of its few developers/project manager. Back to the first MRGA article – it showed overall low quality of the project's code and developers inability to improve it for years due to multiple reasons, dev's team selecting most funny ones as excuses for their failures. I gave them a dumb simple syscall fuzzer (that they were unable to write for 20 years) and highlighted over 30 critical system bugs discovered with it help. I have been planning about 5 or 6 parts of MRGA journey that giving developers of this meme OS more critical system bugs in different areas (discovered by the way in less than two weeks, 😊).
What were expectations from MRGA post? At first, you should understand that several people spent their years of youth involving in this particular project, so they created a virtual area of significance from that fact. It is like that you have Windows NT operating system clone in your portfolio that should clearly make you an uber expert in OS development. Or make you top tier security/software engineer from initially been a mediocre level reverser of crackmes. So when someone begins to criticize their previous work, entire area of significance shaking as hell too. But only if you are dumb attention whore of course. Or never learning idiot. Because obviously if people are talented – when they grown up they are capable of rethinking their past work and capable of self-criticism. Unfortunately (I'm joking, actually I enjoyed it) MRGA post immediately revealed a nature of some people, put their butt-hurt to the incredible level (so some of them even tried to do a spam campaign against MRGA publication). A toxic community of ReactOS current and previous developers/users completely lacking any self-criticism, full of hypocrisy, incompetence embedded into their own virtual world, guys who build their area of significance on others people work they actually stole / borrowed / adapted at the best. My expectations were exceeded in a bad way and I revised a strategy of my work with such “contingent”. Instead of giving them another bunch of their bugs for fix (together with another portion of critics) I decided to wait a little, accommodating their project development timeline, giving them enough time to develop and apply all required fixes. It’s decided to wait an year, passing few major releases. It is now December 2019 – an year after MRGA Part 1 post and it is time to check results and try to figure out why it is that bad (spoiler alert).
Part 1. The Fixes
A little of. With some unfortunately fixed in a wrong way😄 Note that I tested both 4.12-release and 4.14-dev versions. The first bug in list at MRGA Part 1 was ntoskrnl.exe (NT core) service NtAllocateUuids (ROS_NTOS_BSOD_004, names are numerological sequence of initial discovery). It has been fixed by added missing input parameters validation. As well as NtDisplayString (ROS_NTOS_BSOD_003). They also removed debug breakpoint set into NtRaiseException (ROS_NTOS_BSOD_005) thus resolving another issue. Missing parameters validation added to the NtSetUuidSeed (ROS_NTOS_BSOD_009). Additionally they managed to fix NtCreatePagingFile (ROS_NTOS_BSOD_053) which was a part of BSODScreen screensaver that I exclusively presented to ReactOS. Spoiler alert: do not worry this screensaver Easter egg functionality will return (near the epilogue part) 😊
The last one ntoskrnl syscall dumb fuzzing bug was in NtUnloadDriver (ROS_NTOS_BSOD_007). It also got attention from ReactOS developers. Unfortunately when something more complicated pop ups ReactOS devs gives up. This service is a best example of a failed fix. Initial problem with this service was absence of input parameter validation, so code was dereferencing invalid pointer resulting in Blue Screen Of Death. They tried to apply fix to that by checking input parameter and then capturing it into safe buffer allocated on service side. Unfortunately the logic of this function is screwed up so this bugfix is only partial and works only with ROCALL (syscall fuzzer mentioned above). Input parameter they attempt to validate and latter use from safe kernel allocated copy is a pointer to UNICODE_STRING. In ReactOS it is equal by it definition to the Microsoft ones, this is basically a buffer with given maximum and current length in bytes.
If you look on IopUnloadDriver implementation (https://github.com/reactos/reactos/blob/5706f6e9f4b237ada8098938ca2d4580f28d458a/ntoskrnl/io/iomgr/driver.c#L1187) you will see they attempt to work with UNICODE_STRING buffer without proper verification of it length. You probably know what comes next 😃 I took original BSOD generator code and upgraded it for this "fix".
This ReactOS patch code was written in the beginning of 2019 and wasn't modified since that time, leaving this bug without any attention for a few releases. Lol, this is "academic" quality code.
 |
| Pic 1-1. ReactOS fix in a nutshell. |
 |
| Pic 1-2. "Kvality". |
Another fun service is NtQueryOpenSubKeys (ROS_NTOS_BSOD_052). Why I pay attention to it? While it wasn't in list of fixed after 4.10, it is related to subset of NT APIs they were refactoring to get rid of bluescreens. In initial MRGA post I mentioned that some of their syscalls are subjects of "time-of-check to time-of-use" bugs (race conditions). I even provided them example with such bug in NtQuerySecurityObject (ROS_NTOS_BSOD_050). Year after I look at "fixes" and what I see is terrible. This syscall source https://github.com/reactos/reactos/blob/167bffd80fb8189de34007d78e697af4444cf533/ntoskrnl/config/ntapi.c#L1469-L1547. And here is how to crash it.
 |
| Pic 1-3. ReactOS typical state. |
Not the first and not the last bug of this kind in ReactOS.
Total number of bugs discovered by ROCALL in December 2018 in ntoskrnl was 10 for 0.4.10-release and 5 for 0.4.12-dev. How many is that?
In total, ReactOS has 296 syscalls (they copycat W2k3) with 54 of them are stubs returning status code STATUS_NOT_IMPLEMENTED. Several syscall implementations contain only parameters checking and nothing else, code suddenly drops UNIMPLEMENTED and quits. Additionally some bugs in their syscalls cannot be revealed by current version of ROCALL because it does only basic brute-force. ReactOS syscall implementations sometimes incomplete, some parameters that are valid and used in Windows are unreferenced or defined as "Unknown". Thus everything from above reducing possible bug rate. About 4% (0.4.10-release) and 2% (0.4.12-dev) of their system call table were affected with critical bugs. For ntoskrnl syscalls only estimated bug rate was approximately 5% (with both ROCALL + bugs discovered differently). They fixed everything found by ROCALL (keep in mind NtUnloadDriver is still bugged). So it is good to see at least some adequate reaction on their own bugs. What about win32k?
Part 2. The Blue Screens Festival
Are you curious about what was not fixed? Everything(!)
else of MRGA Part 1. Maybe because:
 |
| Pic 2-1. This is Fine. |
 |
| Pic 2-2. Please No. |
In total x86 ReactOS has 682 win32k syscalls in "checked" build and 676 in "free" (full list ntos+win32k https://gist.github.com/hfiref0x/16cc7a1f72cfebcce5810509ffd13b98). The only difference between "checked" and "free" versions of ReactOS win32k syscall table in a few stubs added near the end of table. Don't know if they use anything except "checked" build. Win32k syscalls have same limitations as ntoskrnl one (with different number of unimplemented, partially implemented ones, of course), plus additionally several of them require CSRSS context for successful call. Overall ROCALL-only affected bug rate is around 4% with total estimated bug rate exceeding 10% (not all of them are bluescreens or hangs OS but some of them produce undefined behavior which may latter affect OS stability).
These are the tests you deserve
In my opinion, after checking their source code, only a coupe of ReactOS developers are familiar/know with what they do, while others simple do copy-pasting with some perverted logic. My favorite code authors of course are from win32k area. Let's take an example, or how do they write tests. Our example is a win32k service NtUserGetClassInfo (bug id is ROS_NTUSER_BSOD_019). This bug cannot be found by ROCALL as triggering it requires successful preconditions. This service implements what is known as GetClassInfo in user32.dll. It has designated test file https://github.com/reactos/reactos/blob/62f6e3b397f54b95df1496d742732bca8ee07b04/modules/rostests/apitests/win32nt/ntuser/NtUserGetClassInfo.c This test is bad as it doesn't provide full coverage of function parameters usage. If you look on NtUserGetClassInfo implementation you will notice exceptionally dumb bug https://github.com/reactos/reactos/blob/0749a868fcae2f7c0963b7cc010aa622d2515c6c/win32ss/user/ntuser/class.c#L2758-L2764
I took this original test and merged it into kvality call example (code is missing syscall gate implementation, but you can find it in my win32u dll I built for ReactOS, links in the end of post).
 |
| Pic 2-3.Kvality test. |
Looking at the same source file we can easily spot another bug, this time it is insufficient input parameters validation of NtUserGetClassName (ROS_NTUSER_BSOD_020). Source https://github.com/reactos/reactos/blob/0749a868fcae2f7c0963b7cc010aa622d2515c6c/win32ss/user/ntuser/class.c#L2788-L2820. They probing ClassName UNICODE_STRING parameter and saving it to the local copy. Next this local copy used in subfunction UserGetClassName where it eventually does operation with non validated unicode string buffer. This is a popular bug among ReactOS developers.
 |
| Pic 2-4. NtUserGetClassName result. |
If you think this is just a one bug of this kind you are mistaken. Most of ReactOS tests are incomplete and only designed to test key functionality and/or if it is callable at all or not. Whats happening when you have such approach? Obvious bugs are not caught for years. Another example is NtGdiGetPath (ROS_NTGDI_BSOD_017). This is kernel mode implementation of gdi32 GetPath function. You can find only a basic test in ReactOS for this function and it is bad as usual. This bug cannot be found with ROCALL as it requires successful preconditions, https://github.com/reactos/reactos/blob/6416ee982fae08766478784adedae54cca7c0869/win32ss/gdi/ntgdi/path.c#L2689-L2735. As commit history shows this file is rarely modified and nobody actually do audit that code.
 |
| Pic 2-5. GetPath result. |
Several implemented services doesn't have any tests at all. With overall "outstanding" coding kvality of win32k components all of them are potentially sleeping BSOD-generators. E.g. NtUserThunkedMenuItemInfo (ROS_NTUSER_BSOD_049). https://github.com/reactos/reactos/blob/893a3c9d030fd8b078cbd747eeefd3f6ce57e560/win32ss/user/ntuser/menu.c#L6341-L6369, indeed what could be wrong here.
 | ||
| Pic 2-6. NtUserThunkedMenuItemInfo result. |
This is ridiculous, isn't it? In the same source file another bugs stay unfixed for years. E.g. meet NtUserGetMenuItemRect (ROS_NTUSER_BSOD_048), https://github.com/reactos/reactos/blob/893a3c9d030fd8b078cbd747eeefd3f6ce57e560/win32ss/user/ntuser/menu.c#L5887-L5949. It looks like all this written by single author who equally incompetent in both writing code without undefined behaviors and in user mode parameters probing.
 |
| Pic 2-7. NtUserGetMenuItemRect. |
Lots of blue screens! This code base is bugged like hell. Sometimes single function contain multiple bugs. Have no idea how it is possible with all these years in development that they never look at their code before and only after it crashes with an error. Have a look at NtUserCallOneParam (ROS_NTUSER_BSOD_044) https://github.com/reactos/reactos/blob/94a42d43b59e59aa3995248577e74588af6727ea/win32ss/user/ntuser/simplecall.c#L357-L383. How it is possible that GetProcessDefaultLayout (which is user mode caller of this code) is never got any tests for all these *years* in development?
 |
| Pic 2-8. Common bug result. |
You can find a lot of similar bugs by just walking their win32k designated source tree. Twenty one year of development, do you remember that? 👌 Ironically one of most active ReactOS developers even have dedicated blog post entry - "How do security issues happen?" https://reactos.org/node/932, it is enjoyable read especially if combined with watching their blue screens generator code later.
Part 3. Regressions
Since last year check stability of some components like for example BTRFS seems degraded and now this FS doesn't save ReactOS from re-installation in case of BSOD in their current 4.14 dev version. Previously you had a good chance to survive when another portion of "Kvality" code executed in a bad way, but not now. You either stuck with infinite loop of reboots, stuck on damaged registry message or stuck on login(!) screen where you cannot login because... keyboard no longer works 😆 However this maybe a glitch of just a current dev version and maybe in 4.14 release this won't be that terrifying. So I was forced to use 4.12 and load 4.14 only for code compatibility tests because 4.14 is basically unworkable even by ReactOS standards.
 |
| Pic 3-1. You Shall Not Pass. |
 |
| Pic 3-2. Installation completed. |
Back to BTRFS, was this regression hard to expect? Not really if you are slightly common with development of this OS. There is an interesting ReactOS pull request https://github.com/reactos/reactos/pull/308. This is code created by talented ReactOS follower which purpose is to actually make ReactOS better (not great but still better than what it is). This PR is stuck on ReactOS main devs incapability to do anything on their own. If only half of their pettiness (in identifying line breaks, indents and additional spaces, between lookthereisnospacesandtypo here) was used to audit the code, the next idiotic code would never have been in the repository for years https://github.com/reactos/reactos/blob/893a3c9d030fd8b078cbd747eeefd3f6ce57e560/drivers/usb/usbhub/usbhub.c#L216-L256 (Spoiler alert, no lock release, using IRP pointer which is no longer valid and cannot be safely dereferenced, ROS_USBHUB_001, ROS_USBHUB_002). Very strange isn't it? Not really, if they pass commits of this quality -> https://github.com/reactos/reactos/commit/5538facfdd0edd11038f9dd00bb4a6afec440403, spoiler alert, there is possibility of invalid handle passed to CloseHandle. All spaces/line breaks, indents are in place so it managed to get into master, sarcasm. It seems ReactOS devs treat their development too seriously, especially if you look on it miserable results. They are preferring matching their idiotic criteria of coding style/contribution above actual code and what it does. In the same time this project is full of code that does not match their own criteria and they are okay with that. What is the point then? Find a monkey that can insert correct number of indents, spaces, can set up braces in a beautiful way and declare magic values as consts.
I would like to wish Vadim (he also builds custom ReactOS images, check them out) to find a better use of his talents and don't waste his time with such mediocre projects with no particular purpose or future.
Part 4. Use Cases and ReactOS myths
Firefox and it suffering
Okay, maybe there were any improvements for simple use case? Snapshot reverted to clean ReactOS state just right after installation completed. For easy access to applications that are somewhat compatible with ReactOS it provides Application Manager (💩 a moment when typical Linux + Wine is more compatible with Windows programs than designated NT clone). We are looking of course for browser for better and exciting experience from ReactOS. I chose Firefox for obvious reasons. Once installed it asked for update (well no surprise, it is version 48, almost 4 years old). Update successfully downloaded and even somewhat installed (entire OS was lagging during this process). After update process has ended I was unable to run Firefox, the process is deadly stuck in task manager. Okay, maybe I need restart my system, well you know you always reboot your PC after installing web browser. Unfortunately this particular use-case ends here. Because of this after reboot.
 |
| Pic 4-1. Use Case End. |
ReactOS myths
When it comes to ReactOS PR I often hear same myths about this OS. First of it (guess what) can be easily dismounted just by looking on their code and all these bugs. Second one is about "we never used anything from MS blah blah blah" is an obvious lie for saving face and it is working only with partially brain dead audience, and third one is about how this OS is better against malware compared to 2K/XP/2003. While turning discussion into typical ReactOS propaganda and demagogy this often ends with "malware cannot work, because we are in alpha stage, nothing works". One of most favorite jokes about ReactOS sound like "are the viruses already work on it?" There you must understand that current malware highly likely indeed will not work on ReactOS just because this platform is outdated and missing features that modern malware will require for basic operations. However since entire code base derived from the late of 199x - early of 200x we have an opportunity for malware of that age. So here is an ultimate answer on question - how does ReactOS protected against malware? Nohow. Actually it is open yard for it, way easy to work than even on Win2k.
The test scenario: take popular widespread malware of the early 200x and run it on ReactOS. Then we take an antivirus software of that age and attempt to detect/remove this malware.
As malware sample we will use Hidden Dragon parasitic virus (aka Jeefo/Hidrag, sample SHA-1 2ac1c19e268c49bc508f83fe3d20f495deb3e538).
As antivirus program – something light/basic and capable of detecting and removing this malware – Doctor Web 4.33, console version, why console read next. ClamAV too. Something else? Well, it was problematic to find DrWeb of that age, so I leave this area of experiments for these who wants waste their time.
When started Jeefo immediately got to the LocalSystem by installing itself as "PowerManager" service. Next it started file infection activity. In less than one minute it infected multiple files inside "ReactOS" system directories - this was confirmed by searching for Jeefo specific data "jeefo!" - a part of obfuscated string this virus uses for marking infected executable. Note that all of them were working stable and OS didn't crash. It infected 27 files in first minute and 49 total when I finished test.
 |
| Pic 4-2. Jeefo infected winhlp32.exe |
 |
| Pic 4-3 Jeefo at work. |
Conclusion - parasitic viruses are working well or at least capable of that. What about AV? All attempts to install or run DrWeb GUI version failed - ReactOS hangs, bluescreens etc. So I found console DOS version of scanner, ensured it is working on Windows XP and capable of Jeefo detect/removal and then copied it to the ReactOS machine. Not to say I was surprised but DrWeb failed to work, while been able to initialize. By the way initialization process took around FIVE minutes to complete, while on Windows XP it takes few seconds at best.
 |
| Pic 4-4. DrWeb failed to work. |
Next attempt was with more complex malware - SpyEye bot, unfortunately first sample (SHA-1 ae38b3e2f135c018570fa01360ed49df94f86224) failed to initialize because of missing dll function and second sample (SHA-1 594740f33841eed53fad5a712f5b35f7190ebc72) hang entire ReactOS during start (note this bot does not utilize any sophisticated stuff or kernel mode drivers). As conclusion here - more recent malware coded at the late of 200x will likely not work, with exception to... ransomware. This is actually fun to see - entire GUI start flickering, speaker produces strange sounds and everything is so screwed up, this type of malicious software also feel itself not really good with ReactOS. This is screenshot of Winlock banner type ransomware working with some difficulties (Borland Delphi origin script-kiddie coding problems).
 |
| Pic 4-5. Winlock (SHA-1 81a2dddfea7786bdaeef62f194d14571b69b8508). |
So general answer here - malware can work, anti-malware - not, this is genius. By installing and using this piece of software on real hardware you are putting your hardware and your data at extremely high risk, opening your PC for malware (practically you are shooting in your own head). Don't forget file viruses are still not vanished completely and typical use case of ReactOS is running old programs, which maybe infected by file viruses that were widespread back at early of 200x.
Partially true story
Another and probably the last popular story about ReactOS is that it is protected from Windows exploits. While it is basically true and cannot be called "myth" in full meaning of this word because exploits for Windows kernel and it components usually utilize Microsoft specific bugs and features that are missing and/or maybe implemented differently in ReactOS, this doesn't mean these exploits cannot affect ReactOS. Here we have an interesting dilemma, you have exceptionally good quality code to reproduce not only original, but also it critical bugs. Or your code is simple "inspired" by contents of few zip archives 😉 or some program with some lady on logo. Anyway it took me a little to google Microsoft Windows XP - 'win32k.sys' Local Kernel Denial of Service by Lufeng Li, shake it a little to be compatible with ReactOS syscall and what a coincidence - it works! 😆 I do realize this can be caused by overall kvality of the given system call prior to the initial problem but it is too boring to find exact reason, I just was a little bit surprised, so good job you managed to surprise me!
ReactOS as platform for retro gaming
How about using ReactOS as platform for running old games? Perhaps we can play some old games that cannot be played on modern Windows versions? Hahaha, of course. No. I know about Solitaire but I want to play in something more exciting. Something like Quake. Unfortunately Quake 1 doesn't work, I somehow managed to get it to the main menu, but after that it always crashes. So next one was Quake 2. While I understand this game can run on modern PC I still want to try it on ReactOS. OpenGL rendering mode crashed it, so I switched to software rendering and was able to somewhat play it. Why "somewhat"? ReactOS seems having problems with timing because Quake 2 runs like if it on x4 speed, pretty unplayable. However, yes it can be started. Huge success for ReactOS! The last game in my try list was Unreal from Epic MegaGames. Attempt to run with OpenGL renderer resulted in this (framerate is about 1 fps per 2 seconds).
 |
| Pic 4-6. Unreal with OpenGL renderer. |
 |
| Pic 4-7. Unreal with software rendering. |
It works! 😉 Still slightly over accelerated but much better than Quake 2. This can be playable with a little pain (of course if you don't mind to play without sound with keyboard and mouse are sometimes does not responding as quickly as you want from them).
 |
| Pic 4-8. Unreal NyLeve map. |
So if you are masochist and can play without sound with some glitches - ReactOS is our chose for playing Unreal. Definitely not my, Unreal for sure can be played on modern hardware and Windows 10 easily. So what is the point of gaming on ReactOS?
Epilogue
This is a syscall table with all mentioned bugs (MRGA+IRGA) and their id's, as per beginning of December 2019. There is much more, but this is what was already made public. Numbering in order of discovery, each ReactOS component has it own id list. Numbering include all types of bugs including system crash results (BSOD/Stop/etc).
As conclusion of the above - it seems this project has no real goals, nor even understanding of it own purpose and suffers from ridiculous number of critical bugs.
Someone may say - it is educational project, giving students insides to Windows internals API and experience of OS development.
It is a complete nonsense. Are you kidding or what? How does this reverse-engineered project which for the past 15 years has been trying to hide the original ms code can teach anything on Windows Internals? Which internals by the way? Twenty five years old Windows kernel? Give these students real Windows code from Windows Research Kernel and this will be million times better than making them dig in that ancient garbage called ReactOS which suffer from numerous bugs and design solutions that only can be made by inexperienced students. Currently it is not a problem to find that WRK source.
What I honestly don't understand - why for all these years no one actually rewrite that old code, this is one of the key parts of OS. All the above bugs are easy to find, and easy to fix, this is not a rocket science. Of course making endless commits with language fixes (when nobody gives a single fuck except commit author) is easier, but still, wtf.
Next stop on ReactOS station will be in the end of 2020 or 2021 depending on moon phase, if something extraordinary won't happen until this of course. Maybe we can touch x64 version then (and BSOD it of course) 😃
P.S.
Hey pshh, I know what you want, another bug that crashes/hangs ReactOS. Here I have it for you, it is one-liner as you like (ROS_GENERIC_001).
 |
| Pic 5-1. "Why are you so broken, suka blyat?" |
Spoiler for BSODScreen
It is NtUserGetAsyncKeyState (ROS_NTUSER_BSOD_018) where they implemented perfect integer overflow and protected service from it by doing sanity checks in the user mode wrapper. |
| Pic 5-2. BSODScreen spoiler. |
Links
- ROCALL - ReactOS syscall fuzzer. https://github.com/hfiref0x/ROCALL
- BSODScreen - BSOD screensaver that does real BSOD but only on ReactOS. https://github.com/hfiref0x/BSODScreen
- Win32u - Windows win32u similar dll for easy working with Win32k services, machine generated, maybe broken in next ReactOS versions due to changed syscalls. https://github.com/hfiref0x/Misc/tree/master/source/ROS/win32u
- Making ReactOS Great Again, Part 1. https://www.kernelmode.info/forum/viewtopic6f46.html?f=11&t=5302
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.