[FreeNAS] Possible to manually apply a binary patch?

Colleagues,

  1. Is it possible to MANUALLY update a couple of binaries on a running system with binaries from FreeBSD's repository in order to patch a couple known security vulnerabilities?
  2. Issues are:
    • I have a FreeNAS appliance based upon FreeBSD 8.3-p6 on a CLOSED network.
    • I would like to MANUALLY apply a BINARY upgrade/patch.
    • I cannot use the make or freebsd-update since they're not on the target system.
  3. Binaries I want to upgrade are:
    • ntpd from version 4.2.4p5 to 4.2.4p7 due to CVE-2009-1252 (probably minor change)
    • bzip2 from version 1.0.5 to 1.0.6 due to CVE-2010-0405 (probably minor change)
  4. If possible:
    • Where can I get the updates?
    • How can I check the metadata associated with the new binaries packages?
    • Do I need to check dependency integrity manually?
    • Can root just copy over the old binary to the new binary?

Thanks,

-Jim
 
Yes, it is possible to copy binaries over existing binaries. FreeNAS may use custom patches or build flags that could create incompatibilities, but that is unlikely. You would probably have to install a machine with FreeBSD 8, update to 8-STABLE, and then build your own binaries to get the latest code.

However, there's good news. Those security problems are years old, 2009 and 2010, and FreeBSD 8.3 just came out a couple of months ago. Known problems are fixed before a release, so they should not be present on anything based on FreeBSD 8.3.
 
Now, something doesn't make sense to me because when I log into FreeNAS which is based upon FreeBSD 8.3, it says:

Code:
FreeBSD 8.3-RELEASE-p6 (FREENAS.amd64) #0 r24814M: Sun Mar 10 16:35:05 PDT 2013
Code:
[root@NAS1]>ntpd -v returns:
ntpd - NTP daemon program - Ver. 4.2.4p5

[root@NAS1]>bzip2 -h returns:
bzip2, a block-sorting file compressor. Version 1.0.5. 10-Dec-2007
4.2.4p5 and 1.0.5 are vulnerable code versions for ntp and bzip2. I verified it. Is there some way to verify which versions of those packages are actually incorporated into OFFICIAL FreeBSD 8.3? Because they definitely are not part of FreeNAS 8.3.1-RELEASE based on FreeBSD 8.3-RELEASE-p6.

Many thanks too; I totally appreciate the community support.

-Jim
 
wblock@ said:
It is explained well here: Thread 17688

Got it! So a version will not change on imported SW but will fix the vulnerability. That's good news. Now I'm going to pound on my vulnerability scanner for coming up with false positives.

Many thanks.

-Jim
 
jamoses said:
Now I'm going to pound on my vulnerability scanner for coming up with false positives.
They are great for doing a quick scan but you need somebody experienced to make sense of the results. I've seen way to many "security" people taking whatever their vulnerability scanner threw up as the absolute truth without verifying or interpreting the results.
 
SirDice said:
They are great for doing a quick scan but you need somebody experienced to make sense of the results. I've seen way to many "security" people taking whatever their vulnerability scanner threw up as the absolute truth without verifying or interpreting the results.

That is precisely what we're doing here:
  1. Vulnerability scanner throws results (which is better than actually performing the DoS attack on my own machine to verify the vulnerability) and our rule here is either patch the vulnerability, or open a trouble ticket against the vulnerability scanner finding.
  2. Verify that the version the scanner found is actually the affected version on the subject OS.
  3. Now for an OS other than FreeBSD, I could verify that the vulnerability is patched by verifying the affected software's version and by virtue of good versioning record keeping.
  4. Unfortunately, for FreeBSD only, I now have to go verify that a patch was applied to fix a vulnerability EVEN THOUGH the version within FreeBSD may not have change 4 years later because they ONLY fix the vulnerability. (i.e. CVE-2009-1252)
  5. My 2 cents: I kind of think that there should be a version change for any piece of software to denote a security vulnerability patch, just so the binary can be verified against a non-patched version short of comparing checksums/SHA1 on different binaries caring precisely the same version number.
 
Checksums don't work on systems where the OS is updated/upgraded from sources, every compilation results in binaries that are unique to that compilation regardless of changes or no changes to the source code.
 
Back
Top