I can't find Paget's original doc.. and wikipedia isn't the greatest
security resource...but .....
http://en.wikipedia.org/wiki/Shatter_attack
With Windows Vista </wiki/Windows_Vista>, Microsoft aimed to solve the
problem in two ways: First, local users no longer log in to Session 0,
thus separating the message loop of a logged-in user's session from
high-privilege system services, which are only ever loaded into Session
0. Second, a new feature called "User Interface Process Isolation"
(UIPI) was introduced, whereby processes can be further protected
against shatter attacks by assigning a "privilege level" to each
process. Attempts to send messages to (or interact with in any way via
the Windows API </wiki/Windows_API>) a process with a higher privilege
level will fail, even if both processes are owned by the same user.
Internet Explorer 7+ </wiki/Internet_Explorer>, for example, utilizes
this feature to prevent its rendering components from interacting with
the rest of the system.
As Aaron Margosis said. http://blogs.msdn.com/Aaron_Margosis/ aren't
they addressing this in Vista?
http://66.102.7.104/search?q=cache:OyUSKJKTE7wJ:security.tombom.co.uk/shatter.html+exploiting+design+flaws+in+the+Win32+api&hl=en&gl=us&ct=clnk&cd=1
Using a google cache for those that want to read the original Paget doc....
...and this thread...
http://archive.cert.uni-stuttgart.de/archive/bugtraq/2002/08/msg00167.html
"Chris, 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)
the chief blame lies with the vendor of the software whose bad
programming you are exploiting. There is no excuse to put a window for a
process with the LocalSystem security context on a user's desktop. I am
not aware of any Microsoft application that makes such a mistake. John
Howie "
Please note that thread is way back from way back in 2002.... it's a
crappy app...it gets back to demanding secure coding in everything that
I introduce in my firm... I can't hold Microsoft responsible for
Intuit's stupidity and lack of secure coding practices.. it's me and the
marketplace's fault for not making it a higher priority that they follow
secure coding guidelines than give me features and new buttons... or am
I missing something? Aren't they addressing it now in Vista?
More Vista stuff for those interested:
IT's Showtime:
http://www.microsoft.com/emea/itsshowtime/sessionh.aspx?videoid=223
*For most of the history of computing, operating systems have lived in
their own little bubbles of trust. Every part of an operating system
pretty much assumed that every other part was exactly what it claimed to
be and performed only what it claimed it could do. Recent attacks,
though, have shown that such implicit trust is no longer suitable for
computers that connect to hostile environments. In this session, Steve
Riley explores how these technologies work to thwart malware's attempts
to take over your computer.*
Denis Jedig wrote:
Susan,
thank you for your reply.
Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote:
Aaron Margosis says:
"Actually, not true. Services can no longer interact with the
desktop. Services that did always interacted with Session 0 (the
console session, in Windows pre-Vista), and were already broken with
XP's Fast User Switching and other terminal services scenarios, where
user sessions were frequently not session 0. On Vista, NO
interactive user session will be in session 0, so all those services
insisting on displaying UI will not do so on a desktop where a user
is running applications.
This is a valuable clarification.
Also, runas.exe etc do not result in elevated tokens - you can run
stuff under a different account, but it doesn't get a full-privileged
token."
However, I still can't get behind this one - if you run an application
under a different account, even if you don't get a full-priveleged
token, you might potentially be able to execute anything on behalf of
this account through shattering from another window on the same
desktop due to the very lack of UIPI for runas-run applications.
Denis
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
---------------------------------------------------------------------------
