From: chrisp at ngssoftware.com (Chris Paget)
Subject: Response to the iDefense "Shatter" paper

-----BEGIN PGP SIGNED MESSAGE-----

Hi there,

Firstly, I've only just subscribed to full-disclosure having been
forwarded the iDefense paper by my colleagues here at NGSSoftware.
Apologies if I've missed some important parts of the discussion and
am repeating what may have been said already.

iDefense are absolutely correct in saying that EM_SETWORDBREAKPROC
can be used in exactly the same way that WM_TIMER can, in order to
force another application to jump to an arbitrary location in memory.
 They are also correct in saying that the problems are not unfixable;
it was perhaps a little hasty on my part to state this in the
original white paper.  However, I do not believe that the iDefense
paper takes the issue far enough; here at NGS we have discovered many
new techniques for exploiting Shatter attacks.  Their technique for
injecting shellcode, while working acceptably, is just one of many
that we have located; EM_SETWORDBREAKPROC, while dangerous, is
likewise just one example of many new Shatter techniques for code
execution that we have independantly discovered.

For example:  MS03-025 is a patch for a Shatter vulnerability in the
Utility Manager service, installed by default and running as
LocalSystem on Windows 2000 computers.  It is vulnerable to privilege
escalation attacks using the LVM_SORTITEMS message.  The Microsoft
advisory on the issue can be found at
http://www.microsoft.com/security/security_bulletins/ms03-025.asp
while the NGS advisory can be found at
http://www.nextgenss.com/advisories/utilitymanager.txt

I will be presenting on the subject of Shatter at the Black Hat
Briefings in Las Vegas, at the end of July.  I will be discussing in
detail the new issues we have found, correcting some errors in the
original paper, releasing several new exploits for Shatter attacks
(some for privilege escalation, and some for rather different
issues), and discussing the depth of the issue as well as proposing
in detail some solutions for fixing them.  Please don't ask me for
more information until then; I'm happy to discuss the original paper,
the iDefense paper, and the MS03-025 patch, but I will not be
providing more information about my Black Hat presentation until
after the event.  Rest assured that there is a lot of new content in
it, and I will be around at both Black Hat and Def Con afterwards to
answer any questions that are outstanding.

Two things in particular that I would like to state in response to
the iDefense paper.  Firstly, while the technique of filtering
messages that are received by an application will work, it is an
approach from the wrong side.  It is a "We know this is bad so we'll
filter it" approach, while what is needed is a "We know this is good
so we'll allow it" solution.  I will be explaining two alternative
solutions in detail at Black Hat, although all three potentially
suffer from the same problem.  Secondly, the iDefense paper indicates
that Microsoft's security best practices are not to have highly
privileged windows on a low-privileged desktop; this is not a firm
stance from Microsoft.  In fact, their latest statement on the issue
(in the text for the WM_TIMER patch - MS02-071) states:

"I saw a posting Microsoft authored shortly after this issue was
reported, in which you said the problem was that processes with
differing levels of privilege were running on the interactive
desktop. It sounds like youve changed your opinion.

We have. When we initially examined the situation, we concluded that
the problem here lay solely in the fact that highly-privileged and
lower-privileged processes were both present in the interactive
desktop. We pointed out that, by design, all processes on the
interactive desktop are peers, and stated that we believed the real
solution was to not mix processes of varying privileges.

However, upon deeper investigation, we determined that the real
answer is somewhat more complicated. Its possible for a highly
privilege process to coexist safely with less privileged processes on
the interactive desktop, provided that its been properly designed to
vet all requests before acting on them. However, the flaw in WM_TIMER
would undermine these safeguards even if they were present. As a
result, although we still recommend that developers use extreme care
before writing a process that has high privileges and runs in the
interactive desktop, we believe that in this case the real culprit is
the flaw in WM_TIMER."

To state Microsoft's policy as recommending that highly privileged
applications should not interact with users is somewhat misleading,
if not actually erroneous.  Microsoft's stance on the issue is
unclear, at best.

That said, I applaud iDefense for their research, and I am grateful
to them for taking the time to read and understand the issue, and
then investigate it in more depth.  Hopefully, this paper and the
presentation I deliver at Black Hat will have the desired effect of
spurring more research into the problem, increasing the average
developers understanding of the problem, and preventing the attacks
as far as is possible.

Chris Paget

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.3

iQEVAwUBPw7Ir+OSVp6V7CLvAQFGjQf+OIrdj1K6dAgYq651nTpWmcZy6iboe95X
wYAN5rnsU1pxzLGFbry9l/MrJXlTTVcqY2BUQoGpby6PePTSbeKyghtOjsIN3+ZG
IL1DiesCvaJL+zjD6x6F8DtvdPvaD1izIBu6RKbZNicR0hKKiS0R8N9XbXkSXMY1
/vBSBVlophH4m1XKXpIwg7Ng1aUWoE6CASOPlw3iLOOdcf1OI2/MizFLRFTSK+rl
rq6zxLqCRsnWN72w0xKydSMa/5EY62e1+k5TrlQpd84rO90Caf9KKWSQNHcny6RT
paeAXlY0J+7vn3jt6eahQ8gPeey+GDc+WKVGMHmFMNFli8Fv3c8Exw==
=WfVv
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists