New NSA-funded programming language could close long-standing security holes

According to Steve McConnell, author of "Code Complete", software development projects that reach 512,000 lines of code or more can see four to 100 coding errors per thousand lines of code. Coding errors create the software vulnerabilities that criminal hackers attack in order to enter and pillage the enterprise. Anything that can help to prevent those holes should be of interest to CISOs and their teams.

One example is the NSA-funded, research-based Wyvern programming language from Carnegie-Mellon University. Wyvern seeks to limit coding errors by various means including enabling the use of five different programming languages inside the host language in a secure manner, according to Jonathan Aldrich, associate professor, the Institute for Software Research in the School of Computer Science, Carnegie-Mellon University. Aldrich is the research group leader for the group behind the Wyvern project.

But not everyone is convinced that Wyvern is on the right track. In fact, Wyvern could be vulnerable to attack, according to Robert Coleridge, CTO, Secure Channels. Coleridge is a 40-year veteran software engineer. Secure Channels just patented a new encryption technology that 155 black hat hackers at Black Hat USA 2014 failed to break, according to a Secure Channels media release.

CSO explores the potential and the risk of Wyvern.

Wyvern, Programming Languages, and Security

The Wyvern Programming Language is a host language that enables developers to import any five programming languages for use on a software project, says Aldrich. Programmers can import existing languages or languages that they create that are uniquely equipped with the proper expressiveness for their industry domain. They or anyone in their field can import that language into Wyvern and use it with other languages, Aldrich explains. So extensibility is one of Wyvern's strengths.

Programmers need to use multiple languages to complete projects. "One language is not enough because different problems and solutions are expressed in different ways," says Aldrich. For example, SQL is optimized to describe queries to databases and has advantages over the query language for C#. This is one example of why coders prefer to go outside a single language to incorporate other languages.

Programmers can already include multiple programming languages in projects but the way they do it today introduces coding errors, according to Aldrich. Today, they use strings to code database queries into projects by first importing a database library, then passing strings to it, which interpret the libraries as a domain-specific database. These strings are not as safe as writing actual SQL queries in SQL, according to Aldrich.

In another example, HTML is great for expressing the structure of web pages. Developers can use strings to include HTML but, again, strings are not as secure as using HTML itself, Aldrich says. "HTML strings can lead to cross site scripting errors, for example," says Aldrich. Wyvern will offer each language the developer cares to add as a native extension inside the host language.

Wyvern further seeks to address software vulnerabilities by fixing a core technical issue, i.e., the lack of modular extensibility. "Today, we can already import a library and use that library to write SQL into our code. But if that library approach is not modular, the library can conflict with other programming libraries," says Aldrich. So, for example, if a developer has two languages that use less than and greater than delimiters, there could be conflicts. "The conflict occurs when the compiler sees ambiguous source code that could be part of more than one language. The compiler can't do its job properly when this happens and the program either won't run or won't run properly. We fixed that in that even if the languages overlap in syntax they are guaranteed not to conflict," says Aldrich.

The Wyvern language uses what Aldrich calls types to avoid these conflicts. Because a developer selects a type, Wyvern will tell the programmer what language she can use with that type, and this will ensure proper interpretation of the code as belonging to the one language and not the other. "We have associated a syntax for a new language for each type optionally, using a domain-specific notation," says Aldrich; "adding the domain-specific notation helps the programmer express the program more efficiently and without introducing security vulnerabilities". Associating the domain-specific notation with the type ensures that the compiler can always tell what the intended language is.

That's not all CMU plans for Wyvern's security enhancements. Wyvern project developers would like to add architectural control as a feature of the language. According to Aldrich, this would give development project leads additional tools and a compiler to ensure that all developer team members follow the required security practices to maintain secure coding and avoid coding errors. "Perhaps the lead developer insists that because they are writing distributed systems, the developers must use TLS. So, the lead developer could use the architectural control mechanism to ensure that no developer can introduce a code patch allowing non-encrypted communication with a server," Aldrich explains.

Wyvern Programming Logic

While Aldrich holds that strings can be responsible for unsecure coding, Coleridge contends that these strings are just a bunch of ones and zeros and are inherently not vulnerable or dangerous. "It is how the developer compiles the code and whether it is coded securely that can make software unsecure. But software cannot be unsecure solely based on whether you choose to use strings," says Coleridge.

And though Aldrich communicated that Wyvern could use architectural control to maintain secure coding practices, Coleridge says that architectural control and maintaining secure coding practices are two ideas that don't really have anything to do with each other. And for those concerned about either one, the solutions exist on the market today. "There are already good tools out there for both architectural control and to make sure developers follow secure coding practices," says Coleridge.

According to Aldrich, the goal of Wyvern is to improve secure coding.

But, Wyvern is a meta-language, not a true programming language, which intends to allow people to use different languages, explains Coleridge. "With anything that flexible, it could be easy to slip malware and viruses into it," says Coleridge. If that is true, Wyvern could be a new source of vulnerabilities rather than the cure.

Selection criteria for NSA funding

In 2013, the NSA distributed a broad announcement to approximately 200 university departments about available funding for small research labs or lablets for unclassified research into fundamental scientific components of cybersecurity in order to create a scientific foundation for security. "This effort is aimed at providing the nation with assurance in its information systems," says Stuart Krohn, Technical Director for the Science of Security, the NSA. The CMU research proposal was one of only four that the NSA eventually funded under the Science of Security initiative.

The NSA selected the CMU research because CMU's research proposal addressed finding scientific bases for creation and scalability of security components so the nation can trust the resulting systems. Success means Wyvern could help developers to construct secure systems with known security properties without having to re-analyze the components themselves. These are hard problems.

Enterprise Security

Whether Wyvern sinks or swims, the larger goal of the project is right on target. While enterprises have focused on network security, people are realizing that it is equally important to have developers write applications in a secure manner. "Attackers can find a way inside the network to attack those applications. For end-to-end security, every application should be secure," says Aldrich. The CMU developers intend Wyvern to address that.

Join the CSO newsletter!

Error: Please check your email address.

Tags applicationssecurityData Protection | Application SecuritynsaAccess control and authenticationsoftwaredata protection

More about CSOMellonNSA

Show Comments

Featured Whitepapers

Editor's Recommendations

Solution Centres

Stories by David Geer

Latest Videos

  • 150x50

    CSO Webinar: Will your data protection strategy be enough when disaster strikes?

    Speakers: - Paul O’Connor, Engagement leader - Performance Audit Group, Victorian Auditor-General’s Office (VAGO) - Nigel Phair, Managing Director, Centre for Internet Safety - Joshua Stenhouse, Technical Evangelist, Zerto - Anthony Caruana, CSO MC & Moderator

    Play Video

  • 150x50

    CSO Webinar: The Human Factor - Your people are your biggest security weakness

    ​Speakers: David Lacey, Researcher and former CISO Royal Mail David Turner - Global Risk Management Expert Mark Guntrip - Group Manager, Email Protection, Proofpoint

    Play Video

  • 150x50

    CSO Webinar: Current ransomware defences are failing – but machine learning can drive a more proactive solution

    Speakers • Ty Miller, Director, Threat Intelligence • Mark Gregory, Leader, Network Engineering Research Group, RMIT • Jeff Lanza, Retired FBI Agent (USA) • Andy Solterbeck, VP Asia Pacific, Cylance • David Braue, CSO MC/Moderator What to expect: ​Hear from industry experts on the local and global ransomware threat landscape. Explore a new approach to dealing with ransomware using machine-learning techniques and by thinking about the problem in a fundamentally different way. Apply techniques for gathering insight into ransomware behaviour and find out what elements must go into a truly effective ransomware defence. Get a first-hand look at how ransomware actually works in practice, and how machine-learning techniques can pick up on its activities long before your employees do.

    Play Video

  • 150x50

    CSO Webinar: Get real about metadata to avoid a false sense of security

    Speakers: • Anthony Caruana – CSO MC and moderator • Ian Farquhar, Worldwide Virtual Security Team Lead, Gigamon • John Lindsay, Former CTO, iiNet • Skeeve Stevens, Futurist, Future Sumo • David Vaile - Vice chair of APF, Co-Convenor of the Cyberspace Law And Policy Community, UNSW Law Faculty This webinar covers: - A 101 on metadata - what it is and how to use it - Insight into a typical attack, what happens and what we would find when looking into the metadata - How to collect metadata, use this to detect attacks and get greater insight into how you can use this to protect your organisation - Learn how much raw data and metadata to retain and how long for - Get a reality check on how you're using your metadata and if this is enough to secure your organisation

    Play Video

  • 150x50

    CSO Webinar: How banking trojans work and how you can stop them

    CSO Webinar: How banking trojans work and how you can stop them Featuring: • John Baird, Director of Global Technology Production, Deutsche Bank • Samantha Macleod, GM Cyber Security, ME Bank • Sherrod DeGrippo, Director of Emerging Threats, Proofpoint (USA)

    Play Video

More videos

Blog Posts

Market Place