Michal Zalewski recently publicized
a couple of denial of
service problems with the Postfix mailer. Distributors responded quickly;
here's a quick look at who released updates and when:
||Community 1.0.1, 2|
Professional 1.1, 1.2, 1.5
||8.2, 9.0, Corp. Svr. 2.1|
|Red Hat||7.3, 8.0, 9||1|
|SuSE||7.2, 7.3, 8.0, 8.1...||1|
(See the LWN
vulnerability entry for current information on distributor updates).
Here, "response time" is calculated as the number of days between the
posting of Michal's advisory and the distributor update. Distributors
clearly had a bit of advance notice with which to produce their updates,
which is a good thing. There was very little delay before updates were
made available to users.
The only problem is that, as Postfix creator Wietse Venema pointed out, both of the vulnerabilities had
been fixed a long time ago. One of the problems was fixed in version 1.1.12,
released in November, 2002. The other (fixed in 1.1.13) does not exist in
Postfix 2.x, which has been available since February. But even relatively
modern distributions (such as Red Hat Linux 9) are built with
which dates back to May, 2002. It is laudable that the distributors were
so quick to make updates available. But if they had stayed a little closer
to the current release of Postfix, much of this scramble might have been
unnecessary, at least for more recent distribution releases.
One can always come up with possible reasons for the shipping of such old
software. For most distributions, only a small minority of users run
Postfix, so it is probably relatively low on the prioritized list of
packages to update. Switching to a new major release (2.0) is always a bit
of a scary move; distributors tend not to rush into that sort of change.
And, then, there is the little fact that neither fix was marked by the
Postfix developers as a security fix. As we have seen in this case,
distributors move quickly when a security issue is outstanding, but slowly
The fixes were not advertised as being security related for a simple
reason: the developers did not know - in either case - that a security bug
was being fixed. One fix just sort of happened during a big (2.0) code
reorganization, and the other fix looked like just another bug fix at the
time. The end result is that, as a result of inaction on the part of both
developers and distributors, users have been running vulnerable code for
months when a fix was available.
to post comments)