With all the DNS stuff that is going on at the moment, it took longer than planned to release libevent 1.4.6-stable, but here it is. You can download the source from the usual place:
This was meant to be a quick bug fix release, but a number of changes have crept in. Here's a brief summary:
- Several HTTP fixes
- Corrected handling of trailing headers in chunked replies
- Correctly deal with multi-line HTTP headers
- Improved signal handling for kqueue and epoll backends
- Various other bug fixes
See the changelog
for full details.
We would like to thank the people who have reported bugs and patches including Scott Lamb, Moshe Litvin, Alexander Drozdov, Adam Langley, Ian Bell and others. To report a bug, make a feature request, or submit code, you can use our sourceforge interface
As everyone was upgrading their DNS infrastructure to be ready for August 7th, some security reseachers independently discovered the DNS flaw and disclosed it. For those of us, who were either informed or had figured out the problem ourselves, it is surprising to find irresponsible and grossly negligent disclosure from respected members of our community. There was a reason that Kaminsky did not disclose the flaw publicly when he found it. The DNS infrastructure needed to be upgraded and repaired.
Well, the time has run out. A current study by David Dagon and myself puts the number of open recursive resolvers using static source ports at about 78%. That is a lot of servers that need to be patched. Two more weeks till August 7th could have helped to fix many of them. Unfortunately, we will not find out now.
As we are all trying to patch and upgrade our resolvers and NAT devices, I created a small image tag that automatically assesses the randomess of a visitor's resolver:
This is still in reference to the CERT Advisory on Multiple DNS implementations vulnerable to cache poisoning
. You can place the image tag on your web page to test your visitors:
<center><a href="http://www.provos.org/index.php?/archives/42-DNS-and-Randomness.html"><img src="http://porttest.honeyd.org/-s-_dns.png" border=0></a></center>
The a href
link can of course point to a more helpful web page and the image itself can also be changed according to need.
If you want to show this on your pages with different images, just let me know.
Over the last few days, we have heard a lot about DNS cache poisoning and how we need to get our recursive resolvers to use random source ports. We are being told that this is a flaw in the protocol, but no details are going to be available until a presentation at Blackhat in August. DNS cache poisoning of course has been around for a long time, most notably when the 16-bit query IDs were not randomized. Here are some good references:
Oarc in the meantime has made a port testing server
available. A simple invocation of dig tells you if your recursive resolver is vulnerable:
dig +short porttest.dns-oarc.net TXT
The TXT record assesses a resolver's source port randomness as poor, fair or good. Unfortunately, on my network, I found this record constantly cached from other resolvers, so I wrote a small Python tool that analyzes the randomness
of both your source port numbers as a well as your query IDs. The tool can be downloaded from:
Its usage is pretty simple:
Continue reading "DNS and Randomness"
This year, I have the pleasure of chairing the 3rd USENIX Workshop on Hot Topics in Security
, an invitation-only workshop that provides a forum for leading security researchers to discuss current trends and new research ideas. At the program committee meeting in Mountain View, we selected 13 out of 37 papers for the final program
. It's pretty hot
. Here are some of the talks I am looking forward to:
- Towards Application Security on Untrusted Operating Systems
- Defeating Deniable File Systems: A TrueCrypt Case Study
- Panic Passwords: Authenticating under Duress
- Absence Makes the Heart Grow Fonder: New Directions for Implantable Medical Device Security
HotSec is taking place on July 29th, one day before the technical program of the USENIX Security Symposium
. The keynote for USENIX Security is going to be exciting: Debra Bowen
, the California Secretary of State, is speaking on Dr. Strangevote or: How I Learned to Stop Worrying and Love the Paper Ballot
See you there,
I often use Tor
for anonymous web browsing; mostly when investigating malware distribution sites. Most people configure their browser so that it proxies HTTP via Privoxy
To prevent information leakage, we ideally would run a virtual machine that tunnels all traffic via Tor, such as the VirtualPrivacyMachine
. However, if you do not want to go through all that trouble, Systrace can come to the rescue. For investigations, I run Firefox under Systrace with a systrace policy that allows connections only to Privoxy. All other connections attempts are denied and logged. It is interesting to see how many connections Firefox tries to do all by itself that do not go via the proxy. There are update pings, and all kinds of other connections.
In this case, Systrace is not being used against an adversary but rather against an untrusted application. It works quite nicely at that, too.