What does backported mean?

Last Updated on May 31, 2023 by Dave Farquhar

This is the question I just can’t shake in my career. Maybe if I answer it in writing, it’ll save me one conversation. What does backported mean, and do I need to be concerned about it?

Backporting is the process of applying bugfixes, especially security fixes, from new software to older, discontinued versions of the same software. This allows businesses to run older software securely while maintaining compatibility that the newer version may lack. This practice is most common on open-source software on Linux systems, so don’t get any ideas about using backporting to make it safe to run Adobe Acrobat 1.0 on Windows 98. That isn’t happening.

Why use backporting?

Backporting is important because updates break stuff. Granted, updates don’t break stuff all the time. But we’re prone to remember that one time an update rendered a system unbootable, even if it happened in 2003, and it makes us gun-shy. And having been a sysadmin working on bringing a downed system back from the dead, I know it’s painful, especially when that one guy keeps coming around every 22 minutes asking if it’s fixed yet, and reminding you how much money we’re supposedly losing because the system is down.

I was a sysadmin for more than 12 years. I lived all that. So I get it.

The thing is, it’s not all updates that break stuff. Updates that deprecate old functionality or remove it entirely are bad. I see that from time to time when I visit a web page and get garbage on the screen instead of content. Usually near the beginning of the garbage, there’s a stern warning that this functionality will break in some future version. Someone applied that future version, and now the web server is spewing garbage.

Sometimes updates that add functionality cause unexpected problems too. Another piece of software that interacts with it might accidentally trigger that new functionality and then behave unexpectedly. This is rarer, but plausible.

Sometimes you have to run old versions of Apache or, especially, PHP to keep other software working, but you also need the security updates from newer versions. That’s where backporting comes in. This gives you the bugfixes but nothing else, so the backported version should be infinitely close to 100% compatible with the old one.

What backporting looks like

There are several ways to recognize backporting. The version numbers are the most common telltale sign. Typically, a version containing backported fixes will include a dash followed by additional numbers or some other designator. Red Hat stresses that the Apache version 2.26 that it ships differs from the Apache 2.26 versions you download from anyone else, because they backported patches to it.

If you don’t have access to the computer system in question, but you know the vendor, you can look for the vendor’s source code packages. Under most open source licenses, vendors provide the source code of their modified version. By examining the changelog in the source code, you can see if newer fixes were backported to correct security issues.

Are tools like Qualys and Nessus smart enough to recognize backporting?

As a security guy, the question I hear most frequently today is whether Qualys or Nessus recognize backporting. The answer there is it depends. Usually they recognize backporting just fine, if you perform an authenticated scan. With an authenticated scan, Qualys or Nessus can ask the package manager what version of the software is installed. They can also examine the filesystem and check the versions of the individual binaries if needed. They don’t typically check MD5 or SHA1 signatures on the binaries, but they could if that was the only way to identify a file. Both tools are well aware of the vendor-sanctioned update that fixed the vulnerability. They’ll recognize and give you credit for running the latest Red Hat version of Apache 2.26.

What they won’t recognize is if you custom-compiled your own copy of Apache 2.26, since the binary probably won’t match what the vendor supplies. You’ll make life much easier on yourself if you stick with the vendor-supplied versions.

Unauthenticated scans are dicier propositions. Authenticated scans allow the scanner to log in and run commands so it can thoroughly investigate the software on your system. If Apache is installed but not actively running, an authenticated scan will find it. If it’s old and vulnerable, it’ll alert you to it, too. Unauthenticated scans have to go on what ports are open and how they behave. If there’s no remote command to make the daemon respond with its full version number, including the backport information, the vulnerability scanner won’t give you credit for installing the backport.

Authenticated scans are safer, more thorough, and more accurate, since they don’t have to probe the ports beyond verifying they’re open.

What to do when your sysadmin and vuln scanner disagree

What if your sysadmin insists the system has a backported patch installed, but Qualys or Nessus say it doesn’t? First, make sure the system actually authenticated. It can help to scan just the system in question. Export the scan results as a CSV and look in the results column (Qualys) or Plugin Output column (Nessus/Tenable) for the vulnerability in question to see what the vulnerability scanner found that it objects to. Look over the informational findings to make sure the system authenticated, the account has sufficient privileges, and is being identified properly. Scanner account privileges need to be administrative in nature.

Usually, the results or plugin output column will tell enough that a good security analyst collaborating with a good system administrator can figure out what’s going on. If the findings are still questionable, open a support case. You may have found a condition that Qualys or Tenable haven’t encountered yet. Both of them will revise their signatures from time to time as customers discover new conditions in the field.