After the recent OpenBSD hackathon, I took a day off to chill out in Trieste before flying home. In the mean time, a blog post regarding the perils of getpid wrapping appeared. Unfortunately, by the time I made it home and reconnected to the tubes, kettenis and bcook had already fixed the bug, before I even had a chance to shit my pants. The gall of some people.

more...

Basically: the network is insecure; the bad guys can steal your Facebook login; check that you are using HTTPS. I’ve never seen a wifi warning this clear and direct before. Bonus points for mentioning that smartphone apps are a particular weakness.

A special Fourth of July post. If you love America, you’ll love the Welcome to Night Vale podcast. It does a great job walking the line between mocking the nutjobs who believe in world government black helicopters and the sheeple who don’t. A little something for everyone to hate.

The whole show, every episode, plays with credulity, but one segment from episode 14, “The Man in the Tan Jacket”, was in a category of its own. It’s not the most absurdly comical segment, but a striking reminder of the typical internet discussion regarding the relative probability of just about anything.

Early Saturday morning, Fun Complex cameras picked up blurry motion near the soda machine. The footage is quite fuzzy and difficult to discern. Perhaps it is merely rats or racoons digging through an uncovered supply of junk food. But it is, of course, much more likely that a lost nation of people, living in the bowels of a small town blowing alley, are finally revealing themselves. Taking our food supplies and preparing for war. ... It takes very little extrapolation to believe that they worship a god named Huntocar, who demands sacrifice to keep their underground city thriving in the absence of nourishing sunlight. And a fair assumption is that they are ruled by a child king, recently coronated, who is too weak to reign back the generals intent on marching upon us in war.

From time to time, somebody posts an unsourced account of that time the Secret Service tasered their cat because they googled for “how to make money”. As it makes the rounds of all the user news sites, somebody will inevitably post a comment pointing out some logical inconsistencies in the original and asking how the more fanciful events may have transpired. Someone will then reply, explaining everything with no facts and fewer sources. And finally comes the third comment, my favorite. “I’m pretty sure that’s what happened.”

A few notes regarding agl’s post on encrypting streams and tools I’ve worked on.

signify will only verify a message if it is entirely correct. The OpenBSD installer doesn’t stream install files through tar anymore. This was something we needed to change precisely because of the situation Adam warns about. Instead the full tar file is downloaded, verified, and then extracted. Tainted data never hits the real file system.

pkg_add combined with signify works a little differently, instead checking the checksum of each file, but the tainted data is first saved to temporary files before being renamed. I’m less familiar with the exact details, but a quick chat with espie said it should be safe.

reop, which is a true encryption at rest tool, does in one sense repeat the mistakes of 20 years ago. Each message is encrypted as a single large “packet”. However, the entire message must decrypt and authenticate successfully before any output is produced, so it’s actually safer than a small packet streaming program which may produce partial output. (reop cheats a bit by imposing a message size limit; it simply can’t encrypt large files, for large values of large.)

Just watched the season 3 episode of The Good Wife, “Bitcoin for Dummies”. For an episode that aired more than two years ago, that’s pretty edgy, especially considering what I assume to be the show’s target audience. It’s fictionalized, but it does a pretty good job of depicting Bitcoin accurately. Unlike another show that simply namedropped Bitcoin to prove it was the future, the episode actually spent considerable time explaining and incorporating Bitcoin into the plot. There’s talk of the exchange rate, the crash, mining, hoarding, etc. All the more remarkable for airing in January 2012.

The plot revolves around the government’s pursuit of “Mr. Bitcoin”, played by guest star Jason Biggs, for creating an illegal currency. Naturally, this brings up the question of whether Bitcoin counts as a currency or a commodity for bartering. Linguistic analysis is used to unmask Mr. Bitcoin based on his manifesto. A hidden message is found in the blockchain. There’s also some of the usual TV IP tracking hijinks, of course, but otherwise it’s well done.

This is the only legal drama I’ve ever seen that included the phrase “preimage resistance”. Also, funny line: “Cryptographer jealousy. The ugliest kind.”

I’m pretty impressed with The Good Wife. The writers are obviously working in (then) current trends, but I think it’s fair to say they’re using them as inspiration, and not just chasing ratings with buzzwords. The portrayals seem pretty accurate and not unusually contrived. Another episode deals with a judge accepting a juror’s friend request. Real life relation. The episode where they extract information (metadata, anyone?) from redacted government files was also a winner.

The WSJ has a longer recap if you’re more interested in what Alicia and Diane were wearing than Bitcoin.

Some thoughts on The Disruption Machine. I only just read it, but apparently I’m late to the party. I can’t help but think it’s funny that writing up a review of an article three days before it’s publication counts as too late. (I think it arrived on Wednesday, I read it yesterday at lunch, and today I’m writing. I apologize for my tardiness.)

more...

Because it’s summer and therefore nice and warm (or terribly, impossibly warm) out, I go outside and walk around the city. Because it’s a city, that means people ask me for money. Sometimes it’s grizzled old men sitting on a stoop. Sometimes it’s chipper young people who jump in front of me. Guess which group this post is about.

It’s one thing (an annoying thing, but borderline acceptable) to stand in the middle of the sidewalk so that I have to go around instead of walking in a straight line. Watching me course correct, then side stepping to block my path and accost me is never acceptable. I deal with this by making a mental note of the responsible organization and then blacklisting them for one month. Penalties accrue. This summer’s front runner appears to be Planned Parenthood, though it will be some time before they overtake the all time record holder. Two summers ago the ACLU accosted me more than once per day on average, earning them an effective lifetime ban.

The stupid part is I’m generally in agreement with these organizations, disagreeing more in degree than kind. The problem seems to be that unlike the local neighborhood homeless beggars, the political beggars are shipped in from elsewhere. I imagine the college job fair pitch goes something like “travel the country and harass strangers with like minded hotties”. The result is that it’s a new beggar every day with no recollection of the previous dozen encounters. Even the duck tour people learn to recognize me as a resident and leave me alone. (Presumably the political beggars set up shop all summer long to get in on the tourist trade, but since the duck tour peddlers have claimed all the good corners, they get pushed out to areas that are in fact mostly locals.)

A short while ago, I converted some memcmp calls in libssl to CRYPTO_memcmp. As noted at the time, it’s easier to assume something is secret and sensitive to timing attacks than to prove it’s not. However, one must be a little cautious because CRYPTO_memcmp, unlike its libc namesake memcmp, is actually an equality function (zero or not-zero) and not a comparison function (negative, zero, positive for less than, equal, greater than). (Don’t confuse it with OPENSSL_memcmp, which does have memcmp semantics, but is vulnerable to timing attacks because it’s not constant time.)

more...

A few days ago, jsing fixed a bug in libssl. It’s not the end of the world, but it’s a bug. Here’s the diff.

 int
 ssl3_final_finish_mac(SSL *s, const char *sender, int len, unsigned char *p)
 {
-	int ret;
-	ret = ssl3_handshake_mac(s, NID_md5, sender, len, p);
-	p += ret;
-	ret += ssl3_handshake_mac(s, NID_sha1, sender, len, p);
-	return (ret);
+	int ret_md5, ret_sha1;
+
+	ret_md5 = ssl3_handshake_mac(s, NID_md5, sender, len, p);
+	if (ret_md5 == 0)
+		return 0;
+	p += ret_md5;
+	ret_sha1 = ssl3_handshake_mac(s, NID_sha1, sender, len, p);
+	if (ret_sha1 == 0)
+		return 0;
+	return (ret_md5 + ret_sha1);
 }
 
 static int

Two variables are introduced, one for each function called, and the local variable for this function’s return value is removed.

Now look at the OpenSSL fix for the same bug.

 int ssl3_final_finish_mac(SSL *s, 
 	     const char *sender, int len, unsigned char *p)
 	{
-	int ret;
+	int ret, sha1len;
 	ret=ssl3_handshake_mac(s,NID_md5,sender,len,p);
+	if(ret == 0)
+		return 0;
+
 	p+=ret;
-	ret+=ssl3_handshake_mac(s,NID_sha1,sender,len,p);
+
+	sha1len=ssl3_handshake_mac(s,NID_sha1,sender,len,p);
+	if(sha1len == 0)
+		return 0;
+
+	ret+=sha1len;
 	return(ret);
 	}
 static int ssl3_handshake_mac(SSL *s, int md_nid,

A new variable is introduced for one function, but the existing variable for this function’s return value continues to be used to store a called function’s return.

Why is this bad? As alluded to earlier, improper return checking bugs are rampant in TLS libraries. Apple’s #gotofail bug and the following week’s GnuTLS bypass were both caused by setting a return code too soon, and then bubbling it up. Here we have the identical bug (diminished in severity), and the opportunity to correct a poor practice by eliminating semantic overloading of variables. Why not take it?

A short program to demonstrate network filtering with Lua. Although the kernel provides pf filtering and some bandwidth shaping facilities, they don’t cover every scenario. For example, consider the case where our server is connected to a network port where we pay for some amount of bandwidth, but have burstable speeds much faster than that. Commonly seen as 95th percentile billing. As long as we’re under our five minute quota, we want to pass traffic full speed, but as we approach that mark, we want to start clamping down. The pf.conf burst queueing rules can’t quite handle this situation.

For more flexibility, we can pass all our network traffic through userland using tun and have an arbitrary program analyze and shape it. This setup requires a whole mess of virtual interfaces to be configured with ifconfig, but it’s really not so bad. We want to pass ethernet frames, so we use the link0 flag.

ifconfig tun0 create link0
ifconfig bridge0 create add em0 add tun0
ifconfig tun1 create link0
ifconfig vether0 create
ifconfig bridge1 create add vether0 add tun1

Now we have a vether interface connected, via bridges and tuns, to the network. We configure this interface with our IP (run dhclient if you like), and it effectively replaces em0 as the primary interface. This is an endpoint configuration; vether can be replaced by a physical interface for a router. All that’s missing is a program to pass traffic between the two tun interfaces.

Here’s a short Lua (luajit) program. It reads from the two tun interfaces and passes packets between them as they arrive. As the amount of traffic passed approaches our five minute quota, it starts probabilistically dropping packets. As written it lets you use 75% of your quota at full speed before rather sharply curtailing it. (As a bonus, it will occasionally print a frequency count of each byte to demonstrate other uses.)

netfilt.lua

See also trickle.