The Artima Developer Community
Sponsored Link

Java Buzz Forum
Not Seeing the Forest for the Gotos

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Charles Miller

Posts: 1014
Nickname: carlfish
Registered: Feb, 2003

Charles Miller is a Java nerd with a weblog
Not Seeing the Forest for the Gotos Posted: Feb 25, 2014 4:04 PM
Reply to this message Reply

This post originated from an RSS feed registered with Java Buzz by Charles Miller.
Original Post: Not Seeing the Forest for the Gotos
Feed Title: The Fishbowl
Feed URL:
Feed Description: tail -f /dev/mind > blog
Latest Java Buzz Posts
Latest Java Buzz Posts by Charles Miller
Latest Posts From The Fishbowl


Almost every report on the recent Apple SSL security bug has focused on the code. On the failure of developers to notice the pernicious extra goto statement.. On the way it could have been picked up by code review, or static analysis, or (my favourite) by making sure you put braces around one-line conditional branches.

Just as much has been made of the almost-too-coincidental fact that within a month of the bug shipping to the public, Apple was added to the NSA's PRISM hitlist of vendors subject to "data collection".

I'm not a conspiracy theorist. Here’s how I am 95% sure they did it, because it's too obvious for them not to be doing it.

Somewhere, in a boring lab in a boring building, an overworked government employee has the job of running a mundane (hopefully automated) test suite against every new release of an OS or web browser. The test suite tries to fool the browser with a collection of malformed or mis-signed SSL certificates and invalid handshakes, and rings a triumphant bell when one is mistakenly accepted as valid.

Focusing on goto or braces, misses the point. There are an uncountable number of ways a bug like this could end up in a codebase. It's not even the first, or even the worst example of an SSL certificate validation bug: back in 2002 an issue was discovered in Internet Explorer (and also, to be fair, KDE) that meant 90% of web users would accept a trivially forged certificate.

The Apple SSL bug existed, and remained undetected for a year and a half, because Apple wasn't testing their SSL implementation against dodgy handshakes. And it made us unsafe because the NSA, presumably alongside an unknown number of other individuals and organisations, government and otherwise, were.

It's a depressingly common blind spot for software developers. We’ve become much better over the years at verifying that our software works for positive assertions (All my valid certificates are accepted! Ship it!), but we're still depressingly bad at testing outside the “happy path”.

What we call hacking is a form of outsourced QA. Hackers understand the potential failure modes of systems that can lead to a compromises of integrity, availability or confidentiality, and doggedly test for those failures. Sometimes they succeed because the systems are incredibly complex and the way to exploit the failure incredibly obscure, and there's just more people with more time to look at the problem from outside than from within.

Far more often, they succeed because nobody else was looking in the first place.

Read: Not Seeing the Forest for the Gotos

Topic: Counteroffers, Secrecy, and Fear Previous Topic   Next Topic Topic: Android Weather app using Yahoo weather provider and AutoCompleteTextView (Part 1)

Sponsored Links


Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use