The GLIBC "ghost" bug was published & fixed a few weeks ago. Just for completeness, here is a strictly unofficial systemtap-based band-aid for this security bug, tested on RHEL5/RHEL6 era glibc versions 2.5 and 2.12. Of course you should get a properly patched glibc, but this could tide one over for a while.

#! /usr/bin/stap -g

global added%
global trap = 1  /* stap -G trap=0 to only trace, not fix */

/* CVE-2015-0235 "ghostbuster" band-aid

Works by incrementing the size_needed variable set around line 86
of glibc nss/digits_dots.c, so as to account for the missing sizeof
(*h_alias_ptr).  This makes the subsequent comparisons work and
return error codes for buffer-overflow situations.

GLIBC DWARF debuginfo is needed, because we insert a statement
probe just after the initial assignment.  stap -g (guru mode)
is needed because we're modifying state. 

85
86   size_needed = (sizeof (*host_addr)
87                 + sizeof (*h_addr_ptrs) + strlen (name) + 1);
88
89   if (buffer_size == NULL)
90     {
91       if (buflen < size_needed)
92         {
93           if (h_errnop != NULL)
94           *h_errnop = TRY_AGAIN;
95           __set_errno (ERANGE);
96           goto done;
97         }
98     }
99   else if (buffer_size != NULL && *buffer_size < size_needed)
100    {
101      char *new_buf;
102      *buffer_size = size_needed;
103      new_buf = (char *) realloc (*buffer, *buffer_size);
*/


probe process("/lib*/libc.so.6") /* Adjust wildcard for your distro. */
      .statement("__nss_hostname_digits_dots@*:87-102")
      /* We use a range here because optimized glibc may only have
         a few clear-cut PC-ranges for statements.  This particular
         line range is unusually reliable, because the digits_dots.c
         file has seen very little change in glibc, up until the
         CVE bug fix.  We use the added[] array to make sure we only
         increment once per thread per function invocation. */
{
   if (! added[tid()])
     {
        added[tid()] = 1; # we only want to add once
        printf("%s[%d] BOO! size_needed=%d ", execname(), tid(), $size_needed)
        if (trap)
           {
              /* The &@cast() business is a fancy sizeof(uintptr_t),
                 which makes this script work for both 32- and 64-bit glibc's. */
              $size_needed = $size_needed + &@cast(0, "uintptr_t")[1]
              printf("ghostbusted to %d", $size_needed)
           }
        printf("\n")
     }
}

probe process("/lib*/libc.so.6").function("__nss_hostname_digits_dots").return
{
   delete added[tid()]
}
Posted Tue Feb 3 20:33:00 2015 Tags:

In the news: the killer pilot selfie, related to a small airplane accident last year. The US NTSB just released a report about finding a GoPro video camera in the wreckage, noting that during a previous flight, the pilot was recorded as taking selfies in the cockpit during critical phases.

The press goes wild, Darwin Award nominations come out, yadda yadda. ... and I can't defend the pilot from the charge of stupidity - the weather conditions precluded a safe flight, regardless of photography.

But I have a beef with the NTSB. While the "full narrative" simply stays factual, the probable cause blurb contains fiction. Namely, it says:

Contributing to the accident was the pilot's distraction due to his cell phone use while maneuvering at low-altitude.

The problem is that there is no evidence shown that the pilot used his cell phone during the accident flight! Sure, he probably distracted himself during the previous flight, and risked his life and all that, but he still landed safely! Then, later, he took off again, climbed into the low clouds at night-time, stalled & spun in -- but the NTSB has no basis to say that then, minutes later, there was any cell phone use or residual distraction.

The probable cause report would have been less sensational and more accurate if it had stated its conclusion conditionally, i.e., "If the pilot used his cell phone during the accident flight, it would have probably distracted him."

Posted Wed Feb 4 08:35:00 2015 Tags:

I present ldd2rpm, a little script to find which rpms are needed to satisfy all the dynamic-linking requirements of listed binaries/shared-libraries. May it assist you in sanity-checking and bloat-shaming package dependencies.

#! /bin/sh

rpmqf() {
   rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" -f "$1"
}

for program in $@
do
   rpmqf "$program"
   ldd "$program" | grep '=>' | awk '{print $3}' | grep / | 
   while read file
   do
        rpmqf "$file"
   done
done | sort -u

Use it thusly:

% ldd2rpm /lib64/libpcp.so.3
avahi-libs-0.6.31-30.fc21.x86_64
cyrus-sasl-lib-2.1.26-19.fc21.x86_64
dbus-libs-1.8.14-1.fc21.x86_64
glibc-2.20-7.fc21.x86_64
nspr-4.10.8-1.fc21.x86_64
nss-3.17.4-1.fc21.x86_64
nss-softokn-freebl-3.17.4-1.fc21.x86_64
nss-util-3.17.4-1.fc21.x86_64
pcp-libs-3.10.2-1.fc21.x86_64
zlib-1.2.8-7.fc21.x86_64

You can feed that list to a pipeline suggested at stackexchange to find transitive dependencies:

% repoquery --requires --recursive --resolve `ldd2rpm PATH`
Posted Fri Feb 13 15:52:00 2015 Tags: