Relaxing with the XDR Vulnerability

[This article was contributed by Tom Owen]

A vulnerability in a library is unsettling. When the affected code is in glibc it seems like genuine grounds for alarm. Not only the library itself, but potentially every static-linked executable may need to be replaced or rebuilt, and it takes a very confident system administrator to swear to the link status of everything on the system.

These vulnerabilities do appear from time to time. Fortunately, it generally turns out that thought is a substitute for panicky rebuilds. The XDR vulnerability provides a handy example.

RPC (Remote Procedure Call) is an upper-layer network protocol developed by Sun as part of their vision of network-centric computing. Services offered via RPC appear to be simple functions which are called by applications; this system has been a key basis for many distributed applications, with NFS being the most famous. One obstacle to passing program data between hosts is the varying binary representation of basic data types like integers and floating point numbers. Ones-complement integers aren't much of a problem these days, but little and big endian byte orders are in use as are non-IEEE floating point formats. The solution used by Sun is for all hosts to convert data to and from a standard network representation; this representation is called "external data representation," or XDR.

The routines for XDR data conversion are included in glibc. One of these routines (xdr_array()) has a vulnerability where a crafted message can cause a buffer overflow. Finding out how much to worry about this vulnerability is really a matter of finding all of the uses of the XDR code in your system.

The place to start is with the new glibc itself. There's no good reason not to install this update -- it's insurance against changes in the future if nothing else. Another sensible precaution for any site is to ensure that RPC network traffic is stopped at the firewall. Running RPC across the public Internet is a fine security challenge, but not an obvious win. A complete block takes a bit of research as RPC ports sometimes vary from site to site, but blocking TCP and UDP for 111 (the portmapper) and 2049 (NFS) is a start. If RPC can't get in from outside then you won't be interpreting any external messages as XDR.

For many Linux sites RPC is needed to support NFS, or other services like NIS. That's the first stopping point -- all sites without NFS and without some other need for RPC-based services can stop now. Job done.

The next set of easy exits is for the bulk of those RPC and NFS sites.

Dynamic linking has its downside, but like most good ideas, its disadvantages turn out to be the same as its benefits. For certain, dynamic linking means that a working system can be silently wrecked by installing an application with an incompatible version of some library. But that same feature gets us out of trouble here -- if ever there was a library to link dynamically, glibc -- stable and ubiquitous -- is it.

Distributors that have published fixes are typically offering the updated library itself and perhaps some NFS daemons. Since most applications use dynamic linking with glibc, replacing that library is sufficient to close the vulnerability. For most sites, updating glibc is all that is required.

Everybody left counts as a programmer or a builder. Programmers will know whether they have a problem. The rest of us -- call us naive builders -- are the ones with the problem. It's here that we have to fall back on the safe course. If we truly can't tell whether we're using the XDR functions or static linking then, finally, it's time to rebuild and reinstall our applications.