LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityPostfix TLS plaintext injectionTransitioning 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:
How would an attacker exploit this? It would play man-in-the-middle
on the connection between SMTP client and server, perhaps using ARP
spoofing at a public WIFI access point. Instead of adding a harmless
RSET command, it could steal email or authentication credentials.
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:
This reflects what once was the primary mission of Postfix: to deliver
mail, not to force other systems to implement all the Internet RFCs
correctly. Nowadays, strict protocol compliance is becoming a requirement
for senders to get their email delivered. As this episode shows, stricter
protocol enforcement by receivers can bring security benefits, besides
blocking spambots.
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. ]
Brief items Security quotes of the week
But their most interesting attack focused on the car stereo. By adding
extra code to a digital music file, they were able to turn a song burned to
CD into a Trojan horse. When played on the car's stereo, this song could
alter the firmware of the car's stereo system, giving attackers an entry
point to change other components on the car. This type of attack could be
spread on file-sharing networks without arousing suspicion, they
believe. "It's hard to think of something more innocuous than a song," said
Stefan Savage, a professor at the University of California.
-- ITworld
(seen at Boing
Boing)
The lack of a security mindset is what accounts for upstream ripoffs of
grsec features ultimately being incomplete or improperly implemented. Code
will go in following an initial interest, but no single person will stick
around years later to make sure it's still correct. A prime example of this
is constifying of function pointers in the kernel. While in upstream it was
confined to a few struct types since 2007, it was expanded a great deal in
grsec and maintained until today (I'm even nice enough to make security_ops
and selinux_enable read-only under KERNEXEC). Upstream never maintained
constification since the initial patchset. Occasionally I'd complain about
this publicly, and a spurt of interest would follow, only to be
unmaintained yet again. Often times someone would make the effort of
submitting all the constifying patches from grsec only to see a fraction of
them applied (with no reason for the rest to not be applied). There's no
eye for consistency or quality, just the name and a facade of security.
-- Brad
Spengler
Of course it has taken us more than 13 years to take Nmap where it is
today. So even Greg [Hoglund] had to acknowledge that he and one employee
couldn't outdo us in a day. So he proposes that they "take a couple
of days" to write their Nmap killer :).
-- Nmap developer Fyodor reads some HB Gary emails (the whole post is worth reading for
its amusement value)
Your passwords have been hashedIn 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.
New vulnerabilities aaa_base: arbitrary file corruption
asterisk: multiple vulnerabilities
build: unsafe use of cpio
cgit: denial of service
chromium-browser: multiple vulnerabilities
chromium-browser: multiple vulnerabilities
kernel-rt: multiple vulnerabilities
krb5: denial of service
libvpx: denial of service
openldap: multiple vulnerabilities
perl-mail-box: boundary guessing
php-zendframework: cross-site scripting
pidgin: denial of service
vsftpd: denial of service
wireshark: denial of service
wordpress: multiple vulnerabilities
Page editor: Jake Edge |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||