It is our pleasure to announce that Aur lien Jarno is now an assistant to the Debian Security Team.

He will concentrate most of his efforts on security support for the new kFreeBSD kernel.

Thanks Aur lien, and welcome to the team.

Contributed by:Steffen Joeris, on behalf of the Security Team

I ve just added the Wordpress Minify [1] plugin to my blog. It s purpose is to combine CSS and Javascript files and to optimise them for size and it s based on the Minify project [2]. On my documents blog this takes the main page from 313KB uncompressed, 169KB compressed, and a total of 23 HTTP transfers to 306KB uncompressed, 117KB compressed, and 21 HTTP transfers. In each case 10 of the HTTP transfers are from Google for advertising. It seems that a major obstacle to optimising the web page load times is Google adverts of course Google has faster servers than I do so I guess it s not that much of a performance problem. The minify plugin caches it s data files and I had to really hack at the code to make it use /var/cache/wordpress-minify a subdirectory of the plugins directory was specified in many places. deb http://www.coker.com.au lenny wordpress
I ve added a wordpress-minify package to my repository of Wordpress packages for Debian/Lenny with the above APT line. I ve also got the following packages:
adman
all-in-one-seo-pack
google-sitemap-generator
openid
permalink-redirect
stats
subscribe-to-comments
yubikey The Super Cache [3] plugin has some nice features. It generates static HTML files that are served to users who aren t logged in and who haven t entered a comment. This saves significant amounts of CPU time when there is high load. The problem is that installing this requires modifying the main .htaccess file, adding a new .htaccess file in the plugins directory, and lots of other hackery. The main reason for this is to avoid running any PHP code in the most common cases, it would be good for really heavy use. Also PHP safe mode has to be disabled for some reason, which is something I d rather not do. The Cache [4] plugin was used as the base for the Super Cache plugin. It seems less invasive, but requires the ability to edit the config file. Getting it into a shape that would work well in Debian would take more time than I have available at the moment. This combined with the fact that my blog will soon be running on a system with two quad-core CPUs that won t be very busy means that I won t be packaging it. If anyone would like to Debianise the Cache or Super Cache plugin then I would be happy to give them my rough initial efforts as a possible starting point. I m not planning to upload any of these packages to Debian, it would just add too much work to the Debian security team without adding enough benefit.

• [1] http://wordpress.org/extend/plugins/wp-minify/
• [2] http://code.google.com/p/minify/
• [3] http://ocaoimh.ie/wp-super-cache/
• [4] http://wordpress.org/extend/plugins/wp-cache/

Last week I resigned from my position as member of the Debian Security Team. Historically several Debian teams have had members inactive for months and years at a time, and I'd rather be removed of my own volition than end up listed but inactive like that. It's been a pleasure working with all members of the team, past and current (especially Joey), and who knows I might return in the future. If you're interested in security work then getting involved isn't difficult. It just takes time, patience, and practise. ObFilm: The Goonies

Alexander Wirt just wrote a mail to our mailinglist to announce that lenny-backports suite is ready for uploads. We will of course continue supporting etch-backports with security updates as long as etch will be supported by the Debian security team.

Happy backporting!

SE Linux is almost ready to use in Lenny. Currently I am waiting on the packages libsepol1 version 2.0.30-2, policycoreutils 2.0.49-3, and selinux-policy-default version 0.0.20080702-4 to make their way to testing. The first two should get there soon, the policy will take a little longer as I just made a new upload today (to make it correctly depend on libsepol1 and also some policy fixes). Update: libsepol1 version 2.0.30-2 and policycoreutils 2.0.49-3 are now in Lenny (testing). Now I’m just waiting for the policy. Ideally we would be able to pin the apt repositories to take just the packages we want from Unstable (here is a document on how it’s supposed to work [1]). That doesn’t work, so I also tried setting “APT::Default-Release “stable”;” in /etc/apt/apt.conf (as suggested on IRC). This gave better results than pinning (which seems to not work at all) but it still wanted to take unreasonably large numbers of packages from unstable. Currently to get SE Linux in Lenny (Testing) working you must first upgrade everything to the testing versions, then install libsepol1 from Unstable (this is really important as until a few hours ago the Policy packages in Unstable didn’t depend on it). Then you install policycoreutils and finally the policy package which will be selinux-policy-default for almost everyone - I have not tested the MLS package (selinux-policy-mls) and it’s quite likely that it won’t work well. The policycoreutils package has a bug related to Python libraries [2] which I don’t know how to fix. Any advice would be appreciated. It’s obvious that the package name needs to not contain a hyphen, but what the name should be and where the files should be stored. The release team have been pretty cooperative with my requests so far to get broken things fixed, hopefully I’ll find a solution to this (and the other similar issues) soon enough to avoid any great inconvenience to them. I’m sure that they will agree that significantly broken packages (which have syntax errors in scripts) need to be fixed before release. There are also some last minute policy issues that need to be fixed. To properly test this I’m now running the server for my blog and mail server on Lenny with SE Linux. I think that I’m only one policy bug away from running in enforcing mode. While the situation is pretty difficult at the moment (I’ve had a report forwarded to me from an OLS delegate who tried Lenny SE Linux with the older policy packages and got a bad result), I believe that once Lenny is released we will have the best ever support for SE Linux. The Debian security team recently released an update to the SE Linux policy packages to match the recent updates to BIND [3]. I was grateful that they did this - and without any significant involvement from me. I was asked to advise on the patch that they had written, I confirmed that it looked good (which took hardly any effort), and they did the rest (which appears to be a moderate amount of work). Given the situation it would have been understandable if they had decided that it was something that could be worked around. I expect that SE Linux on Lenny will get more users than on Etch, so therefore more issues of this nature will be discovered so I expect to have more interaction with the Debian security group in future.

• [1] http://jaqque.sbih.org/kplug/apt-pinning.html


• [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=486120


• [3] http://www.debian.org/security/2008/dsa-1617

Share This

This Tuesday Robert Felber released a new upstream version. It is a (local) security bugfix (and some minor fixes) which was reported on Sunday by Chris Howells to the Debian Security Team (as well as to other vendors). Today DSA-1531 was released. Right from the DSA:
“… created its socket in an insecure way, which may be exploited to overwrite or remove arbitary files from the local system.” So please update you systems if you use this package asap. While we are at policyd-weight… there is one bug open (#471645) where I’m unsure if I want to fix it, cause only stable is effected and the problem can be solved by providing a adjusted array of rbl in the config file. Should I ask for inclusion directly into stable? But it’s a really minor issue. Or try to get 0.1.14.15 uploaded to volatile? I’m really unsure and suggestions are welcome.

Serious business involving the vmsplice() exploit: The kernel is fixed, hopefully Debian security team will have a fix for production use soon. In the meantime, waldi has provided unofficial fixed images. Thanks! They are confirmed to be working. These images are for etch. Lenny and sid are still vulnerable, but I suspect this will be fixed soon. If you are using these images in virtual machines, be aware that you will need to install the modules into each one or they may have problems later. GNOME is broken on Debian/kFreeBSD: All of this exploit nonsense made me consider installing Debian/kFreeBSD on one of my machines to see if it was worth using as a desktop system. Sadly, it doesn’t work for me right now. I guess I’ll try back in a couple of months. Also, it’d be nice if a new install CD was released with the proper /etc/apt/sources.list (ftp.gnuab.org -> ftp-debian-ports.org).

Today is the end of a pretty long week-end of dealing with samba. About 10 days ago, we (the samba packaging team in Debian) were privately notified of security issues found by the Samba Team developers in this quite popular package. This very close to one of their bi-annual releases, namely 3.0.25. No less than three security issues were unveiled. Two of them (CVE-2007-2446 and CVE-2007-2447) affect all currently supported Debian releases, namely sarge, etch and sid. One (CVE-2007-2444) affects both etch and unstable. This was the beginning of long days of rehearsal, helped out by Noah Meyerhans from the security team. Finally, updated versions for sarge and etch were uploaded to oldstable-security and stable-security for the autobuilders to catch up (they still are catching up because I uploaded the updates without the .orig.tar.gz file, which unveiled a bug in the security autobuilders apparently). These updates for sarge and etch should be available as soon as the security team completes the final checks and approval, I guess. And, today, the Samba Team gave us early access to the newly released 3.0.25 version of samba so that we could build and upload that package 2 hours before it was officially announced..:-) Thanks a lot again to the Samba Team for their care and more particularly to Gerald "Jerry" Carter (someone I have deep respect for, along with Jeremy Allison and Andrew Tridgell). Thanks to Steve Langasek for his hard work preparing the 3.0.25 release (tracking down an upstream bug in the Pythin bindings build). And, finally, thanks to the Debian security team and more particularly to Noah Meyerhans for his work on backporting some of the patches. This was a tiring but really motivating week-end. I hope that all Debianers who use Samba will enjoy the result.

My face is covered in egg. Antti-Juhani Kaijanaho found a security problem in EoC, both the 1.0.3 and the 1.2.3 versions. The problem is that EoC did not quote shell arguments properly. I have fixed the problem in 1.2.4, which contains no other changes relative to 1.2.3. This problem has the code CVE-2006-5875. You can find the 1.2.4 version from the EoC website: http://liw.iki.fi/liw/eoc/ and I have also uploaded it to Debian's unstable. Debian's stable contains 1.0.3, and I have prepared a patch for that. It is actually essentially the same patch as was used to create 1.2.4. The Debian security team has uploaded a fixed version of the 1.0.3 package to security.debian.org. I've attached it to this message in case anyone not running Debian wants to stay with 1.0.3, but I won't be releasing a 1.0.4 unless someone really needs it (if you do, please tell me immediately). For risk assessment: I was unable to come up with an exploit. Doing so would require getting a certain kind of construct through the SMTP level to EoC, and I wasn't able to make that happen, but I would not rely on it being impossible. Therefore, please upgrade immediately. I apologize for this problem. It was amateurish to let the problematic code into a released version of the program, I knew better than do that.

I personally continue to work on Debian how I can but the Dunk Tank think made me thoght about the priorities that some people are putting in few (better, one) position only of project. I disagree completely how is this working and see, not too few people, reducing their work on Debian. Some are clearly not caused by this annoyance but others not. Why does our FTP Masters and NEW queue processing people are not included on that list of people that are receiving money to work? Debian Security team? Debian Installer team? Those teams has the same importance of RM team. Can we release without a propor security or lacking a Debian Installer? Of even, can we release without a good libc or a stable and well maintained GCC compiler? That “Dunk Tank” or, in my understanding, “How we workaround a project concensuos” thing, is wrong. Obs.: you don’t need to agree with me and that is my point of view.

Disclaimer: I am not comfortable with technical documents in my native language, German. I generally find German translations of technical stuff clumsy, overly complicated and badly worded. I might have a “special” feeling for the language, but some output of translators is just too bad to tolerate.For example, I constantly keep stumbling over the german translation of the Debian security team FAQ, which I consider horrendously badly done. Especially the use of the german word “Gutachten”, which basically means “opinion” in the legal sense (as the document produced by an expert called by a court of law) to translate “advisory” is a very very bad choice. My toes curl when I read the german version.In April 2005, I suggested to the German translation team to review the translation of the security team FAQ. I might not have chosen the right wording for that request, but besides a lot of flamage and “the translation is just fine”, I received the usual “send a patch”. Which I did in April 2005.No answer. In October 2005, I asked again, and received answer from the translator that my patch was just too intrusive. Well, a bad translation was rewritten, and the bad translation is still being used.Consequences for me? I’m not going to bother any more about German translations. English is just fine, and when somebody needs a German translation, I’m going to translate the stuff myself. Pointing people to the official German translations is just too embarrassing. A pity.

Before:

skx@desktop:~$ ssh security-master.debian.org groups
Password:
Debian webwml sec_data
skx@desktop:~$

After:

skx@desktop:~$ ssh security-master.debian.org -l skx groups
Password:
Debian security webwml sec_data

… or in other words I’m no longer a secretary of the Debian Security Team, instead I’m a full member!