Skip to main content

Benjamin Oakes

Photo of Ben Oakes

Hi, I'm Ben Oakes and this is my geek blog. Currently, I'm a Ruby/JavaScript Developer at Liaison. Previously, I was a Developer at Continuity and Hedgeye, a Research Assistant in the Early Social Cognition Lab at Yale University and a student at the University of Iowa. I also organize TechCorridor.io, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Google announces the first practical technique for generating a SHA-1 collision

by Ben

This is big news.

We hope that our practical attack against SHA-1 will finally convince the industry that it is urgent to move to safer alternatives such as SHA-256.

Source: Announcing the first SHA1 collision – Google Online Security Blog

The technology community still uses SHA-1 for many things.  One of the most concerning implications of this team’s technique is that it implies attacks against Git, which uses SHA-1 for every commit.  Imagine if you had a tag (a SHA-1 sum) that referred to two different sets of changes: a benign changeset on your machine and a malicious changeset on GitHub.  Then you deploy that tag and the malicious code runs instead of the code you expected.

As far as I know, such an attack on Git hasn’t been demonstrated yet, but in theory, I think you could replace a SHA-1 commit as I described.  I bet someone will demonstrate that someday.  (Think of padding files with bogus comments until you get the checksum you want.)  It would be difficult (though not impossible) to switch Git to SHA-256, but I don’t know of any efforts to do that — though Git 2.11 is starting to acknowledge that abbreviated SHA-1 checksums do collide in practice.

Will such an attack happen today or tomorrow?  Probably not; it takes a huge amount of resources right now.  However, computation is cheaper than ever; I bet attackers will start to use services like Travis CI for computations like this, like I’ve heard is starting to be done with Bitcoin mining in pull requests on open source projects.

The best mitigation I’m currently aware of is cryptographically signing your commits, and this may be a catalyst for that to become standard practice.

Chrome dropping support for OSX 10.6, 10.7, and 10.8

by Ben

Today, we’re announcing the end of Chrome’s support for Windows XP, as well as Windows Vista, and Mac OS X 10.6, 10.7, and 10.8, since these platforms are no longer actively supported by Microsoft and Apple. Starting April 2016, Chrome will continue to function on these platforms but will no longer receive updates and security fixes.

Source: Google Chrome Blog: Updates to Chrome platform support

Snow Leopard (10.6) is the Windows XP of the Mac world in many ways. A surprising 10% or so of Mac users are still using it and presumably unable to upgrade, either because they are using an early 32-bit Intel Mac or are using a 64-bit Mac that Apple decided not to support with Mavericks (10.9). (This includes most polycarbonate MacBooks and other models, including those without enough RAM.) If you are running a version of OSX before 10.9, the simplest way to ensure continued support would be to switch to Firefox. (You could also use Windows or a flavor of Linux, both of which would provide a supported version of Chrome on older Mac hardware, but that does mean leaving OSX behind.)

It’s unfortunate that Google is dropping Chrome support, and that Apple left particular Macs behind, especially since some older Apple models will run 10.11 just fine. I find it ironic that Microsoft Windows still supports the same hardware that Apple has abandoned, as it could have run OSX 10.9.

Oracle to ‘sinner’ customers: Reverse engineering is a sin and we know best

by Ben

 “Recently, I have seen a large-ish uptick in customers reverse engineering our code to attempt to find security vulnerabilities in it. < Insert big sigh here. > This is why I’ve been writing a lot of letters to customers that start with “hi, howzit, aloha” but end with “please comply with your license agreement and stop reverse engineering our code, already.”

Source: Oracle to ‘sinner’ customers: Reverse engineering is a sin and we know best | ZDNet

This article is hard to believe.  Imagine if the people that discover these vulnerabilities sold them on the black market instead of reporting them to Oracle.  I would hope that Oracle would prefer receiving an email to widespread zero-day attacks.

Though I’m not a lawyer, this makes me wonder what constitutes reverse engineering, and also the legality of license clauses that disallow reverse engineering in this situation.  Unfortunately, Wikipedia doesn’t mention anything about reporting security vulnerabilities, which seems like something that should always be allowed.

From the Wikipedia article:

In the United States even if an artifact or process is protected by trade secrets, reverse-engineering the artifact or process is often lawful as long as it has been legitimately obtained.

Reverse engineering of computer software in the US often falls under both contract law as a breach of contract as well as any other relevant laws. This is because most EULA’s (end user license agreement) specifically prohibit it, and U.S. courts have ruled that if such terms are present, they override the copyright law which expressly permits it (see Bowers v. Baystate Technologies).

Sec. 103(f) of the DMCA (17 U.S.C. § 1201 (f)) says that a person who is in legal possession of a program, is permitted to reverse-engineer and circumvent its protection if this is necessary in order to achieve “interoperability” – a term broadly covering other devices and programs being able to interact with it, make use of it, and to use and transfer data to and from it, in useful ways. A limited exemption exists that allows the knowledge thus gained to be shared and used for interoperability purposes.

Do security vulnerabilities fall under “interoperability”?  Are there “whistle blower” laws that encourage security vulnerabilities to be reported and dealt with responsibly?  If not, should there be?

The Key Master

by Ben

Now I Know – The Key Master.

In December 2011, Harris got an email from someone claiming to be a recruiter for Google, wondering if the mathematician was interested in working for the company. The email noted that Harris “obviously [has] a passion for Linux and programming” and the recruiter wondered if Harris was “open to confidentially exploring opportunities with Google.” The email struck Harris as odd — his passion was clearly for math, not necessarily Linux or programming. And as far as he could remember, he hadn’t done anything which suggested an interest in working for Google. Harris’s skepticism took hold and he checked to see if the email was coming from Google at all — and upon further investigation, he found out that it was.

This guy should get an award, like Google normally gives when someone finds a flaw in their security and points it out to them instead of exploiting it.

The Internet’s Telltale Heartbleed

by Ben

The Internet's Telltale Heartbleed : The New Yorker.

This is by far one of the most approachable and accurate descriptions of Heartbleed that I’ve seen. Definitely worth reading if you keep wondering what this thing is.

Rate Limiting and Velocity Checking

by Ben

Rate Limiting and Velocity Checking.

I was shocked how little comprehensive information was out there on rate limiting and velocity checking for software developers, because they are your first and most important line of defense against a broad spectrum of possible attacks. It’s amazing how many attacks you can mitigate or even defeat by instituting basic rate limiting.

Take a long, hard look your own website — how would it deal with a roving band of bored, morally ambiguous schoolkids?

Disabling RdRand in Linux

by Ben

Linus Responds To RdRand Petition With Scorn – Slashdot.
Torvalds’ response to whether RdRand could be compromised in the Linux kernel | Hacker News.
Linus Torvalds responds – Change.org.

This got a surprising amount of attention, mostly because of one of Linus’ classic responses. My feeling is that it’s good to question these types of things. However, making a petition against using a hardware random number generator, and including some vague concerns about the NSA probably isn’t quite the right way to go about it.

Anyway, I learned today (from a Slashdot comment) that you can simply pass nordrand to the kernel to disable RdRand if you really don’t like it. Whether or not “the NSA” is on your list of reasons is up to you.