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.

Application Security

Security Lessons From a New Programming Language

A security professional needed a secure language for IoT development. So he wrote his own, applying learned lessons about memory and resources in the process.

When a security researcher needs to create an application, there are many choices in terms of programming languages and frameworks. But when project requirements include SSL and an embedded Internet of Things (IoT) platform, the number of good options becomes limited. That's why Thomas Pornin decided to build his own language.

Pornin, who is technical director and member of the cryptography services practice at NCC Group, has been thinking about programming languages, their strengths, and their weaknesses for more than 30 years. He has worked on many different, complex tech deployments and has the experience of launching an open source project, BearSSL, an SSL stack that is smaller than most SSL implementations available to developers.

The language Pornin wanted to build had two significant requirements: First, its resulting applications had to fit onto a resource-constrained IoT device, and that those applications performed reasonably well. Next, the applications developed using the language would not be subject to certain built-in vulnerabilities seen in some applications. Those vulnerabilities tend to revolve around the way the processor allocates and uses memory, so Pornin focused on memory in his thinking about language security.

Getting the project started took time. "I took care to write a big specification, a 65-page document," Pornin says. "In it, I explained how it should work and why it should work that way."

From Spec to Language
The initial specification was the basis for T0, Pornin's first pass at the programming language. T0 was designed to create applications that would work on an embedded system — defined as one with severely limited memory resources, a CPU that's not very powerful, no memory management unit, and no operating system to mediate the application's interaction with the hardware.

Pornin decided to base the design of his secure IoT language on Forth — a programming language that is oriented around the idea of stacks (memory structures where the last item pushed in is the first thing pulled out). He says the decision was partially driven by practical considerations about the discipline that stacks impose on the way memory is used, and partially by aesthetics. The stack orientation means that Forth code uses a distinctive notation (Reverse Polish Notation) familiar to anyone who used an HP calculator without the "=" key.

T0 was able to create compact, operational code. Pornin simplified the job of writing the T0 compiler by having it produce C source code as its output — code that then had to be recompiled and linked into the final executable code using an existing C compiler. It was much of what he wanted, but it was not yet secure. That waited for T1.

The Next Step
In T1, which Pornin described in a presentation at NorthSec 2019, protection for memory and restrictions on stacks were introduced. While Pornin is still working on building out the details of T1 and creating the full compiler for the language, he believes the language is moving in his desired direction.

There are already a number of languages that can be used for embedded applications. Depending on the hardware in use, C, Java ME, Go, Rust Embedded, and Forth may be possibilities. So does Pornin think other security practitioners should write their own programming languages?

"I think that anybody who is really serious about development should have the idea somewhere in their head," he says. "They should think about what they would like to see in a programming language." He adds with a laugh, "And it would also be good for people at large if most would stop before actually doing it."

It is useful, though, for developers and security practitioners to understand how the compilers work and the sort of code they produce. Understanding whether they create code that makes the most of memory protection and memory structures available in the hardware can help them write more secure, more robust applications.

Related Content:

 

Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions, and service providers in the Business Hall. Click for information on the conference and to register.

 

 

 

 

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Edge-DRsplash-10-edge-articles
7 Old IT Things Every New InfoSec Pro Should Know
Joan Goodchild, Staff Editor,  4/20/2021
News
Cloud-Native Businesses Struggle With Security
Robert Lemos, Contributing Writer,  5/6/2021
Commentary
Defending Against Web Scraping Attacks
Rob Simon, Principal Security Consultant at TrustedSec,  5/7/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-29040
PUBLISHED: 2021-05-16
The JSON web services in Liferay Portal 7.3.4 and earlier, and Liferay DXP 7.0 before fix pack 97, 7.1 before fix pack 20 and 7.2 before fix pack 10 may provide overly verbose error messages, which allows remote attackers to use the contents of error messages to help launch another, more focused att...
CVE-2021-29041
PUBLISHED: 2021-05-16
Denial-of-service (DoS) vulnerability in the Multi-Factor Authentication module in Liferay DXP 7.3 before fix pack 1 allows remote authenticated attackers to prevent any user from authenticating by (1) enabling Time-based One-time password (TOTP) on behalf of the other user or (2) modifying the othe...
CVE-2021-29047
PUBLISHED: 2021-05-16
The SimpleCaptcha implementation in Liferay Portal 7.3.4, 7.3.5 and Liferay DXP 7.3 before fix pack 1 does not invalidate CAPTCHA answers after it is used, which allows remote attackers to repeatedly perform actions protected by a CAPTCHA challenge by reusing the same CAPTCHA answer.
CVE-2021-22668
PUBLISHED: 2021-05-16
Delta Industrial Automation CNCSoft ScreenEditor Versions 1.01.28 (with ScreenEditor Version 1.01.2) and prior are vulnerable to an out-of-bounds read while processing project files, which may allow an attacker to execute arbitrary code.
CVE-2021-29039
PUBLISHED: 2021-05-16
Cross-site scripting (XSS) vulnerability in the Asset module's categories administration page in Liferay Portal 7.3.4 allows remote attackers to inject arbitrary web script or HTML via the site name.