10 ms·
Was the iOS SSL Flaw Deliberate?
- kalleboo 13y agoWouldn't it be way safer and easier for any attacker (NSA or otherwise) to compromise a trusted CA than to compromise the Apple SSL code?
- camillomiller 13y agoI really hope Apple will disclose its findings on this matter, in name of the transparency they're advocating. Imagine if Apple itself states something along the lines of "we found out that the line of code responsible for the bug was planted on purpose". Should they make such a statement? Better: COULD they make it?
- antsar 13y agoI fear they'd be too concerned about the potential impact on their business.
- mikeash 13y agoI'd love to see it, but I seriously doubt it. Apple is secretive to an incredibly annoying degree. Has Apple even publicly discussed the basic details of this bug? As far as I've seen, every single bit of analysis has come from outside the company, based on simply viewing the source code. Apple acknowledged that there is a vulnerability, but they haven't even said what it is in any detail.
- ancarda 13y agoI'd like to believe Apple simply as no code review but it's odd they removed a specific check -- was it not suppose to be there? Does anyone know if the patch added the line back in or if it removed the duplicate goto? The one thing that points to it not being a backdoor is I doubt Apple would open source the code. Surely they'd maintain a separate branch or something?
- rikkus 13y agoThey could have made it open source because they knew they were under pressure to backdoor it, so wanted people to see what happened without explicitly telling the world... Or not. It's a fun theory though.
- interstitial 13y agoYou think a billion dollar, cash-rich company known for software excellence would understand testing and hardening? A company known for draconic quality assurance, would skimp? Silly me. HN must be right.
- gmac 13y agoAs noted in the article, plausible deniability is a key criterion for thinking of this as a possible NSA insertion. In other words, it's only possible that it's an NSA job if it's also possible that it isn't. Something tells me therefore that we're unlikely ever to know for sure.
- interstitial 13y agoDon't scare the geeks of HN. They have well-tuned, waffle-brains with syrup-tight barriers. Suggesting there is a world with blurry boundaries scares them.
- Jgrubb 13y agoPosting this comment on HN hints at a lack of self awareness.
- maxerickson 13y agoDoesn't it strain credulity that the NSA would (bother to) insert a flaw that would be detected by many commercially available analysis tools (or the right compiler flags)? (I certainly shouldn't pretend to know much about C, but the above matches my understanding of the situation)
- blueskin_ 13y agoI was wondering if this was going to be one of those pages that just says "Probably." or similar in large text.
- nicholassmith 13y agoOften when things like this happen there's a large conspiracy at play in some peoples minds, "Apple deliberately left a security vulnerability". But it falls apart pretty quickly, it's in an open sourced package, so the assumption is someone is eventually going to see it, so it's not going to remain a secret and thus is useless as a stealth backdoor. The likelihood is pretty simple, someone fucked up. On a potentially huge level, but a fuck up none the less. These things do unfortunately happen, and no doubt it'll prompt an internal review of their change management process, and their build chain, and what they can do to isolate issues like this in the future.
- corresation 13y agoWhile I believe that it was just a screw-up that wasn't caught because of gaps of process (the code essentially repeats blocks with minor changes, so I can envision someone doing some refactoring -- removing the passing of the context -- and trying to save time by copying the first changed block to the second, failing to overwrite that single additional line), considering the possibility that it was intentional in no universe suggests that it was Apple the organization that chose and instituted the vulnerability. A single employee receiving a second paycheck from a three-letter organization could have been responsible. A vulnerability could have been used to plant it. And so on. Remember when everyone was railing about Google giving NSA a backdoor (cue a thousand "don't be evil" cries) when in reality the NSA and friends were simply exploiting a weakness of Google's network. The net effect was the same. It could be intentional and still entirely unintentional as far as Apple the company is concerned. And to the open source thing -- it sat there for 18 months. Indeed, it was caught [EDIT: Actually I don't know how it was caught. I faintly recall someone posting an issue someone submitted to Apple detailing some weird behavior with invalid private keys, but can't find it now]
- ybaumes 13y ago"And to the open source thing -- it sat there for 18 months." !!! Just .. wow. If it was the first time we heard such stories. But it happends many time with the linux kernel source code and all. I definitively conclude that source code begin open to everyone is not a mark of higher quality.
- garethadams 13y agoI think I'll apply Betteridge's law[1] to this one. [1]: http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines http://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines
- SigmundA 13y agoAlso: http://en.wikipedia.org/wiki/Hanlon's_razor http://en.wikipedia.org/wiki/Hanlon's_razor
- wglb 13y agoI would be going with this one. A simple mistake has far less drama.
- DennisP 13y agoThat's a maxim I apply in general, but given that we know there are, in fact, known malicious actors purposely introducing flaws to security software, I think it might be a mistake to reflexively apply it here.
- ronaldx 13y agoHanlon's razor is just the worst. Systematic incompetence is malice. Here's my alternative but equally reasonable platitude: "Never attribute to incompetence what could be attributed to malice with plausible deniability."
- tptacek 13y agoAnother sad indicator of the level Schneier is playing at today, in the same vein as "avoid elliptic curves, we don't trust the math". Once again: the only reason this bug got so much attention and press is that it's easy for laypeople to get their heads around. All you have to understand is how "goto" works. The bug is vivid, and so (paradoxically) seems scarier. Significantly worse bugs are found every week. Within a few days of the announcement of this TLS bug, a Flash bug was announced, after being detected in exploits in the wild, that enabled reliable drive-by hijackings of browsers --- multiple browsers. It was off the HN front page within an hour. TLS bugs aren't even unusual. We get a new one every few years ago. Firefox managed a PKCS1v15 parsing bug that allowed anyone with a Python script and 30 milliseconds to generate a certificate for any domain. Other browsers have screwed up certificate chaining, so that any domain could sign any other domain. But nobody understands PKCS1v15 padding, nobody understands certificate chaining, and so nobody writes stories about these bugs. But their impact is identical to this one.
- makomk 13y agoWhatever may or may not be wrong with Schneier's article, it's certainly a hell of a lot better than (say) conflating a vulnerability that was in released, stable versions of iOS and OS X for over a year with one that never made it into an actual release of Firefox in order to make it look like the media were making a big deal about nothing[1], as you did previously on this topic. I'd suggest you take a good, hard look at your own tactics before accusing others of misinformation, and that anyone else doesn't take your word on these matters. (Sadly that comment got upvoted all the way to the top of the discussion, just like this one no doubt will.) [1] https://news.ycombinator.com/item?id=7284290 https://news.ycombinator.com/item?id=7284290 (Edit: also, while it was 4 years ago and my memory's a bit fuzzy, I seem to recall the earlier, actually exploitable in the wild, PKCSv15 vulnerability was discussed a lot in the tech media and community. It just didn't get the mainstream media attention, most likely because it wasn't as badly mishandled and "obscure security issue fixed already" is much less of a story than "you're at risk now and there's nothing you can do, because someone fucked up".)
- tptacek 13y ago
- Patient0 13y agoIt looks like the sort of bug that can be introduced by an erroneous merge in source control.
- pieter_mj 13y agoWhy is is so important to know wether this bug was left deliberately or not, or even sneaked in by the NSA? To the more important questions 'Did the NSA almost immediately discover this bug' and 'Did they exploit it', I answer with a resounding yes.
- pierre_a 13y ago> The flaw is subtle, and hard to spot while scanning the code The author can't be serious. This particular bug has made the rounds and is understood even by non-programmers.
- mikeash 13y agoThe ability to understand it when it's pointed out is unrelated to the ease of spotting it among a thousand lines of other code when you don't know what you're looking for.
- mukundmr 13y agoWell, http://www.opensource.apple.com/release/os-x-109/ http://www.opensource.apple.com/release/os-x-109/ has the list of open sourced code from Mavericks. Let the code analysis begin, it would help everyone out.
- hengheng 13y agoHonest question, what are decent tools to find bugs like this in C code nowadays? I was saddened to read that gcc cannot check for unreachable code.
- anon1385 13y agoThe -Wunreachable-code flag does work in clang, to some extent at least (I have a rather old version here so YMMV). Other tools that may help: The clang static analyzer: http://clang-analyzer.llvm.org http://clang-analyzer.llvm.org Valgrind: http://www.valgrind.org http://www.valgrind.org Address Sanitizer: http://clang.llvm.org/docs/AddressSanitizer.html http://clang.llvm.org/docs/AddressSanitizer.html The various -fsanitize options in clang (undefined behaviours, integer overflows etc): http://clang.llvm.org/docs/UsersManual.html#id28 http://clang.llvm.org/docs/UsersManual.html#id28
- mzs 13y agoThere is a list here: http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis http://en.wikipedia.org/wiki/List_of_tools_for_static_code_a... Also there is oclint not listed there, which is pretty amazing, but it has a strange notation for ignoring wqrnings. splint is pretty good too though and still supports the legacy lint stuff like /* NOTREACHED / BSD lint seems to work still (though it looks like the lintlib is no longer built on FreeBSD and stdlib is not lint clean!) but even it would have caught this gotofail: 01: #include <stdlib.h> 02: 03: int 04: main(int argc, char *argv[]) 05: { 06: if (argc == 0) 07: goto fail; 08: goto fail; 09: 10: exit(0); 11: 12: 13: fail: 14: exit(1); 15: } $ lint a.c a.c: stdlib.h(286): warning: ANSI C does not support 'long long' [265] stdlib.h(287): warning: ANSI C does not support 'long long' [265] stdlib.h(287): warning: ANSI C does not support 'long long' [265] a.c(10): warning: statement not reached [193] a.c(15): warning: function main falls off bottom without returning value [217] a.c(4): warning: argument argv unused in function main [231] _types.h(61): warning: struct __timer never defined [233] _types.h(62): warning: struct __mq never defined [233] lint: cannot find llib-lc.ln Lint pass2: exit used( a.c(10) ), but not defined $ cc a.c $ ./a.out $ echo $? 1 edit: grrr, sorry small copy/paste mistakes before.
- cl8ton 13y agoI don't think the bug was deliberate, could of been just an honest mistake. But on the other hand, why didn't the compiler generate an "Unreachable Code" warning during build? We have explicitly set this warning to "Treat as Error" during our builds.
- Eiwatah4 13y agoGcc doesn't have such a warning. Clang has it, but it has to be explicitly enabled. (It's not even in -Wall or -Wextra.)
- deleted 13y ago[deleted]
- throwaway2048 13y agoIt appears that -Wunreachable-code was removed from gcc due to optimizer issues http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html http://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html
- rimantas 13y agoWhere am I mistaken that having this bug deliberate is meaningful only if you control most of the networks? In which case there are a lot scarier things to worry about.
- ape4 13y agoI prefer always using brace brackets for if's... if (cond) { goto fail; } instead of: if (cond) goto fail;
- xroche 13y agoYes, and this is actually a sane coding rule. Without it, badly written macros (using several ;-separated lines for example) will cause subtle bugs like this one.
- simias 13y agoI would argue that in this case the problem lies in the macro, not the lack of braces. You can't program defensively against broken macros. I've seen quite a lot of discussion surrounding the coding style around this "goto fail" vulnerability, but IMO that's missing the forest for the tree. If this coding error was truly a mistake (which I tend to believe) it was probably the result of a bogus copy/paste. Shit happens, no matter the coding style. In my opinion the real problem is: why wasn't this code properly tested and audited? For crypto code it borders on gross negligence. In particular, I disagree with TFA that "The flaw is subtle, and hard to spot while scanning the code". When you're used to read properly indented C code the 2nd "goto fail" with its weird indentation jumps to the eye IMO. Also the fact that the same statement is repeated twice in exactly the same way. I'm used to reading a lot of kernel code using the same kind of error handling and it really stands out IMO.
- zacinbusiness 13y agoI don't think the NSA is nearly as technologically capable as people think they are. If they want info from someone all they have to do is detain them and bust open their kneecaps with a hammer. No one would ever find out. So there's really no reason to go through all the shadow games. If this is an intentional bug, I think it's likely a hacker or just a disgruntled employee. But I'd be willing to wager that it was a tiredness error, rushed to implementation by an overworked and likely underpaid engineer deep within Apple.
- iaskwhy 13y agoHave you seen the more technical slides with some of the hacks they use? They are very technilogically capable. Actually, they are much more capable than most people used to think.
- zacinbusiness 13y agoI'm sure they can do these things. I'm just not sure why they would. If the NSA wants my encrypted email keys they can ask me, they can hack my server, or they can break my jaw. The last option is considerably cheaper. So the entire organization seems like a gigantic waste of money to me.
- iaskwhy 13y agoI understand your point but you might be missing NSA view on this. Their goal is (apparently) to source as much data as possible and, although breaking a jaw doesn't sound expensive as a one-off, it gets extremely expensive when doing it for a given percentage of the world population. In our own language, it's not scalable. And neither are the other options. Global automation of the gathering of personal data is much cheaper and much more useful (again, apparently).
- zacinbusiness 13y agoThat's a fair point. Really the whole thing bugs me. It seems they could be solving real problems with all those cycles.
- gwu78 13y agoIt's not just an "iOS" flaw. It's a "latest, greatest Apple OS" flaw. And anyone who given a choice between SSL and TLS relies on TLS is not putting security as a top priority. And why would anyone who cares even the slightest about security use Flash? Are you serious? I guess this is why security consulting could be easy money... clients want to use Flash and "stay secure". Yeah, sure, we can handle that for you. Well, now you cannot even use a Mac without the potential for HTTPS authentication not working. Better make sure the OS is updated. Sounds a lot like Microsoft. Maybe you could start a business updating Mac OS's. "Does anyone know what's going on inside Apple?" If they did they couldn't say. All employees are sworn to secrecy. I blackhole all traffic from Apple devices to *.apple.com You would not believe (or maybe you would, if you are a "security consultant" or some such)... you would not believe the amount of "phoning home" that these devices do. I agree you can't trust "security consultants" who do their marketing via blogs and forums. But you surely cannot trust Apple either. The flaw was one line of code. I'm curious. What is the size on the update? Imagine if you could make the change yourself, recompile and dd an image to your device.
- tehwalrus 13y ago...There are goto statements in the code that is running on my laptop and phone? I feel dirtier now.
- deletes 13y agoDid you ever read assembly?
- tehwalrus 13y agoI know that function calls are fundamentally just jmp calls underneath, and that's exactly what a goto is too, but we built high level language compilers (including C compilers) so that we didn't have to deal with goto-centric spaghetti any more. As with everything, gotos work just fine if you restrict yourself to a few specific uses. At that point, however, you've basically just invented function calls, switch statements, and maybe exceptions if your rules aren't strict enough, which can all be managed by a compiler which always generates the correct number of jmp's to do the job. EDIT: you could more accurately replace each instance of "function call" in the above with "subroutine" as FORTRAN defines them, which is closer to what you get for free with gotos than a function call with an actual stack pointer.
- lutusp 13y ago> I know that function calls are fundamentally just jmp calls underneath, and that's exactly what a goto is too ... No, this is false, both at the high-level-language and assembly-language level: http://en.wikipedia.org/wiki/X86_calling_conventions http://en.wikipedia.org/wiki/X86_calling_conventions A function call transparently returns to the point at which the call originated and resumes execution. A GOTO departs from the original location, never to return. That is a crucial difference. > EDIT: you could more accurately replace each instance of "function call" in the above with "subroutine" as FORTRAN defines them, which is closer to what you get for free with gotos than a function call with an actual stack pointer. Still wrong -- you're confusing two very different things. A function call, in both the assembly and high-level sense, is completely different from a GOTO instruction.
- mikeash 13y agoIf I were at the NSA and wanted to introduce a bug like this, I'd get access to Apple's build servers (either through an exploit or by just talking to an employee who has access) and arrange for a binary patch to be applied to the generated object files at build time. It would be basically undetectable, as no amount of source code auditing would reveal it. Could probably make it look like a compiler bug without too much difficulty. Of course, this presumes that the NSA needs to introduce bugs like this. I imagine they do just fine for now merely taking advantage of naturally occurring bugs.
- mzs 13y agoAgain I think this was just a mistake, but there are other groups that could want to add something like this other than the NSA where it would be more plausible for them to have such a need. It shows that Apple needs to reconsider its processes though, and I guess they are now, which should make the likelihood of something like gotofail for nefarious means working very small from now on.
- mikeash 13y agoI'm hoping that their security folks are now going through and writing extensive automated tests for all of this code, and anything similar, and turning on lots of automated static analysis to go along with it. I fear that it may end up as, "we already found the bug, we don't need tests now". But that's probably pessimistic of me.
- fit2rule 13y agoI honestly think it was deliberate. What class of Operating System developer ships their OS releases without 100% CODE COVERAGE? Apple do code coverage testing, surely? I mean, more than the "-warn-dead-code" args that get flung around. I can't understand how this would have gotten released into the wild if they were doing industry-standard code coverage tests. And .. if they're not doing industrial-strength code-coverage testing on their iOS/OSX release builds, thats the real news here ..