Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Analytics

2/27/2007
03:20 AM
50%
50%

Security's Symbiosis

Let's face a simple truth: Hackers (white and black hat alike) and vendors need each other

This breaking story just in:

    0wn3d Ltd. in conjunction with Cigital Inc. announced the recent discovery of a kernel level exploit in the Gary McGraw automaton. The exploit involves the simple application of ice to McGraw's front walk. If properly applied, McGraw will collapse under his own weight as he walks over the ice, causing severe structural damage to multiple leg bones and requiring hours of surgical correction.

Way too many of these kinds of vulnerability announcements go by in one week on mailing lists such as bugtraq, vulnwatch, and security tracker. Without security researchers to keep vendors in line, we would not make anywhere near as much progress in security. But in many cases security researchers seem only to be in the game for fame and glory, making things less secure as vendors scramble to fix problems. How much disclosure is enough? Do we really need it?

Vulnerability Pimps Suck
In a recent paper titled "Teaching an Old Dog New Tricks," security guru Marcus Ranum argues that independent "security researchers" who spend their time constantly looking for security bugs are a drain on the security community. He even has a name for these people: vulnerability pimps.

He thinks that if these people were really serious about security they would join product security teams at the vendors and eschew their 15 seconds of fame on CNN or at DEFCON.

Marcus does not approve of releasing any information at all about bugs that will place people at risk, regardless of other reasons. And he practices what he preaches. When he recently used Fortify to discover a number of exploitable buffer overflows in the venerable fwtk firewall toolkit (which he helped to create back in the Pleistocene era), he didn't gleefully run to the press or even write the exploits up for bugtraq. Instead, he contacted the owners of the appropriate modules and told them what he had found.

As he says:

    Contrary to the ideology of the "full disclosure" crowd, everyone I contacted was extremely responsive and assured me that the bugs would be fixed and in the next release; No hooplah, no press briefing, no rushing out a patch. I won't get my fifteen minutes of fame on CNN but that's all right. I'd rather be part of the solution than part of the problem.

Vendors Need a Little Push
I don't completely agree with Marcus, probably because of my own security past. In the mid '90s when I was working with the Princeton team to break Java, we had a hard time getting Sun, Netscape (remember them?), and Microsoft to take our discoveries seriously. We learned that only through a careful process of very public disclosure could we get them to acknowledge and, more importantly, fix the serious security problems that we constantly uncovered.

Over time, the companies began to understand that we were serious about security and when we called they paid attention. But in the beginning when we were "anonymous," they often had better things to do.

The last thing on our minds back then was coverage in the Wall Street Journal. We came to find that the press could be used to leverage huge corporations into responsible action where they would otherwise turn a deaf ear.

Where we do agree with Marcus is in the nature of disclosure. We were very careful not to release information that would allow rampant attacks on unfixed systems. This was pretty easy to do. Instead of publishing exploit code, we published detailed descriptions of the vulnerabilities and only shared the exploits themselves with the vendors.

Of course a determined attacker could have taken our explanations and reconstructed working exploits, but in 10 years of very public exposure, this never happened once. It turns out that most malicious hackers are lazy buggers! What did happen was that many people learned important lessons about software security and mobile code, from two critical perspectives -- attack and defense.

The problem with Marcus' theory is a naïve belief that vendors will always do the right thing given the opportunity. Sometimes they just don't. Some particularly important security researchers doing essential work in software security know this, and they are more than happy to use public disclosure and the power of the press to move vendors in the right direction:

  • David Litchfield of Next Generation Security Software has led a campaign to keep Oracle from BS'ing its way through security by holding the vendor accountable for its patches, scrutinizing its approach to software security, and countering its impressive, self-congratulatory publicity machine.
  • Avi Rubin and Ed Felten have done the same thing for Diebold on the electronic voting machine front. Unfortunately, Diebold continues to insist on security idiocy to the detriment of our democracy.
  • Greg Hoglund and I embarked on a campaign to bring security light to online games where hacking has become a real business and a majority of the millions of users of these systems have no idea what's going on (see our upcoming book Exploiting Online Games).

Sometimes vendors cooperate immediately, especially when you are a well known security guru (Marcus). Sometimes vendors need a bit of a nudge in the right direction. And sometimes vendors remain recalcitrant even in the face of public pressure and outcry.

Proper Security & the Dark Arts
I designed a modified yin-yang brand for the cover of my book Software Security: Building Security In (now the logo for Addison-Wesley’s Software Security Series which I edit). This is not just geeky eye candy -- there's a philosophical approach to security implied by the image.

Figure 1:
www.swsec.com

The yin-yang design is the classic Eastern symbol used to describe the inextricable mixing of standard Western polemics (black/white, good/evil, heaven/hell, etc.). Eastern philosophies are described as holistic because they teach that reality combines polemics in such a way that one pole cannot be sundered from the other.

In the case of software security, two distinct threads -- black hat activities and white hat activities (offense/defense, construction/destruction) -- intertwine to make up software security. A holistic approach, combining yin and yang, black hat and white hat, is required.

In my view, security absolutely requires a mix of destructive and constructive activities. Destructive activities are about attacks, exploits, and breaking software -- the kinds of things that vulnerability pimps do. These kinds of things are represented by the black hat (offense). Constructive activities are about design, defense, and functionality -- the kinds of things that vendors should be concentrating more resources on. These are represented by the white hat (defense). Both hats are necessary.

Ultimately we need disclosure, and there is a clear role for security researchers. Meanwhile, I have to get back to patching the Gary McGraw automaton.

Gary McGraw is CTO of Cigital Inc. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 4/7/2020
The Coronavirus & Cybersecurity: 3 Areas of Exploitation
Robert R. Ackerman Jr., Founder & Managing Director, Allegis Capital,  4/7/2020
'Unkillable' Android Malware App Continues to Infect Devices Worldwide
Jai Vijayan, Contributing Writer,  4/8/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-1633
PUBLISHED: 2020-04-09
Due to a new NDP proxy feature for EVPN leaf nodes introduced in Junos OS 17.4, crafted NDPv6 packets could transit a Junos device configured as a Broadband Network Gateway (BNG) and reach the EVPN leaf node, causing a stale MAC address entry. This could cause legitimate traffic to be discarded, le...
CVE-2020-8834
PUBLISHED: 2020-04-09
KVM in the Linux kernel on Power8 processors has a conflicting use of HSTATE_HOST_R1 to store r1 state in kvmppc_hv_entry plus in kvmppc__tm, leading to a stack corruption. Because of this, an attacker with the ability run code in kernel space of a guest VM can cause the host kernel to...
CVE-2020-11668
PUBLISHED: 2020-04-09
In the Linux kernel before 5.6.1, drivers/media/usb/gspca/xirlink_cit.c (aka the Xirlink camera USB driver) mishandles invalid descriptors, aka CID-a246b4d54770.
CVE-2020-8961
PUBLISHED: 2020-04-09
An issue was discovered in Avira Free-Antivirus before 15.0.2004.1825. The Self-Protection feature does not prohibit a write operation from an external process. Thus, code injection can be used to turn off this feature. After that, one can construct an event that will modify a file at a specific loc...
CVE-2020-7922
PUBLISHED: 2020-04-09
X.509 certificates generated by the MongoDB Enterprise Kubernetes Operator may allow an attacker with access to the Kubernetes cluster improper access to MongoDB instances. Customers who do not use X.509 authentication, and those who do not use the Operator to generate their X.509 certificates are u...