The Failure of my Security Blogging Contest

On the 20th of January (8 days before the start of linux.conf.au) I advertised contest to write blog posts related to computer security for the conference Planet [1].

The aim of the contest was to encourage (by money prizes) people who had no prior experience in computer security to get involved by writing blog posts. The rules permitted security professionals to enter but only for an honourable mention, the money was reserved for people without prior experience.

The money that I initially advertised was a fraction of what was reserved for prizes, the idea being that if the contest went well then the prize pool could be easily increased but that if it didn’t go well then there would only be one small prize for someone to win by default. At the time I considered a single entry winning by default to be the worst case scenario.

The eventual result was that there was only one entry, this was from Martin Krafft on the point of keysigning [2]. Martin has prior experience in the computer security field which excludes him from a money prize, but he gets the only honourable mention. From a quick conversation with him it seems that his desire from entering the contest was to get his ideas about weaknesses in the keysigning process spread more widely, so this seems like a fairly ideal result for him. I agree with Martin that there are significant issues related to the keysigning process, but my ideas about them are a little different (I’ll blog about it later). His point about people merely checking that the picture matches on the ID and not verifying what the ID means is significant, the fact is that the vast majority of people are not capable of recognising ID from other countries. Other than requiring passports (which differ little between countries) I can’t think of a good solution to this problem.

Congratulations Martin! It is a good post and a worthy entry.

Now as to why the contest failed. I spoke to some people at the end of the conference about this. One delegate (who I know has the skills needed to produce a winning entry) said that I advertised it too soon before the conference and didn’t give delegates time to write entries. While I can’t dispute his own reasons for not entering I find it difficult to believe that more than a small proportion of delegates had that motivation. The LCA Planet had some lengthy posts by other delegates, and the guy who won second prize in the hack-fest spent something like 20 hours coding on his entry during the conference time (I suspect that my contest had the potential for a better ratio of work to prize money). Also the 8 days before the conference started was a good time to write entries for the contest.

One suggestion was that I propose that the conference organisers run such a contest next year. The problem with this is that it’s difficult to say “I tried this and failed, could you please try it too”. If nothing else I would need some significant reasons to believe that the contest has the potential to be more successful before attempting it on a larger scale. If the contest had been backed by the LCA organisers then it might have been more successful, but that possibility seems unlikely (and there is scope for an event to be more successful than mine while still being a failure). The reason that I consider it unlikely that official support would make it more successful is that I first advertised the event on my blog (syndicated to the conference Planet). Everyone who has a blog and attends the conference can be expected to have read about it. I then advertised it on the conference mailing list which I believe had as subscribers a large portion of the people who have enough spare time to create a blog specifically for the purpose of entering such a contest.

A blogging contest related to a conference but which had a wider scope (IE not limited to one field but instead covering anything related to the conference) might be successful. If someone wants to run such a contest next year then it’s probably worth doing.

Of course I have not given up on the plan of getting more people involved in computer security, expect to see some blog posts from me in the near future with other approaches to this. Suggestions would be appreciated.

Security Blogging Contest

It seems that my blogging contest idea is a failure. Could the interested people please meet me near the LCA registration desk at the start of the lunch breakh today for a post-mortem.

Any last-minute entries can be submitted by telling me the URL then.

Suse and LCA

I previously wrote about how I gave a talk about SE Linux at a conference spot when a talk about AppArmor was scheduled. It turned out that the Suse people had notified the LCA people some time in advance about the fact that John would not be attending the conference. The LCA people had removed the entries from their databases and when the conference schedule was printed it had no reference to such a talk.

The problem occurred when another tutorial (which had occupied the slot that was previously assigned to John) was moved to a different part of the schedule. For some reason the CMS that they use did not leave the slot in question empty but instead restored earlier contents (which was the Suse tutorial). No-one at LCA noticed this error and from that time on the web page generated by the CMS was used as the authoritative source of information about the issue by delegates and most of the LCA team.

1

My LCA Talk

Last year at LCA Crispin Cowan suggested to me that I make a joint offer of a combined tutorial on SE Linux and AppArmor as a way of publicly comparing the two technologies. I ended up not accepting the challenge, among other things I had a long-term project going in production in early December that needed some ongoing support.

Crispin’s plan B was to just give a lecture about AppArmor. Recently Crispin joined Microsoft [1] and John Johansen of Suse was going to give the talk in his place. The LCA people made a minor mistake by having the conference web site give the description of the tutorial option [2] (which I don’t believe was ever going to happen as I had not accepted the offer), but it’s easy to understand the webmaster copying the wrong description when the one person makes two offers (which I believe is not a common practice).

So this morning I and about 150 other people were waiting in the main lecture theatre and no-one from Suse turned up.

Being fairly audacious when the announcement was made that the event was officially cancelled I stood up and asked if anyone would like an impromptu talk about SE Linux instead. The audience received that idea quite well.

My talk wasn’t as good as I had hoped, not having had a proper breakfast or any caffeinated drinks reduced my mental stack space. So I could talk well on one topic but when questions diverted me to a side topic I found it difficult to remember the previous point I was making. Fortunately when giving an impromptu talk with no notes or presentation materials the audience expectations for a consistent plan of the talk seem reasonably low. ;)

I started by talking about my SE Linux Play Machines. Some of that material had been covered in previous talks at other conferences (such as at a previous SE Linux Symposium), but some things (such as my use of Xen) I had not previously covered, but none of it had been mentioned in a talk in Australia for a while. Having given an hour-long talk about SE linux yesterday to an audience with many of the same members I wanted to start by talking about something that they hadn’t heard before, and I was also wearing a Play Machine T-shirt (with the root password printed on it) [4]. After I finished talking about my Play Machines and started covering some of the same material as yesterday about a quarter of the audience left (which was fair enough).

I then spoke about general SE Linux issues, largely in response to questions. I covered the differences between the policies (including the history of policy development), the JFFS2 XATTR development (and how SE Linux couldn’t be used on an iPaQ without it), issues of disk space usage for XATTRs for SE Linux labelling on various filesystems and how it drives the use of context mount options, poly-instantiated directories (including some discussion on how the actual storage location for such directories can be on a different filesystem and how this could be convenient when using encrypted filesystems), how Apache/PHP work in a SE Linux environment, and a lot more.

I couldn’t resist mentioning to the audience the irony that I had declined a challenge for a joint presentation and then got a sole presenter spot (and a large audience) due to the Suse guy not showing up.

For future situations I plan to load lecture notes from all my common talks on my iPaQ. Then next time I have such a speaking opportunity I can give a better prepared talk.

Update: It turned out that the LCA people had been informed that the Suse talk was cancelled and had made a mistake, see this link for details.

Change of Rules for the Blogging Contest

Due to the lack of entries so far I am amending the rules. It is no longer required that an entry be on the blog of the person who submitted it. Being on any blog that is aggregated by the conference Planet will do.

This is known as a “guest post“. All it requires is that you email the post content to a blogger who you trust and they post it crediting you as the author. Guest posts are fairly common among serious bloggers, a google search will surely give more information.

3

LCA 2008 Security Miniconf

Today I gave a talk about Debian security at the security mini-conf of LCA.

Before I started the talk I asked for suggestions as to how to get more entries in my security blogging contest [0]. During the talk I asked for suggestions as to how to get more people involved in security development. One suggestion was to offer incentives. I’m experimenting with that with my blogging contest and may do future variations of the same thing.

I started with describing some of the history of security in Debian (primarily things that involved me in some way):

In 2003 I suggested that exec-shield be a standard feature in Debian kernel images [1]. I created a kernel-patch-exec-shield package in 2003 and Marcus Better took it over in 2004. We are hoping to get it included in Lenny. AMD64 architecture doesn’t need exec-shield as the CPU has separate write and execute bits in the page table, but it would be nice to get exec-shield included before the last P4 machine gets decommissioned.

A presentation at the security miniconf at LCA 2005 on the topic of stack smashing is interesting [2]. At the time Adamantix was a distribution based on Debian which used PaX (similar to exec-shield). Adamantix has gone away. Hardened Gentoo has been available with Pax for all this time (but is not widely used). RHEL and Fedora have been available for all this time with exec-shield…

In mid 2002 I demonstrated the first SE Linux Play machine at a conference in Germany. It was fully operational with root as the guest user. At that time SE Linux support in Debian was essentially complete. Since that time the scope of the SE Linuc project has increased slightly (EG controlling DBUS access) so the amount of work required for full support is greater. Most of that support is in Debian and Etch is basically working with SE Linux (although not quite as well as it was in 2002 due to lack of support for the strict policy). The aim is to have Lenny SE Linux become as functional as SE Linux in Fedora Core 5. While FC5 has more SE Linux features than the SE Linux project supported in 2002 it’s still a great disappointment that it’s taken so long.

FC5 had pam_namespace to polyinstantiate directories such as /tmp. Lenny will hopefully have it.

I described the current status:

The hardening-wrapper package in unstable allows environment variables starting with DEB_BUILD_HARDENING_ to be used to control execution of GCC. Documented on the Debian Hardening Wikipedia page [3]. It’s still a little experimental and may change in the near future, but it works.

Lucas Nussbaum is working on automatically building Debian packages with warnings for security related issues. The aim is to build all packages and maintain a central location for the logs to allow DDs to find and fix the problems in their packages.

The Alioth Hardening project [4] will hopefully get some action soon (the people involved are busy doing work but not updating the project). The current plan is to base the Debian Hardening work around it.

SE Linux in Debian is something that I want to get working correctly. There are still some significant issues that make strict policy unusable (such as correct labelling of /etc/passwd) as of last time I tested it.

Finally I described the future plans. There were many questions about usability features for SE Linux, I mentioned in concept the features that Red Hat and Tresys people are developing (which I often don’t use as I prefer vi for policy editing).

There were some questions about how SE Linux works. More than half the audience indicated that they had used it so I assumed some basic knowledge of SE Linux when describing how SE Linux works in regard to minimum privilege and the benefits of MAC in terms of limiting the scope of attack. I noted that every program has bugs and every program which performs security related tasks (which includes serving data to the net without being owned) should be assumed to inevitably have security related bugs (see the The Inevitability of Failure paper []).

Based on the Twilight of the Books [5] article I decided to give this talk with no slides as an experiment. I talked from notes that I wrote and advised the delegates to read my blog for the details. Not presenting any slides meant that the room lights were all left on, which made things much easier when answering the many questions (I prefer an interactive format to my talks and have more questions than most speakers). It will be interesting to get some feedback from delegates about how they regarded this.

12

Storing a GPG key

Chris Lamb has suggested storing a GPG key on a RAID-5 device [1]. The idea is that it can be stored on several physical block devices such that losing just one will not give the key to an attacker.

A default GPG secret key will be about 1.2K in size (3 sectors of a hard drive). A minimal key (with 1024 bit DSA keypair) will be 0.9K (2 sectors). I expect that very few people have secret keys greater than 4K in size.

To create a software RAID-5 device under Linux the tool mdadm is used. The default chunk size is 64K, so a 1.2K file will probably be on a single device. If you use the -c option of mdadm to specify a smaller chunk size then the smallest that is accepted is 4K which still permits a default GPG secret key to be on a single device. The Ext2 and Ext3 filesystems will always align such file data to a 4K boundary unless the device is smaller than a certain size (or a special mkfs option is used) to give a 1K block size for the filesystem. If an Ext2 or Ext3 filesystem is used with 1K blocks then you might get a 1.2K file split across multiple 4K RAID chunks.

So storing a GPG key on RAID-5 won’t prevent an attacker who steals one part from getting all the most valuable data. It will make it more inconvenient for them (if you are lucky it will prevent them getting all the data) and it will also make it difficult for the owner of the GPG key to determine which of the devices actually contains the secret data (probably all of them will end up having copies if you edit the secret key).

Now if RAID-5 did allow chunk sizes that were smaller than the secret key or if you have Ext2/3 with 1K blocks and get lucky with file fragmentation then the problem still isn’t solved. The reason is that you don’t require N-1 of the N disks to get some useful data out of a RAID-5 array (run strings on one element of a RAID-5 array to verify this). A single disk on it’s own will have some data that can be used, as file(1) can recognise GPG secret keys so you could just copy 1K chunks of data into separate files and use file to determine which (if any) has the data in question.

The really exciting question is, what do you get if you have the first 1K of a 1.2K GPG secret key? If it could be proved that the first 1K does not give an attacker any advantage then this might provide some benefit. But I think that this is a very dubious assumption, when dealing with such things it’s best to assume the worst. Assume that an attacker who has 1K out of 1.2K of secret data has the ability to reconstruct the rest. In that case the Linux kernel RAID-5 provides no benefit for storing a GPG secret key.

Just try not to get your devices that contain secret data stolen. Maybe a watch with a built-in USB device is a good idea. Thieves seem to be targetting mobile phones instead of watches nowadays and something that’s strapped to your wrist is difficult to lose.

1

Secure Computation on an Insecure Base

Julien Goodwin asks whether an insecure platform can perform secure computation [1]. My immediate reaction was to recall Charles Babbage’s quote On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” […] I am not able rightly to comprehend the kind of confusion of ideas that could provoke such a question [2].

However on careful reading of Julien’s post it seems that he is most interested in the integrity of the computations rather than the secrecy. He suggests the possibility of performing the computation twice and comparing the results. Of course the issue to consider is whether both computations could be subverted. It seems most likely that if you are using someone else’s computation cluster for the calculations then performing the same calculation on two nodes of that cluster will give the same result both times (whether it’s right or wrong).

If there was a computation that would get a result that can be verified with little computation then it would be an easy problem to solve. For example if I wanted to brute-force a passphrase for a GPG key then I could try all combinations that were known to be possible, if one was flagged as correct then in a millisecond I could verify it. If none of the possibilities were listed as correct then I could assume that the process was broken in some way. The problem with this is that such a passphrase can have arbitrary length (I know someone who uses more than 50 characters). So if I used a brute-force attack on passwords of up to 9 characters that doesn’t exclude a 10 character password.

Probably the best potential use for insecure systems is for analysing large data sets. There have been several projects to harness unused computation resources to perform various large calculations (protein folding and SETI are two examples). Most such projects use closed-source programs because the people who run the contests are afraid of cheats who modify their programs to merely say “no” repeatedly and quickly. Of course this wouldn’t be a problem if they didn’t have a high-score table, and disassembling the program to hack the protocol can’t be that difficult (consider the work invested in reverse engineering protocols such as SMB which are much more complex).

It would probably be reasonably to randomly send batches of work to two machines in different regions for such large-scale public computation projects.

Finally if you want to perform calculations on secret data on someone else’s hardware then you may have lost before you even start.

3

LCA 2008 Security Blogging Contest

I have decided to run a contest for security related blog posts that appear on Planet Linux Conf Au [1]. That Planet is for people who are attending Linux Conf Au [2], and the prize (or prizes) will be given out at the conference.

The aim will be posts on the topic of computer security from people who are not experts. Anyone who has been employed as a security consultant or developer of security software or who has spoken at a conference such as LCA on a topic related to security can enter but will only be eligible for an honourable mention. Any such expert who enters for an honourable mention MUST note on their entry that they are not eligible for a prize to avoid any possible confusion.

Only blog posts of a positive nature will be well regarded by the judges. Negative reviews are only acceptable if they have positive suggestions for improvement and/or bug reports linked from them.

You may submit a series of posts on a theme, and multiple posts on different security issues will help an entry – we will judge the contributions of the person not a single post.

The prize pool is currently $50, which I hope to expand – but such expansion depends in part on the quality and quantity of early entries, so if some good entries are submitted soon then there will be more and bigger prizes. Currently the prize pool comes from the pockets of me and Casey, commercial sponsorship will be accepted and may increase the prize pool significantly.

The duration of the contest is from this moment until at least lunch-time on Friday the 1st of February. We may extend the contest until Friday night and announce the winner(s) on Saturday – but at this time you should not count on such an extension and plan to have your entry or entries in by mid-day on Friday the 1st of Feb (Australian eastern daylight savings time).

So far of the people I have invited to join the judging panel only Casey Schaufler has accepted. Casey and I will consider offers to assist in judging from people who have a combination of security and blogging experience that is significant, but note that as of this time all prize money comes from the judges…

When you write a post that you wish to submit for the contest please comment on this post with the URL to make sure that the judges don’t miss it. Entries submitted on the last day may need some other form of notification, I will write a future post which clarifies this issue.

Some issues related to selecting the winners have yet to be determined, I will write future posts with more information. But please don’t hesitate to enter now, well written posts that have a positive tone are what you need. Also entering quickly will help increase the prize pool, more prizes means a greater chance that you will win one!

One thing I am considering is how to manage commercial sponsorship if it is offered. One possibility I am considering is allowing a sponsor to declare that half of the money they pay will be used as prizes for entries that relate to their product. That would give an extra incentive for people to blog about topics related to the sponsor but still give extra prize money for other topics. In that situation the relation between the sponsor’s product and the prize winning entry or entries would be liberal, so a post about standard Unix security features would be eligible for prize money from any commercial Linux distribution.

Finally you must have your own individual blog to enter the contest. Guest-posts on other people’s blogs or group efforts are not eligible for anything other than an honourable mention.

Update: The contest is over and was not a success. See this page for the details [3].

2

Bruce Schneier Advocates no Encryption

Bruce has written an interesting post about wireless encryption [1]. His main ideas seem to be that it’s nice to provide emergency net access for random people, that attempting to secure a wireless network only causes more problems when (not if) it is broken, and that your machines which are mobile need to be secure against a hostile LAN anyway.

These all make sense. I’d probably be doing the same if it wasn’t for the problems I had getting 802.11b gear working in my house (maybe conflicts with some of the other wireless equipment I run) and for the fact that I run NFS over my home network (which needs decent performance and has no security).