So, I got enough of the requisite sponsorship and finally booked some flights

---

DebConf 11 is a post from: jwiltshire.org.uk Flattr

Matt Brown writes about StartCom, the Israeli issuer providing basic SSL certificates for nothing. In fact I ve been using StartSSL certificates for about three years now, but I get them issued to Level 2 verification which incurs a fee. (It s more expensive now than when I was first validated, but still good value.) StartCom are the only issuer I ve ever dealt with who work like this. They validate the individual, using:

• two forms of government ID
• third-party background checks
• telephone verification at a number of their choosing, based on the checks

This makes me trust them far more than other issuers, who don t bother with any meaningful validation at all. Their approach is to establish identity, then allow you to:

• validate domains and issue as many certificates as you wish, valid for two years, including SAN and wildcard certificates
• validate email addresses and issue X.509 certificates in your name
• issue code signing and XMPP certificates
• undertake stringent Organisation Validation, and then issue certificates in a company name as well as an individual
• validate other individuals with a web-of-trust arrangement, like CACert
• undergo Extended Validation and issue EV certificates
• if you have an unspecified amount of money, become a private CA yourself

Although this doesn t make up for trust (the presence of an SSL certificate doesn t guarantee the data you send is safe upon arrival) it does make me much happier to see a CA taking proper verification measures instead of just handing out certificates at random and it s much cheaper for me too, being verified once and then issuing as many certificates as I need. Highly recommended. *that is, more trustworthy

---

StartSSL: finally, a trustworthy certifier* is a post from: jwiltshire.org.uk Flattr

For many months I ve wondered what would happen if one completed half a census return online and half on paper. Tonight, finally, I get to find out. (for international readers: it s the night of the U.K. census, which with a little imagination has the potential for all sorts of fun.)

---

A little civil disobedience is a post from: jwiltshire.org.uk Flattr

I ve had a very courteous email from one of the founders of ALLOW, following my analysis of their password reset procedure.

Thank you for your feedback regarding the security of our platform. We are constantly reviewing these processes and regard our members security as paramount, whilst ensuring our processes are navigable to the majority of the UK. We have had the platform professionally penetration tested but your email demonstrates an excellent understanding of the challenges and we would welcome your suggestions on our options of improving the password reset process. We will be extending our SSL certificate to the publicly accessible website and please be assured that this is held on a different architecture to that of the Member application.

This is very promising!

---

Response from ALLOW Ltd. is a post from: jwiltshire.org.uk Flattr

I was interested to hear about a company here in the UK called ALLOW Ltd., offering marketing database management under a we ll get you off lists, then pay you to go back on at your pleasure basis. That sounds a fair deal to me, so I decided to sign up for it.

Our technology is built using some of the best and most secure tools in the industry. We have partnered with infrastructure providers who handle some of the most sensitive data in the UK (such as medical and financial records). Both the digital and physical security measures we have implemented are amongst the strongest available anywhere. This includes full encryption of all data at all times, full implementation of secure socket layers, security certificates and physical restriction of access to the data, our servers and our offices. Our systems have been fully penetration tested (that means we ve asked people to try and break in).

(There are other suitable assertions in various places they even have a set of principles about safeguarding data.) Unfortunately, this promise is rather undermined in several ways after noticing the first couple, I did a little digging to see what else was exploitable. Here s the final part of the joining process, where you choose a username and password combination: The text I ve cropped too eagerly says Choosing a secure password is an essential part of protecting your personal information , or thereabouts. I duly chose a complex password that fitted the requirements, and to my surprise it was rejected. I tried another, and it was rejected; then a third and a fourth. By trial and error I worked out what was going on: 1. The password must contain only the listed special characters, not just include one of them. That s a bit of a problem, because even assuming a basic ASCII set, 15 characters are unavailable to users; 80 are left, so that s about a 15% fall in the available combinations*. Not a good start. More concerning is the presence of a security question field. It s used for resetting the password in the event losing it, but this technique for recovery has long been ridiculed the shared secret is often common knowledge amongst friends, and sometimes (as in this case) the available questions are fairly easy for an attacker to find the answer to in public records or solicit from the victim without arousing much suspicion: 2. The security questions available include First pet s name and worse, First school name . It s pretty pointless enforcing stringent password requirements, and then bypassing them with something so susceptible to a dictionary attack. I was pleased to find that failing to log in to an account more than a few times results in a temporary lockout, which should deter casual brute force attacks. But I wanted to know how that security question would be used, so I forgot my password and followed the links to reset it. Here s the form: Actually the first form, not shown here, initially just asks for a username, giving an error message if it isn t registered, and here s another problem: 3. The password reset process confirms the existence, or non-existence, of a given username half the credentials required to log in to any visitor. I d be prepared to take a bet that most users will choose What was the name of your first school? as a security question. The first pet you have is often at such a young age you can t remember it clearly; the name of the street you grew up on might change a couple of times if you moved house. But first school I attended? I ll never forget that, so it makes most sense to use as a backup password . It s also the best one for an attacker to try and find out from public sources. But that aside, as you can see the password is not generated at random and communicated to the real account holder out-of-band, in the manner of many other sites. Instead: 4. A new password is immediately set to a value already known by the attacker. Once inside, an attacker can also change the security question or answer, or both, so you can t even regain your account by telephoning the company unless you can convince them you re genuine, in which case the security question was a total waste of time anyway. I awarded some marks for notifying the user by email that the password has been changed, but immediately docked them again because bingo! You re now a victim of identity theft! Let s assume you ve been locked out, the security question has been changed and you want your account back. ALLOW don t let you telephone them; you either have to dig around and find an address to send an email, which we all know can be intercepted, or (and you re encouraged to) contact them through a form on the site. You ll probably include some personal details, because you want to convince them of your real identity; indeed, two of the options on the form are I ve got a question and Something doesn t work . I sent my findings through this very form, under the latter heading, and to my surprise: 5. Despite promises of full encryption of all data at all times, full implementation of secure socket layers , the contact form is transmitted to ALLOW in the clear, with no protection whatsoever. So now anyone listening in your connection knows all about you too: your ISP, any of the peers along the route, the deep packet inspection advertisers if your ISP is less than reputable, and the neighbour who connects to your wireless and slips you a fiver every month for the privilege. Nice work, privacy specialists. (For the record:

• I have sent these findings to ALLOW and await a response have a response.
• Yes, this scenario is unlikely, but it doesn t fill me with confidence about the rest of their business activities.)

* please feel free to correct my maths. It was never my strongest subject.

---

Privacy specialists should hire security specialists is a post from: jwiltshire.org.uk Flattr

In Bits from the Security Team a few weeks ago, Thijs Kinkhorst wrote:

Since a couple of years we ve been handing off security issues of minor or
theoretical impact but for which a fix would be desirable at some point, like
certain classes of denial-of-service attacks, off to stable point updates.
We re looking for a person that wants to coordinate this: monitor the Security
Tracker for issues classified as such by the Security Team, converse with
maintainers to get such updates done and coordinate with the stable release
managers on this.

I m happy to confirm, now that it s been announced, that I am that person: point release security co-ordinator. Affected packages If your package fulfils these criteria:

• it had a security problem reported in the past (that is, it was allocated a CVE number);
• it didn t get a Debian Security Advisory, but it wasn t marked unimportant in our tracker;
• it has been fixed in unstable, but the version in stable or oldstable is still vulnerable

it is a candidate for updating in stable or oldstable, and you ll probably receive a mail from me at some point asking you to do so. You can pre-empt this mail of course, by backporting your fix to the affected versions and contacting the release team to get your fix into stable, without waiting for me. In such a case, please drop me a note with the details so I can tick your off on my hit^W candidate list. Making a stable/oldstable upload This is documented in the Developer s Reference, but to summarise:

1. Prepare your fix, targetting stable or oldstable, and build it in an up-to-date chroot for that release
2. Send a diff of the new package to the release team, asking for permission to upload
3. Upload as normal, and wait for it to be included in the next point release. Meanwhile, notify the security team of your upload, if it fixes a CVE.

Tracking candidate packages I m going to start off tracking filed bugs for SPU candidates and OSPU candidates with usertags in the BTS, under my own address. In time that might be merged into an address used by the security team, but for now I m still finding a good workflow so it s much easier this way.

---

Point Release Security Co-ordinator is a post from: jwiltshire.org.uk Flattr

The following developers got their Debian accounts in the last month:

• Jonathan Wiltshire (jmw)
• Michael Hanke (mih)
• Sebastian Reichel (sre)
• Siegfried-Angel Gevatter Pujals (sgevatter)
• K re Thor Olsen (kaare)
• Didier Raboud (odyx)
• Benjamin Drung (bdrung)

Congratulations!

The following developers have returned as Debian Developers after having retired at some time in the past:

• Matt Zimmerman (mdz)
• Jerome Marant (jerome)
• Scott James Remnant (keybuk)

Welcome back!

I recently had to setup netconsole in order to diagnose some grsecurity-related suspend/resume problems. The idea is to have the broken machine send its kernel messages to a remote machine via the network.
As a prerequisite, the local machine (the one sending the console messages) must have the following kernel options turned on:

• CONFIGFS_FS
• NETCONSOLE
• NETCONSOLE_DYNAMIC

(The first and last ones are required in order to be able to configure netconsole after boot, through the configfs interface.)The remote machine should be told (using netcat) to listen on a specific UDP port (64001 in this example):

netcat -l -p 64001 -u -s 192.168.1.1 2>&1 tee /root/netconsole.log

Then, running this script on the local machine will turn netconsole on (don't forget to customize the appropriate parameters for your environment):

#!/bin/sh
modprobe configfs
umount /sys/kernel/config 2> /dev/null
mount -t configfs none /sys/kernel/config
modprobe netconsole
mkdir  /sys/kernel/config/netconsole/hostname
echo "xx:xx:xx:xx:xx:xx" >  /sys/kernel/config/netconsole/hostname/remote_mac
echo 192.168.1.1 >  /sys/kernel/config/netconsole/hostname/remote_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/remote_port
echo 192.168.1.2 >  /sys/kernel/config/netconsole/hostname/local_ip
echo 64001 >  /sys/kernel/config/netconsole/hostname/local_port
echo eth1 >  /sys/kernel/config/netconsole/hostname/dev_name
echo 1 >  /sys/kernel/config/netconsole/hostname/enabled
dmesg -n 8

That's all you need to start seeing messages on the remote machine's screen.
Interested readers may want to look at other ways to configure and use netconsole.

I have received a brand new USB card reader. At first sight, everything was working well “out of the box”, but when I have checked the log files, I could see the following lines repeated very frequently: I repeat everything seems to work OK, but I can’t stand this kind of messages, especially when it deals with storage (by experience, everything works well during the tests, you simply ignore error messages, and you loose your data the first time you really use your hardware!).
After some googling, I have found this issue is hardware related. A lot of people seem to get hit by this. Some have even reverted to USB 1 (UHCI)! Further googling pointed out this article. I have tried to disable USB auto-suspend, and changing the idle-delay time (default is 2 seconds). But it doesn’t help. Just for reference, this can be done like this:
echo -1 > /sys/module/usbcore/parameters/autosuspend Note the following part of the documentation:
The idle-delay values for already existing devices will not be affected To make the change permanent, you need to append usbcore.autosuspend=-1 to the boot parameters (USB support is compiled into Debian kernels).
More information on: http://www.mjmwired.net/kernel/Documentation/usb/power-management.txt I can also see the following message at boot time: According to this recent discussion, it seems it is harmless. I have however noticed that unplugging the card reader and re-plugging it after the system has booted make these log entries disappear. Does someone have an idea? Note that I use the latest Debian 2.6.25 kernel: