Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Apple SSL Bug In iOS Also Affects OS X

timothy posted about 8 months ago | from the sympathetic-reaction dept.

OS X 140

Trailrunner7 writes "The certificate-validation vulnerability that Apple patched in iOS yesterday also affects Mac OS X up to 10.9.1, the current version. Several security researchers analyzed the patch and looked at the code in question in OS X and found that the same error exists there as in iOS. Researcher Adam Langley did an analysis of the vulnerable code in OS X and said that the issue lies in the way that the code handles a pair of failures in a row. The bug affects the signature verification process in such a way that a server could send a valid certificate chain to the client and not have to sign the handshake at all, Langley found. Some users are reporting that Apple is rolling out a patch for his vulnerability in OS X, but it has not shown up for all users as yet. Langley has published a test site that will show OS X users whether their machines are vulnerable."

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

Apple (-1)

Anonymous Coward | about 8 months ago | (#46312889)

All about the looks of their g4y hardware but fails horribly at security.

Hey look at that pretty shiny! I bet it gives out root access to the world!

Re:Apple (0)

Anonymous Coward | about 8 months ago | (#46312941)

I bet you give root access to the world.

Re:Apple (4, Funny)

Anonymous Coward | about 8 months ago | (#46313055)

I bet your mom gives out root access to the world.

Hmm... (3, Funny)

93 Escort Wagon (326346) | about 8 months ago | (#46312893)

The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

Coincidence? I think not!

Re:Hmm... (1)

wiredlogic (135348) | about 8 months ago | (#46313265)

The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

Coincidence? I think not!

Adam Langley is an anagram of "A lang madly e". Clearly this is the product of some leet Canadian insider who has gone rouge with this disclosure. Time to put on a new layer of tinfoil.

Re:Hmm... (1)

LynnwoodRooster (966895) | about 8 months ago | (#46313551)

The researcher who found the bug is Adam Langley. CIA headquarters is in Langley, Virginia.

Coincidence? I think not!

Adam Langley is an anagram of "A lang madly e". Clearly this is the product of some leet Canadian insider who has gone rouge with this disclosure. Time to put on a new layer of tinfoil.

Mascara, even!

Re:Hmm... (1)

sjames (1099) | about 8 months ago | (#46314857)

Must be a lumberjack.

Feature (1)

stooo (2202012) | about 8 months ago | (#46314889)

>> The researcher who found the bug is Adam Langley.
>> Bug removes SSL ...

it's a feature, not a bug.
https://pbs.twimg.com/media/Bh... [twimg.com]

Considering Apple admitted.... (-1)

Anonymous Coward | about 8 months ago | (#46312901)

that this backdoor wasn't in previous versions, and they added it later, I think we have proof that the government made them do it. This furthers the legacy of the Bush junta.

Re:Considering Apple admitted.... (2)

davester666 (731373) | about 8 months ago | (#46313179)

No, it was a stupid coding standards error

if (x)
          goto error;
          goto error;
if (y)
          goto error;

error:
return

if the coding standards required braces around the code block like this

if (x)
{
        goto error;
        goto error;
}

it would have eliminated the effects of this coding error

Re: Considering Apple admitted.... (1)

hobbes75 (245657) | about 8 months ago | (#46314939)

If the language would require the braces it would even be better...

Re:Considering Apple admitted.... (1)

multi io (640409) | about 8 months ago | (#46315477)

No, it was a stupid coding standards error

Which is just what you would do to have plausible deniability. :-P

Lets see how far back... (2, Insightful)

Anonymous Coward | about 8 months ago | (#46312913)

Let see how far back Apple will patch this thing, if they leave Snow Leopard (10.6) out for the wolves or not.

In the past under Jobs, only the last two OS X versions got security updates. He was a real prick about trying to force people to upgrade to their latest bloated your machine so you have to buy a new one prematurely crap.

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46312951)

If you actually read the articles, you'll discover that 10.6 is not even affected by this bug.

Re:Lets see how far back... (4, Insightful)

ugen (93902) | about 8 months ago | (#46312955)

Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org:1266/ )

On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x. For now I've switched from Safari to a 3rd party browser that does not have this bug - but email is still vulnerable and so can be other components. That said, I have little trust in SSL even when it works as designed, so I won't lose much sleep over this.

Re:Lets see how far back... (1)

Rick Zeman (15628) | about 8 months ago | (#46313045)

Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet. Just verified on my 10.6 box (to verify visit https://www.imperialviolet.org... [imperialviolet.org] )

On the other hand, iOS 6.1.5 is - and now I have a choice of using insecure iPhone or upgrading to 7.x.

Or, perhaps upgrading to iOS 6.1.6 [apple.com] which corrects that bug.

Re:Lets see how far back... (1)

Anonymous Coward | about 8 months ago | (#46313103)

If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

Re:Lets see how far back... (1)

Rick Zeman (15628) | about 8 months ago | (#46313489)

If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

Ugh. I didn't realize that. That's just...short-sighted.

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46314699)

While that sucks for Enterprise Users who's IT Department won't let them upgrade...

In what way is it short-sighted? In what way is it different than pretty much anything Apple has done in the last decade?

They're pretty open about their intentions too, so it's not like it's some big conspiracy.

Re:Lets see how far back... (1)

grumling (94709) | about 8 months ago | (#46316037)

Which is yet another reason I keep seperate work and home devices. If they aren’t going to keep up with security patches and the device is comprimized, it only affects “their” stuff, not mine.

Re:Lets see how far back... (2)

ugen (93902) | about 8 months ago | (#46313327)

iOS 6.1.6 is not available for iPhone 5. It is only available for devices for which there is no iOS 7, unfortunately. First thing I checked.

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46313167)

their own SSL/TLS library

Why would you do that?!

Re:Lets see how far back... (1, Troll)

zippthorne (748122) | about 8 months ago | (#46313385)

So that they wouldn't be affected by bugs in OpenSSL?

The idea that it's a bad idea to roll your own security features because you're probably not a security expert is not something that is necessarily applicable to an organization as large as Apple, which can certainly afford to employ as many security researchers as it needs to to match the security knowledge of other common security tool organizations.

Further, a world in which there is only one (hopefully well-researched) implementation of critical security software also has drawbacks, as any errors in that software will affect everyone.

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46313605)

So that they wouldn't be affected by bugs in OpenSSL?

Instead they're affected by bugs in their own implementation. Worse, the footprint of their implementation compares to something like OpenSSL is so small that their problems are likely to remain under the surface until they surface suddenly and bite them in the ass: with Open Source, all bugs are shallow.

I could understand it if OpenSSL was a closed proprietary implementation, or widely known as being complete crap, but in this instance: why would you do that?!

Re:Lets see how far back... (1)

Anonymous Coward | about 8 months ago | (#46314109)

Instead they're affected by bugs in their own implementation. Worse, the footprint of their implementation compares to something like OpenSSL is so small that their problems are likely to remain under the surface until they surface suddenly and bite them in the ass: with Open Source, all bugs are shallow.

Their implementation is open source. So, I call bullshit on your assertion.

Given that they open sourced their implementation, and didn't use OpenSSL, I'd bet heavily that there's some requirement that they have that OpenSSL did not, and would not fulfil.

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46315295)

Given that they open sourced their implementation, and didn't use OpenSSL

So I'll just keep asking, because no one can provide an answer: why would you do that?!

I'd bet heavily that there's some requirement that they have that OpenSSL did not, and would not fulfil.

It's Open Source; what was stopping them just adding the functionality they needed, other than NIH? Nothing. Nothing at all.

Re:Lets see how far back... (1)

Anonymous Coward | about 8 months ago | (#46315641)

So I'll just keep asking, because no one can provide an answer: why would you do that?!

As has been mentioned in this thread several times –because OpenSSL kept repeatedly making bin-compat breaking changes to their API. The result was that they could not ship up-to-date versions of OpenSSL, and hence were open to all kinds of security vulnerabilities that way. Their solution was to change to an API that they knew could be consistent.

Re:Lets see how far back... (2, Interesting)

dgatwood (11270) | about 8 months ago | (#46313231)

Snow Leopard (10.6) is not vulnerable to this bug, since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet.

No, that's not correct at all. First, it doesn't affect 10.8.5, either, which blows that theory. Second, Secure Transport was introduced way back in 10.2, and has been used for Foundation and Core Foundation SSL negotiation since at least 10.4, according to various security vulnerability reports (and probably earlier). In other words, this has absolutely nothing to do with Apple "switching" anything. It's just a bug, and a fairly recent bug at that.

Re:Lets see how far back... (2)

ugen (93902) | about 8 months ago | (#46313367)

It is correct and, if you have 10.6 handy - you can verify that under that system Safari is using OpenSSL. To do so, simply move /usr/lib/libssl.*.dylib elsewhere and try to run Safari. It will fail due to missing libraries.
On 10.9 Safari will happily run with OpenSSL libraries removed.

You are welcome to dig through otool -L output to find how it's linked up, but the fact remains - Safari was switched over from OpenSSL to homegrown crypto sometime after 10.6.

Re:Lets see how far back... (1)

PopeRatzo (965947) | about 8 months ago | (#46313399)

since Apple did not switch from OpenSSL to their own SSL/TLS library back then yet.

Why did they switch? I haven't been able to find out from the articles I read.

Re: Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46313627)

Apple regarded the OpenSSL API as too much of a moving target and decided to write their own to have a more stable API, from what I've heard.

Re: Lets see how far back... (1)

PopeRatzo (965947) | about 8 months ago | (#46313927)

I'm pretty thick. Why isn't a "moving target" a good thing when you're talking about security?

Is OpenSSL open source? That would make it more trustworthy, wouldn't it?

Not long ago I wouldn't even have thought about these things, but with some formerly trusted players putting back doors and exploitable weaknesses into their products for the sake of the NSA, I figure I better ask some questions.

Re: Lets see how far back... (1)

Anonymous Coward | about 8 months ago | (#46314079)

Not-invented-here-syndrome.

Actually, the official story is that OpenSSL didn't maintain ABI compatibility across versions to Apple's satisfaction. Of course, instead of just forking or maintaining patches against OpenSSL, they decided to implement their own SSL stack from scratch.

Something like this was inevitable. Apple's crypto and SSL stack can't hold a candle to OpenSSLs in terms of features and algorithms. And while everybody agrees that OpenSSL is ugly code, it's code that's been hammered on for nearly two decades, and has a ton more eyeballs pouring over it than Apple's crypto stack. It was kind of ridiculous, because OpenSSL is the de facto standard in open source (even though the "official" standard in Linux per the LSB is NSS), and a million applications will continue using OpenSSL, only now, once Apple rips it out completely (it screams deprecated when try to compile against it today), they'll have to bundle it themselves.

Re:Lets see how far back... (1)

Espectr0 (577637) | about 8 months ago | (#46313597)

If you don't want 7.x you can use 6.1.6 which got released to fix this

Re:Lets see how far back... (2)

PNutts (199112) | about 8 months ago | (#46313693)

Not on all devices. AC posted this so it got lost in the filters: If you are able to upgrade to iOS 7, you are not able to upgrade to 6.1.6.

Re:Lets see how far back... (1)

mattr (78516) | about 8 months ago | (#46314075)

Slashdotted.

Re:Lets see how far back... (1)

grantspassalan (2531078) | about 8 months ago | (#46314269)

I just checked with https://www.imperialviolet.org... [imperialviolet.org] And I got the message "Safari can't open that page because Safari can't established a secure connection to the server". I am running Mac OS 10.8.4 so does that mean I am safe?

Re:Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46313545)

Yeah and what about my 1st generation iPad that’s been permanently locked into iOS 5.1.1 and, according to Apple is not upgradeable.
Also almost all apps in the app store are switching up to iOS7 and will no longer install.
A very small percentage of them will offer to download an outdated version of an app at install time. But very few do this. Most just tell you to fuck off and die.

Is Apple going to tell those of us still hanging on to Jurassic iDevices to eat shit and die?

I have 4 iPhones, I just use my old ones around the house as wifi only devices. Am I to throw those away too?

Apple better come out with patches for legacy stuff or they are gonna piss of a LOT of people !

Re: Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46313661)

iOS 5 doesn't have this bug

Re:Lets see how far back... (1)

jbolden (176878) | about 8 months ago | (#46316295)

Apple has consistently been opposed to long term legacy use. Anyone pissed off by this is completely irrational. iPad 1 was an April 2010 device, which Apple had an expected life for of 2-3 years.

You don't like rapid upgrades Microsoft will be happy for your tablet business.

Re: Lets see how far back... (0)

Anonymous Coward | about 8 months ago | (#46314901)

It seems 10.6.8 is not even affected. i can not enter the test page from my SL wit firefox. So I suppose its secure.

Informative discussion thread (5, Informative)

MisterSquid (231834) | about 8 months ago | (#46312937)

Over at MetaFilter, there's a pretty informative thread calling out these parts among others [metafilter.com] .
  • iOS 6 users with iOS 7-capable devices will be given the latest iOS 7.
  • iOS 6 users without iOS 7-capable devices will be given the latest iOS 6
  • Mac OS X users pre-Mavericks (10.9) are OK.
  • Mac OS X Mavericks users should avoid using Safari.
  • You can visit this link [gotofail.com] to see if your device/browser is affected.

Re:Informative discussion thread (0)

ugen (93902) | about 8 months ago | (#46312995)

:( But I *really* don't want iOS 7. I think this is all planned by Apple to move remaining holdouts to the current iOS. Fuck.

Re:Informative discussion thread (0)

Anonymous Coward | about 8 months ago | (#46313037)

and OS X.

Re:Informative discussion thread (0)

angel'o'sphere (80593) | about 8 months ago | (#46313185)

iOS 7 is the worst mobile OS I have ever seen.
If you are an iPhone, iPad user I recommend not to upgrade to it.
The UI is the absolute ugliest thing I can imagine, many superb iOS applications like the address book or the Calendar or the Notes application look like utter shit.
The standard usability with swipes of a finger or multiple, fingers is completely messed up. The pad or the phone does most of the time not what you want, and if you want to do something special, like killing a process: it simply does not work (you have to google for it, *facepalm* Apple changed *everything* for no apparent reason ... my next ... likely next month ... pad will be an android). What do I talk about? The search function is gone (no it is not ... but to find it you have to google) Scrolling in a web browser does not work (sure it does, when you have learned not to start at the lower edge of the screen) Web browsers reload old tabs randomly ... instead of simply showing their contents ... can be 'fixed' by rebooting ... for a while.
When you load the "monster menu" by swiping up from the lower edge of the screen, what do you likely want to chose/change? Screen brightness! Never changed anything else. But what happened's? The screen gets dimmed ... how retarded is it to dim a screen and display a slider to adjust screen brightness?
Every internet connection breaks. Neither mail nor any browser or anything works reliable ... after a few days you have to reboot. Loading a web page (even if it is only a few kB might take minutes, it is faster to cancel it a dozen times and hit reload)
And yet: according to public media most of the iOS 7 users like it.
Retarded, or fraud.

iOS 7 is Fine (0)

Anonymous Coward | about 8 months ago | (#46313235)

Or maybe ios 7 takes some getting used to but is basically fine. It'd be nice if they added some chrome around buttons. In general, the new UI is less cramped and more gestural. I guess this expects more from the user as some features are blatantly visible.

Re:Informative discussion thread (0)

Bing Tsher E (943915) | about 8 months ago | (#46313407)

There are finally affordable real Windows (8.1) tablets out. I just got a Dell Venue 8 Pro for $300 at Walmart. It has real x86 Windows in an 8" tablet. Its so far unlike (far superior to) ant Dell hardware I've recently owned. We're no longer forced to choose between iOS or Android.

I know evil, etc. This thing might kill Android tablets, though. It also includes free MS Office 2013 in the $300 price. Double evil, etc. It could Really kill Android tablets

. Finally being able to run Seamonkey, and any other x86 'doze stuff on a pocketable tablet is pretty nice.

Re:Informative discussion thread (1)

fluffy99 (870997) | about 8 months ago | (#46313699)

There are finally affordable real Windows (8.1) tablets out. I just got a Dell Venue 8 Pro for $300 at Walmart.

Meh, it's a low end netbook without a keyboard. I'm still waiting for anyone besides Apple to produce something with decent resolution. 1280x800 is a bit low in an 8" tablet for trying to do MS Office (which also sucks if you don't have a mouse and keyboard. But still it's an affordable option if you don't want the limitations of Android, can't afford an iPad mini, and don't mind crappy windows 8.

Re:Informative discussion thread (0)

Anonymous Coward | about 8 months ago | (#46314039)

Apple doesn't make screens, so one has to assume the reason no other tablets are available with high-res screens is because Apple paid their screen manufacturers not to provide them to their competitors. I wouldn't count on high res screens showing up intil the Chinese maufacturers who haven't received payoffs figure out how to make them (actually: purchase or steal the process technology from ASML, Canon, Nikon or Minolta).

Re: Informative discussion thread (0)

Anonymous Coward | about 8 months ago | (#46314329)

Uhhhg. If the Venue 8 is anything at all like the Venue 11, it's absolute trash. I got the Core i5 version of the 11 as part of a large server purchase at work and it's a nightmare to use. The display brightness is flakey, even with automatic brightness turned off. The form factor is stupidly awkward. It's too wide to hold comfortably in landscape and will leverage you our of your chair if you try to use it in portrait. Gotta love a device that encourages you to hold it with your hand near the lock button then penalizes you by stealing 15 seconds of your life when you accidentally press it. My HP touchpad running Android 4.1 is far superior, not to mention more ergonomic.

Re:Informative discussion thread (0)

Anonymous Coward | about 8 months ago | (#46314027)

I hate iOS. 5, 6, 7, it's shit. We have two iPads in the house, and every time I use it, I'm reminded why I don't have a smartphone (because using a screen smaller than an iPad would be pain on an unimaginable level).

With that said, your rant about iOS 7 is just stupid. I found everything you said you had to google for in only a few minutes of messing around. I'll happily admit that none of it was super intuitive, but anyone with half a brain should be able to stumble onto most of these, especially if they were already familiar with earlier iOS versions.

I've also not had any problems with network connections, I'm not sure what your problem is - but we are using a nice reliable wireless connection. Shitty connection problems sound like cellular issues to me. I've rebooted the iPads collectively less than five times, and they are use for hours at a time every day by my children.

Re:Informative discussion thread (1)

grub (11606) | about 8 months ago | (#46315511)

I guess those are YMMV problems. Though I agree about the screen brightness one.

wow that site looks like shit (0)

Anonymous Coward | about 8 months ago | (#46313019)

a blue background with white text

mind is blown

NSA (4, Interesting)

Qwerpafw (315600) | about 8 months ago | (#46313023)

Some bloggers and commentators online (no mainstream media news sites... yet) have suggested that this bug was introduced by the NSA based on the fact that Snowden's leaked slides showed evidence that the NSA had developed and was working on further ways of targeting and compromising secured iOS traffic.

We know the NSA compromised RSA through Dual EC_DRBG. It's not hard to imagine they wanted to compromise SSL/TLS on Apple platforms.

The bug was found via internal code review according to the credits for discovery, which means nobody else has disclosed they knew about this in the wild (so this is an exposed zero day crypto exploit on both OS X and iOS platforms).

This link is informative - the kicker is he properly indented but obviously duplicated and incorrect "goto fail;"

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

static OSStatus
SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams,
                                                                  uint8_t *signature, UInt16 signatureLen)
{
        OSStatus err; ...

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

fail:
        SSLFreeBuffer(&signedHashes);
        SSLFreeBuffer(&hashCtx);
        return err;
}

Maybe this came out due to bad coding practices, but the kind of bug where the code visually looks ok on the surface, compiles and passes without compiler warnings, and works fine aside from allow the comprise is very suspect.

And at the minimum the NSA has been exploiting this rather than alerting people. Our government needs to stop weakening computer security and go back to working for the people, not against them.

Re:NSA (1)

Anonymous Coward | about 8 months ago | (#46313043)

Uh, wouldn't such code generate " never executed" warnings for everything after the dupe goto??

Re:NSA (0)

Anonymous Coward | about 8 months ago | (#46313129)

Not with either gcc, or clang, neither of which support that option, no.

What it would generate is warnings from clang static analyser that several variables were written to, but never read.

Re:NSA (0)

Anonymous Coward | about 8 months ago | (#46313521)

Which variables? There are unreferenced parameters, but all the written variables there get a potential read.

Re:NSA (5, Insightful)

93 Escort Wagon (326346) | about 8 months ago | (#46313351)

This is a fundamental problem all the traitorous NSA behavior has created - every time something like this comes up, we're going to wonder if THEY are behind it. Problem is, that way lies madness... we can never really know.

1) It could very well be an innocent coding error. Heck, I could see myself doing this one with the slip of the fingers in BBEdit. I probably HAVE done it at some point in time.

2) It could be an intentional bug slipped in by someone on NSA's payroll.

3) Or, it could be even more nefarious. Perhaps NSA has known about this, but thought the use case was too restricting. So they kept quiet until they were able to slip a more broadly exploitable hole in the development code (or, alternatively, something the compiler can slip into your output). Then, to force everyone to update, they reveal this older bug. We all update, and BAM! They've got us.

We can't really know, anymore.

Re:NSA (1)

Rick Zeman (15628) | about 8 months ago | (#46313493)

This is a fundamental problem all the traitorous NSA behavior has created - every time something like this comes up, we're going to wonder if THEY are behind it. Problem is, that way lies madness... we can never really know.

1) It could very well be an innocent coding error. Heck, I could see myself doing this one with the slip of the fingers in BBEdit. I probably HAVE done it at some point in time.

2) It could be an intentional bug slipped in by someone on NSA's payroll.

3) Or, it could be even more nefarious. Perhaps NSA has known about this, but thought the use case was too restricting. So they kept quiet until they were able to slip a more broadly exploitable hole in the development code (or, alternatively, something the compiler can slip into your output). Then, to force everyone to update, they reveal this older bug. We all update, and BAM! They've got us.

We can't really know, anymore.

As Henry Kissinger is reputed to have said, "Even paranoiacs have enemies...."

Re:NSA (1)

AHuxley (892839) | about 8 months ago | (#46314187)

What do we know over the past 40-50 years of telco/computer gathering?
"DEA and NSA Team Up to Share Intelligence, Leading to Secret Use of Surveillance in Ordinary Investigations"
https://www.eff.org/deeplinks/... [eff.org]
Intentional bug slipped in might get noticed outside the more bespoke high end machine encoding production efforts of the 1960-70's.
Software teams are big, staff from varied countries, backgrounds, skill sets, review, in-house (unknown) next gen automated testing software - a person making repeated deep'errors might just stand to senior reviewers over time.
Option 3 sounds good. The hints about Magic Lantern keyloggin software might provide some insight too.
http://en.wikipedia.org/wiki/M... [wikipedia.org]
A federal law enforcement agency hints that some aspect of the codebase is open to ongoing court approved "keyloggin" efforts thats not found in the wild, not found by AV behavioral software and would be "good" if it could remain until:
The bug is found.
The EU?US AV efforts catch new malware that seems to report back to 'nothing' anymore and is built on some past effort - all very normal.
The next way in is found and the old option can be patched as it might be found in the wild and used by 'real' malware.

Re:NSA (0)

Anonymous Coward | about 8 months ago | (#46315059)

1) It could very well be an innocent coding error. Heck, I could see myself doing this one with the slip of the fingers in BBEdit. I probably HAVE done it at some point in time.

I never make this particular mistake for a long time. 20 years ago I decided that using a non-block on if, for and while statements were a mistake in the C language.
I always type in the braces to make sure that when I eventually will be modifying the code to do two things I don't forget to place those braces.

Re:NSA (3, Interesting)

Your.Master (1088569) | about 8 months ago | (#46313633)

This bug looks like the sort of bugs that can come from merging between different code branches in very large codebases. A duplicated line, or a missing line, is a common merge-conflict resolution, *especially* where essentially the same code was added in both branches and then merged together. As an example, if this was a refactor of an existing function that was made similarly in two branches, but a little extra trailing whitespace was clipped in only one branch, then you could get a duplicate line out of an automerge operation.

Re:NSA (1)

chuckugly (2030942) | about 8 months ago | (#46313885)

This sort of thing can be hard to see; this specific case is easy to spot due to the uniformity of the code around it. I've seen much harder to spot instances of things like this.

Re:NSA (1)

bondsbw (888959) | about 8 months ago | (#46314367)

This is exactly why I NEVER EVER use multiline if statements without braces.

Re:NSA (1)

BasilBrush (643681) | about 8 months ago | (#46316417)

Nobody does intentionally. Because there's no such thing.

It's single statement if blocks without braces that people should be avoiding as a matter of style.

Re:NSA (1)

TFoo (678732) | about 8 months ago | (#46314459)

Looks like a SCM merge error to me. That kind of stuff happens, unfortunately...

Re:NSA (1)

Anonymous Coward | about 8 months ago | (#46314895)

IMHO This should have been caught in the developer's IDE as a dead code warning.

p.s. This should have also been caught by automated code coverage tests.

Re:NSA (0)

Anonymous Coward | about 8 months ago | (#46315933)

Regardless of backdoors, whoever reviewed and approved a security function where the failure mode is allowing access should be hanged summarily.

This is a C Standard Bug (4, Informative)

Harry8 (664596) | about 8 months ago | (#46313031)

C and C++ still haven't fixed this egregarious bug in the standard. There is no reason for single line, un-braced blocks. People use them to show off how "cool" they are that they don't need to brace because it's only one line. It makes for difficult to spot bugs like this. We need to actually yell at the people on the standards committees to FIX THE BUGS in the standard. There are other really obvious ones and they all should be fixed before adding more new features. YES I'M LOOKING AT YOU C++14! There are plenty of ways you can make a new standard still work alongside code from an old one (compile old, broke, brittle, stupid code with a compiler flag indicating the old standard and new, beter files (yes "translation units c++") with the new one. Introduce a #THIS_FILE_IS_STUPID pragma to disable sanity on old code compiled with the new standard and plenty of others. Pick one, bless, it, implement it and FIX THIS CRAP http://opensource.apple.com/so... [apple.com] The 35th and 36th incidences of the words "goto fail;" in that file are the problem, not easy to spot until you look really closely and it's a bug that a sane standard would make impossible. FIX IT!!

Re:This is a C Standard Bug (2)

angel'o'sphere (80593) | about 8 months ago | (#46313203)

I never saw a bug related to braces, this bug neither is.
If at all the bug is (difficult to spot) because of a wrong indentation.
Bottom line the bug is absolutely obvious. You read the code from top to bottom and you see the bug, or you don't has nothing to do with braces or indentation.
It is the old C versus Python argument. The argument makes no sense. Either you can read the code and comprehend it or you cant.
No compiler, bracing or anything else can prevent it.

Re:This is a C Standard Bug (2)

ChunderDownunder (709234) | about 8 months ago | (#46314117)

You may claim the bug is obvious and yet it slipped through to production. So rather than bring up the blame-log on the indvidual developer - programmers make mistakes and enforcing coding standards such as indentation or braces help in identifying errors where errant coders fail.

If indeed Apple does have a coding standard, then this one slipped through. Using an IDE to pretty-print the code according to the coding standard, prior to checkin, would have revealed the inconsistency of indentation in the duplicated line. Of course performing a visual diff on the previous revision would likewise have exposed the flaw.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46314813)

The error causing this bug makes the function fail every single time it's run. This isn't the sort of thing where braces should matter, this is a catastrophic failure of overall production procedures. How could they not have any goddamn unit tests? Even if they're too cheap for that, why wasn't there even a "Hey, let me try this just once before we ship it?" It's pathetic, especially considering this is in security.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46315879)

This. I wish I knew this a while ago when an interviewer told me their engineers could be working for Apple. Back then I only thought huh? I'd have a good laugh now.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46314815)

If at all the bug is (difficult to spot) because of a wrong indentation.

Indentation is a human thing, the compiler ignores it (just like pretty-much all whitespace).

And therein lies the problem: A representation to which its parsing differs between humans and compilers.

Bottom line the bug is absolutely obvious.

See the above human v.s. compiler difference, and you may understand that "obvious" isn't the correct word for it.

... unless you find it "normal" that you ignore, while reading such code, standard human parsing in favour of whatever parsing your current compiler uses.

... but than why are you using indentation at all ?

So no, its not an indentation problem, its an expectation problem, with the compiler not having the first clue of what its is you are expecting. Something that could well be mitigated by enforcing those brackets others have mentioned, so that humans and compilers see the same thing.

Personally I contract such "if" ... constuctions to be on the same line, conventions be damned.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46314819)

I've seen bugs related to a lack of braces, in my own code, too. But much like rm -fr / as root, it's a mistake you only make once, and usually very early in your career, or preferably before or outside your career.

There's no end to stupid mistakes you can make. Like inverting a boolean condition, which could be extremely difficult if not impossible for a static analyzer to find in the general case. This is an issue with experience. If you're a budding programmer, code and code and code as much as you can, pushing your limits, so you can shake your bugs out, literally and figuratively.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46313223)

Or at least a compile-time warning. I definitely agree nonetheless.

Yeah, I've been ridiculed for insisting on always using braces by "smarter" people than me...

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46313233)

If you can't write an if statement correctly, it's not the fault of the standard, it's your fault. GO FIX YOURSELF, STUPID MORON.

Re:This is a C Standard Bug (1)

Anonymous Coward | about 8 months ago | (#46313251)

This same argument can be made about all kinds of things that compilers warn about. But yet, compilers warn. Why? Because any competent programmer will admit that they are not perfect, and use every tool they can to help prevent their own mistakes. At least an option to warn about missing braces like this would help avoid silly mistakes like this that *do* creep into code.

Re:This is a C Standard Bug (1)

Your.Master (1088569) | about 8 months ago | (#46313615)

Your argument isn't working. In the wild, iOS and OSX have been exploited because somebody failed to notice this error. This is a thing that actually happened. Doesn't really matter whose fault it is and if they are all morons, what matters is whether we can we make it less likely.

I would propose that a Python-like static analyser might be able to catch this sort of thing, provided you don't get too fancy with macros. The fact is, virtually everybody has standardized on indentation for if statements as a readability boon, even in the vast majority of languages which use explicit symbols rather than indentation to make code blocks. So I kind of think that the indentation should have the meaning we are already ascribing to it. It's one of the things Python does right.

This of course brings back the tabs vs. spaces religious wars. To which I say, pick one model for your project and enforce it statically, and I recommend that model be some number of spaces. There's just too little benefit in adding complication like extra varieties of whitespace, or indentation that is usually meaningful but sometimes misleading, etc. (especially when a text editor could just treat every eg. 4 leading spaces on a line as a "pseudo-tab" for display purposes anyway if your panties really get in a twist about configurable column-spacing).

I can understand that this code that I just made up now* never actually prints "Fridays are the best", but surely you can see that it appears to, right? And I'd say that as much as possible, we should enforce that code runs the way it looks like it should run:

void StupidExampleFunction(){
        for(day=0;day<7;day++){
                if(day==1) printf("Mondays are the worst :(");}
                if(day==5) printf("Fridays are the best!");{
        }
}

Obviously this is poorly written code, but I think you can see how mistakes can creep in because we've essentially assigned meaning to things that aren't actually syntax, which is misleading when it doesn't align with the actual syntax.

*I didn't actually compile it so there may very well be a syntax error or something, but I think you see what I'm getting at. Also, on languages that do have curly braces I like them each on their own line to make it trivially easy to pair them up so that mistakes like this are nearly impossible.

Re:This is a C Standard Bug (1)

Anonymous Coward | about 8 months ago | (#46314091)

So use a fucking editor that indents things correctly (ie. not Emacs or Vi). You would literally never have these sorts of errors if your editor doesn't allow free-form indentation. You are editing a program, not free-form text, there is absolutely no excuse for freeform indentation outside of comments, and even there it is generally bad form.

Re:This is a C Standard Bug (2)

wiredlogic (135348) | about 8 months ago | (#46313293)

Lint tools can catch this sort of unconditional goto which one would hope is never used intentionally by goto afficionados.

Re:This is a C Standard Bug (1)

ChunderDownunder (709234) | about 8 months ago | (#46314119)

Compiler warnings or source code analysis tools are often ignored though, sadly, as an afterthought or distraction.

Re:This is a C Standard Bug (1)

loufoque (1400831) | about 8 months ago | (#46315375)

I am a member of the C and C++ standards committees. I'm sorry to tell you your proposal is inane, and were it to come up I wilk veto it.

Re:This is a C Standard Bug (0)

Anonymous Coward | about 8 months ago | (#46315667)

I'm okay with it if you want to continue to be part of the problem, cowboy.

But this ain't the 80's any more and languages should deprecate features
that provide convenience without functionality, especially when there is
overwhelming evidence that those features can harm the language.

It happened before in C with the =+ vs. += and the "right" thing was done.
If I'm talking over your head, just re-read what I've written, slowly this time.

I cannot think of a single coding instance where not typing an extra 2 characters
makes anything better in the final product; and I've fixed more bugs do to this
than I care to remember...

CAP = 'murder' which I have no intention of doing!!! :)

Breaking NEWS about Apple!!!!!!! (-1)

Anonymous Coward | about 8 months ago | (#46313213)

Tim Cook's bladder is full! Can he hold it or will he piss himself?!!?!!?!?!?!! Slashdot must report on this dilemma! immediately!!!

How does this work? (1)

willoughby (1367773) | about 8 months ago | (#46313277)

So how does "Researcher Adam Langley" get access to the code in order to do "an analysis of the vulnerable code in OS X"?

Do these experts have access to the source via some agreement with the vendor?

Re:How does this work? (1)

Anonymous Coward | about 8 months ago | (#46313353)

opensource.apple.com

Re:How does this work? (2, Insightful)

Anonymous Coward | about 8 months ago | (#46313357)

No.
Just access:
http://opensource.apple.com/so... [apple.com]

So I guess that it can have been exploited for some time.

Re:How does this work? (0)

Anonymous Coward | about 8 months ago | (#46313719)

It just works.

in other words (0)

Anonymous Coward | about 8 months ago | (#46313375)

APPLE DOESN'T TEST THEIR SECURITY CODE

I'm yelling because it's really a big deal.

Re:in other words (1)

profplump (309017) | about 8 months ago | (#46313819)

Because bugs exist testing must not?

Re:in other words (0)

Anonymous Coward | about 8 months ago | (#46314077)

Look at the code, a signature will never fail. That means Apple never tried feeding it a bad certificate. Their release process apparently doesn't include even the most basic sanity checks on critical security code that the integrity of the entire system relies upon.

Re:in other words (0)

Anonymous Coward | about 8 months ago | (#46314131)

The fun part is, this shit is FIPS certified too.

Re:in other words (0)

Anonymous Coward | about 8 months ago | (#46315115)

|s that like the Microsoft Certified System Administrator certificate my mom said I had to get or I couldn't stay in her basement anymore?

I wasn't going to say it but.. (0)

Anonymous Coward | about 8 months ago | (#46313393)

I am forced to switch to Crome because of this and now I'm reading Slashdot Beta. FFFFFUCK BETA!!

Test fail (1)

manu0601 (2221348) | about 8 months ago | (#46314011)

At mine, the test site at https://www.imperialviolet.org:1266/ [imperialviolet.org] does not even load. Firefox says:

Secure Connection Failed An error occurred during a connection to www.imperialviolet.org:1266. A PKCS #11 module returned CKR_DEVICE_ERROR, indicating that a problem has occurred with the token or slot. (Error code: sec_error_pkcs11_device_error)

Re:Test fail (1)

mattr (78516) | about 8 months ago | (#46314093)

I get
The webpage at https://www.imperialviolet.org... [imperialviolet.org] might be temporarily down or it may have moved permanently to a new web address.
Error code: ERR_FAILED

Re:Test fail (0)

Anonymous Coward | about 8 months ago | (#46315153)

Try gotofail.com [gotofail.com] .

Obligatory (0)

PNutts (199112) | about 8 months ago | (#46314231)

"You're bracketing it wrong."

GOTO??? (0, Flamebait)

Anonymous Coward | about 8 months ago | (#46314483)

Goto in a modern program... really? Hasn't the world pretty much come to the conclusion, since the invention of structured programming, that "goto" should be avoided. Every programming class I have ever taken I have been told to never use goto. Did Apple not get the memo?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?