[1] 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".)

But as I said a few days ago (https://news.ycombinator.com/item?id=7284957) I think this far more likely to be an NSA-exploited bug than an arbitrary-code-execution bug in Flash, because it's something which can be exploited widely and quietly without worrying about accidentally causing new versions of the program to core dump and reveal the presence of the bug.

I hate to say it, but I think you're being insufficiently paranoid.

I'm coming around to your take on TLS, for what it's worth, although the only thing I can think of that's worse than TLS are the crypto transports generalist developers come up with.

In other words, you're not being objective. You already attribute good character to the people you know at Apple, and are therefore are looking for ways to defend them against an accusation that hasn't even been made. The fact that you unnecessarily called Schneiers current occupation as 'sad', imo, tends to support this rationalisation.

None of the issues with Flash or certificate verification bugs you bring up are relevant to the discussion Schneier is having about this being the perfect kind of backdoor, and that, if it were a backdoor, it would have been hugely successful over the last year or more.

I have no doubt at all that if NSA knew about this bug, they were exploiting it. That's what they do. It is not my argument that this bug is irrelevant to NSA.

It's unlikely that Apple would agree to sabotage their own products in a way that will eventually be detected and affect their own credibility. That's restricting the argument that people are making to a straw man, though. Have spies ever worked that way? What people are mostly speculating about is whether this was an intentionally introduced vulnerability, not the mechanism by which that would come about.

Let me give you the perspective of someone who is outside the security business but knows a good deal about PR and the media and how it operates. And selling books (one that I was doing was mentioned on the front page of the WSJ - all from PR that I organized on my own).

Schneier has certainly transformed himself and it's all about his image and selling books with his new found fame. I know it when I see it. Because as he just said in a way "it's what I would do if I wanted to..."

So in other words he has an axe to grind in getting mentioned in the media. Period. That doesn't mean what he is saying isn't correct in some fashion of course. But it does give credence to the statement "Another sad indicator of the level Schneier is playing at today". That level is publicity for Schneier. So to repeat myself, exactly what I'd be doing if I was him.

I agree with you based on the security people I know at Apple. However, I would be surprised if Apple's security people have enough time to carefully audit every line of security-relevant code which other people at Apple touch.

So you're absolutely sure that there is no developer (in the position) at Apple that would take a discrete paper bag of $$$ to make just a tiny error by hitting ctrl-v twice?

If I were the NSA, a strategy with much lower variance would be to hire a lot of smart folks to do the intense security reviews and testing that Apple (and many other companies, presumably) fail to do, and try to find bugs before they're patched. As tptacek has pointed out, there are plenty of these, and an organization with the resources of the NSA can probably find them frequently enough for most purposes without sticking its neck out.

The odds are that this engineer will never be revealed publicly, and it will not effect his/her reputation in any way.

>but small enough to not trigger questions about where it came from.

You don't think that the NSA has the ability to hide money?

And for what? The NSA can hide money, but you or I would quickly find ourselves talking with the IRS if our spending or bank accounts rose dramatically without a commensurate rise in reported income. We could probably hide a few thousand dollars a month under the table, but that doesn't sound like it would turn the head of even a particularly amoral Apple engineer already making six figures.

I'm not saying this scenario is impossible. But to be plausible, it requires both the perpetrator and the NSA to take on a degree of risk that doesn't seem to match the reward for either.

If this is standard procedure for the NSA and happens often, given the risk involved, why hasn't anyone been caught at it and publicly exposed?

If the NSA made an exception and executed some unusually elaborate cloak and dagger to seduce or blackmail an Apple employee for this change, why do we think it was for this vulnerability and not the dozens of others that are discovered annually?

Very very good point.

Until you made it, I might have thought "well of course NSA looks for bugs to exploit", but I didn't think through the implications.

Here we have Apple open sourcing their security code. They made the NSA's job 10x easier than w/o the source. So of course the NSA will lint and review and test and exploit Apple's source code. Intensively. It's low-hanging fruit, of the Apple variety. :)

Do you have any information, whether they're using any kind of of code -security- auditing tools?

Could it be that the programmer simply got a backdoor request, which s/he in protest implemented this way to ensure to be caught.

I don't agree. Most people don't even have a basic understanding of coding. I think that it has more to do with the fact that there are about 500 million vulnerable devices out there, and that we are talking about Apple. Remember Antennagate, it wasn't even that big of a deal and look at what the press made of it.

[edit]

Also I bet most readers of Schneier's bug know what goto is as well.

I think that's the reason why this bug should get a lot of attention and press. Most programmers can see this bug instantly, without even knowing the purpose of the code. How long does something like that in a (maybe the most) security-critical piece of code in a product go unseen and uncorrected without it being a result of maliciousness or incompetence?

How many dopey errors like this would have to be inserted into how many products to guarantee that the vast majority of communications could be monitored for (lets say) 5-10 years? 50 errors in 15 products? This single error compromised all iPhones, all iPads, and all Macs.

This sort of strategy would be the most efficient way for the NSA to spend money that I've ever heard of it doing. If money isn't exchanged (the companies aren't being paid to compromise themselves) we don't even have the evidence trail that outed RSA, who sabotaged their products in an equally deniable way.

I'm with the people asking who did the commit that introduced the bug. I'd like to know if they had any intelligence connections.

Can you think of a reason why that would be in any computer program, and if you saw it in while reading any code, wouldn't it either indicate some weird trick that you maybe don't understand (and should look up) or an obvious error?

It doesn't look like anything that any static analysis tool wouldn't instantly scream about, either. I can't think of a less subtle error to accomplish the same thing.

edit: http://blog.veracode.com/2014/02/do-not-pass-qa-do-not-goto-...

Veracode does static analysis of the binary, and says that it would be thwarted because it wouldn't know that some functions were meant to be called. Static code analysis would tell you that it was impossible for some of the code to be run.

edit 2:(the second comment on the vericode blog)

caf | February 24, 2014 11:05 pm

In the Evil Unit Tests part you can use code coverage tools to at least verify that your unit tests exercise all code paths. It won’t catch every bug, but it would have caught this one.

I'm talking about tools like http://oclint.org/ and http://clang-analyzer.llvm.org/

If they work anything like similar tools in other languages, they would have found this bug trivially.

Flash I know to be insane. I don't use Firefox. So, less reason to care.

But yes, Schneier has become the USA Today of security advice. A lot of people read USA Today, so it's important, but it's probably not where you go for deep or substantial analysis. (and, generally a week after everyone else has discussed an issue to death)

When you say "significantly worse bugs are found every week", are you considering them worse using Schneier's yardsticks above, or your own (which to me as a lay person appear to be their potential for damage)?

Is there a public test-suite that implementers can check against?

Plus, if there were tests, they just become another target.

* The TLS stacks all have different APIs, and you'll need some fine-grained configuration over client options to exercise the code.

* There are only a few important TLS stacks, and the effort required to build a test suite is probably greater than the effort required to build a TLS stack.

It would still be a cool project. If it exists, I'd love to hear about it.

http://www.theregister.co.uk/2014/02/20/flash_adobe_posts_em...

That was the day before the iOS update. You scared me for a moment that there was a flash update I had missed cause of all the hoopla around gotofail.