[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    [cap-talk] Security culture at Microsoft (was Plash 1.14: file
From:       David Hopwood <david.nospam.hopwood () blueyonder ! co ! uk>
Date:       2005-11-29 0:37:50
Message-ID: 438BA2DE.1090704 () blueyonder ! co ! uk
[Download RAW message or body]

Karp, Alan H wrote:
> Mark Seaborn wrote:
> 
>>There is an "X Security Extension", which XFree86 implements, but it's
>>not very useful.  It divides X clients into two protection domains,
>>which it calls "trusted" and "untrusted".  Clients in one protection
>>domain can still interfere with each other.  You really need a lot
>>more protection domains than two. :-)
> 
> Windows has an API for putting processes into JOBs.  You can restrict
> processes in a JOB so that they can only send Windows messages to other
> processes in the same JOB.  This was the basis for our paper
> "Shatter-Proofing Windows",
> http://www.hpl.hp.com/techreports/2005/HPL-2005-87.html.  You can do
> something similar for X.

# Unfortunately, there is a more serious bug in the Windows XP implementation.
# If you do a PostMessage() from within a job, specifying HWND_BROADCAST as the
# target window handle, the Windows message is delivered to all top level windows,
# both inside the job and outside the job. A test program assigned to a job with
# UILIMIT that sends WM_CLOSE to HWND_BROADCAST results in all open windows
# closing. While this denial of service attack is just an annoyance, it means
# that windows messages are escaping the confines of the job and could be used
# in Shatter attacks.
#
# This behavior is in direct contradiction to that specified for UILIMIT [9].
# The Remarks section for this restriction says:
#
#  "If you specify the JOB_OBJECT_UILIMIT_HANDLES flag, when a process
#   associated with the job broadcasts messages, they are only sent to top-level
#   windows owned by processes associated with the same job."
#
# We reported this behavior to Microsoft. Their response states
#
#  "I have forwarded this information to the product group for further research
#   as a bug. It appears after researching this, that this is not a security
#   vulnerability. If this is not the case and I have overlooked the security
#   implications, please send me details on how an attacker might able to exploit
#   this vulnerability and what the results of an (sic) successful exploit might
#   be."

Typical. Despite all the hype about taking security seriously, the culture at
Microsoft really hasn't changed. Even faced with an obvious example in which
a security-relevant feature is not implemented as spec'd, the response is still
instinctive denial.

-- 
David Hopwood <david.nospam.hopwood@blueyonder.co.uk>

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]