91–100 of 295 posts
It should relatively simple to NOP out the 2nd goto, if the rest of the function hasn't been optimised away.
If blocks without curly braces ಠ_ಠ
They exist because of the long, bloody history of mistakes by very smart people.
Does anybody know the .dylib or binary file where this function resides on OSX? I can't find libsecurity_ssl on my system. It should relatively simple to NOP out the 2nd goto, if the rest of the function hasn't been optimised away.
Earlier quoted context omitted.
the gotos actually make sense in this case. unless you'd prefer some insane tree of if/else?
I agree, I was thinking about what this situation would look like in other langs and when I turned to Go, I realized: While Go has goto for tricky situations like this, because it has defer you don't have to use it often, assuming the free calls were needed (and the vars were not going to be GC'd): defer SSLFreeBuffer(&hashCtx) defer SSLFreeBuffer(&signedHashes) if err = SSLHashSHA1.update(&hashCtx, &serverRandom); e…
err = SSLHashSHA1.update(&hashCtx, &serverRandom); if (err != nil) { return err; }
Unfortunately OSX does not appear patched even in the latest developer center 10.9.2 build (13C62). Tested in both Safari and OS-distributed curl. Chrome/Firefox of course is still fine since it uses the NSS stuff, but plenty of OS services use the OS crypto. (I'm violating NDA by commenting on pre-release Apple stuff, of course.) Windows or ubuntu bootcamp until they fix this, I think.
MITM of any SSL connection in Safari and other system apps, and they couldn't even bother to have an OS X patch ready at the same time as the disclosure for iOS? I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this.
If blocks without curly braces ಠ_ಠ
if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
{
goto fail;
}
{
goto fail;
}Earlier quoted context omitted.
It could actually. Exceptions and RAII are not resilient against typos and programmer error. If the exception handler caught the wrong type, for example catching by value instead of reference, instead of having a catch(...) it would have the same problem as the above. It's harder to spot this sort of error than a double goto and incorrect parentheses - because you have to check the code that throws and the code that…
I don't see the possibility for catching the wrong type (or not catching it) if you get one character wrong. Unless of course you have two valid type names that just differ in one character, but that is a general pitfall and not exception specific. If you always throw by value (and not by pointer) then it does not matter if you catch by value or by reference, the catch block will be activated either way. The only iss…
int e;
int update() { throw &e; }
the & is the one character - it's a typo - only catch(...) will catch it.
Earlier quoted context omitted.
MITM of any SSL connection in Safari and other system apps, and they couldn't even bother to have an OS X patch ready at the same time as the disclosure for iOS? I think anyone relying on the security of OS X is going to have to seriously rethink their OS choice after this.
Indeed the only secure OS nowadays is Linux. Everything else should be considered compromised by default a priori.
It's interesting watching all the speculation about "was it a backdoor, or just a bug?" Lots of points in favor or against: 1) It's a huge compromise, and "open" to anyone to exploit, which would ultimately get caught and fixed faster. But it's also not targeting anything specific, so there's less of a signature of the attacker. 2) Incredibly simple, and thus a plausible mistake. 3) Hidden in plain sight I'd generall…
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…