Re: xp remote desktop bluescreen or how to shoot your pc

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

techsc wrote:
- i have posted this bug report more than one year ago already -

Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure:

Here comes the procedure to reproduce a severe bug in the windows xp
terminal service (RDPDD.dll):

Set up a windows xp pro host and connect then from a remote
computer via remote desktop.

1) connect and logon (create new session) at color depth 15bit

2) disconnect (leave the user logged on)

3) connect and logon to the created session at color depth 16bit

4) disconnect

5) connect and logon to the created sesseion at color despth 15bit

-> voila, the remote desktop host system reboots!

- I can reproduce this bug on all 4 availble computers (all xp pro
with sp3) at my location.

Shenan Stanley wrote:
ATI video cards?

techsc wrote:
The bug is not related to any video card. I can reproduce the bsod
on ati, nvidia and even on vmware virtual machine cards. Anyone can
try it.

Shenan Stanley wrote:
It's Windows XP - it's pretty much a dead horse.
A year ago - it was actually pretty much a dead horse. ;-)

Not to mention - I am unsure why anyone would do what you specify -
and I am just meaning connecting at such a low color depth, much
less this change from low to slightly higher back to low.

Geoff wrote:
Not very constructive. The fact it is reproducible across a variety
of platforms is cause enough for concern. XP is far from dead,
since MS has yet to produce a newer system in sufficient population
and appeal to supplant all the installed XP boxes, it should still
be on the table for a fix. It's a bug that should have been
detected and fixed by now. The bug is reproducible on my Dell
laptops and HP desktops.

If this scenario, or something like it, can be shown to kill a
machine during the connect process without needing a valid login it
would make for a fine denial of service attack. Since the code base
for RDP is probably close to if not identical to Terminal Services
it could be used to take down a TS box. It demonstrates a potential
vulnerability that could be exploited as a DoS or, with the proper
frames, a way into a kernel driver for elevation of privilege.

To techsc: this is not a proper place for a bug report in any case.
This should be submitted to the Microsoft support team as a proper
bug report, not in the newsgroups. You won't get much action from
MS by posting here, as you have demonstrated.

techsc wrote:
Shenan:

You're still talking about how unusual - in you personal point of
view - the reported blue screen will come up.

Accept it like it is: A real bad bug in the OS. And yes, in my
infrastructure this bug leads frequently to total computer resets.

However, I halready asked in the thread:

Please: How can I report that bug to Microsoft correctly?

techsc wrote:
Your comment does not help at all.

It is a bug in Windows XP and after one year there is still no
reaction or fix available.

Shenan Stanley wrote:
To be clearer, I wouldn't expect a reaction or a fix if I were you.

It's great that you found a problem (albeit one I doubt many people
would ever run into, nor do I immediately see any exploitable
concept in it) and fantastic that you reported it. However - you
reported it (supposedly) one year ago. That would be July 2008.
Windows Vista (the supposed replacement for Windows XP) was
released to businesses in November 2006 and to the public in
January 2007. Windows XP SP3 (which did make changes to the Remote
Desktop client - at least, if not to the entire sub-system) was
released in late April/early May 2008.

I see the first report of the problem you speak of (public -
possibly you?) here:
http://forums.nvidia.com/index.php?showtopic=84939

And I never said it was not an issue - I agree it is a curiosity
and could be, in unique cases, a valid issue for some users. It
would be more of a problem (for Microsoft to put attention to) and
not just an issue if (1) it did it on Windows Vista (does it?)
and/or if it did it on Windows 7 (does it?) and/or the server OSes
and/or (2) it did it whether or not you logged into the remote
Windows XP desktop (you seem to actually have to log into the
remote desktop - meaning I couldn't write a script to hit some
random machine and crash it without having a valid logon/open
session.) (2) would make it a serious flaw - exploitable. (1)
would make it a current issue.

I don't disagree - if you properly reported the issue via correct
channels a year ago (as you say) - then in a supported OS (Windows
XP is a supported - for now - OS) you should get some sort of
statement - at the very least. However - I wouldn't expect one as
you have presented the issue. Not saying you *shouldn't* expect
one, I'm just doubting you will get one.

The only way *I* (as a peer) could help you with a flaw such as
this is to suggest you not change the color depth in such a pattern
as you have found to be disruptive and log into remote Windows XP
machines in the given specific fashion. It's a work-around, to be
sure. Choose a specific color depth and stick with it and/or log
off the remote computer when done with a forced 'different' color
depth for 'speed' reasons - I suppose.

techsc wrote:
Shenan:

And please stick to the thread. I have posted a very simple and 100%
reproducable bsod bug. I am not the originator of any nvidia thread.

Your statement, it would be required to change the color depth
several times is wrong. However, this is also not the point.

Shenan Stanley wrote:
I did stick to the thread.

I can do nothing for you. No one here really can.

Sure, the problem is reproducable - and some people (in some ways)
could cause this if they do not log off a remote machine and then
reconnect to it twice more - the second time using a different
bit-rate than the first and then disconnecting (without logging
off) and connecting back the third time at any bit-rate other than
the second connection - including but not limited to the originally
connected bit-rate.

Report it to Microsoft.

Stop using Remote Desktop and switch to something else would be my
actual suggestion - TeamViewer is great, but if for commercial
applications, VNC and Single-Click gives you almost the same
functionality for free, and both without as much setup on the
customer end.

I use all sorts of remote tools to connect across many different
types of internet connections all the time. I know of many
help-desk setups that do it as well and they do not encounter this
issue - mostly (I think) because they just have not seen the need
to change the bit-rate and combine that with multiple logons with
the same user without logging out of the remote machine.

techsc wrote:
Shenan,

if you have no helpful input please do not reply to such threads.

Letting you know that no one here can do anything about a bug in the OS (we
are volunteers, not Microsoft employees/programmers) and letting you know
you would be better served reporting the problem to tthose who can actually
do something (Microsoft) and giving you the only work-arounds possible at
this time (using third party applications such as TeamViewer and/or VNC) *I*
would say is helpful, in this case.

We disagree about the commonality of your reported problem. That's all. It
exists, no argument there - it's just going to be rare that someone comes
across it - IMO. Maybe you have a case where it is not rare to change
bit-rates (disconnect/reconnect twice) without logging off the remote
computer. I'm not saying the issue doesn't exist, in fact I cannot say this
any better than I did a while back in this conversation, "To be clearer, I
wouldn't expect a reaction or a fix if I were you."

I'm just being truthful with you.

I think you should report it, but I think you should be realistic about it
and not expect much of a response out of something that will be likely
considered a rare occurence caused by a very unique set of events a user
must perform. It's just honesty with the possible work-arounds thrown in.

Also - I suggest giving examples when you report the issue - examples of
when this could be common practice and perhaps visual examples of this
happening. Along the latter lines (because - again - I cannot personally
see where the simple work-around of always connecting at the same bit-rate
and/or logging off when done isn't a possible and easy work-around - or
actually not the norm) maybe I can help...

I've made a few videos - some demonstrating the issue at hand, some
demonstrating when the issue is *not* an issue. I carried out further tests
and documented them here to assist you in your report to Microsoft, if you
are going to make one.

I cannot fathom contributing more than that to help you present your case -
but - here's what I got...

I tested this combination -- Windows Vista SP2 remotely connecting to
Windows XP SP3 (NLA enabled):

15 --> 16 --> 15 = Reboot of Remote Client (with video.)
http://www.youtube.com/watch?v=q_Pt_V8Z_O8

Since this caused a reboot and is the one you are concerned with, I decided
to log off the remote machine between each change...

15 --> logoff --> 16 --> logoff --> 15 --> logoff = No Problem (with
video.)
http://www.youtube.com/watch?v=FELnZQ0qiQA

But there are so many more combinations to try - here are some I did try and
the results.
(I logged off the remote computer at the end of each '3 change test' - not
each change - just at the end of each combination of three.)

15 --> 24 --> 15 = Reboot of Remote Client (with video.)
http://www.youtube.com/watch?v=c-46Sz42-_Y

15 --> 32 --> 15 = Reboot of Remote Client (with video.)
http://www.youtube.com/watch?v=Ba6IHU3oiyo

15 --> 256 --> 15 = No Problem (with video.)
http://www.youtube.com/watch?v=i4jJBvwkkEg

16 --> 15 --> 16 = No Problem (no video.)
24 --> 15 --> 24 = No Problem (no video.)
24 --> 16 --> 24 = No Problem (no video.)
16 --> 24 --> 16 = No Problem (no video.)
32 --> 15 --> 32 = No Problem (no video.)
32 --> 16 --> 32 = No Problem (no video.)
16 --> 32 --> 16 = No Problem (no video.)
32 --> 24 --> 32 = No Problem (no video.)
24 --> 32 --> 24 = No Problem (no video.)
256 --> 15 --> 256 = No Problem (no video.)
256 --> 16 --> 256 = No Problem (no video.)
16 --> 256 --> 16 = No Problem (no video.)
32 --> 256 --> 32 = No Problem (no video.)
256 --> 32 --> 256 = No Problem (no video.)
256 --> 24 --> 256 = No Problem (no video.)
24 --> 256 --> 24 = No Problem (no video.)

Although not all the possible combinations, I think you can understand me
not doing all the work *you* might need to do to make *your* case to
Microsoft that this needs to be fixed.

I did prove myself incorrect - only the three bit-rate changes (15 -->
16 --> 15, 15 --> 24 --> 15 and 15 --> 32 --> 15) without remote logoff -
seems to give the reaction of rebooting the remote Windows XP SPx machine in
a repeatable fashion.

Unfortunately (for your case) - that only makes the work-arounds that much
easier to suggest. ;-)

- Don't switch between bit-rates when connecting to a machine with an active
session
- Use something with more benefit than remote desktop gives.
- Log off the remote machine between sessions when possible.
- Don't use 15-bit at all.

I actually did get the remote client to reboot once by just continuously
changing bit-rates. It took about 22-23 changes though - none of which were
15-bit. So I guess with enough changes in bit-rate without logging off the
remote client, it could cause a reboot at random.

I wanted to see if it still did this if the reverse was done - so connecting
to Vista from Windows XP. I tried a few of the ones that definitely caused
issues in Windows XP - and a few others. None of them seemed to produce the
problem reflected in the test above remoting into Windows XP. So it seems
the issue was resolved in future versions of Windows (beyond Windows XP.)

I do wonder if Windows 2003 shows the same issues... But I will leave that
to you.

Do some searches, do some research, put in some effort into a report with
many details and let us know what happens.

Hope that helps.

--
Shenan Stanley
MS-MVP
--
How To Ask Questions The Smart Way
http://www.catb.org/~esr/faqs/smart-questions.html


.

Relevant Pages

  • SecurityFocus Microsoft Newsletter #228
    ... RaidenHTTPD Remote File Disclosure Vulnerability ... Microsoft Outlook Web Access Login Form Remote URI Redirecti... ... Microsoft Windows Hyperlink Object Library Buffer Overflow V... ...
    (Focus-Microsoft)
  • SecurityFocus Microsoft Newsletter #212
    ... MICROSOFT VULNERABILITY SUMMARY ... ARJ Software UNARJ Remote Directory Traversal Vulnerability ... Microsoft Windows XP WAV File Handler Denial Of Service Vuln... ...
    (Focus-Microsoft)
  • SecurityFocus Microsoft Newsletter #229
    ... Windows NTFS Alternate Data Streams ... MICROSOFT VULNERABILITY SUMMARY ... VBulletin Forumdisplay.PHP Remote Command Execution Vulnerab... ... AWStats Debug Remote Information Disclosure Vulnerability ...
    (Focus-Microsoft)
  • Re: xp remote desktop bluescreen or how to shoot your pc
    ... Windows XP Pro En SP3 Remote Desktop Blue Screen Procedure: ... Here comes the procedure to reproduce a severe bug in the windows xp ... this is not a proper place for a bug report in any case. ...
    (microsoft.public.windowsxp.work_remotely)
  • SecurityFocus Microsoft Newsletter #232
    ... Windows Firewalls Lacking ... MICROSOFT VULNERABILITY SUMMARY ... Gene6 FTP Server Remote Default Install Code Execution Vulne... ... Relevant URL: http://www.securityfocus.com/bid/12736 ...
    (Focus-Microsoft)