Categories:
/ (30)
discoveries/ (1)
events/ (5)
humor/ (6)
paradigms/ (3)
rants/ (3)
New developments, especially if they receive a name and media attention before the actors actually managed to fill the name with something, tend to generate a lot of fuzz and inaccurate information. It is an unfortunate fact that the security community is usually riding in the first coach of the FUD [1] train. Remember Y2K and Prof. Brunnstein [2,3]?
One of the primary reasons for the leading FUD role of the security community might be the mental process of reviewing a new system or set of systems for attack surfaces. In the beginning, the entire system is seen as a whole. Then, gradually, individual parts of functionality, their intention and implementation are considered in greater detail. Most of the time, a gap between intention and design or intention and implementation is uncovered sooner or later. This gap of course is only present in the small part of the system you are currently looking at.
What often follows is the false application of the same process backwards when considering the impact and importance of the discovery. It goes like this:
Although none of the observations above is provably wrong, the thought process of a security review is not useful for impact considerations. Many other factors play into the impact of a discovery and deserve a special, case-by-case consideration.
The Web 2.0 has all the potential for the next big wave of FUD in security. First of all, it's not done yet. We are seeing new players on the Web but the general direction of developments is sketchy at best. One of the more solid observations is that the Web 2.0 is a work of composition from known technologies at a higher abstraction level than before. Most components are not reinvented but rearranged and adjusted. This leads to some of the lesser-known components and especially patterns [6] to be considered new, revolutionary developments [4].
The new Web primarily teaches us lessons we should already know. Basics like the fact that perimeter security cannot work in networked environments, since they wouldn't be networked if it did - think mesh-ups. Basics like: defence in depth is one of the few paradigms that actually have a chance to work in the wild and keep complex systems alive. But we knew that before, didn't we?
Another indication for a new FUD wave is usually a massive increase in predictions of the future ("Some times, I get the feeling that old generation of security experts and hackers will never grasp this principles the way the upcomming waves will."[4]) and, if the predictions are not coming along fast enough, they receive help from the prognosticator ("The spider that I wrote is anything by malicious. It just spiders. However, keep in mind that it will take less then 5 minutes to make it equipped with the latest AJAX exploits. Therefore, I am not responsible for your actions. Be responsible. Here is the spider source code"[5]).
It should really be noted that there are plenty of security problems to be solved in existing and emerging environments. A security problem is not less sexy just because it doesn't affect millions of innocent users. In fact, the singular focus on the next world-smashing security issues obscures the view onto underlying issues and especially simple and reliable solutions that are sitting just around the corner, waiting to be discovered by the sensationalist crowd. There is really no need for more FUD, we got plenty of real work to do.
Update
pdp was nice enough to point me to the following discussion about this
article that I want to share:
http://sla.ckers.org/forum/read.php?13,13871
Thanks man.
References
posted at: 19:17 by FX | path: /rants | permanent link to this entry
By now I have come to accept that around Y2K the music industry decided that innovation is no longer needed and they can well make enough money by reselling and covering pretty much every song ever written between 1960 and 1999. What's fascinating me is that vendors in the computer industry have come to the same conclusion regarding the security of their products. I can only see two potential reasons behind this:
Congratulations to Sun Microsystems, you successfully moved the Internet over a decade back in time. As of today, we have a new worm spreading, exploiting an authentication vulnerability in telnet of all things! In Solaris (SunOS 5.10 and 5.11), you must know, there is no need to actually posses the password of a telnet user. All you need to do to get a shell with the privileges of the user "adm" is:
SomeLinux$ telnet -l "-fadm" my.poor.sun.isp.net
The same would work for root, but luckily the default installation of Solaris does not allow remote root telnet logins. Not only is this an ages old type of vulnerability, it's reintroduced by Sun into their latest operating system. How on earth can QA miss something like that? In 1995, this type of vulnerability hit a long list of UNIX vendors (see here). Therefore, when hacking around in their telnetd implementation, I would expect that at least someone would check if this new feature they are implementing might be a very bad idea indeed.
But Sun just picks up where Cisco is leading the pack right now. Let's take a look at a few of their recent publications:
cisco-sa-20070228-nam NAMs communicate with the Catalyst system by using the Simple Network Management Protocol (SNMP). By spoofing the SNMP communication between the Catalyst system and the NAM an attacker may obtain complete control of the Catalyst system."
cisco-sa-20070214-pix Multiple vulnerabilities are found in Cisco PIX 500 Series Security Appliances and the Cisco ASA 5500 Series Adaptive Security Appliances. They affect the following: Enhanced inspection of Malformed Hypertext Transfer Protocol (HTTP) traffic, Inspection of malformed Session Initiation Protocol (SIP) packets, Inspection of a stream of malformed Transmission Control Protocol (TCP) packets [...]
cisco-sa-20070213-iosips The Intrusion Prevention System (IPS) feature set of Cisco IOSŪ contains several vulnerabilities. These include: Fragmented IP packets may be used to evade signature inspection, IPS signatures utilizing the regular expression feature of the ATOMIC.TCP signature engine may cause a router to crash resulting in a denial of service.
cisco-sa-20070124-crafted-tcp The Cisco IOS Transmission Control Protocol (TCP) listener in certain versions of Cisco IOS software is vulnerable to a remotely-exploitable memory leak that may lead to a denial of service condition.
cisco-sa-20070124-crafted-ip-option Cisco routers and switches running Cisco IOSŪ or Cisco IOS XR software may be vulnerable to a remotely exploitable crafted IP option Denial of Service (DoS) attack. Exploitation of the vulnerability may potentially allow for arbitrary code execution. The vulnerability may be exploited after processing an Internet Control Message Protocol (ICMP) packet, Protocol Independent Multicast version 2 (PIMv2) packet, Pragmatic General Multicast (PGM) packet, or URL Rendezvous Directory (URD) packet containing a specific crafted IP option in the packet's IP header.
cisco-sa-20070118-certs The Cisco Security Monitoring, Analysis and Response System (CS-MARS) and the Cisco Adaptive Security Device Manager (ASDM) do not validate the Secure Sockets Layer (SSL)/Transport Layer Security (TLS) certificates or Secure Shell (SSH) public keys presented by devices they are configured to connect to.
cisco-sa-20070105-csacs Certain versions of Cisco Secure Access Control Server (ACS) for Windows and the Cisco Secure ACS Solution Engine (here after both referred to as purely Cisco Secure ACS) are affected by multiple vulnerabilities that cause specific Cisco Secure services to crash. Two of the vulnerabilities may permit arbitrary code execution after exploitation of the specified vulnerability.
cisco-sa-20061025-csa Cisco Security Agent (CSA) for Linux contains a denial of service vulnerability involving port scans. By performing a port scan against a system running a vulnerable version of CSA, it is possible to cause the system to become unresponsive. Cisco Unified CallManager (CUCM) and Cisco Unified Presence Server (CUPS) ship with a vulnerable CSA version.
I'm sorry this list gets so long, but I'm really trying to just focus on the glaringly silly ones. To sum it up, Cisco's security software and appliances crash when being presented with port scans or intentionally malformed packets. Duh! Hello Cisco! These are the devices your customers are paying a lot of money for to protect them against the exact threats they are vulnerable against! And a security analysis and response system that doesn't even validate any SSL certificate or SSH key? What did your QA exactly test under the functionality topic of authentication? Something along the lines of: "I logged in - check."?
At least the picture is consistent. Sun, shipping UNIX since 1982, reintroduces a vulnerability type that was considered extinct for more than a decade. Cisco, shipping IP routers since 1987, notices in 2007 that they still don't know how to correctly parse IPv4 options in a ping packet, even with their latest and greatest IOS XR.
So far, there have been no provable relations between a company's turnover, stock price and market share and their security track record. The only exception is of course Microsoft. I wonder if that's what is really needed to make the other big ones understand the enormous responsibility they have due to the cheer amount of today's daily life functionality depending on their code. After all, when looking at the professional and social life in today's Internet, it is indeed 2007 and not back in the 90s. Turn off all Cisco equipment on the Internet and try to do your daily job - it might get a little bit more difficult than usual.
posted at: 13:49 by FX | path: /rants | permanent link to this entry
When people announce that they have found a vulnerability in something that should be really secure, it should always trigger interest with reservations. Yesterday, a contracting consultant currently working for us announced that he identified a bug in the reference implementation of the Twofish crypto cipher. While this would not have been the first time in our halls that an issue in a cryptographic reference implementation was identified, it astonished me.
At first sight, the code he showed did indeed look like a variable initialization was missing:
DWORD RS_MDS_Encode(DWORD k0,DWORD k1)
{
int i,j;
DWORD r;
for (i=r=0;i<2;i++)
{
r ^= (i) ? k0 : k1; /* merge in 32 more key bits */
for (j=0;j<4;j++) /* shift one byte at a time */
RS_rem(r);
}
return r;
}
The initialization of the variable r wasn't really obvious and I missed it too. Frankly, my annoyance was significant since we are currently helping a customer to design a security protocol with Twofish being one of the cornerstones, due to the cipher's strength and conservative design. And we went to great lengths to get it right, getting a cryptographer on board for the project and verifying everything over and over again. The prospect of looking at a broken reference implementation wasn't really what I wanted to hear.
After reviewing the code today, it quickly became obvious that there was no bug in the function; it initializes r when entering the loop. But, while looking at the reference implementation, I noticed the following comment at the beginning of the file:
Notes: * Pedagogical version (non-optimized) * Tab size is set to 4 characters in this file
While browsing the source code, I immediately stumbled over a few lines such as:
/* works for big and little endian! */ d[i/8] |= b << (4*((i^1)&7));or
outBuffer[n/8] = (outBuffer[n/8] & ~ bit) |
(ctBit ^ ((((BYTE *) x)[0] & 0x80) >> (n&7)));
And I have to say: with all due respect, this is everything but pedagogical code. What is the point of presenting the pedagogical reference implementation of a cryptographic algorithm in a language such as C, where out of bounds array access isn't really noticed and one can write code such as the examples shown above? To teach students that really important code must look like this? If this is not optimized for actual use, why not present the code in a readable form, computing everything one step at a time and preferably in a programming language that doesn't look like a someone rolled an armadillo over his keyboard?
Schneier and Ferguson correctly state in their book "Practical Cryptography" that complexity kills most security systems and that the only known way of handling complexity is to modularize the problem into chunks that the human mind can handle. This advice should be adjusted to read: chunks that an average human mind can handle. I know that many people are proud of their brilliance, rightfully or not, but that's not the point.
Cryptography is fragile and delicate enough by nature. But it is also a very important building block of many security systems. Therefore, many programmers must implement cryptography in their respective programming languages and some of them may not be able to correctly understand either the C gibberish in the reference implementation or the LaTeX special math character party in the official Twofish paper. May be it's just my world view as a consultant, but we always try to explain demanding content as simple as possible while still being correct, which is in fact the real challenge.
A common answer is: If people don't understand it completely, they should not implement crypto. This seems simple enough, but the number of people in the world who do not fall under this rule is too small compared to the amount of software that needs protection. We need security mechanisms most programmers (and auditors) can handle; otherwise we will keep producing insecure software. Not even the most brilliant person can write all his programs himself without the need to trust another, potentially unknown programmer. And the other programmer will, be definition, be less brilliant.
Schneier and Ferguson keep repeating the following important sentence in their book: "We have enough high performance insecure systems, we don't need another one." They are totally right. But with all due respect, please consider this rule yourself next time.
posted at: 13:37 by FX | path: /rants | permanent link to this entry