Trusting Software Distribution

In 2005, I wrote a paper “Don't Trust Your Vendor's Software Distribution Methodology”. The goal of the paper, besides to gain some CISSP credits, was to build awareness to our lackadaisical submission into popular insecure software distribution methods. When I was busy writing it, TK came over one day and said, “This is big, and if you write this well you’ll be testifying before Congress”. Nancy Pelosi hasn’t phoned.

I haven’t got the penmanship or charisma of Thomas Jefferson or Fredrick Douglass. A year approaches since this paper was last published and the soapbox beckons.

Your systems are vulnerable.
Your bank is at risk.
Your switches, routers and firewalls cannot be trusted.

Picture Bob. He is your network engineer. One day Bob is assigned with upgrading the software on a router. Bob is an excellent network engineer. He downloads the specific software, loads and tests it in a lab. Following change management policies, he certifies everything is good to go and in a specific change window the upgrade is a success. Unfortunately, the site he visited to download the software wasn’t the vendor’s site. Unbeknownst to anyone, he has now loaded malware on the router.

Two questions to the reader

1. How many of your vendors provide software distributions methods that provide endpoint authentication?
2. How many of your products have an internal mechanism to ensure hierarchical trust?

Hashes don’t usually help

When I play out the scenario, many people first respond, “but, I checked the MD5 hash”. Lets walk the lines of communication.

1. Launch browser
2. Type in http://downloads.vendor.com
3. DNS Request
4. Navigate website.
5. Download software http://downloads.vendor.com/software2.0.tar.gz
6. Download signature http://downalods.vendor.com/software2.0.md5
7. Check signature
8. Install software on router
9. Reload

What went wrong?

1. In step 3, a DNS server could have a poisoned cache.
2. In steps 5 and 6, Bob is using http. This is a non-authenticated protocol.
3. Thank goodness Bob checked the signature in step 7. Too bad, again, the signature was obtained using a non-authenticated protocol.
4. The router itself made no attempt to verify the trust of the software.

Fixing the issue.

Technically, these issues are easy to fix. First, never download any software over non-authenticated protocols. You should be using HTTPS or SCP and don’t forget to confirm the certificate or host key. Checking a signature is a good idea. However, remember that it’s intention is to ensure integrity, not trust. The most important part of the equation is for vendors to deliver solutions to ensure trust. A closed system like a router should have a pre-loaded certificate. If the software is signed with a certificate matching that of the pre-loaded certificate’s signer, then we can have a high level of trust.

Don’t limit your fear

Are you anxious or confused yet? The matter of trust isn’t limited to open source distributions, but it does provide an open door to statistical gathering. When you look at the rampant use of open source software used in commercial products, banking industries and security products one should be timid. Very, very few of our popular open source packages provide means to download code over authenticated protocols. For example, the FreeBSD ports tree currently boasts 16206 ports. Of these ports, only 13 list download sites using HTTPS. None of those 13 include the heavily used distributions like Apache, MySQL, PostgreSQL, PHP or Ruby. By no means should one assume that these statistics indicate a greater trust on commercial source versus open source. Both are probably equally at fault.

Risk is Rampant

In recent years, financial institutions like Bank of America and Citigroup have boasted their use of open source products. Apparently, the FDIC recognizes the risk. In 2004, the FDIC issued a letter “Risk Management of Free and Open Source Software” in which they both caution on the use of open source software and provide best practices on risk reduction.

Bottom Line

At the end of the day, very few of my vendors or open source distributions provide me with a trusted method to download code. Whats the problem? Is it cost, complexity, ignorance or all of the above?