Re: Privilege-escalation attacks on NT-based Windows are unfixable

From: Sam Simpson (
Date: 08/23/02

From: Sam Simpson <>
Date: Fri, 23 Aug 2002 09:18:02 +0100

On Fri, 23 Aug 2002 01:43:21 +0100, Alun Jones wrote:

> In article <>, Sam
> Simpson <> wrote:
>>On Thu, 22 Aug 2002 23:09:43 +0100, Alun Jones wrote:
>>> In article <ak3afc$qtq$>,
>>> wrote:
>>>>The difference is that those are flaws such as buffer overflows of
>>>>individual applications. Whereas this is a systemic design flaw in the
>>>>Windows API. The only two solutions are to get millions of application
>>>>writers to check their applications and if necessary fix them or to
>>>>get Microsoft to fix the API.
>>> How many "millions of application writers" use a high-privilege
>>> process to expose a user-interface to the low-privileged user's
>>> desktop?
>>Well MS did and distributed the application with the Windows 2000 Pro
>>disk - what's your point?
> We are being told that "millions of application writers" will have to
> make changes and re-release.

Why usually proceeds a question rather than a statement ;)

> You keep harping on about one that's
> already been fixed, and there's one other application that we know to be
> vulnerable. I'm waiting for the other nine-hundred and
> ninety-nine-thousand, nine-hundred and ninety-eight application writers
> to show up.

I've never asserted that there are a million writers.

>>> Does
>>> it perhaps say something that the only example found in Microsoft's
>>> code is an obsolete application that nobody had heard of even when it
>>> was current? Oh, no, that's right, it's an example of how good
>>> Microsoft is when it comes to security considerations.
>>They implement bad practice in "core OS code" - no surprise really ;)
> Is the "Still Image Service" really core OS code?

Is a web browser? Is a web server?

If it's installed from a distribution disk then I'd say yes.

Or you can be practical and claim that the "OS" is just the Kernel +
Win32 SubSystem....Then we can move on and talk about how printer drivers
execute at Kernel level rather than in user space etc ;)

>>right. In some OS's it isn't possible to inject executable code into
>>another process via window messages. In windows it is.
> I'll take your word for that, since I don't have a detailed knowledge of
> other systems' shell functions and libraries - I don't like to comment
> on those things that I don't understand.

This is Usenet - live a little :)

> However, it's clear from a few
> minutes' perusal of Bugtraq that any means of passing data from one
> program to another makes it possible to inject executable code into
> another process, and it takes only a relatively simple flaw to cause it
> to be executed. What other OS has taken it upon itself to relieve
> secure applications developers of the necessity to check user input?

This isn't a "user input" thing.

>>Good. Thank god such an interactive yet secure service couldn't exist in
>>the base install of Windows 2000 Pro because of the robust MS security
>>docs ;)
> You keep going on about this as if it's a vulnerability that hasn't been
> fixed. Why do you have to appeal to old code as if it is an example of
> the current state of play? Can't you find current flaws to prove your
> point?

I'm using it as an example of how it's better to produce secure
principles at an OS level rather than at the application level and using
the "MS can't code apps to their own standards" as an example of why
relying upon app vendors isn't a good security practice.


Sam Simpson

Relevant Pages