Risk //

Compliance

4/3/2013
02:37 AM
50%
50%

Taming Bad Inputs Means Taking Aim At 'Weird Machines'

Overly accommodating platforms and protocols let attackers use inputs like code, essentially allowing attackers to program an unintentional virtual machine

In 2002, Microsoft CEO Steve Ballmer argued that vulnerabilities are a fact of life: "Let's acknowledge a sad truth about software: any code of significant scope and power will have bugs in it," he stated in a much publicized memo at the time.

While a decade of vulnerability research and software development have only reinforced the claim, security and academic researchers have continued to look for ways to eradicate bugs -- or at least minimize their impact -- on systems. One of the most practical approaches, known as LangSec, evolved from studying the methods that hackers took in exploiting software using a system's unintended reactions to crafted inputs essentially as a programming language.

"Because of this computational power, the code that handles complex data is really indistinguishable from a virtual machine to which the data serves as byte code, making any input a program," says Sergey Bratus, research assistant professor at Dartmouth College and one of the researchers leading the LangSec project.

LangSec, created by technologist Meredith Patterson and cryptographer Len Sassaman, aims to eliminate the scattershot techniques for sanitizing inputs and instead create the simplest set of allowable inputs -- a language -- that minimizes the risk of unintended consequences. In a presentation at the Shmoocon conference in February, Patterson and Bratus recommended that software developers direct data through a program component, or recognizer, designed to check the validity of the input against a minimal language.

The current trend in accepting as large a variety of inputs as possible -- and going so far as to attempt to correct potential input errors -- contributes to insecurity, Bratus says. Allowing a complex language turns a software program into a "weird machine" that does not act as expected and can be controlled by an attacker, he says.

"We are doing input processing wrong," Bratus says. "The part of the program that handles inputs should be as limiting as possible. The theory provides good guidance on what that means."

While user inputs are a major cause of software vulnerability, many other classes of security weaknesses exist. The LangSec approach provides one tool for programmers to create more secure code, says Fred Schneider, Samuel B. Eckert Professor of Computer Science at Cornell University.

"What they are doing is building an input filter for their programs -- a kind of firewall," Schneider says. "It will defend against some attacks, but not all."

[Taking a page from the metrics used to rank tornadoes and software vulnerabilities, attack-mitigation firms look to find a better measure of denial-of-service attacks than bandwidth and duration. See New Metric Would Score The Impact, Threat Of DDoS To An Enterprise.]

For more than a decade, Schneider and colleagues from Carnegie Mellon University and Harvard University have focused their efforts on creating a more general foundation for building security into the programming languages used by developers. By creating a security policy and using specific techniques to enforce the policy on programs, the approach -- known as Language-Based Security -- can create programming languages that force a user to write secure code.

"It is possible to design programming languages in which the programmer is coerced into telling the compiler -- that is, by writing some details into the program -- enough information so that the compiler is almost certain to prevent the compilation of a program that has certain classes of bugs," he says.

Schneider and his colleagues are currently working on exporting the language-based security techniques to the real world.

Because the LangSec project came from work done in the security community and its goals are more modest, it could have an easier time being adopted, however. Already, some security-software developers have started creating recognizers to secure their own projects, Bratus says.

"It's about building armored recognizers, and building the fortifications and building it properly according to science and engineering," he says. "At some point, you will stop fearing your inputs, and much of this uncertainty and doubt will go away."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Microsoft Word Vuln Went Unnoticed for 17 Years: Report
Kelly Sheridan, Associate Editor, Dark Reading,  11/14/2017
Companies Blindly Believe They've Locked Down Users' Mobile Use
Dawn Kawamoto, Associate Editor, Dark Reading,  11/14/2017
121 Pieces of Malware Flagged on NSA Employee's Home Computer
Kelly Jackson Higgins, Executive Editor at Dark Reading,  11/16/2017
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Managing Cyber-Risk
An online breach could have a huge impact on your organization. Here are some strategies for measuring and managing that risk.
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.