×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Apple Fixes Dangerous SSL Authentication Flaw In iOS

timothy posted about 9 months ago | from the are-you-telling-us-the-whole-story? dept.

Security 101

wiredmikey writes "Users of iOS devices will find themselves with a new software update to install, thanks to a certificate validation flaw in the mobile popular OS. While Apple provides very little information when disclosing security issues, the company said that an attacker with a 'privileged network position could capture or modify data in sessions protected by SSL/TLS.' 'While this flaw itself does not allow an attacker to compromise a vulnerable device, it is still a very serious threat to the privacy of users as it can be exploited through Man-in-the-Middle attack,' VUPEN's Chaouki Bekrar told SecurityWeek. For example, when connecting to an untrusted WiFi network, attackers could spy on user connections to websites and services that are supposed to be using encrypted communications, Bekrar said. Users should update their iOS devices to iOS 7.0.6 as soon as possible." Adds reader Trailrunner7: "The wording of the description is interesting, as it suggests that the proper certificate-validation checks were in place at some point in iOS but were later removed somehow. The effect of an exploit against this vulnerability would be for an attacker with a man-in-the-middle position on the victim's network would be able to read supposedly secure communications. It's not clear when the vulnerability was introduced, but the CVE entry for the bug was reserved on Jan. 8."

Sorry! There are no comments related to the filter you selected.

And thus is it delivered to all supported devices (4, Informative)

Rosyna (80334) | about 9 months ago | (#46310083)

The update is available to all supported devices (From the iPhone 3GS running 6.1.x and up).

Re:And thus is it delivered to all supported devic (1)

AmiMoJo (196126) | about 9 months ago | (#46310157)

How does that work? It seems that you need to get iOS 7 to get the patch. Did they back-port it to iOS 6? Or do they have some mechanism like Google does for updating older versions via their app store?

Re:And thus is it delivered to all supported devic (3, Informative)

berj (754323) | about 9 months ago | (#46310175)

They also released 6.1.6 which patches this bug.

Re:And thus is it delivered to all supported devic (3, Funny)

Anonymous Brave Guy (457657) | about 9 months ago | (#46312513)

Unfortunately, Apple seem to have abandoned iOS 5 support already.

iOS 6 isn't even 18 months old yet and was their Windows Vista, so a lot of people didn't upgrade. iOS 7 isn't even 6 months old, had security problems of its own at launch, and runs like a limping dog on some very popular devices still in widespread use, so a lot of people didn't upgrade to that either.

The vulnerability here was caused by a rookie error that could easily have been found and fixed by following any one of several best practices in their software development process, and for something security-related they should have been following all of them.

This is a very poor show from Apple on all counts. :-(

Re:And thus is it delivered to all supported devic (0)

Anonymous Coward | about 9 months ago | (#46312979)

iOS 5 does not have the bug (I just checked with 5.1.1)

Re:And thus is it delivered to all supported devic (-1)

Anonymous Coward | about 9 months ago | (#46310161)

The update is available to all supported devices

I wonder how much Apple paid Dice for the first post?

Such a sycophantic response to a NSA-mandated "feature".

Re: And thus is it delivered to all supported devi (0)

Anonymous Coward | about 9 months ago | (#46310337)

You are a blithering idiot.

Don't forget your tin foil hat on your way out. Now piss off. End off.

Re: And thus is it delivered to all supported devi (-1)

Anonymous Coward | about 9 months ago | (#46310363)

You are a blithering idiot.

Such a dismissive, vitriolic response.

You SMMs really don't want your activities being discussed do you? It'll be happening more and more though, so you'd best get used to it.

Re: And thus is it delivered to all supported devi (2)

AHuxley (892839) | about 9 months ago | (#46310377)

The AC seems to be hoping we have all forgotten
"Revealed: how US and UK spy agencies defeat internet privacy and security" (6 September 2013)
http://www.theguardian.com/wor... [theguardian.com]

Re: And thus is it delivered to all supported devi (0)

Anonymous Coward | about 9 months ago | (#46310401)

The AC seems to be hoping we have all forgotten

Bingo!

AC is trying to use bluster and derision to block discussion of Apple's collusion with the US spy agencies.

Those methods include covert measures to ensure NSA control over setting of international encryption standards, the use of supercomputers to break encryption with "brute force", and – the most closely guarded secret of all – collaboration with technology companies and internet service providers themselves.

Through these covert partnerships, the agencies have inserted secret vulnerabilities – known as backdoors or trapdoors – into commercial encryption software.

They're panicking now, and trying to cover up.

Very Important Apple News!!!!!! (-1)

Anonymous Coward | about 9 months ago | (#46310109)

Tim Cook's rectum is full! Will he take a shit now or later?! Eager readers must know!

How about OS X? (4, Insightful)

rvw (755107) | about 9 months ago | (#46310143)

I heard OSX has the same problem.

@Apple: Admit that it exists (plus give advice how to prevent problems) or let us know that OSX is safe.

Re:How about OS X? (5, Informative)

berj (754323) | about 9 months ago | (#46310187)

Yes. 10.9.1 has this problem (not sure about earlier versions). 10.9.2, which is in beta, patches the problem. Should be released soon.

Re:How about OS X? (0, Funny)

Anonymous Coward | about 9 months ago | (#46310203)

... 10.9.2, which is in beta ...

And we all know how much we love beta...

Re:How about OS X? (1)

antdude (79039) | about 9 months ago | (#46312505)

What about 10.7.6, 10.8.3, etc.?

Re:How about OS X? (1)

berj (754323) | about 9 months ago | (#46313793)

I've not read that they exhibit this bug. I've only seen 10.9.0 and 10.9.1 mentioned.

I don't have any non-mavericks machines anymore otherwise I'd test it.

Re:How about OS X? (0)

Anonymous Coward | about 9 months ago | (#46315473)

10.7 isn't vulnerable. 10.8 most likely isn't vulnerable, too. They don't use Apples own implementation of the SSL stack but OpenSSL. 10.9 switched to Apple's library, that's being used on iOS, too.
You can test your browser (Safari) here: gotofail.com

Re:How about OS X? (1)

dxdt+ (3551481) | about 9 months ago | (#46332479)

Checked: 10.8 doesn't exhibit this SSL security bug.

Re:How about OS X? (1)

Trillan (597339) | about 9 months ago | (#46325331)

10.7 probably isn't vulnerable, as it predates iOS 5 (which doesn't have this flaw).

If 10.8 is vulnerable, the suggested upgrade would be 10.9.3 anyway. (10.9 has the same requirements as 10.8, and is a free upgrade.)

I would like to see an article that explains which versions are vulnerable, however.

Re:How about OS X? (1)

frankns (118743) | about 9 months ago | (#46326435)

Running 10.9.2 here and gotofail.com continues to report the vulnerability ...

Re:How about OS X? (1)

Trillan (597339) | about 9 months ago | (#46328573)

There's no contradiction there. You are running a seed of 10.9.2, not 10.9.2.

I'm more curious if Apple will put out a fix BEFORE 10.9.2 ships; rumours still peg 10.9.2. a few weeks away.

Re:How about OS X? (1)

dxdt+ (3551481) | about 9 months ago | (#46332367)

Which version of 10.9.2 is fixing this major security bug?

You can prevent problems by not trusting SSL (1)

Marrow (195242) | about 9 months ago | (#46310931)

Really, why would you trust a system where someone you dont know or trust is in charge of the private keys for the encryption?

Re:You can prevent problems by not trusting SSL (2)

dkf (304284) | about 9 months ago | (#46311281)

Really, why would you trust a system where someone you dont know or trust is in charge of the private keys for the encryption?

Failing to secure your connections is just wilfully stupid. SSL is the best option we've got to avoid a whole range of attacks (it's far easier than the alternatives) but it does require correct implementations and careful selection of who to trust; SSL itself does not specify who to trust (and how can it? It's just a technical protocol for how to establish a secure channel over an insecure connection, typically implemented with TCP/IP).

Explicitly listing who to trust is best, but it's extremely hard to scale up (since you have to pre-share the keys). A web-of-trust scales better, but once someone makes a mistake (easily done) it all crumbles. Using a certificate authority scales much better, and isn't quite as brittle as a WoT, but it does rely on the CAs (especially the root CAs; non-roots are easier to discipline) being very highly trustworthy. Commercial pressures are unlikely to make limiting the scope of domains that any CA can issue for practical (and in any case, certificates are not tied to domains in general; that's a feature of some particular types of certificates only).

Every time someone suggests "oh we can't trust SSL" it is invariably because they don't know what it does and doesn't do, and because they think that there's only one kind of threat. That's incredibly wrong-headed and foolish.

Re:You can prevent problems by not trusting SSL (1)

Marrow (195242) | about 9 months ago | (#46311387)

I am not saying we should run unsecured connections or that there is a single type of threat. And your post ends up sounding like a bunch of excuses as to why we have no choice but to trust something like SSL because its the only thing we got and we are stuck with it.

Re: You can prevent problems by not trusting SSL (1)

Anonymous Coward | about 9 months ago | (#46311703)

Your comment demonstrates a total lack of understanding of SSL.

Private keys are always ONLY in the hands of the communicating parties. You never transmit your private key to anyone, if you're doing things right.

Third party Cert Authorities sign a certificate fingerprint. They establish a "trust chain" where if you trust the CA to do verification of identity, then you can trust the identity of the signed certs. The CA never sees the private key to do this trust certification.

If you don't trust CAs, skip all that. Sign the certificate yourself and SSL as a protocol still works fine for encryption. It just no longer guarantees identity of the endpoint without additional out-of-band checks by your application.

Re:You can prevent problems by not trusting SSL (1)

amorsen (7485) | about 9 months ago | (#46313445)

No one you don't know or trust is in charge of the private keys for the encryption. Except if you don't trust the party you are talking to, in which case you are looking for DRM, not encryption.

Increase safety by avoiding proprietary software (1, Insightful)

jbn-o (555068) | about 9 months ago | (#46311713)

The software Apple distributes to users is proprietary, even if part of that software is built from free software. Proprietary software is never safe for users. Its safety is for the proprietor—what the program allows the proprietor to do to the users.

Apparently memories around here are so short people can't remember when researchers showed Apple can read iMessages [slashdot.org] anytime Apple wants and the users have no idea which messages are being read. Whether anyone at Apple reads someone's iMessages is a detail so long as Apple can read any iMessage they choose. The same applies to any proprietor for any software which doesn't respect your software freedom. You avoid these problems by avoiding proprietary software.

Re:Increase safety by avoiding proprietary softwar (2)

93 Escort Wagon (326346) | about 9 months ago | (#46312293)

Given this bug exists in published open source code, I'm not sure how your point is relevant to this particular issue.

https://www.imperialviolet.org... [imperialviolet.org]

Open source code is not a panacea. Have you not been paying attention to the number of RHEL kernel updates (to pick one example) released in 2014?

Re:Increase safety by avoiding proprietary softwar (1)

jbn-o (555068) | about 9 months ago | (#46316049)

The point you fail to understand is that with software that respects a user's freedom, one doesn't need to wait for someone else to fix the bug for them and then hope that bug actually gets fixed when the ostensible fix is released. Users running nothing but free software have options to fix any bug and verify that fix which proprietary software disallows.

The rest of your statement is a form of false dichotomy—arguing from perfection. I never said anything was perfect.

Shipping Obviously Untested Code (1)

billstewart (78916) | about 9 months ago | (#46314767)

It's not like nobody's ever declared they're done and shipped code without testing it first, or without fixing all the bugs they found, but they obviously didn't test this one.

Fail: goto fail;

time space circumstance righting themselves (-1)

Anonymous Coward | about 9 months ago | (#46310163)

spiritual vortex? history physics & reality collide poorly causing unsanity symptoms (early last year). it's been caught in time hopefully http://news.yahoo.com/substitute-teacher-taped-spouting-bizarre-conspiracy-theories-high-135248463.html

poppycock (-1)

Anonymous Coward | about 9 months ago | (#46310197)

that's how i remembered what happened just last night, there were particles of it in our bed. no confusing caramel corn & cashews with fairytail dust? as for what else happened i'm still in the cloud...

Details of bug (5, Informative)

DrDevil (90608) | about 9 months ago | (#46310205)

The bug is that the cn hostname from the certificate is not verified. So it's possible to use your own website SSL cert as a cert for any other site and Apple devices will accept it no question. Of course, to exploit, you'd need to modify a tool like webmitm to serve a fixed certificate.

Very very dangerous, seems to be a result of switching away from OpenSSL although details are still flaky.

Re:Details of bug (1)

CODiNE (27417) | about 9 months ago | (#46311293)

I was curious about Apple deprecating OpenSSL so went looking into it.

Apparently OpenSSL doesn't keep a stable API between versions so developers should either static link it (ensuring eventual security problems if they are shipping out of date versions) or use something else if dynamic linking since Apples software updates would update OpenSSL and break apps using it.

Re:Details of bug (0)

Anonymous Coward | about 9 months ago | (#46378239)

Like Apple cares about ABI compatibility. They release new versions every few month and drop suppose for the old.

Then again, Apple could just have written a glue layer for any changed API/ABI. Maybe that was harder than actually writing your own SSL implementation, with obvious results.

Re:Details of bug (3, Insightful)

am 2k (217885) | about 9 months ago | (#46311557)

Apple never "switched away" from openssl, they shipped their own implementation with the very first version of Mac OS X. They only packaged openssl with the system for other apps to use. I actually rewrote the XMPP encryption stuff in Adium to use the security framework instead of openssl way back in 2007, since that allowed me to use the built-in system dialogs for presenting certificates.

Re:Details of bug (0)

Anonymous Coward | about 9 months ago | (#46311845)

Apple never "switched away" from openssl, they shipped their own implementation with the very first version of Mac OS X

They switched away when they ported it.

Re: Details of bug (2, Informative)

Anonymous Coward | about 9 months ago | (#46311683)

That's not the bug at all. It has nothing to do with hostname verification whatsoever. In fact, traditional RSA+AES CBC connections are not affected at all. Only ephemeral, or so-called "perfect forward secrecy" key exchanges are affected.

However because cipher choice and handshake choice are left to the server (picking from a set that the client advertises) in the protocol, a malicious server can always pick the vulnerable key exchange and exploit it.

The precise bug is subtle. The failure to verify the hashed signature of the ephemeral key exchange means that the server can present any valid public cert without ever knowing the private key for the cert.

Re: Details of bug (0)

Anonymous Coward | about 9 months ago | (#46320047)

Yep

goto fail (5, Informative)

tero (39203) | about 9 months ago | (#46310229)

in
http://opensource.apple.com/so... [apple.com]

  if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                goto fail;
                goto fail;

Re:goto fail (2, Interesting)

Anonymous Coward | about 9 months ago | (#46310237)

?! Any decent compiler would throw up a warning for unreachable code. I know that the whole "many eyes" thing is a miss and an audit of any open source code will usually pick up trivial problems, but that one doesn't even make any sense unless Apple coding practices are so poor that no sensible person would touch their products.

Re: goto fail (1, Interesting)

Goldfish1974 (749652) | about 9 months ago | (#46310319)

That's why sensible people use Android...at least you know how its broken...better than Apples rose colored glasses...

Re: goto fail (1)

BitZtream (692029) | about 9 months ago | (#46310975)

Uhm ... so you don't know whats broken when you've been given a link to the source in question? But on Android you magically do?

So are you just retarded and only can read source for Android and no other purpose or just too stupid to realize that the source code in question here is VERY open ... and fucking linked a few posts above your for fucks sake.

Fucking ignorant fanboy won't even read the fucking web page your on.

Re: goto fail (-1)

Anonymous Coward | about 9 months ago | (#46311467)

You fucking stupid piece of shit. Something as amateurish as that double goto would have been easily caught. No wonder iOS is security through obscurity. Wasn't philly the shill schiller bragging about iOS being the most secure OS in the world? "Be careful out there". What a fucking joke you sheep are.

Re: goto fail (-1)

Anonymous Coward | about 9 months ago | (#46313359)

There is no double goto in the linked page, only in the boned pasting of it above.

So, who is a stupid piece of shit?

Re: goto fail (1)

Trillan (597339) | about 9 months ago | (#46325369)

Um, sure there is. Search for SSLHashSHA1.update; it's in the second group of them.

Re: goto fail (1)

Trillan (597339) | about 9 months ago | (#46325727)

The source is available; how does "security through obscurity" apply at all?

Re:goto fail (4, Informative)

tero (39203) | about 9 months ago | (#46310361)

Yeah, you'd think a compiler should have caught that.. but neither GCC or Xcode seems to do that..

Adam Langley has a great blog post dissecting this:
https://www.imperialviolet.org... [imperialviolet.org]

Re:goto fail (1, Funny)

arglebargle_xiv (2212710) | about 9 months ago | (#46310635)

Yeah, you'd think a compiler should have caught that.. but neither GCC or Xcode seems to do that.

Visual Studio will detect and complain about this. So all Apple would need to do is switch to Microsoft Vis.... oh. Damn.

Re:goto fail (1)

BitZtream (692029) | about 9 months ago | (#46310953)

So does Clang in current versions of Xcode. No one uses GCC on Apple anymore so its really irrelevant. We've moved on to compilers that don't suck ass. GCC remains for fanboys but thats about it.

The person you're replying to hasn't used Xcode for a very long time apparently.

Clang bitches about any silly coding mistake pretty much, not just unreachable code due to a return or some sort of jmp over code, but also warnings about things such as not catching every case in a switch on an enum.

I'd give up my left testicle if Apple would magically port and start using Visual Studio in OSX though. I can't stand dealing with Windows anymore, but god I long for an IDE that doesn't suck ass.

Re:goto fail (1)

Antique Geekmeister (740220) | about 9 months ago | (#46311097)

As does gcc with the right flags, which detect "unreachable code". That can often generate a storm of warnings that require a great deal of additional time to sort through and resolve, and can be different depending on compile time definitions. So it's not often used.

Re:goto fail (0)

Anonymous Coward | about 9 months ago | (#46311365)

Which flags?

Re:goto fail (1)

arglebargle_xiv (2212710) | about 9 months ago | (#46313897)

As does gcc with the right flags, which detect "unreachable code".

No it doesn't. -Wunreachable-code is accepted as a compiler option, but it does nothing while making you think it's actually doing what it claims to.

(Yet another of the many reasons why the sooner clang/LLVM kills gcc, the better).

Re:goto fail (1)

am 2k (217885) | about 9 months ago | (#46311111)

No one uses GCC on Apple anymore so its really irrelevant. We've moved on to compilers that don't suck ass. GCC remains for fanboys but thats about it.

Tell that to certain tools [wikipedia.org] coming from Linux that rely on STL interas only available in the GCC version of STL...

I'd give up my left testicle if Apple would magically port and start using Visual Studio in OSX though. I can't stand dealing with Windows anymore, but god I long for an IDE that doesn't suck ass.

I know quite a few Mac developers that say exactly the opposite ("I'd port my Mac app to Windows, if there was an IDE that didn't suck ass...").

Re:goto fail (0)

Anonymous Coward | about 9 months ago | (#46311381)

Interesting Apple bug.

They have a test website at https://www.imperialviolet.org:1266/ to demonstrate it.

Too bad Apple didn't use openssl:

openssl s_client -connect www.imperialviolet.org:1266 -tls1
CONNECTED(00000003)
depth=2 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority
verify return:1
depth=1 /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
verify return:1
depth=0 /description=A8d2s17a3J6Ka0PO/C=US/CN=www.imperialviolet.org/emailAddress=webmaster@imperialviolet.org
verify return:1
16142:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1092:SSL alert number 40
16142:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:536:

Re: goto fail (0)

Anonymous Coward | about 9 months ago | (#46320057)

Nice example!

warning about unreachable code (0)

Anonymous Coward | about 9 months ago | (#46310381)

It's there [gnu.org] if you need it, but you have actually to use it.

In the reference they explain why it isn't part of regular -Wall, too.

Re:warning about unreachable code (4, Informative)

eddy (18759) | about 9 months ago | (#46310443)

Sorry, it's not there. It's silently ignored, which is the WORST POSSIBLE SOLUTION to the problem. Ugh.

The -Wunreachable-code has been removed, because it was unstable: it relied on the optimizer, and so different versions of gcc would warn about different code. The compiler still accepts and ignores the command line option so that existing Makefiles are not broken. In some future release the option will be removed entirely.

http://gcc.gnu.org/ml/gcc-help... [gnu.org]

Re:goto fail (1)

ChunderDownunder (709234) | about 9 months ago | (#46310605)

Coding standards often specify pedantic use of superfluous braces, even for single line clauses, e.g.

if (condition) { // single line here
}

But clearly the folks at Apple know better. :-(

Re:goto fail (2)

BitZtream (692029) | about 9 months ago | (#46310993)

The linked file uses both braces for single line ifs and without braces for single line IF's ... that is a really bad sign as a developer in my opinion. That means they aren't enforcing style guidelines and that makes code a fuckton harder to read. I can adapt to either style fairly easy, but when you mix it my mind gets wonky, my mind tends to find it ambiguous too!

Re:goto fail (0)

Anonymous Coward | about 9 months ago | (#46310645)

The point is, that it's not unreachable. The second goto is reached if the if check fails, and causes the fail: label to execute with error set to 0, jumping right over the checks below this if.

Re:goto fail (1)

BitZtream (692029) | about 9 months ago | (#46310969)

There is no unreachable code of goto fail jumps to the right place.

If you look at the actual source and think a moment, its pretty clear and isn't entirely illogical, though I admit, it is broken.

The snippet you are replying too looks stupid standing on its own, in context it doesn't stand out nearly as well, and there is absolutely no way you can tell by that snippet if there is any unreachable code or not, you have no idea from the snippet whats after those gotos or what those gotos do.

Re:goto fail (1)

kybred (795293) | about 9 months ago | (#46311261)

The lines of code immediately after the second 'goto fail;' up to the 'fail' label are unreachable. There is no label or closing brace after the second goto fail, so how would it get executed?

ahh grasshopper (0)

Anonymous Coward | about 9 months ago | (#46311819)

Only if one had the foresight to include -wall in the compiler options AND then actually read all the warnings.

Re: goto fail (2)

ugen (93902) | about 9 months ago | (#46310365)

Curious. This would seem to result in a failure every time. Without reading the code further - how could auth ever succeed? Or did it ignore the failure return code and relied on hash update results anyway?

Switching away from OpenSSL that is widely used and audited for generations of releases to homegrown crypto is a mistake on Apples part. This is most certainly not the last security flaw in their code we will see.

Re: goto fail (2)

tero (39203) | about 9 months ago | (#46310387)

Yeah, the hash update succeeds, so err contains successful value when it jumps to the end. It never reaches the dead part where it updates.

Re: goto fail (3, Insightful)

ugen (93902) | about 9 months ago | (#46310393)

Dumb. We are in for more than that. It took a decade to get OpenSSL clean with many more eyes on it.

Re: goto fail (1)

Anonymous Coward | about 9 months ago | (#46310389)

"goto fail" is misleading, imho. It's more "goto finally". After cleaning up, the function returns the current value of err, which would after the unconditional "goto fail" be 0, i.e. success.

Yes. Writing code is easy (I do it every day). Writing security-related code is moderately easy if you're mathematically minded. Writing robust security-related code is fucking hard - not just because of all the implementation details, but because humans repeatedly make schoolboy errors. It's just how we are. If your code isn't being audited by multiple people on every changeset, you're wasting your time doing anything more than hobby projects. And Apple's iOS is arguably not a hobby project.

Re: goto fail (1)

amaurea (2900163) | about 9 months ago | (#46310407)

The return code from the function is "err", which is the result of the last test that was done inside the function. The second goto is only reached if err is 0 (success), so at that point the function returns success.

Re:goto fail (0, Troll)

ChunderDownunder (709234) | about 9 months ago | (#46310523)

goto considered harmful.

Re:goto fail (1)

bgarcia (33222) | about 9 months ago | (#46312155)

I wouldn't blame the goto here.
The problem is single-line if bodies.
Or not using a tool that auto-indents the code.

Re:goto fail (2)

AmiMoJo (196126) | about 9 months ago | (#46310587)

It's similar to some of the bugs that the NSA/GCHQ have inserted in the past. Knowing this we should really make compilers detect this kind of error.

Re:goto fail (0)

am 2k (217885) | about 9 months ago | (#46311581)

It's similar to some of the bugs that the NSA/GCHQ have inserted in the past. Knowing this we should really make compilers detect this kind of error.

Or they should just reject the goto command. This kind of issue could never have happened if the developer would have used properly structured code.

Re:goto fail (1)

Jackmn (895532) | about 9 months ago | (#46381263)

Using goto for error handling in C is a well-established idiom [cert.org] , and is often the best option available. The alternatives either involve deeply nested if statements, or duplicated cleanup code.

For example, this pattern is used quite heavily in the Linux kernel. Linus (and a few others) had had something to say on this matter [koblents.com] .

Re:goto fail (0)

Anonymous Coward | about 9 months ago | (#46311287)

The bug was not in the 10.8.5 sources [apple.com] , so it was introduced later than that. Would have been interesting to see the git/svn repo to see who did...

Re:goto fail (1)

arglebargle_xiv (2212710) | about 9 months ago | (#46313995)

Goto fail. Go directly to fail. Do not pass the signature check. Do not collect an error status.

Todays lesson (0)

Anonymous Coward | about 9 months ago | (#46314043)

Grass hopper, this is one of those lessons where you always add { } brackets after any if conditional -- even if its a one line if.

Re:goto fail (1)

tlhIngan (30335) | about 9 months ago | (#46314781)

in
http://opensource.apple.com/so... [apple.com]

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
                                goto fail;
                                goto fail;

That looks to be the result of a bad patch - anyone who uses git probably can see what happens if you don't rebase patches properly - you end up with patches that apply in very strange and very wierd ways. Especially if the patch in question contains a lot of repeated statements such that the context diff doesn't contain enough context.

Either that, or it was a patch that was being applied manually (because it wasn't rebased properly) and someone forgot to delete an extra line

(It's great fun when code gets so similar that the patch really can apply almost anywhere - it's resulted in some very strange device trees after patching the Linux kernel).

?! Any decent compiler would throw up a warning for unreachable code. I know that the whole "many eyes" thing is a miss and an audit of any open source code will usually pick up trivial problems, but that one doesn't even make any sense unless Apple coding practices are so poor that no sensible person would touch their products.

The problem is it's really easy to miss warnings when a build is in progress - the compiler may produce a ton of warnings, but it's all intermixed and interspersed during the build (especially during multicore builds) that it's hard to see or even find.

Especially in builds for a large system - people are likely to just kick off the main build and miss warnings on the bit that they fixed.

Heck, I do that when fixing code in Android - I'd fix a bug, kick off the build and it'll scroll by way too fast. Even finding an error can be a chore because of all the output - it can be hundreds of lines behind the prompt.

Jailbreakers (0)

davidc (91400) | about 9 months ago | (#46310431)

Apple's strategy is to release an OS, wait a bit, then start releasing small incremental updates that ought to have been in the initial release in the first place. I suspect they do this on purpose in order to confound the jailbreakers.

Re:Jailbreakers (2)

MikeMo (521697) | about 9 months ago | (#46310879)

Apple's strategy is to test, test, test and then test the best they can, release multiple beta versions to developers for testing, take a very long time to release new versions, and then patch the missed bugs that show up as fast as they can. Pretty much the way any professional software house does business.

Or are you of the opinion that it's possible to release such a massive amount of code totally bug-free?

Re:Jailbreakers (1)

93 Escort Wagon (326346) | about 9 months ago | (#46312401)

The problem is - and we've seen this before - Apple is unnecessarily reinventing the wheel in certain cases. It's the same general problem Microsoft ran into when they decided they wanted to develop their own completely in-house tcp stack earlier this millennium - you're starting from scratch, and you sometimes end up with code that exposes bugs that were patched in the time-tested tools years (or even decades) earlier. Or, as in this case, there are fewer cumulative sets of eyes reviewing your open source code.

It's also why rolling your own crypto is probably not a smart practice, even with the NSA's traitorous actions. If you're truly smart enough to do that, you're still better served looking for the problems in existing ciphers.

Re:Jailbreakers (1)

jo7hs2 (884069) | about 9 months ago | (#46310885)

That's a little paranoid even for a post about Apple.

What about iOS 6? (0)

Anonymous Coward | about 9 months ago | (#46310773)

What about iOS 6? Is it affected too, and can I get an update without going to iOS 7?
(Now, I don't want eye cancer, TYVM)

Re:What about iOS 6? (1)

ciurana (2603) | about 9 months ago | (#46312103)

Apple also released iOS 6.1.6 in response to the bug.

If your iPhone is jailbroken, there's ongoing discussion to release a patch via Cydia and Evasi0n.

Cheers!

Update their iOS devices to iOS 7.0.6 (0)

nurb432 (527695) | about 9 months ago | (#46311043)

And those that cant, send us 700 for a new device. And thanks for playing.

Re:Update their iOS devices to iOS 7.0.6 (2)

Rosyna (80334) | about 9 months ago | (#46311235)

Or they could update to iOS 6.1.6 on their iPhone 3GS (previous versions of iOS did not have this bug)

Re:Update their iOS devices to iOS 7.0.6 (2)

immaterial (1520413) | about 9 months ago | (#46311241)

Really... Five hours after the *first post* already shot down this claim?

Re:Update their iOS devices to iOS 7.0.6 (0)

Anonymous Coward | about 9 months ago | (#46311339)

Sadly - this update bricked my 128G iPad air.
Performed a wifi update to 7.0.6 - next thing I new - the pad wanted me to connect to iTunes!
Tried to update via usb/itunes - downloads bootloader - bluescreen ( how microsoft ) - update fails with either error 9 or 4013.
Tried va DFU - exaclt the same - seriously WTF !!!!
How is this an incentive to update !
Device due for pickup / replacement.

Re:Update their iOS devices to iOS 7.0.6 (0)

Anonymous Coward | about 9 months ago | (#46312575)

Must be nice to be paid by Google to post crap like this...

Re:Update their iOS devices to iOS 7.0.6 (1)

nurb432 (527695) | about 9 months ago | (#46316109)

They all suck. What is your point?

Goto? (2)

BlackPignouf (1017012) | about 9 months ago | (#46311171)

1) I haven't seen GOTO statements since my GWBASIC days, and I've surely never seen this many.
2) I really like one-liners for if statements in Ruby: "do_this if x==1"
3) Two-liners for C if statements without curly braces feel wrong, are dangerous and hard to read
4) http://xkcd.com/292/ [xkcd.com]
5) GOTO 1

Re:Goto? (1)

Anonymous Coward | about 9 months ago | (#46312251)

1) I haven't seen GOTO statements since my GWBASIC days, and I've surely never seen this many.

Then you don't write much low level C code. Error handling in C is possibly the only place where goto statements are useful, because the alternative is deeply nested if statements. Other languages solve it by using try-catch-finally blocks.

Re:Goto? (1)

Barlo_Mung_42 (411228) | about 9 months ago | (#46312319)

I've seen them used in this case where you would otherwise need an ugly nested if. Two in a row though? That seems decadently excessive.

Exception handling (1)

mveloso (325617) | about 9 months ago | (#46324543)

This is exactly when you use gotos in real life. If you look at low-level implementations it's easier to use goto and hit cleanup code than it is to unwind a ridiculous amount of crap.

Also, it's funny - Apple's style guidelines used to require curly braces around all statements in the if, even if it's a one liner. Guess those unix guys have subverted the paradigm.

That's one way to get everyone to update (1)

koan (80826) | about 9 months ago | (#46311193)

Unlikely to effect me as I never use WiFi and MIM is a bit less likely over a cell connection.

OS X (1)

oDDmON oUT (231200) | about 9 months ago | (#46312009)

I used the test site set up at https://www.imperialviolet.org... [imperialviolet.org] with a X.6.8 rig using both Safari and FF. It passed with flying colors.

Does this mean earlier versions of OS X don't have the bug?

Re: OS X (0)

Anonymous Coward | about 9 months ago | (#46312455)

Correct. The bug was introduced in 10.8 or 10.9.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?