To accelerate the transition to memory safe programming languages, the US Defense Advanced Research Projects Agency (DARPA) is driving the development of TRACTOR, a programmatic code conversion vehicle.
The term stands for TRanslating All C TO Rust. It’s a DARPA project that aims to develop machine-learning tools that can automate the conversion of legacy C code into Rust.
The reason to do so is memory safety. Memory safety bugs, such buffer overflows, account for the majority of major vulnerabilities in large codebases. And DARPA’s hope is that AI models can help with the programming language translation, in order to make software more secure.
“You can go to any of the LLM websites, start chatting with one of the AI chatbots, and all you need to say is ‘here’s some C code, please translate it to safe idiomatic Rust code,’ cut, paste, and something comes out, and it’s often very good, but not always,” said Dan Wallach, DARPA program manager for TRACTOR, in a statement.
There is a ton of literature out there, but in a few words:
Rust is built from the ground up with the intention of being safe, and fast. There are a bunch of things you can do when programming that are technically fine but often cause errors. Rust builds on decades of understanding of best practices and forces the developer to follow them. It can be frustrating at first but being forced to use best practices is actually a huge boon to the whole community.
C is a language that lets the developer do whatever the heck they want as long as it’s technically possible. “Dereferencing pointer 0?” No problem boss. C is fast but there are many many pitfalls and mildly incorrect code can cause significant problems, buffer overflows for example can open your system to bad actors sending information packets to the program and cause your computer to do whatever the bad actor wants. You can technically write code with that problem in both c and rust, but rust has guardrails that keep you out of trouble.
But if they have fully tested and safe C, and they’re converting it to Rust using AI, that seems more dangerous, not less.
Just recently a bug was found in openssh that would let you log into the root user of any machine. With extreme skill and luck of course, but it was possible.
OpenSsh is probably one of the most safe C programs out there with the most eyes on it. Since it’s the industry standard to remotely log in into any machine.
There is no such thing as fully tested and safe C. You can only hope that you find the bug before the attacker does. Which requires constant mantainance.
The the about rust is that the code can sit there unchanged and “rust”. It’s not hard to make a program in 2019 that hasn’t needed any maintainance since then, and free of memory bugs.
Just so you know, that bug was a months long hack, probably by a State actor, not just something they didn’t spot before.
It still goes to show that there’s no fully tested C code. I’m sure OpenSSH has had the eyes of thousands of security researchers in it. Yet it still has memory-related bugs.
There is no fully tested and safe C. There’s only C that hasn’t had a buffer overflow, free after use, … yet.
It’s hyperbole, but the amount of actually tested C without bugs is few and far between. Most C/C++ code doesn’t have unit, nor integration tests, and I have barely seen fuzzing (which seems to be the most prominent out there).
Anti Commercial-AI license
That would be perfectly safe in any language.
use after free, whoops
Anti Commercial-AI license
deleted by creator
That’s a pretty good explanation. So along the same level of explanation, what are these memory problems they are talking about?
I explained a little about buffer overflows, but in essence programming is the act of making a fancy list of commands for your computer to run one after the other.
One concept in programming is an “array” or list of things, sometimes in languages like C the developer is responsible for keeping track of how many items are in a list. When that program accepts info from other programs (like a chat message, video call, website to render, etx) in the form of an array sometimes the sender can send more info than the developer expected to receive.
When that extra info is received it can actually modify the fancy list of commands in such a way that the data itself is run directly on the computer instead of what the developer originally intended.
Bad guy sends too much data, at the end of the data are secret instructions to install a new program that watches every key you type on your keyboard and send that info to the bad guy.
Many thanks.