Non-semantic indentation claims another victim.
Apple's SSL/TLS bug
121–130 of 295 posts
Re: Apple's SSL/TLS bug
#122Earlier quoted context omitted.
Ok for example: int e; int update() { throw &e; } the & is the one character - it's a typo - only catch(...) will catch it.
Well, since you're throwing an int-pointer then catch(int*) should also catch it quite happily. I guess you mean there will only be a catch(int) in addition to catch(...) so in that aspect you're right of course. Still, I would think taking the address of something you throw should ring quite a few warning bells as opposed to merely a missing ref (&) in the catch handler. Similarly to "return &e" which would also be…
My point being it would raise far less warning bells than an unguarded goto.
Re: Apple's SSL/TLS bug
#123Earlier quoted context omitted.
[deleted]
He didn't say it isn't OSS. He just pointed out that it is educational to see the actual code as we do in this OSS case.
You are probably right. The thread was so full of people making similar assumptions, my early morning brain lumped this in.
Re: Apple's SSL/TLS bug
#124Earlier quoted context omitted.
Safari/iOS 4.3.3: not vulnerable Safari/i0S 7.0.4: VULNERABLE Chrome/iOS 7.0.4: not vulnerable Looks like using Chrome instead of Safari may help; I'd say it would be more interesting if standard mail client can be fooled.
This also impacts iOS 6; there's an update available.
Is it possible to get the iOS 6 update if your device supports iOS 7? iTunes only offers the 7.0.6 update.
Re: Apple's SSL/TLS bug
#125Worth noting that static analysis finds bugs like this immediately. TLS code seems like the perfect candidate to run through static analysis on every checkin. There are products such as Coverity and PVS-Studio that would have immediately flagged this and probably some open-source ones built around LLVM as well (unsure about this one, though). I personally use Coverity and have it hooked up in the same way everyone co…
Yep, PC-lint from Gimpel catches it:
Error -> Warning 527 Unreachable code at token 'ret' (col 12)
Re: Apple's SSL/TLS bug
#126If blocks without curly braces ಠ_ಠ
Braces don't help in coding styles that put the opening brace on a separate line from the control statement. if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) { goto fail; } { goto fail; }
Another solution, (popular at Microsoft FWIW) if you have a common pattern like
if ((err = DSomething()) != 0)
goto fail;
Re: Apple's SSL/TLS bug
#127How is this code not covered by a unit test? I'll admit I don't think of myself as great at unit testing, but the first thing I do when writing one for a new tool or class is use a code coverage tool to look for uncovered lines and once I have written a few basic behavioral tests I write tests to exercise and validate the output of the uncovered lines. This ensures that the tests I write to cover the public API don't…
Well, as the article says: A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes.
Something one would have reasonably expected after second biggest company in the world (NASDAQ, Fortune 50), and first in the IT sector.
The entire OS is damn too huge piece of software for Apple not to test intesively to a fanatic stretch. Since all the NSA revelation and the proven extent to which US government lied and continues to lie to its people about all data gathering, I fail to categorize such a simple but yet brilliant overlook as a mistake.
Re: Apple's SSL/TLS bug
#128How is this code not covered by a unit test? I'll admit I don't think of myself as great at unit testing, but the first thing I do when writing one for a new tool or class is use a code coverage tool to look for uncovered lines and once I have written a few basic behavioral tests I write tests to exercise and validate the output of the uncovered lines. This ensures that the tests I write to cover the public API don't…
Well, as the article says: A test case could have caught this, but it's difficult because it's so deep into the handshake. One needs to write a completely separate TLS stack, with lots of options for sending invalid handshakes.
So you need a mock peer, whoop-de-fuckin-do. Seems like one of these security weenies could sit down and write a test for once.
By the way the test coverage in OpenSSL is piss-poor as well.
Re: Apple's SSL/TLS bug
#129Earlier quoted context omitted.
My gut says the probability of a random typo executing without raising an error or exception is rather low. The probability of it doing so in a way that well aligns with the interests of nation states, large corporations, and/or criminal enterprise is even lower. This might explain DROPOUTJEEP particularly considering how much more efficient it is than breaking messages after they are encrypted. http://mobile.eweek.c…
Sure, this aligns with interests, but the bug's existence is predicated on the entire code base being written with substandard style rules and no static analysis or tests , which suggests to me that incompetence got here first.
Weaknesses are what sophisticated adversaries attempt to exploit. Lack of static analysis in the code base might make an exploit take a particular form and make it easier to craft an exploit.
But it's the size of the target base and its quality which makes it worth trying considering the way in which iPhones may be present in even a security savvy an individual's social context.
Re: Apple's SSL/TLS bug
#130Emerging tools such as gofmt and clang-format are able to automatically re-format your code based on the language rules rather than the human behind the monitor. Using those tools this specific category of issues should at least be visible in the formating diff. Interesting. Never thought about it that way before.
Trying to get teams to agree on the code style is the hard part when using such tools. `gofmt` somewhat avoids that by defining one true way and only giving minor customization options.
clang-format has the same property. You just have to tell off a bunch of neckbeards and/or fire them if they can't agree to its formatting rules.
Having cast-in-stone formatting rules makes code review easier and shorter and avoids lots of arguments. For ultra-dangerous languages like C++, automatic formatting is indispensable.