Another Bug Caused by Memory Unsafe String APIs

A recent vulnerability came across my radar earlier this week. The description was vague but said:

“There is a stack overflow vulnerability caused by strcpy.”

This API first appeared in UNIX in the 1970s. There are many other APIs that don’t exhibit the same memory unsafety that these APIs do, but for some reason, we still continue to see these APIs being used. Why? Better versions exist. Is it paranoia due to the infinitesimal amount of overhead the safe versions impart? Is it because today’s developers learned programming in the ’70s? Heck, even the documentation in the strcpy man page clearly screams out “do not use this API”:

“If  the destination string of a strcpy() is not large enough, then anything might happen. Overflowing fixed-length string buffers is a favorite cracker technique for taking complete control of the machine. Any time a program reads or copies data into a buffer, the program first needs to check that there’s enough space. This may be unnecessary if you can show that overflow is impossible, but be careful: programs can get changed over time, in ways that may make the impossible possible.”

“Anything might happen” indeed, and the last sentence is also pertinent; you may be totally safe today and yet, tomorrow, another developer refactors your code and introduces a new configuration you hadn’t planned for. Suddenly you’re vulnerable.

Think you’re safe? Don’t be so sure.

Even if your developers are coached to steer clear of these APIs, code they rely on via imports/dependencies may include use of these APIs. What do you do then? Tolerate the use of the risky behavior, accepting it as a potential security risk? How thorough were the upstream developers in ensuring their use of the risky APIs was safe? What if they become a victim of the refactoring scenario described above? You become vulnerable by transitivity.

Furthermore, how do you even know if your dependencies are even using these risky APIs to begin with? Typical SBOM tools will enumerate the dependency and its known CVEs, but what about strcpys lurking beneath the surface, ready to be misused? Most SBOM tools won’t report this level of detail.

At Deepfactor, we want to help developers be aware of these risks. Knowing if you’re vulnerable allows developers and security teams to assess risky API use intelligently by identifying when these APIs are used, regardless of where the usage occurs (in your code or that of your dependencies). Of course, we give you the SBOM too, but we go one level deeper and show you precisely where your code uses the APIs it really shouldn’t be using.

Just showing the developer that they have accidentally done this is a huge step forward, but we take it one step further. We show a full execution stack trace leading up to the risky API, including source file and line number. This immediately shows the developer all they need to know to contextually identify in which codepath the usage occurred. This makes the issue much easier to remedy.

Of course, strcpy isn’t the only risky API. It’s one of many examples of unbounded string manipulation functions that suffer from similar issues. Deepfactor alerts on usage of any of them.

There have been efforts to “fix” this. For example, OpenBSD tried to make the use of these APIs somewhat more obvious by the following “in your face” linker warning:

… but as this would end up likely scrolling up the screen or lost in some build logs, a developer may not even know it ever happened.

As an industry, until we no longer accept usage of these APIs at all, we’ll be fighting these battles forever. Either that, or we all need to move to memory safe languages like Rust that don’t have these sorts of issues to begin with. But that’s a different battle. For now, we need to rely on security tools to help us steer clear.

Quick Clip: Learn about Deepfactor Developer Security’s Software Bill of Materials