Security

Postfix TLS plaintext injection

Transitioning between states, or contexts—unencrypted to encrypted for example—is one place where security flaws can sometimes hide. We have seen one example of that in the TLS renegotiation vulnerability that cropped up in late 2009. More recently, a somewhat similar problem was discovered in the Postfix mail transfer agent (MTA) (as well as other mail server software and MTAs). The problem lies in improperly handling the transition between states such that the boundaries that should exist between them are not enforced.

The problem came to light in a lengthy post on March 7 to the postfix-users mailing list by Postfix creator Wietse Venema, but he had discovered it back in January. Venema silently fixed the problem in Postfix at that time, and then worked with CERT to coordinate fixes for other affected projects and vendors. That work has been completed, so the details are now being made public.

The problem occurs when Postfix changes from unencrypted to encrypted mode via the STARTTLS SMTP command. Venema goes into some detail about how Postfix makes that switch (at least at a high level), but the basic flaw is that it doesn't flush its buffers after it switches over to the TLS encrypted mode. That allows a man-in-the-middle attacker to inject some plaintext commands into the SMTP data stream between the STARTTLS and the client's first TLS-encrypted SMTP commands.

Venema demonstrates the problem using the OpenSSL s_client command with a minor modification. Using that program, one can easily test for the problem. In the example, the STARTTLS command is followed directly by the RSET command, which just resets the state (sender and receiver addresses for instance) of any in-progress mail transaction. In an affected MTA, the TLS negotiation will take place, so that subsequent traffic is encrypted, but the server will read the buffered RSET command even though it was sent prior to the establishment of the TLS session. But, since the server believes it is in encrypted mode, it treats the RSET as being in that context.

Obviously, a RSET is not particularly harmful. There are other things an attacker could do, as Venema mentions:

The exploits would look similar to those described for the TLS renegotiation flaw. If the attacker can predict what commands a client will send (which isn't terribly difficult at least for SMTP), they can prefix their own set of commands and relay the server responses to the victim. Typically, the attacker commands will leave the server in a kind of dangling state waiting for the client to send data that will complete the commands. The classic example is for the attacker to send the SMTP DATA command after setting the from and to addresses appropriately; all of the commands the client sends are then included into the email that gets sent to the attacker.

Clients that don't check the TLS certificate are, in some sense, unaffected by this problem. They are always vulnerable to man-in-the-middle attacks that don't need to rely upon tricks like this plaintext injection. But clients that do check those certificates were at risk. Given that even security-conscious users are much more inclined to use a random open WiFi access point because they are using encrypted communications, this vulnerability could be used to capture a lot of outgoing mail—or worse.

Venema also points out that part of the problem in Postfix was that it was written to adhere to the "robustness principle" (aka Postel's Law): "Be conservative in what you send; be liberal in what you accept". The idea is that protocol implementations should strive to only send compliant messages, but to accept non-compliant messages from others when the intent is clear. Venema puts it this way:

Sadly in some ways, the robustness principle has been generally deprecated over the years as attackers (and other malicious entities such as spammers) have exploited the liberal acceptance of messages to further their aims. It has also allowed ill-behaved programs to continue to exist well past the time they should have been fixed. Strict protocol compliance in both directions is now the norm.

The full message from Venema is well worth reading as it provides many more details than other advisories generally do. It should also be something of a wakeup call to other developers of servers that switch between contexts (either switching from plaintext to encrypted or by encryption renegotiation). Looking closely at those transitions might just turn up a hole or two. Hopefully if bugs like that do get discovered, the developers will put out an advisory as informative as Venema's.

[ We would like to thank Brad Hards for giving us a heads-up about this issue. ]

Comments (none posted)

Security quotes of the week

Comments (none posted)

Your passwords have been hashed

In a long-overdue upgrade, we have recently switched over to storing hashed passwords in our database. We have occasionally been taken to task (and deservedly so) for not doing that, and have finally gotten around to implementing a bcrypt-based hash for passwords. When the LWN site code was first implemented, passwords seemed like a pretty low-security item—there just wasn't much that an attacker could do if they got access to one—and the ability to remind users of their passwords seemed useful. Over time, though, it has become clear that password reuse can make the compromise of even "low security" passwords into a serious problem. Sites like ours clearly should not store passwords in plain text; we are now happy to say that we do not.

The only user-visible side of the change is in the username/password recovery process as we can no longer send you your password in email (at least we hope that's the only user-visible part, the rest should just be working invisibly in the background). Username and password recovery have been added to the Login page in case you ever need them. One thing to note, however, is that none of it will work unless we have an up-to-date email address for you in our database. We don't send very much email that you haven't requested (essentially just subscription reminders) and we definitely will not share your email address with anyone else, so please check your address via the My Account page, and update it if necessary.

Comments (3 posted)

aaa_base: arbitrary file corruption

Comments (none posted)

asterisk: multiple vulnerabilities

Comments (none posted)

build: unsafe use of cpio

Comments (2 posted)

cgit: denial of service

Comments (none posted)

chromium-browser: multiple vulnerabilities

Comments (none posted)

chromium-browser: multiple vulnerabilities

Comments (none posted)

kernel-rt: multiple vulnerabilities

Comments (none posted)

krb5: denial of service

Comments (none posted)

libvpx: denial of service

Comments (none posted)

openldap: multiple vulnerabilities

Comments (none posted)

perl-mail-box: boundary guessing

Comments (none posted)

php-zendframework: cross-site scripting

Comments (none posted)

pidgin: denial of service

Comments (none posted)

vsftpd: denial of service

Comments (none posted)

wireshark: denial of service

Comments (none posted)

wordpress: multiple vulnerabilities

Comments (none posted)