By now, everyone has heard of the TLS renegotiation vulnerability,
Transport Layer Security (TLS, RFC 5246 and previous, including SSL v3 and previous) is subject to a number of serious man-in-the-middle (MITM) attacks related to renegotiation. In general, these problems allow an MITM to inject an arbitrary amount of chosen plaintext into the beginning of the application protocol stream, leading to a variety of abuse possibilities. In particular, practical attacks against HTTPS client certificate authentication have been demonstrated against recent versions of both Microsoft IIS and Apache httpd on a variety of platforms and in conjunction with a variety of client applications. Cases not involving client certificates have been demonstrated as well. Although this research has focused on the implications specifically for HTTP as the application protocol, the research is ongoing and many of these attacks are expected to generalize well to other protocols layered on TLS.
A nice write-up of the issue can be found here,
Marsh Ray has published a new attack on the TLS renegotiation logic. The high level impact of the attack is that an attacker can arrange to inject traffic into a legitimate client-server exchange such that the TLS server will accept it as if it came from the client. This may allow the attacker to execute operations on the server using the client’s credentials (e.g., order a pizza as the client). However, the attacker does not (generally) get to see the response. Obviously this isn’t good, but it’s not the end of the world. More details below.
As for the response of a popular SSL/TLS implementation, the OpenSSL security advisory can be found here,
The workaround in 0.9.8l simply bans all renegotiation. Because of the
nature of the attack, this is only an effective defence when deployed
on servers. Upgraded clients will still be vulnerable.
A TLS extension has been defined which will cryptographically bind the
session before renegotiation to the session after. We are working on
incorporating this into 0.9.8m, which will also incorporate a number
of other security and bug fixes.
Oh, and about Tor,
The Tor protocol isn’t vulnerable here because 1) it doesn’t allow data to be sent before the renegotiation step, and 2) it doesn’t treat a renegotiation as authenticating previously exchanged data (because there isn’t any).
-
A couple of minor notes when upgrading Ubuntu Jaunty (9.04) to Karmic (9.10)…
Karmic no longer uses event.d.
The version of upstart included in Ubuntu 9.10 no longer uses the configuration files in the /etc/event.d directory, looking to /etc/init instead. No automatic migration of changes to /etc/event.d is possible. If you have modified any settings in this directory, you will need to reapply them to /etc/init in the new configuration format by hand.
I found this page to provide useful addition information.
This specification contains the documentation for the Upstart packaging and upgrade policy.
For example, for the purposes of djbdns, this meant that the “/etc/event.d/svscan” configuration had to be converted to “/etc/init/svscan.conf”. I ended up using the following, which is slightly different than what the Ubuntu djbdns package installs (bullet point 8 of this post is relevant).
# svscan - daemontools -- http://www.froyn.net/blosxom/blosxom.cgi/2007/1/12 # # This service starts daemontools from the point the system is # started until it is shut down again. start on runlevel [2345] stop on runlevel [!2345] respawn exec /usr/bin/svscanboot
And, rsyslog is now in use,
The sysklogd package has been replaced with rsyslog. Configurations in /etc/syslog.conf will be automatically converted to /etc/rsyslog.d/50-default. If you modified the log rotation settings in /etc/cron.daily/sysklogd or /etc/cron.weekly/sysklogd, you will need to change the new configurations in /etc/logrotate.d/rsyslog. Also note that the prior rotation configurations used .0 as the first rotated file extension, and now via logrotate it will be .1.
I played around a little with logging in Ubuntu 8.10 in this post (bullet point 7).
(On a side note, if you are doing more than just simple basics with syslog, it may be time to consider replacements like rsyslog and syslog-ng.)
-
Didn’t I mention beauty and elections at some point? Yep,
Perhaps a just as simple and maybe better way to pick who will be elected president than answering “who is taller?” is to answer this more general question – who best looks the part? (A little lamination goes a long way.
) And, of course, a consensus answer gives better results than each individual answer here.
Well, this paper fits right in with that post.
Are beautiful politicians more likely to be elected? To test this, we use evidence from Australia, a country in which voting is compulsory, and in which voters are given ‘How to Vote’ cards depicting photos of the major party candidates as they arrive to vote. Using raters chosen to be representative of the electorate, we assess the beauty of political candidates from major political parties, and then estimate the effect of beauty on voteshare for candidates in the 2004 federal election. Beautiful candidates are indeed more likely to be elected, with a one standard deviation increase in beauty associated with a 1½ – 2 percentage point increase in voteshare. Our results are robust to several specification checks: adding party fixed effects, dropping well-known politicians, using a non-Australian beauty rater, omitting candidates of non-Anglo Saxon appearance, controlling for age, and analyzing the ‘beauty gap’ between candidates running in the same electorate. The marginal effect of beauty is larger for male candidates than for female candidates, and appears to be approximately linear. Consistent with the theory that returns to beauty reflect discrimination, we find suggestive evidence that beauty matters more in electorates with a higher share of apathetic voters.
-
This made me laugh.
[...]But I was most impressed with this anonymous bit of genius dug up by Digg, which uses Google for some armchair sociolinguistic analysis. The graphic compares “less intelligent” queries with “more intelligent” queries, such as “how 2″ with “how might one:”
-
Lastly, TrueCrypt 6.3 has been with the following new features.
Full support for Windows 7.
Full support for Mac OS X 10.6 Snow Leopard.
The ability to configure selected volumes as ’system favorite volumes’. [...]
Oh, and I should mention… So, we had hotplug and cold boot. And, of course, when your system is up and running and transparently encrypting/decrypting data, a stock exploit of, say, the OS could easily mean game over. Now, people are using bootkit functionality against TrueCrypt.
The provided implementation is extremely simple. It first reads the first 63 sectors of the primary disk (/dev/sda) and checks (looking at the first sector) if the code there looks like a valid TrueCrypt loader. If it does, the rest of the code is unpacked (using gzip) and hooked. Evil Maid hooks the TC’s function that asks user for the passphrase, so that the hook records whatever passphrase is provided to this function. We also take care about adjusting some fields in the MBR, like the boot loader size and its checksum. After the hooking is done, the loader is packed again and written back to the disk.
While gaining physical access to a system and tampering with the hardware or popping on a malicious bootloader or what have you, and then the victim using that compromised system, which proceeds to, say, record the TrueCrypt password for the attacker, is outside the protections of the basic TrueCrypt FDE scenario, seeing bootkits demonstrating their capabilities against TrueCrypt and illustrating just what protections tools like TrueCrypt do and do not provide is quite cool. (And, with that horrific sentence, this post draws to its close.)