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.
This archive was generated by hypermail 2b30 : Fri Aug 09 2002 - 10:35:25 PDT