Make simple software security checks part of your purchasing process

The car has no seatbelts, no brake pedal and, on closer inspection, no brakes of any kind. Do you listen to the salesperson drone on about how powerful the engine is, or do you buy a different car?

The same principle applies to software, Peiter “Mudge” Zatko, the well-known l0pht hacker and software security expert who has worked across industry and government for the last twenty-odd years, tells CSO. Checking for basic security features before buying software can and should be part of the enterprise purchasing cycle.

Doing so is not labor- or time-intensive, either. Evaluating software binaries for basic compile-time security flags is as simple as running existing open-source scripts against the binaries in question. While this won’t offer a comprehensive analysis of the software, it will tell you whether the software maker has bothered to do the bare minimum. If they haven’t bothered to do the bare minimum, that is a huge red flag, Mudge says.

“This stuff is so basic (fundamental) that the checks are the same on both sides,” Mudge tells CSO, meaning that the security checks a purchasing organization makes are the same checks a software maker should make before releasing their software. “It’s like looking in a car to make sure it has seatbelts and looking to make sure there is a brake pedal and some disc brakes on the wheels.”

“[These checks] should be done by the manufacturer before being sent out to be sold,” he adds. “Blame is also on the consumer if it’s missing and they couldn’t be bothered to look (since there are no mandated safety laws here).”

Caveat emptor–the ancient principle of “buyer beware”–applies especially to enterprise organizations with the resources to perform minimum due diligence.

What is a “security flag”?

Most programs that you download and install on a laptop are written in C or C++ and turned into machine-readable instructions by a compiler. C/C++ compilers offer optional security “flags”–command-line arguments software build engineers pass to the compiler–that make hacking software much harder.

A common example is ASLR (Address Space Layout Randomization), which has been around for more than a decade and helps prevent buffer overflow attacks. DEP (Data Execution Prevention)—a.k.a. No-Execute (NX)–and Guard Stack (GS), better known as stack canaries, also prevent buffer overflows. While advanced techniques have been developed to end-run around ASLR, DEP and stack canary protections, there’s rarely a good reason to turn them off, and doing so sends an unintentional message to a potential buyer: “We don’t care about security and didn’t even bother to try.”

Here’s an example of running the checksec script against the Zoom Linux client to check for security flags:

Peiter

To its credit, Zoom quickly added these security flags to its Linux binary in response to Mudge’s tweet. CSO checked a week later, on April 19:

J.M. Porup

The Zoom Linux client is now completely, 100% secure…right?

“We should celebrate that Zoom is taking security seriously, …but we do not want them to stop ‘here’. ‘Here’ is the most basic bare minimum,” Mudge tells CSO, noting that the Cyber Independent Testing Laboratories (Cyber ITL) uncovered serious security issues undetectable by checksec, including extensive use of known-insecure function calls.

Does that mean a software maker could, in theory, do the bare minimum and not bother about the rest? Yes, but even if that happened, it would still be a step forward and could serve as the thin end of the wedge to drive security deeper into the company’s software engineering culture.

How to check for security flags

Open-source tools like checksec, winchecksec and otool make it easy to quickly check for the presence of these security flags. Checksec, the tool used in the above screenshots, checks Linux binaries. A similar tool, winchecksec, performs the same security checks on Windows binaries.

CSO ran winchecksec against the Zoom Windows binary and found a similar lack of basic compile-time security flags as well. Unlike on Linux, Zoom on Windows runs from a directory of compiled executable (.exe) and code library (.dll) files. Winchecksec revealed a similar lack of compile-time security flags across all files tested.

J.M. Porup

Open-source tools that peer deeper into the security of compiled software binaries are on their way, Mudge says. For the last several years, he’s been working at Cyber ITL developing advanced tools for checking the software security of binaries at scale. He says he hopes to open-source those tools soon but adds that existing tools like checksec and winchecksec are more than adequate for checking the basics.

Enterprise due diligence at purchasing

The amount of due diligence enterprises perform in checking software security during purchasing varies wildly. Banks have a reputation as notorious sticklers who care deeply about security and spend the time and money to get it right. In other verticals, software security checks during purchasing may be completely absent.

This is often due to a lack of commitment from senior leadership. In a large organization, purchasing and the security teams tend to be siloed so far apart that it becomes an organizational challenge for the two departments to work together. However, failure to spend a couple hours getting the security intern to run these basic security checks can result in catastrophic outcomes down the line.

“If you are a corporate consumer, you should include simple security metrics in your product evaluation and purchasing process,” Mudge says.