Florian, You are correct about Windows Stations and Desktops, but these are not new and have been around since the early releases of Windows NT. They are not a panacea. A (bad) developer can easily create a service that interacts with the user's desktop and launch windows onto it by specifying SERVICE_INTERACTIVE_PROCESS in the dwServiceParameter to CreateService (). There is even a mechanism for services to be made aware when a user is logging on to the system so that they can do just this. Chris' paper on his web-site names one such application. I suspect laziness or ignorance drove the developer to code their application the way that they did. In fact, they would absoultely not want to use an alternate Windows Station as they want to provide a user interface. An application running with a window in another Windows Station or Desktop cannot be viewed by the user unless he/she can switch to it. While there is an API for this it is seldom used (remember the old Switch Desktop utility in the early Resource Kits?). John -----Original Message----- From: Florian Weimer [mailto:Weimer@CERT.Uni-Stuttgart.DE] Sent: Tue 8/6/2002 1:51 PM To: John Howie Cc: Chris Paget; bugtraq@securityfocus.com Subject: Re: White paper: Exploiting the Win32 API. "John Howie" <JHowie@securitytoolkit.com> writes: > This class of attack is not new, it has been discussed before. While you > can assert that the blame lies with Microsoft (and I'll admit they do > have some responsibility to address the problem you describe) A bit of MSDN browsing revealed that Microsoft has already "fixed" the vulnerabilites, despite the claim that this was impossible. The concepts are called "window stations" and "desktops", and there is plenty of documentation. Everything is there: separate sets of hooks, separate message queues, and so on. Maybe there are some flaws, but the overall design seems to be sound. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898
