Delivered-To: | dds@aueb.gr |
Return-Path: | <risks-bounces+dds=aueb.gr@csl.sri.com> |
Received: | from mailgate-internal2.sri.com ([::ffff:128.18.84.104]) |
by blue.servers.aueb.gr with esmtp; Mon, 27 Feb 2006 19:44:30 +0200 | |
id 000D11AC.44033A7F.00002FD6 | |
Received: | from localhost (HELO mailgate-internal2.SRI.COM) (127.0.0.1) |
by mailgate-internal2.sri.com with SMTP; 27 Feb 2006 18:00:20 -0000 | |
Received: | from postal.csl.sri.com ([130.107.1.19]) |
by mailgate-internal2.SRI.COM (SMSSMTP 4.1.11.41) with SMTP id M2006022710001928645 | |
for <dds@aueb.gr>; Mon, 27 Feb 2006 10:00:19 -0800 | |
Received: | from postal.csl.sri.com (localhost [127.0.0.1]) |
by postal.csl.sri.com (8.12.9p2/8.12.9) with ESMTP id k1RHXv6J069435 | |
for <dds@aueb.gr>; Mon, 27 Feb 2006 09:34:00 -0800 (PST) | |
(envelope-from risks-bounces+dds=aueb.gr@csl.sri.com) | |
From: | RISKS List Owner <risko@csl.sri.com> |
Date: | Mon, 27 Feb 2006 9:28:40 PST |
precedence: | bulk |
To: | risks-resend@csl.sri.com |
Message-ID: | <CMM.0.90.4.1141061320.risko@chiron.csl.sri.com> |
Cc: | |
Subject: | [RISKS] Risks Digest 24.17 |
List-Id: | RISKS <risks.csl.sri.com> |
List-Unsubscribe: | <http://lists.csl.sri.com/mailman/listinfo/risks>, |
<mailto:risks-request@csl.sri.com?subject=unsubscribe> | |
List-Post: | <mailto:risks@csl.sri.com> |
List-Help: | <mailto:risks-request@csl.sri.com?subject=help> |
List-Subscribe: | <http://lists.csl.sri.com/mailman/listinfo/risks>, |
<mailto:risks-request@csl.sri.com?subject=subscribe> | |
Sender: | risks-bounces+dds=aueb.gr@csl.sri.com |
Errors-To: | risks-bounces+dds=aueb.gr@csl.sri.com |
blue.servers.aueb.gr | |
autolearn=no version=3.0.3 |
RISKS-LIST: Risks-Forum Digest Monday 27 February 2006 Volume 24 : Issue 17 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/24.17.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> [...] ------------------------------ Date: Sun, 19 Feb 2006 19:06:25 +0200 From: Diomidis Spinellis <dds@aueb.gr> Subject: A Malfeasant Design for Lawful Interception Earlier this month it was revealed that more than 100 mobile phone numbers belonging mostly to members of the Greek government and top-ranking civil servants were found to have been illegally tapped for a period of at least one year [1]. Apparently, the tapping was implemented by activating Ericsson's lawful interception subsystem installed at the Vodafone service provider. How could this happen? After one looks at the design and implementation of Ericsson's Interception Management System (IMS), the real question that comes to mind is how come such events are not happening all them time (or maybe they are?) The system is clearly not designed with security in mind. The major problem of the design is the lack of compartmentalization. IMS is an extremely sensitive application, because it can setup and monitor the tapping of arbitrary phones. Good security engineering practice dictates that such applications should run isolated on trustworthy platforms, minimizing the surface area exposed to malicious attacks. In such a design the system's modules serve the same role as a ship's bulkheads: they provide structural stability and contain damage to specific areas. Instead, according to its user manual [2], IMS runs on top of Ericsson's general purpose AXE exchange network management platform XMATE, which in turn runs on top of a Solaris system chock-full of support software. Among other things, XMATE provides an application programming interface, a command terminal, a macro command tool, and a file transfer application. Any of those could be conceivably exploited to activate the IMS or its functionality. In addition, the XMATE Solaris installation includes many large third party applications: the Common Desktop Environment (CDE), the Applix business performance management software [3], X.25 networking, and the OSI file transfer (FTAM). Again, security vulnerabilities in these large components could be used to seize control of the system and activate the IMS. Even if the IMS was not installed on the network management platform, the design of the platform apparently allows a malicious user to craft the "remote control equipment" MML commands that set up voice communication monitoring and send them to the exchange. In a recent thought-provoking article Matt Blaze identified a number of signaling vulnerabilities in (mainly) older wiretapping systems [4]. Vulnerabilities associated with the way modern systems are designed and implemented are apparently also very important. Disclaimer: The above is my limited understanding, based on the few documents that are publicly available. Unfortunately, documentation that would allow independent experts to assess the security of these systems is scarce. The IMS User Manual [1], although available on a number of Internet sites, is marked with red letters as "Strictly Confidential". (I guess simply "Confidential" would mean that the manual was available for download from Ericsson.) Also, the ETSI standard TR 101 943 V2.1.1 (2004-10) states in section 7.3.2: "It is also to be recommended that operational information about the LI systems, such as how they are implemented, where they reside and how they are operated and maintained, should be kept within a small group of authorized persons." Another instance where obscurity is probably used as a cover for insecurity. [1] http://en.wikipedia.org/wiki/Greek_telephone_tapping_case_2004-2005 [2] http://cryptome.org/ericsson-ims.htm [3] http://www.applix.com/index.asp [4] http://www.crypto.com/papers/wiretapping/ Diomidis Spinellis - http://www.dmst.aueb.gr/dds [...] End of RISKS-FORUM Digest 24.17 ************************