Dear All,
The issue of vulnerabilities in event-driven systems has been mentioned
last month (7th July 2002) in the vuln-dev mailling list at
http://online.securityfocus.com/archive/82/280912/2002-07-04/2002-07-10/0
Perhaps vuln-dev is not that popular as bugtraq :'(. Time to switch
mailling lists.
As part of my studies (http://www.isg.rhul.ac.uk/~simos/) I examined
security issues in event-driven systems and the results have been
published in two (academic) papers, found at
http://www.isg.rhul.ac.uk/~simos/pub/
For the demonstration of these issues, there is a page available at
http://www.isg.rhul.ac.uk/~simos/event_demo/. There are also a
demonstration application and some exploitation ideas.
Regarding the issue whether event-driven system vulnerabilities are a
new type of attack or not, depends on how you classify a new attack. One
way to classify it is to regard an application as an independent entity
that can be attacked from specific types of "dangerous inputs" like
command line parameters, reading data from a file (like "gets()" reading
from STDIN) or reading data from the network. We describe an input as
dangerous if an attacker can manipulate it somehow. The command line
parameters of a SUID application is dangerous input, the cookies that a
WWW server is receiving from a WWW browser is dangerous FOR the WWW
server, the cookies that a WWW browser receives from a WWW server is
dangerous FOR the WWW browser and so on. In [Wheeler, 2002]** there is
such a list of dangerous inputs.
Thus, one way to classify classes of vulnerabilities is to arrange by
inputs that a potential attacker can manipulate. In our case, events
form such an input that an attacker can manipulate. Thus they can be
technically a new class of attacks.
These vulnerabilities exist in Windows because an attacker can
enumerate other people's windows and find the window handles. Then, the
attacker can send crafted events to those windows. The problem arises
from the fact that a "normal" user can send events to an
"administrative" account. The reason I see this happening is that of
usability. You can copy and paste between Windows from different users
and it's flexible to do so.
Furthermore, it is common in event-driven systems like Windows to have
"interface-based" security, that is, an application using the "window
controls" like text boxes to enforce security. An attacker can bypass
these security measures. It is similar to the JavaScript filtering in
specific WWW pages for information sent to CGI scripts. You can bypass
JavaScript and sent directly to the CGI script.
In addition, as [Forrester et al., 2000]* have shown, you have the
added issue of an application malfunctioning if it receives a sequence
of events that it was not designed to receive. The internal state of the
running application gets messed up and you can possible make it do
things that it should not do. This is due to the complicated
interactions of the different events that an application can receive and
can have consequences with other event-driven systems employed in
hardware devices, ATMs and so on.
Finally, an additional issue is the richness of the parameters of the
event types in Windows. You can put pointers to data structures (also
noted by [Forrester et al., 2000]*) or even addresses to subroutines as
it happens with the WM_TIMER event type [Xenitellis, 2002a]***,
[Xenitellis, 2002a]**** and more recently by Chris Paget at
http://security.tombom.co.uk/shatter.html
By using the functionality of window stations you can fix the issue.
However, as long as the attacker and victim windows run in the same
window station, I cannot see currently a way to filter events. There
could be filtering if the receiver of events could know what is the
origin of the event and cut off those that it does not feel comfortable
with. This is putting access controls to the fuctionality of sending
events. However, it will make things more complicated for application
writers.
The way I see all these being handled by the software companies is
through the "risk management" cycle. If there is a high profile
incident, then something may happen. Otherwise things will stay the
same. It happens all the time. It's a rule of nature.
Thanks for your time,
Simos Xenitellis
* Forrester, J.E. and Miller, B.P. (2000) An empirical study of the
robustness of Windows NT applications using random testing, In
Proceedings of 4th USENIX Windows System Symposium, USENIX.
** Wheeler, David (2002), Secure Programming for Linux and Unix HOWTO.
http://www.dwheeler.com/secure-programs/, 2002.
*** Simeon Xenitellis (2002a), "Security vulnerabilities in Event-Driven
Systems ", IFIP / SEC2002 Security in the Information Society : Visions
and Perspectives, May 7-9, 2002, Cairo, Egypt, In Security in the
Information Society: Visions and Perspectives, Kluwer Academic Press,
pages 147-160.
**** Simeon Xenitellis (2002b), "A New Avenue of Attack: Event-driven
System Vulnerabilities", ECIW 2002: The European Conference on
Information Warfare and Security, July 8-9, 2002, Brunel, Uxbridge, UK,
In Proceedings of European Conference on Information Warfare and
Security, pages 177-185.
signature.asc
Description: PGP signature
