etbe - Russell Coker » Security http://etbe.coker.com.au Linux, politics, and other interesting things Thu, 02 Jul 2009 22:54:53 +0000 http://wordpress.org/?v=2.8 en hourly 1 Valgrind and OpenSSL http://etbe.coker.com.au/2009/06/28/valgrind-and-openssl/ http://etbe.coker.com.au/2009/06/28/valgrind-and-openssl/#comments Sun, 28 Jun 2009 11:54:08 +0000 etbe http://etbe.coker.com.au/?p=1223 I’ve just filed Debian bug report #534534 about Valgrind/Helgrind reporting “Possible data race during write” [1]. I included a patch that seems to fix that problem (by checking whether a variable is not zero before setting it to zero). But on further testing with Valgrind 3.4.1 (backported from Debian/Unstable) it seems that my patch is not worth using, I expect that Valgrind related patches won’t be accepted into the Lenny version of OpenSSL.

I would appreciate suggestions on how to fix this, the problem is basically having a single static variable that is initialised to the value 1 but set to 0 the first time one of the malloc functions is called. Using a lock for this is not desirable as it will add overhead to every malloc operation. However without the lock it does seem possible to have a race condition if one thread calls CRYPTO_set_mem_functions() and then before that operation is finished a time slice is given to a thread that is allocating memory. So in spite of the overhead I guess that using a lock is the right thing to do.

deb http://www.coker.com.au lenny gcc

For the convenience of anyone who is testing these things on Debian and wants to use the latest valgrind, the above Debian repository has Valgrind 3.4.1 and a build of GCC to fix the problem I mentioned in my previous blog post about Valgrind [2].

if (default_RSA_meth == NULL)
default_RSA_meth=RSA_PKCS1_SSLeay();

I have also filed bug #534656 about another reported race condition in the OpenSSL libraries [3]. Above is the code in question (with some C preprocessor stuff removed). This seems likely to be a problem on an architecture for which assignment of a pointer is not an atomic operation, I don’t know if we even have any architectures that work in such a way.

static void impl_check(void)   {
        CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA);
        if(!impl)
                impl = &impl_default;
        CRYPTO_w_unlock(CRYPTO_LOCK_EX_DATA);
}
#define IMPL_CHECK if(!impl) impl_check();

A similar issue is my bug report bug #534683 [4] which is due to a similar issue with the above code. If the macro is changed to just call impl_check() then the problem will go away, but at some performance cost.

I filed bug report #534685 about a similar issue with the EX_DATA_CHECK macro [5].

I filed bug report #534687 about some code that has CRYPTO_w_lock(CRYPTO_LOCK_EX_DATA); before it [6], so it seems that the code may be safe and it may be an issue with how Valgrind recognises problems (maybe a Valgrind bug or an issue with how Valgrind interprets what the OpenSSL code is doing). Valgrind 3.3.1 reported many more issues that were similar to this, so it appears that version 3.4.1 improved the analysis of this but didn’t do quite enough.

I filed bug report #534706 about the cleanse_ctr global variable that is used as a source of pseudo-randomness for the OPENSSL_cleanse() function without locking [7]. It seems that they have the idea that memset() is not adequate for clearing memory. Does anyone know of a good research paper about recovering the contents of memory after memset()? I doubt that we need such things.

I filed bug report #534699 about what appears to be a potential race condition in int_new_ex_data() [8]. The def_get_class() function obtains a lock before returning a pointer to a member of a hash table. It seems possible for an item to be deleted from the hash table (and it’s memory freed) after def_get_class() has returned the pointed but before int_new_ex_data() accesses the memory in question.

I filed bug report #534889 about int_free_ex_data() and int_new_ex_data() which call def_get_class() before obtaining a lock and then use the data returned from that function in a locked area[9] (it seems that obtaining the lock earlier would solve this).

I filed bug report #534892 about another piece of code which would have a race condition if pointer assignment isn’t atomic, this time in err_fns_check() [10]. In my first pass I didn’t bother filing bug reports about most of the issues helgrind raised with the error handling code (there were so many that I just hoped that there was some subtle locking involved that eluded helgrind and my brief scan of the source). But a new entry in my core file collection suggests that this may be a problem area for my code.

I think that it is fairly important to get security related libraries to be clean for use with valgrind and other debugging tools – if only to allow better debugging of the code that calls them. I would appreciate any assistance that people can offer in terms of fixing these problems. I know that there are security risks in terms of changing code in such important libraries, but there are also risks in leaving potential race conditions in such code.

As an aside, I’ve filed a wishlist bug report #534695 requesting that valgrind would have a feature to automatically add entries to the suppressions file [11]. As a function that is considered to be unsafe can be called from different contexts, and code that is considered unsafe can be in a macro that is called from multiple functions there can be many different suppressions needed. Pasting them all into the suppressions file is tedious.

]]> http://etbe.coker.com.au/2009/06/28/valgrind-and-openssl/feed/ 6 The Millennium Seed Bank http://etbe.coker.com.au/2009/06/11/millennium-seed-bank/ http://etbe.coker.com.au/2009/06/11/millennium-seed-bank/#comments Thu, 11 Jun 2009 01:29:38 +0000 etbe http://etbe.coker.com.au/?p=1187 Jonathan Drori gave an interesting TED talk about the Millenium Seed Bank [1]. The potential for discovering new uses of plants for food, medicine, and construction is obvious, so it also seems obvious to me that we should preserve as many varieties of plant as possible to allow for future uses. As well as those obvious uses there are other potential uses of plants to cope with the changing climate and new diseases. Seeds from salt-tolerant plants have already been sent to Australia to help deal with the salinity problems related to the ongoing process of desertification and excessive use of bore water.

The seeds are stored in bunkers that are designed to withstand nuclear attack, I doubt that such protection will be necessary – or that it would be successful it it was needed.

Jonathan also gave a TED interview with more detail on this topic [2]. One particularly interesting issue is the work on testing seeds for viability and for developing germination protocols to specify the best combination of changes in temperature, moisture, etc to germinate seeds. This research seems to have a lot of potential to improve crop yields.

He mentioned in passing a project to collect folk-tales related to plants which apparently has led to some scientific discoveries.

A related project is the Norwegian Svalbard seed vault which seems mostly aimed at crop seeds [3]. The main difference is that Svalbard provides black-box storage (like a bank safe-deposit vault) while the Millennium Seed Bank owns the seeds. Incidentally the Bill and Melinda Gates Foundation provides significant support to Svalbard (so Bill does do some good things).

One thing that seems strange to me is the fact that governments are prepared to spend such large amounts of money on anti-terrorism but spend so little on seed banks and other projects that can help protect the food supply. If a country such as Australia (which exports a lot of food) was suddenly unable to produce enough food to even support the local population then the consequences would be much worse than anything Osama could dream up.

]]> http://etbe.coker.com.au/2009/06/11/millennium-seed-bank/feed/ 0 The Main Security Problem http://etbe.coker.com.au/2009/05/15/main-security-problem/ http://etbe.coker.com.au/2009/05/15/main-security-problem/#comments Thu, 14 May 2009 23:25:47 +0000 etbe http://etbe.coker.com.au/?p=1160 All security problems are to some degree people problems. Code may be buggy, but it was written by people who could have been better trained, had more time to spend on code review, etc. When there are multiple programs, OSs, libraries, etc to choose from then choosing a suitable combination of software is a matter of the skill and background knowledge of the people involved.

There are issues of software choice where there is no provable benefit of making one particular choice, EG choosing between a popular product that is OK and for which it is easy to hire skilled people to use it and a less popular product that has better security features but less public knowledge. But this is minor compared to other security problem.

I believe that the greatest security problem is stupid people. Stupid people in technical positions write buggy code and configure servers to be insecure. In consulting and analysis roles they develop bad procedures. In management they hire bad people to do technical work.

The vast majority of security problems can be fairly directly and immediately traced back to stupidity. In the corporate environment that is stupid programmers, stupid managers who hire people who are obviously stupid, and often stupid executives for mandating that software that everyone knows to be insecure should be used across the entire enterprise. In both the home and corporate environments there are a huge number of people who run machines that they know to be compromised. Apparently using a computer that is known to be under the control of an unknown hostile person is something that they don’t consider to be a problem – in spite of the obvious risks of fraud, data destruction, and risk of being implicated in crimes such as the distribution of child porn.

]]> http://etbe.coker.com.au/2009/05/15/main-security-problem/feed/ 6 Email Passwords http://etbe.coker.com.au/2009/04/27/email-passwords/ http://etbe.coker.com.au/2009/04/27/email-passwords/#comments Mon, 27 Apr 2009 11:44:43 +0000 etbe http://etbe.coker.com.au/?p=1147 I was doing some routing sysadmin work for a client when I had to read mail in the system administration mailbox. This mailbox is used for cron job email, communication with ISPs that run servers for the company, and other important things. I noticed that the account was subscribed to some mailing lists related to system administration, the following is from one of the monthly messages from a list server:

Passwords for sysadmin@example.com:

List Password // URL
—- ——–
whatever-users@example.org victoria3

That doesn’t seem terribly exciting, unless you know that the password used for the list server happens to be the same as the one used for POP and IMAP access to the account in question, and that it is available as webmail… Of course I didn’t put the real password in my blog post, I replaced it with something conceptually similar and equally difficult to guess (naturally I’ve changed the password). The fact that the password wasn’t a string of 8 semi-random letters and digits is not a good thing, but not really bad on it’s own. It’s only when the password gets used for 3rd party servers that you have a real problem.

I wonder how many list servers are run by unethical people who use the passwords to gain access to email accounts, and how many hostile parties use such lists of email addresses and passwords when they compromise servers that run mailing lists.

Now there would be an obvious security benefit to not having the list server store the password in clear-text or at least not send it out every month. Of course the down-side to doing that is that it doesn’t give someone like me the opportunity to discover the problem and change the password.

]]> http://etbe.coker.com.au/2009/04/27/email-passwords/feed/ 5 Amusing Thanks.txt Entry http://etbe.coker.com.au/2009/04/21/amusing-thankstxt-entry/ http://etbe.coker.com.au/2009/04/21/amusing-thankstxt-entry/#comments Tue, 21 Apr 2009 08:19:21 +0000 etbe http://etbe.coker.com.au/?p=1132 My SE Linux Play Machine [1] has a file named thanks.txt for users to send messages to me [2].

On a number of occasions people have offered to give me things in exchange for the password for the bofh account (the one with sysadm_r privileges). I’ve been offered stolen credit cards, a ponzi scheme of root access to servers on the net, and various other stuff. Today I received an amusing joke entry:

Hello Kind Sir,

I am Dr. Adamu Salaam, the the bank manager of bank of africa (BOA) Burkina Faso West

I am sending you this message about the $3.14159 million dollars in bank account number 2718281828450945. I will give you this money in exchange for the password to the ‘bofh’ account.

The amount of money is based on the value of Pi. The account number is based on the mathematical constant e [3].

It’s a pity that the author of that one didn’t sign their real name. Whoever created that should have claimed credit for their work.

]]> http://etbe.coker.com.au/2009/04/21/amusing-thankstxt-entry/feed/ 0 Question about a “Secure Filesystem” http://etbe.coker.com.au/2009/03/16/question-about-a-secure-filesystem/ http://etbe.coker.com.au/2009/03/16/question-about-a-secure-filesystem/#comments Sun, 15 Mar 2009 21:00:56 +0000 etbe http://etbe.coker.com.au/?p=1084 I have just been asked for advice about “secure filesystem” and decided to blog my answers.

The first issue is what is meant by “secure filesystem, that could either mean the ability to restrict file access (EG by supporting SE Linux security contexts and using SE Linux for file access control) or the ability to encrypt data in case the machine is stolen. For access control I recommend SE Linux of course. For encryption on a local machine I mostly use dm-crypt which is configured with the cryptsetup utility. I encrypt at the LVM logical volume level as it is common that there are some LVs that don’t need to be encrypted. For files that need extra encryption or files that are shared between machines I use GPG.

A question was asked about kernel vs user-space filesystem encryption. AES is in the kernel so there is no lack in terms of strong encryption there. Also performance is pretty good (in most cases the CPU is fast enough that the hard drive is the bottleneck). For fine grained encryption (such as some of the experimental filesystems that encrypt data separately for each user) user-space is probably the only way to go.

If you want servers to be “high-security level” and protected from “hackers or unauthorised people” then it’s difficult to offer any advice that is smaller than a text book. I suggest that if you have such questions then you should do one of two things. If you are running a corporate IT department then hire an expert who can help with determine your specific requirements and meet them. If you want to learn about computer security and run your own systems in the best way possible then read as much from the experts as possible.

If you are looking for a project to contribute to related to security then if you choose SE Linux I could offer some specific advice on things that need work. I suggest not deciding on whether to do “kernel level or user level” work up front, but decide first which area of security you want to work on and then select a project which fits – then you should be able to determine whether your skills are best suited to kernel or user space coding. As for whether developing a new filesystem is necessary, I will note that SE Linux works well on Ext3 and XFS, it has just become usable on JFFS2, and it will work on other newer filesystems in the near future. Adding SE Linux support to a filesystem is not a difficult task if the filesystem supports XATTRs. I believe that there is a lot of scope for other access control systems to be developed which use XATTRs for security labels.

I can’t advise on e-books. I generally don’t read books, I read blogs and papers. Anything that I read which I consider to be worth recommending will probably have a link from my blog.

]]> http://etbe.coker.com.au/2009/03/16/question-about-a-secure-filesystem/feed/ 1