from Hacker News

The Apple goto fail vulnerability: lessons learned (2014)

by MrXOR on 1/16/21, 8:45 AM with 39 comments

• by dwheeler on 1/16/21, 10:30 PM

  Hi, I'm the author of the referenced article. Thanks for pointing to it!

  However, can you change HN thread to the article title, which is: "The Apple goto fail vulnerability: lessons learned"?

  I never used the term "backdoor" in the entire article, and I certainly never claimed that this was an intentional backdoor or that it looked just like a backdoor. I said, "The Apple goto fail vulnerability was a dangerous vulnerability that should have been found by Apple." - but I never said it was intentional. I personally doubt it was intentional (it's possible, but I have no specific evidence suggesting it).

  While I'm here... ask me anything (AMA)!

• by bobbylarrybobby on 1/16/21, 9:06 PM

  For as long as I live, I’ll never understand style guides that permit omitting brackets around a single line following an if statement (or for, while, etc), nor code formatters that dont automatically insert them.

• by CoolGuySteve on 1/16/21, 10:04 PM

  Meh, I worked on C at Apple and that programming style was idiomatic there. There’s nothing malicious about it, it was almost certainly a diff tool or merge error that resulted in the duplicated line.

  One thing that was weird about our merges was that we always had way too many branches in flight for the current OS X, the last OS X, the next OS X beta, iOS, the next iOS, and the Windows iTunes stuff.

  Even though we had a small team inside our division dedicated to releases, it's almost guaranteed there will be merge issues when managing that many forks of the same SVN or git repo.

• by netsharc on 1/16/21, 8:24 PM

  One of the ideas to make this error visible is to forbid misleading indentation (section 3.5). It would be cool if the IDE can show this goof straight away..

• by seanwilson on 1/17/21, 7:57 AM

  > Arie van Deursen argues that “code formatting is a security feature” and that indentation “white space is a security concern. The correct indentation immediately shows something fishy is going on...” [vanDeursen2014]. Arie van Deursen also argues that code formatting should be done by tools, not by hand, and shows that clearly this code was not routinely formatted automatically.

  Praise then for languages with significant white space? Using a formatter tool to add the white space and a lint rule in your compiler to catch when it's not done is a bandaid for something that should be encoded into the language in my opinion. Leaving this stuff optional to enforce only eats up productivity for no decent upside.

• by Jerry2 on 1/16/21, 10:31 PM

  Title of this story is heavily editorialized. The article mentions nothing about the backdoor.

• by tester756 on 1/16/21, 10:29 PM

  >The problem with ‘goto’ is that it allows developers to create ‘flow’ in code that is unnatural... and that’s bad because developers should always strive to make code easy to read.

  Those aren't mutually exclusive

• by fmntf on 1/17/21, 8:14 AM

  The code written in my company must follow the MISRA rules. Among the others, there is a rules that requires branches to have code blocks, and another one that prohibits the use of goto.

  Yes, compilers have flags, coding standards can achieve the same results. The point is that this stuff is non standard, not everybody uses GCC or Clang. Stating "this code is MISRA compliant" is stronger that "this code does not produce compile warnings with the flags x, y, z on compiler W version a.b.c".

• by viktorcode on 1/17/21, 11:57 AM

  I'm afraid the only working solution to prevent this type of errors is to switch to a programming language that requires you to use braces around if statement body. Static analyser is an optional tool, with output that sometimes points out to perfectly correct code, thus making it more a nuisance then a helping tool in the eyes of a time-constrained programmer.