| |||||||||||||
Security response: how are we doing?Security response: how are we doing?Posted Nov 17, 2011 16:29 UTC (Thu) by joey (subscriber, #328)Parent article: Security response: how are we doing?
pam: One CVE does not affect pam due to the kernel version in Debian stable. One CVE does not affect the older pam in Debian stable. Debian stable is vulnerable to the last CVE however. http://bugs.debian.org/599832
kdelibs: Debian stable is not vulnerable due to containing an older KDE. http://bugs.debian.org/647298
xorg-x11: "theoretical sec impact", deferred to next point update http://security-tracker.debian.org/tracker/CVE-2010-4818
rpm: Debian systems don't have trust paths to verify digital signatures on rpms when they are eg, installed with alien, so this vulnerability is very unlikely to make dealing with rpms on Debian less secure than it already was. http://security-tracker.debian.org/tracker/CVE-2011-3378
(Log in to post comments)
kdelibs Posted Nov 17, 2011 16:37 UTC (Thu) by corbet (editor, #1) [Link] Regarding kdelibs, I was working from the Debian security tracker page; perhaps it needs updating?
kdelibs Posted Nov 17, 2011 17:04 UTC (Thu) by joey (subscriber, #328) [Link]
Sorry, I meant to say that one of the two CVEs does not affect stable. The other, as you note, does. (In other words, rekonq is not vulnerable, but kde4libs is.)
kdelibs Posted Nov 17, 2011 17:09 UTC (Thu) by joey (subscriber, #328) [Link]
Oops, no, I was right the first time. kde4libs in stable is too old to be vulnerable. Updating the tracker.
errata corrige Posted Nov 18, 2011 18:26 UTC (Fri) by zack (subscriber, #7062) [Link]
Hi Jonathan, thanks a lot for this article. Keeping the attention level on security issues high is indeed very important for distros.
I also know that getting this kind of data right is particularly hard, given that there is a lot of internal knowledge in distros which is not always as accessible as it should be. In spite of that, you've done a more than decent job at finding security data.
But it is also good that, in the Free world, we can improve on the basis of feedback we receive, and I'm happy to see that you've already received quite a bit of it in comments. Would you considering updating the table to reflect the factual feedback you received here? AFAICT the following changes are warranted:
- the kdelibs line should be "NV" for Debian
- the rpm line should be NV for both Debian and Ubuntu; the point is not much that both distros package RPM, but rather that the vulnerability affect a feature of RPM that is anyhow unavailable in the two distros
- I think it'd also be fair to mention that the xorg vulnerability in Debian has been postponed to the next point release on purpose; the choice is of course debatable, but making an assessment and deciding to postpone is not quite the same as being lagging behind, as the current presentation seemt to imply
Depending on how you read the above data, the "none" count for Debian would go down to either 3 or 4, the most common value for the columns of your table. Considering that, I think it'd be fair to reconsider your "it is, in particular, sad" comment.
[ Disclaimer: I'm the current Debian Project Leader. As such, my point of view can't be more biased. ]
Security response: how are we doing? Posted Nov 18, 2011 3:59 UTC (Fri) by gilbert (subscriber, #81446) [Link]
> xorg-x11: "theoretical sec impact", deferred to next point update
> http://security-tracker.debian.org/tracker/CVE-2010-4818
Note that there were actually four xorg issues involved in that update (with only two being mentioned in the Redhat/Fedora advisories), and it appears that Ubuntu is the only distro that has fixed the remaining two (as of today) [0].
Among those four, at least CVE-2011-4029 is not theoretical as there is existing exploit code in the wild [1]. That should have been enough to make this one DSA-worthy, but that didn't happen [2]. However, fortunately Debian users taking advantage of the stable-proposed-updates mechanism do have an xorg package with this fix included.
Also unfortunately, the Debian openjdk package unfortunately demonstrates the downside of voluntary software maintenance. If there is no one specifically interested and skilled enough to take care of security issues in the package, then it goes unfixed for long periods of time; whereas in a commercial distro like redhat, there is at least someone saying don't let this thing make us look bad. For example, the latest openjdk DSA, which was issued on 27 Sep 2011 fixed issues disclosed on 2 Feb 2011; a 7 month lag.
There have been talks of setting up a security foundation [4], which would establish longer-term security support for the stable releases and may involve encouragement by dangling carrots (i.e. money) in front of packages that are currently lacking interested security volunteers. Who knows if that experiment would work though since money is a very touchy subject within the Debian community.
Fortunately, it seems that there are very few packages that would fall into this security neglection category; the only other notable exception being webkit [5]. I had been working to improve that, but I simply don't have free time right now as I'm finishing my PhD dissertation.
[0] https://lwn.net/Alerts/464080
|
|||||||||||||