LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
SecurityThe future of vendor-secThere is a certain amount of irony in the news that the vendor-sec mailing list—along with the server that distributes it—was compromised. Vendor-sec is the closed mailing list that is used by developers of Linux distributions along with members of the BSD development community ("vendors" by some definition) to discuss security problems before they are made public. So a compromise of the mailing list could easily lead to security issues made "public" well before fixes were available—an attacker's dream scenario. How exactly the server was compromised is not clear, but a short time after the announcement of the server compromise and closing the backdoor that was being used, the attacker returned. Vendor-sec moderator Marcus Meissner reported some five hours later that "the attacker read this [the announcement] and reentered the lst.de machine, went amok and destroyed the machine's installation. The machine has now been shutdown.". The break-in was noticed a week or so before the announcement, which seems like somewhat tardy notice to those who might be posting to vendor-sec, but, worse yet, the best guess for when the original break-in occurred is January 20—more than a month earlier. During that time—possibly longer—the attacker could have been reading the "secret" traffic on the list. Vendor-sec is nominally used to coordinate response between the participants, and to embargo information about the vulnerabilities until all are ready with a fix. Obviously, an embargo is not likely to be observed by an attacker. But it's certainly not at all clear that vendor-sec was leakproof prior to the break-in. According to Meissner's announcement, there are 80-100 people signed up for vendor-sec, so expecting that there are no leaks may be overly optimistic. Even if all of the participants maintain the secrecy, though, the messages were sent in the clear so they could be intercepted along the way, dug out of inboxes by system administrators, or snagged from unattended mail clients. Since at least January 20, of course, someone didn't even need to do any of those, which started Meissner thinking about whether a closed list like vendor-sec is even really needed any more, and if it is, what changes might need to be made. So he threw that out for discussion. The consensus seems to be that there is value in the closed list, but that leaks should probably be expected—hopefully not from attackers, but via list members by mistake, inattention, or, possibly, malfeasance. Meissner has asked Alexander Peslyak (aka Solar Designer), who runs the oss-security list and is the leader of the Openwall Linux distribution, to take over vendor-sec, and part of that might mean that the messages start being encrypted with GPG. That would stop some of the potential leak sources, but obviously not all. But there were also questions about whether the list should be split up and, if so, how. Solar Designer suggested splitting the list up into three different lists, one each for Linux, BSD, and security researchers. The idea would be that subscribers would get less mail that isn't relevant to their interest area, but others thought that was unnecessarily complicating things. As Eugene Teo put it: "I think it is more effective to have just one mailing list like before that everyone can remember." There is discussion of having oCERT (Open Source Computer Emergency Response Team) host a vendor-sec-style mailing list. oCERT already has verified contacts that could be used to disseminate non-public security information to various projects as needed. Andrea Barisani, oCERT project coordinator is open to such an arrangement, though it would likely require more team members to handle the workload. It could turn into a lot of additional work as Barisani describes:
This is a simplified approach compared to what we do now, which is contacting
project maintainers first, negotiating embargo as well as requesting a patch
that we can verify and relay to vendors, spread the patch to affected parties
along with embargo information and coordinate disclosure. This is a
time-consuming process that worked very well with oCERT because the number of
reports was limited, it helped solving complex bugs or vulnerabilities that
affected a large number of projects.
I think we can continue to do this for selected cases but it would be hard to scale enough to support this "tailored" approach for every single report if we expand our visibility, additionally I think everyone would favour less extra process as pointed out already. So far, no real decisions have been made. Some kind of vendor-sec list seems to be useful, but whether it stays a single list, and where and how it will be hosted are up in the air. Even though few are arguing that vendor-sec should go away, there was some interesting data from Mark J. Cox about the trends of reports to vendor-sec. Over time, it would seem that the number of issues being reported first to vendor-sec have dropped significantly. Cox keeps track of how the Red Hat security team first finds out about vulnerabilities, and the data suggests that the importance of vendor-sec for that purpose is diminishing. In 2008, 69 issues were found first on vendor-sec, but by 2010 that had dropped to 29. According to Cox, 29 represents just 4% of the total number of vulnerabilities fixed. In addition, the severity level of those problems first reported to vendor-sec were not as high as some expected: "Of the flaws we rated impact critical or with a CVSS [Common Vulnerability Scoring System] of 'high', only 4 were from that 29 from vendor-sec." There may come a time when vendor-sec (or whatever it becomes) is no longer needed, but we seemingly haven't reached that point yet. There are times when coordinating a fix (and establishing a CRD, coordinated release date) is important to protect end-users from severe, non-public vulnerabilities. While "full disclosure" is preferred by some, others are sold on "responsible disclosure"; as long as that's the case, lists like vendor-sec will need to be available to help orchestrate those releases.
Brief items Security quotes of the week
It's completely impossible to write a
secure application in PHP. Deploying mod_php is the Internet equivalent
of a "BIKERS SUCK" bumper sticker, as HBGary found out.
-- Dave
Aitel (Thanks to Buck Huppmann.)
So my question is this: how can Debian honestly argue that they take
security very seriously? It looks like it takes ages to get something done,
which is usually not a big deal when talking about new features, but is
definitely a problem when talking about security.
-- Frédéric
Buclin
The Freedom Box project will succeed or fail on whether it works
"without sysadmin". If only trained sysadmins can figure out how to
be free, the society won't be free. It's like the early days of the
telephone, when they couldn't figure how to scale up the system
without having every third person be a trained "Operator". Make the
system operate itself. That's where the biggest amount of technical
work needs to go. And not just in software -- though that's a very
good start -- but in hardware and in user experience design. When
millions can buy it and plug it in without training, then millions
can be freed from central servers and central surveillance. Not before.
-- John Gilmore
An Android security update from GoogleGoogle has posted an advisory on the recent malware distributed through the Android market and how the company is responding. "We are pushing an Android Market security update to all affected devices that undoes the exploits to prevent the attacker(s) from accessing any more information from affected devices." It's worth noting that the exploit used known vulnerabilities in older versions of Android; there is little in the advisory about closing those holes before they are exploited.
Vendor-sec host compromised, shut downThe vendor-sec list is where distributors discuss security problems which have not yet been disclosed to the public. It turns out that the machine which hosts this list was compromised, probably in January, and any subsequent traffic was not as secret as participants may have hoped. Since the announcement, the machine has been totally vandalized by the attacker, and vendor-sec is down. The thread is interesting to read; much of it concerns whether the community still needs a closed list like vendor-sec or not.
New vulnerabilities dtc: multiple vulnerabilities
kernel: privilege escalation
kernel: multiple vulnerabilities
kernel: denial of service
libcgroup: multiple vulnerabilities
libtiff: code execution
moin: cross-site scripting
moodle: multiple vulnerabilities
proftpd: denial of service
pywebdav: SQL injection
rubygem-actionpack: cross-site scripting/request forgery
scsi-target-utils: denial of service
seamonkey: arbitrary code execution
subversion: denial of service
texmacs: privilege escalation
tiff: arbitrary code execution
wireshark: multiple DOS vulnerabilities
Page editor: Jake Edge |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||