There seems to be some confusion on the security exposure in the LISTSERV
14.4 interface, so I would like to clarify a few points.

The exposure is that an attacker could cause WA (the web interface CGI
script) to execute arbitrary code. This in turn can expose your entire
system IF you are running a kernel with a security flaw allowing an
unprivileged user to become root. In that scenario, installing the 14.5 web
interface will close this particular attack vector, but your kernel will
still allow anyone to become root. The most important thing to do in that
scenario is to patch the kernel. You should of course upgrade WA as well,
but this will not be sufficient to make your system safe. Pragmatically, if
the kernel is not up to date, other applications and services probably
aren't either, and they could have vulnerabilities similar to WA's.
 
The web interface shipped with LISTSERV 14.5 is not a simple security patch,
but a major rewrite. It is the code stream from the LISTSERV 15.0
development, which was designed (among other things of course) to make these
kinds of security attacks far more difficult (I won't say impossible
because, with any complex development project, there can be no guarantee
that you have thought of every possible attack). Basically, WA 14.5 is WA
15.0 minus features we have not managed to program yet. This is the secret
behind the Deliverability Assessment. If you examine the templates, you will
see that it is not a mock-up of the 15.0 look, but the real thing. The 15.0
team has converted hundreds of web interface screens to the new look, using
the same version of WA that was released as 14.5.

Without getting into the details of the security exposure, we did not think
that making a quick patch to the 14.4 code base was a good solution. A patch
would plug the particular hole reported by NGSSoftware, but not address the
fundamental issue that there are hundreds of functions in the 14.4 web
interface, each of them with its own security checking code that may or may
not be deficient because this new option can have the side effect that this
old functions receives more data, etc. This architecture just had to go. WA
started as a modest browsing interface for public lists and evolved at
breakneck rate into a full-fledged management system that still has a way to
go before we are fully satisfied with it. This is what 15.0 is all about,
not just on the outside (layout, navigation, etc) but also on the inside. I
cannot promise that the new WA is bug-free, but it is fundamentally more
secure than the old one.

As Nathan pointed out, LISTSERV 14.5 is a free upgrade for customers with
maintenance, which is the vast majority of L-Soft customers. These customers
have been sent a 14.5 license key and download instructions through private
channels.

Of course, this does not help customers who have chosen not to purchase
maintenance. Luckily, one of the design requirements for the new WA was
backward compatibility. This means you can take the 14.5 WA executable and
run it with 14.4, as long as you copy ONLY the WA executable ('WA.EXE' on
Windows, 'wa' on unix). You may see errors in the LISTSERV log as WA probes
for the availability of new 14.5 features, but in principle it will work.
You will not need a 14.5 license key as long as you only copy the WA
executable.

The reason I said "designed" and "in principle" and so on is that we have
done our best during design and programming to make sure that it does work
and, within reason, we are willing to make adjustments to the new WA to make
it work better with older versions of LISTSERV. But we cannot test every
function of the new WA on every 14.4 or 14.3 (some have even asked for 1.8e
and 1.8d) build, on every operating system. We can only do so much testing
and support work for customers who do not want to purchase maintenance from
us. I cannot guarantee that the new WA will work in every back-level
scenario, and I cannot guarantee that we will fix it if it doesn't. 

As for 14.3 and earlier versions, I *think* that the new WA will work fine
on 14.3; I don't think that it will work with 1.8e (released in 2002); and I
am pretty sure that it won't work with 1.8d (1999). We have not tested any
of these scenarios, and this is what this list is all about. Customers who,
for whatever reasons, do not have maintenance can try these various
combinations and share the results on the list.

  Eric