I've done a little research about the F7-Enter bug, here're some results: The reason of the system rebooting or halting is because csrss.exe (the process implementing the win32 subsystem) produces and unhandled exception and dies. The OS is unable to continue its normal operation without this fundamental process and it KeBugChecks and dies. In csrss.exe, CSRSRV.DLL!CsrUnhandledExceptionFilter gets called. This function calls NTDLL!NtRaiseHardError with an error code of 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED, that is, csrss.exe is death), and all ends up in KeBugCheckEx when the system reboots/halts. Ok, now, back to cmd.exe. Who implements the history window that it shows when you press F7? well, it isn't implemented by cmd.exe itself, it is implemented inside csrss.exe, specifically, in winsrv.dll. Here lays the implementation for all the F-X functions (F1,F2,F3, etc) that cmd.exe provides to the user. The window itself is drawn by code inside winsrv.dll, what makes me think that any console application can make use of this functionality, but I couldn't find the win32 api to do it (I found functions inside cmd.exe and functions exported by kernel32.dll called SetConsoleCommandHistoryMode, SetConsoleNumberOfCommands, etc. (these functions are not documented in the MSDN Library, July 2000) I played around a little but couldn't make my console application to draw the history window). Because of this, this might not be a cmd.exe bug alone, but something that could affect other applications as well. (I've never seen any application using the same history window as cmd.exe does, so this is very unlikely I think.) Like many others said, it is not necessary to run ping.exe, any program that outputs continues data to the console will cause the same problem. it isn't even necessary to press F7-Enter many times, if you press F7-Enter only one time while data is being output to the console, when cmd.exe is ready to read data from stdin again, the bug occurs. It is also not neccesary to press Ctrl-C, for example: c:>ping -n 5 192.168.88.1 If you press F7-Enter one time while ping is displaying its output and wait for ping to terminate (-n 5 will produce 5 pings.), the bug occurs (sometimes it doesn't or only the cmd.exe window hangs). I haven't established exactly why the bug occurs yet, I have some ideas but nothing certain. I have identified where is the code in winsrv.dll that shows the history box and all the others boxes that appear with the F-Keys. The system crashes inside this code. I've also developed a temporary patch to solve the problem. The patch directly eliminates the functionality of all F-Keys inside cmd.exe (and all applications that use the history window functionality, etc.). So, you can continue to use cmd.exe, but pressing F7 inside it will have no effect at all, pressing F2 will have no effect at all either :), it's possible to easily make a patch that only eliminates F7, but, oh well... at WINSRV.DLL!5FFBD881 there's a function that contains inside a big switch() statement and implements the functionality of the F-Keys. Near the beggining of the function you have the following code: .text:5FFBD891 cmp di, 76h .text:5FFBD895 mov [ebp+var_4], esi .text:5FFBD898 mov [ebp+var_8], esi .text:5FFBD89B jz loc_5FFCFEDF here the code is making some comparison against a parameter that gets passed to it (the value 76h). You can change the .text:5FFBD89B jz loc_5FFCFEDF for a jmp 5FFBDC42 that actually jumps to the end of the function, and returns without performing any action. This is the function that actually decides which window to display (history window, copy window, etc) based on the F-Key you pressed, so following the code a little, very little more, will allow to make a patch that only prevents the use of F7, instead of eliminating the functionality of all the F-keys. All this analysis was done using Windows 2000 Advanced Server SP1, i've observed that the addresses of winsrv.dll shown above change in win2000 professional. The patch I'm posting only works for windows 2000 Advanced Server SP1, if anyone wants the patch immediately before microsoft releases its own, please let me know. Another solution is to add the following registry key to every user (go to HKEY_USERS and add it for every SID): Software\Policies\Microsoft\Windows\System there, create a DWORD value named DisableCMD, and set the value to 1. this will prevent your users to execute cmd.exe. You can also set this value using the policy editor (or alike) more automatically I think, but i couldn't find the proper option. Anyways, this isn't a very good solution, since the code that checks to see if DisableCMD is set is inside cmd.exe itself. If a user can execute on your system his own patched copy of cmd.exe (patched so it doesn't check for the key described above. Note that this is as easy as changing the DisableCMD string for DisableCMX, which anyone can do using his favorite hex editor in just one second), you're vulnerable. If what I said before is correct, and any user can use the history window functionality on its own console application, then, you're vulnerable, a user could execute his custom made application that mimics the cmd.exe bug and reboot your system. The correct patch would be the winsrv.dll patch described above. Remember this is a quick hack while waiting for the proper patch by Microsoft, I take no responsability for any damage or anything bad that this patch could produce. Hope it helps. bye! ==================[ CORE Security Technologies Inc. ]========= Hernan Ochoa mailto:hochoaat_private Senior Security Consultant Florida 141 7mo. piso 2do. cuerpo http://www.corest.com C1005AAC Capital Federal Buenos Aires, Argentina. Tel/Fax : +(54.11)48.78.26.73 Casilla de Correos 877 (1000) Correo Central ==================================================================== -"Es un muchacho sin importancia colectiva, exactamente un individuo". Louis Ferdinand Celine, L'Eglise.
This archive was generated by hypermail 2b30 : Wed Aug 01 2001 - 16:01:54 PDT