or Connect
AppleInsider › Forums › Mobile › iPhone › How Apple dodged the Heartbleed bullet
New Posts  All Forums:Forum Nav:

How Apple dodged the Heartbleed bullet

post #1 of 65
Thread Starter 
In 2011, Apple told its developers that it would be deprecating OS X's Common Data Security Architecture including OpenSSL, describing it as an outdated relic of the late 1990s. Nearly three years later, OpenSSL was hit by a severe flaw that affected a wide swath of vendors and their users, but not Apple.

Heartbleed


When it announced plans to deprecate OpenSSL in June 2011, Apple wasn't aware of the Heartbleed flaw because it didn't yet exist. However, the company was aware of other problems with OpenSSL (libcrypto), a security toolkit Apple began using within the Common Data Security Architecture more than a decade ago.

CDSA, according to the Open Group that designed it, "is a set of layered security services and cryptographic framework that provide an infrastructure for creating cross-platform, interoperable, security-enabled applications for client-server environments is an architecture."

Apple incorporated support for CDSA and OpenSSL in its early development of Mac OS X. In 2004, Apple was recommending that Mac developers adopt CDSA, noting that it "will improve the overall performance of the system by reducing the number of libraries that frameworks link against to do cryptography."

As the company noted in its Mac security documentation from a decade ago, "CDSA is an Open Source security architecture adopted as a technical standard by the Open Group. Apple has developed its own Open Source implementation of CDSA, available as part of Darwin at Apple's Open Source site. This API provides a wide array of security services, including fine-grained access permissions, authentication of users' identities, encryption, and secure data storage."

Apple builds its own security architecture



By at least 2006 however, Apple began working on a new cryptography API for the future, designed to use less code, run faster and support concurrent use of multiple processors. These features were not only necessary for future Macs, but would also be critically important to iOS. Apple began working on a new cryptography API for the future, designed to use less code, run faster and support concurrent use of multiple processors

The desire to build a streamlined, modern security architecture was also driven by a need for FIPS 140-2 validation, required to sell devices to a variety of U.S. government agencies. As sales of iPhone and later iPad began to explode, Apple's efforts to address a robust alternative to the outdated CDSA took on new urgency.

The first step was Common Crypto, a low level C framework supporting core encryption algorithms Apple first released for OS X 10.5 Leopard in 2007 and later brought to iOS 5 in 2011. Apple has continued to work on making low level crypto functions easier for developers to use.

That includes Apple's OS X Security Transforms package, which is deeply integrated with Grand Central Dispatch to enable pipelines of data (including encryption tasks) to be spread out across available processors. It also supports hardware acceleration of crypto functions on modern processors like Intel's Core i5 and i7.

Apple deprecates CDSA & OpenSSL



By 2011, Apple was ready to deprecate CDSA, noting to developers at its WWDC event that the architecture was based on an Open Group standard that few other vendors supported besides Apple, and included lots of features nobody actually used. That required Apple to assume and manage a lot of complex external issues without any real cross-platform benefit.

"CDSA has its own standard programming interface, it is complex and does not follow standard Apple programming conventions," the company noted to its developers in Mac security documentation. iOS never incorporated CDSA, and both OS X and iOS "include their own higher-level security APIs that abstract away much of that complexity."

Building its own security software meant that Apple and its developers were no longer captive to the external development issues and eccentricities related to the OpenSSL open source project, which despite its critical importance and broad use by the industry, was being funded through donations and was, incredibly, maintained by a very small team of just four core developers."OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged "

"Although OpenSSL is commonly used in the open source community," Apple stated in its documentation, "OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.

"If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API."

Apple's concern about OpenSSL lacking a "stable API from version to version" relates to the complications it would face in trying to update or patch security flaws in the open source software package in a way that wouldn't break third party apps wired to a previous version of OpenSSL. Deprecating OpenSSL in favor of its own software meant that Apple had greater control in managing its own platform.

A broad variety of vulnerabilities in Apple's OS X software have actually related to outside software that Apple has bundled with its own, including both open source software packages and third party commercial components like Adobe Flash.

Heartbleed hits OpenSSL



Apple's timing proved to be fortuitous. Just six months after Apple officially deprecated OpenSSL, the Heartbleed flaw was inadvertently introduced in OpenSSL via a Heartbeat feature designed to keep secure connections alive and active. The flawed Heartbeat feature was included in the following March 2012 release of OpenSSL, and enabled by default.

While Apple had been advising its Mac and iOS developers to use other software before the bug had ever been introduced and never distributed the subsequent versions of OpenSSL that incorporated the security flaw, much of the rest of the industry had been standardizing on the latest, freely available version of OpenSSL.

More than two years later, a researcher at Google discovered that the OpenSSL Heartbeat feature was flawed, potentially allowing a malicious user to "bleed" data from a server using an affected version of OpenSSL, and possibly even recover security keys that could be used to spy on intercepted streams of encrypted data. Client software affected by Heartbleed could also be exploited by a malicious server.

"Servers vulnerable to Heartbleed are less secure than they would be if they simply had no encryption at all," noted a report by The Guardian

According to a report by Brendan Sasso of the National Journal, Google began work on addressing the flaw internally without telling anyone else about it, not even the U.S. government, which ostensibly wasn't aware of the vulnerability until Google first disclosed it on April 1 via the company's Google Plus social network.

A timeline compiled by Ben Grubb of the Sydney Morning Herald indicates that various firms over the next week battled both for publicity and against public disclosure of the Heartbleed flaw, with security companies seizing upon it as a way to make a name for themselves, and those affected scrambling to address the problem before they and their clients could be exploited by third parties armed with the same knowledge.

The perceived advantage of open software being innately more secure through broad use and exposure to more eyeballs ran into the reality of disadvantages involved with broad industry reliance upon a widely distributed monoculture of software developed by relatively few people who didn't necessarily share the same design goals as their broad spectrum of users (including that lack of interest in maintaining API compatibility).

A flaw in Apple's own code



Apple and its Mac and iOS users weren't affected by Heartbleed, but just weeks before, the company had been hit by a similar vulnerability related to a flaw in Apple's own code, which just happened to also be related to SSL certificate based security.

In Apple's case, the flaw, branded as "GoToFail," related to code the company maintained itself, although like OpenSSL, Apple's code had also been published as open source. As with OpenSSL, merely being open to eyeballs didn't result in Apple's code being free of undiscovered flaws.

Apple was condemned in a series of posts laced with profanity for patching iOS first (before GoToFail was publicly known about) and not releasing a patch for OS X until three days later.

In contrast, it took a week for the various parties involved in Heartbleed to even coordinate its disclosure, with embargo leaks informing some clients, including OpenSSL, Akamai and Facebook as much as several days before the general public and even major companies including Cisco, Dropbox, Juniper, Twitter, Ubuntu and Yahoo.

Another security flaw, similarly affecting network security, was identified in Android's WebView 16 months ago. While much more serious in that it provided full control of a device to remote malicious users and had functional tools available that allowed virtually anyone to exploit the flaw, roughly 75 percent of Android devices appear to remain vulnerable.
post #2 of 65
"The perceived advantage of open software being inanely more secure..."

Wonderfully apt misspelling.
post #3 of 65
It's funny how there doesn't seem to have been any review at all of either the goto fail or heart bleed. Not internal nor external. Not a unit nor integration test.
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #4 of 65
I know this sounds naïve. But this is why I trust and love Apple!

I remember when Apple shitcanned flash for iOS and when Steve was giving a Keynote and said Adobe always opens slowly. I deleted Adobe photo elements because of that reason and I decided just to stay with Apple software even though it was flawed at times. Eg. MobileMe, early Pages, Apple Mail, Notes on iOS, no cut and paste on first iPhone, Maps, etc. even with the minimal flaws, the interrelation between Mail, iPhoto, iWeb and OSX and iOS was so superior to anything MS or Google were slapping together!
post #5 of 65
"Open source = security" fans aren't fuming about this, they're defensive. Their usual FUD retort is: "but but but who knows how many security holes lurk in private code?"

Well now you can argue the same about open source. Who knows? Because the OpenSSL users didn't, for two years.

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply

"Apple should pull the plug on the iPhone."

John C. Dvorak, 2007
Reply
post #6 of 65
Quote:
Originally Posted by asdasd View Post

It's funny how there doesn't seem to have been any review at all of either the goto fail or heart bleed. Not internal nor external. Not a unit nor integration test.

 

There doesn't seem to be any thing going on at Apple: no innovation, no reviews of security issues... oh wait, maybe because its internal.

post #7 of 65
I propose a toast to the team of developers at Apple who developed its in-house security layers. It probably wasn't the most glamorous project to be on, but based on recent events it certainly turned out to be one of the most important ones.

Cheers everyone!
post #8 of 65
Quote:
Originally Posted by Suddenly Newton View Post

"Open source = security" fans aren't fuming about this, they're defensive. Their usual FUD retort is: "but but but who knows how many security holes lurk in private code?"

Well now you can argue the same about open source. Who knows? Because the OpenSSL users didn't, for two years.

One of the primary reasons Apple gives for using open-source solutions is "Open Source methodology makes Mac OS X a more robust, secure operating system, as its core components have been subjected to the crucible of peer review for decades. Any problems found with this software can be immediately identified and fixed by Apple and the Open Source community."

Pretty shocking when a big ol' rock like this pops out of the ground after two years.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #9 of 65
Quote:
Originally Posted by Corrections View Post

There doesn't seem to be any thing going on at Apple: no innovation, no reviews of security issues... oh wait, maybe because its internal.

Ridiculous sneer. The goto bug was clearly visible in code and should have been caught in one of a unit, integration or general user tests. The latter being as simple as just trying a bad cert in safari. See if that worked.

The OpenSSL bug seems to have been submitted without review or unit test but it was a big addition in functionality. One guy wrote it nobody seemed to review it, it was built into a final product and half the world picked it up.

Ok most people are not security experts but that's insane. Probably all this works at too low a level for most devs.

In general this was a good article though. I think open source is largely a crock unless there are serious paid engineers behind it. Otherwise it's amateur hour.
Edited by asdasd - 4/18/14 at 1:06pm
I wanted dsadsa bit it was taken.
Reply
I wanted dsadsa bit it was taken.
Reply
post #10 of 65

Sounds like Apple was being more proactive than dodging any kind of bullet.  Kudos to them!  Of course, one doesn't hear anything in the news that would ever put Apple in a positive role.  

post #11 of 65
Quote:
Originally Posted by sgk77 View Post

I propose a toast to the team of developers at Apple who developed its in-house security layers. It probably wasn't the most glamorous project to be on, but based on recent events it certainly turned out to be one of the most important ones.

Cheers everyone!

I agree. Very good of u to say! 1smile.gif
Edited by christopher126 - 4/18/14 at 1:47pm
post #12 of 65
Quote:
Originally Posted by sflocal View Post
 

Sounds like Apple was being more proactive than dodging any kind of bullet.  Kudos to them!  Of course, one doesn't hear anything in the news that would ever put Apple in a positive role.  

Thankfully we have sites like AI, so everything that Apple does is put in a positive role.

post #13 of 65
Quote:
Originally Posted by Suddenly Newton View Post

"Open source = security" fans aren't fuming about this, they're defensive. Their usual FUD retort is: "but but but who knows how many security holes lurk in private code?"

Well now you can argue the same about open source. Who knows? Because the OpenSSL users didn't, for two years.

 

I don't know anyone who would say open source = security (If anyone does I've got some free open source software I can give them!) But open source does equate to transparency, which it seems (counterintuitively enough) is a prerequisite to verifiable security. Clearly Apple thinks so.

post #14 of 65
Quote:
Originally Posted by asdasd View Post


Ridiculous sneer. The goto bug was clearly visible in code and should have been caught in one of a unit, integration or general user tests. The latter being as simple as just trying a bad cert in safari. See if that worked.

The OpenSSL bug seems to have been submitted without review or unit test but it was a big addition in functionality. One guy wrote it nobody seemed to review it, it was built into a final product and half the world picked it up.

Ok most people are not security experts but that's insane. Probably all this works at too low a level for most devs.

 

This is entirely false. The OpenSSL Heartbeat component was submitted with review and had many tests written against it - and albeit that bug remained consistent throughout, you can't test every possible scenario until they arise or have been thought of ahead of time. Unfortunately, this goes to show how hard a programmers job is, and that nothing is full proof, and no matter how obvious, problems can be masked and overlooked. We all make mistakes regardless of environment and sometimes those mistakes slip through the cracks. 

post #15 of 65
Google kept Heartbleed secret for over a week and no one is giving sh*t to them. They're f'n evil!
post #16 of 65
Quote:
Originally Posted by bighype View Post

Google kept Heartbleed secret for over a week and no one is giving sh*t to them. They're f'n evil!

According to the original report of the flaw "This bug was independently discovered by a team of security engineers (Riku, Antti and Matti) at Codenomicon and Neel Mehta of Google Security, who first reported it to the OpenSSL team. Codenomicon team found heartbleed bug while improving the SafeGuard feature in Codenomicon's Defensics security testing tools and reported this bug to the NCSC-FI for vulnerability coordination and reporting to OpenSSL team."

"Immediately after our discovery of the bug on 3rd of April 2014, NCSC-FI took up the task of verifying it, analyzing it further and reaching out to the authors of OpenSSL, software, operating system and appliance vendors, which were potentially affected. However, this vulnerability had been found and details released independently by others before this work was completed. Vendors should be notifying their users and service providers. Internet service providers should be notifying their end users where and when potential action is required."

http://heartbleed.com/
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #17 of 65
Quote:
Originally Posted by Nobodyy View Post
 

 

This is entirely false. The OpenSSL Heartbeat component was submitted with review and had many tests written against it - and albeit that bug remained consistent throughout, you can't test every possible scenario until they arise or have been thought of ahead of time. Unfortunately, this goes to show how hard a programmers job is, and that nothing is full proof, and no matter how obvious, problems can be masked and overlooked. We all make mistakes regardless of environment and sometimes those mistakes slip through the cracks. 

 

OpenSSL is written by monkeys

post #18 of 65
Quote:
Originally Posted by Gatorguy View Post

One of the primary reasons Apple gives for using open-source solutions is "Open Source methodology makes Mac OS X a more robust, secure operating system, as its core components have been subjected to the crucible of peer review for decades. Any problems found with this software can be immediately identified and fixed by Apple and the Open Source community."

Pretty shocking when a big ol' rock like this pops out of the ground after two years.

Apple not wanting to use OpenSSL because they wanted a modern security architecture doesn't mean they are hypocritical about supporting open source. The statement you quote from their list page of open source SW in Mac OS X in no way violates that claim that open source can be a powerful tool.

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply
post #19 of 65
Quote:
Originally Posted by SolipsismX View Post

Apple not wanting to use OpenSSL because they wanted a modern security architecture doesn't mean they are hypocritical about supporting open source. The statement you quote from their list page of open source SW in Mac OS X in no way violates that claim that open source can be a powerful tool.

Don't think anyone implied they were being hypocritical.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #20 of 65
Quote:
Originally Posted by capasicum View Post
 

 

OpenSSL is written by monkeys

http://www.quora.com/Whose-fault-is-the-Heartbleed-bug

 

I think the answers here, and specifically the first, generally reflect my feelings about this. 

post #21 of 65
Quote:
Originally Posted by Gatorguy View Post

Don't think anyone implied they were being hypocritical.

My bad. I thought you were quoting those two lines from their two paragraph statement about open source because it said "Open Source […] makes Mac OS X a more […] secure operating system" and that it's easier to fix.

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply
post #22 of 65
Quote:
Originally Posted by Nobodyy View Post
 

http://www.quora.com/Whose-fault-is-the-Heartbleed-bug

 

I think the answers here, and specifically the first, generally reflect my feelings about this. 

"You could blame the author, but he did this work for free, for the community, and with the best of intentions."

 

Well, the road to hell is paved with good intentions.

 

I believe open source to be the correct way of developing and distributing software. But I do not believe in working for free. And I do not accept apologetic nonsense such something being done "for free". That's exactly where the GPL bullshit becomes intense.

 

The Free Software Foundation pays salaries to a lot of people, including Linus Torvalds. Why are they incapable of funding projects of such significance and importance? Torvalds drives a Mercedes, those guys work for free. It seems to me that the FSF brings social inequality to a whole new level - select few take the money, the rest work for free. In the past even slaves were fed by their masters, you know ...

post #23 of 65
Quote:
Originally Posted by SolipsismX View Post

My bad. I thought you were quoting those two lines from their two paragraph statement about open source because it said "Open Source […] makes Mac OS X a more […] secure operating system" and that it's easier to fix.

Gotcha and no prob. I posted that to SuddenlyNewton to note that Apple too considers open-source solutions to generally be secure for the stated reasons. Then something like like Heartbleed pops up to call those supposed security advantages into question.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #24 of 65

Does anyone know if Apple is using OS X as their primary ecommerce solution. They were using webobjects at one point but I don't see many references to that platform anymore. I wonder if they are using some other flavor of UNIX which does use OpenSSL but they were either using the older version which was not vulnerable or they were quick on the patch of the new one. In their data centers, I really doubt they are running OS X, but just a speculation on my part. OS X may be safe but are Apple's servers actually running OS X?

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #25 of 65
Quote:
Originally Posted by capasicum View Post
 

The Free Software Foundation pays salaries to a lot of people, including Linus Torvalds. Why are they incapable of funding projects of such significance and importance?

Because OpenSSL is NOT "Free"(as in Freedom) Software. It is merely Open Source, which is not the same as Free Software. Stallman and the FSF have made it clear that the two are different(in their opinion). Here and Here.

 

OpenSSL is dual licensed under an Apache and 4 clause BSD license.  You want "Free" transport layer security? Here is GnuLTS.

 

Personally I think it's silly of them, but that is their official stance.

post #26 of 65
Quote:
Originally Posted by Gatorguy View Post


One of the primary reasons Apple gives for using open-source solutions is "Open Source methodology makes Mac OS X a more robust, secure operating system, as its core components have been subjected to the crucible of peer review for decades. Any problems found with this software can be immediately identified and fixed by Apple and the Open Source community."

Pretty shocking when a big ol' rock like this pops out of the ground after two years.

Why does this bug make that quote "shocking"?  Even if it's not always true in practice, open source code certainly has the potential to be more secure than closed-source code. Actually what's probably more accurate is:  *well-funded* open source projects (e.g. not OpenSSL) have the potential to be more secure than closed-source projects. 

 

Security isn't just about how many bugs there are in a codebase; it's also about how quickly a project responds to the discovery of bugs. The main effect of the source code being publicly available is to enable researchers to pin down the precise lines of code responsible for bugs and therefore speed up the patching process. In the case of Heartbleed, the security researchers not only reported the problem to OpenSSL but also contributed the patches (http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902), which were rolled out the same day the flaw was disclosed to the public.

post #27 of 65
Quote:
Originally Posted by d4NjvRzf View Post

Why does this bug make that quote "shocking"?  Even if it's not always true in practice, open source code certainly has the potential to be more secure than closed-source code. Actually what's probably more accurate is:  *well-funded* open source projects (e.g. not OpenSSL) have the potential to be more secure than closed-source projects. 

Security isn't just about how many bugs there are in a codebase; it's also about how quickly a project responds to the discovery of bugs. The main effect of the source code being publicly available is to enable researchers to pin down the precise lines of code responsible for bugs and therefore speed up the patching process. In the case of Heartbleed, the security researchers not only reported the problem to OpenSSL but also contributed the patches (http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902), which were rolled out the same day the flaw was disclosed to the public.

Thanks for the input. I'll rephrase then... I was shocked to find out SSL wasn't actually secure.
melior diabolus quem scies
Reply
melior diabolus quem scies
Reply
post #28 of 65
Quote:
Originally Posted by Gatorguy View Post

Thanks for the input. I'll rephrase then... I was shocked to find out SSL wasn't actually secure.

According to a recent thread on AI the solution is do absolutely nothing to protect your valuables because no security is guaranteed.

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply
post #29 of 65
Quote:
Originally Posted by SolipsismX View Post
 
According to a recent thread on AI the solution is do absolutely nothing to protect your valuables because no security is guaranteed.

I can only comment on our experience with upgrading our SSL servers, but the Windows 2012 upgrades have been very problematic. We were scoring "F" on all of our Server 2003 servers in terms of SSL security even though none were vulnerable to Heartbleed. Windows 2012 r2 is just a mess but I guess it is secure. More reports to follow.

Life is too short to drink bad coffee.

Reply

Life is too short to drink bad coffee.

Reply
post #30 of 65
I am curious as to why filemaker which is within the very blood of apple was on open sale and still is, and was hit too. Of course rather nastily by this. Patched. Up quickly of course, but nevertheless on the same boat with everyone outside apple. Strange...
post #31 of 65

The other thing about open source that a lot of people don't realise is that it's mostly developed by companies anyway, not some Utopian ideal of the citizenry spontaneously developing their own solutions. Look at the Linux commits, 75% from companies.  http://apcmag.com/linux-now-75-corporate.htm

Surprise, surprise most people want to get paid when they work.

post #32 of 65
Quote:
Originally Posted by Gatorguy View Post


One of the primary reasons Apple gives for using open-source solutions is "Open Source methodology makes Mac OS X a more robust, secure operating system, as its core components have been subjected to the crucible of peer review for decades. Any problems found with this software can be immediately identified and fixed by Apple and the Open Source community."

Pretty shocking when a big ol' rock like this pops out of the ground after two years.

 

Apple touts open source when it is convenient for them.

post #33 of 65
Quote:
Originally Posted by Haggar View Post

Apple touts open source when it is convenient for them.

As opposed to when it's inconvenient for them? Do you really expect any company to say, "We use open source code when we think it will make our products worse"? 1oyvey.gif

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply

This bot has been removed from circulation due to a malfunctioning morality chip.

Reply
post #34 of 65
Quote:
Originally Posted by Jexus View Post
 

Because OpenSSL is NOT "Free"(as in Freedom) Software. It is merely Open Source, which is not the same as Free Software. Stallman and the FSF have made it clear that the two are different(in their opinion). Here and Here.

 

OpenSSL is dual licensed under an Apache and 4 clause BSD license.  You want "Free" transport layer security? Here is GnuLTS.

 

Personally I think it's silly of them, but that is their official stance.

 

My bad for not checking the OpenSSL license. Thanks for fixing that up for me. Now my post looks a bit idiotic. Nevertheless, there are enough examples of idiocy on the part of FSF such as the GCC monolithic structure.

post #35 of 65
Actually, IMO, Apple's deprecation of OpenSSL means that Apple users face far *more* risk from Heartbleed than users of other operating systems. Although the version of OpenSSL that Apple shipped wasn't affected (because it is ancient), the official recommendation was that if developers required OpenSSL, they should link in their own copy as part of their app. This means:

1. All those apps are now affected because they didn't use Apple's old version.
2. Every app with its own OpenSSL library must be updated individually, unlike a system-installed library.

I don't know how many apps we're talking about here, but I doubt it's zero.
post #36 of 65
Quote:
Originally Posted by capasicum View Post
 

 

My bad for not checking the OpenSSL license. Thanks for fixing that up for me. Now my post looks a bit idiotic. Nevertheless, there are enough examples of idiocy on the part of FSF such as the GCC monolithic structure.

While LLVM/Clang is a better designed compiler, it's also quite a bit newer than GCC. It's easier to rewrite something from scratch when you have hindsight, and when you don't have the responsibility of supporting other projects. For instance, the Linux kernel relies on GCC-specific extensions to C and can only be compiled using GCC (see http://www.ibm.com/developerworks/linux/library/l-gcc-hacks/). At any rate, GCC's "monolithic structure" hasn't seemed to hinder its portability (http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Architectures). 


Edited by d4NjvRzf - 4/19/14 at 8:09am
post #37 of 65
Quote:
Originally Posted by Nobodyy View Post

This is entirely false.
No, "The latter being as simple as just trying a bad cert in safari. See if that worked." is just a fact.
Three other major mistakes where made: if you use a label named 'gotofail' it is assumed that this means certain failure, this wasn't the case and is very misleading, using curly brackets is essential in C and wasn't used and the compiler didn't report "unreachable code" so the build environment wasn't configured properly.
post #38 of 65
Quote:
Originally Posted by knowitall View Post

No, "The latter being as simple as just trying a bad cert in safari. See if that worked." is just a fact.
Three other major mistakes where made: if you use a label named 'gotofail' it is assumed that this means certain failure, this wasn't the case and is very misleading, using curly brackets is essential in C and wasn't used and the compiler didn't report "unreachable code" so the build environment wasn't configured properly.

I clearly state that I was talking about OpenSSL's Heartbeat, not the gotofail. Maybe if you had quoted my entire post you'd have seen that in the second sentence instead of jumping all over nothing.

But also, it's silly to call curly brackets essential 1wink.gif and while I understand that it contributed to the masking of the gotofail issue, it's hardly a mistake, just an alternative form. I agree with you otherwise on the other things, but like I said in my post, as all make mistakes and a programmers life is hard because of human error and logical thinking is very prone to it.
post #39 of 65
Quote:
Originally Posted by DESuserIGN View Post

I don't know anyone who would say open source = security (If anyone does I've got some free open source software I can give them!) But open source does equate to transparency, which it seems (counterintuitively enough) is a prerequisite to verifiable security. Clearly Apple thinks so.

Exactly this. The whole article bases itself on two assumptions:
- there are no other exceedingly bad bugs allowing injection in Apple's code, hence OSS is a worse method than closed source
- the fact Heartbleed is the worse bug of the two is not purely luck

It appears to me, both statements are unlikely to be true.
-

Social Capitalist, dreamer and wise enough to know I'm never going to grow up anyway... so not trying anymore.

 

http://m.ign.com/articles/2014/07/16/7-high-school-girls-are-kickstarting-their-awa...

Reply

Social Capitalist, dreamer and wise enough to know I'm never going to grow up anyway... so not trying anymore.

 

http://m.ign.com/articles/2014/07/16/7-high-school-girls-are-kickstarting-their-awa...

Reply
post #40 of 65
Quote:
Originally Posted by ascii View Post

The other thing about open source that a lot of people don't realise is that it's mostly developed by companies anyway, not some Utopian ideal of the citizenry spontaneously developing their own solutions. Look at the Linux commits, 75% from companies.  http://apcmag.com/linux-now-75-corporate.htm
Surprise, surprise most people want to get paid when they work.

That raises different issues, from a few orders of magnitude more complex than the ones raised (?) by the article ( is OSS really safer than closed source, and are the benefits of OSS offset by the unpredictability of API changes).
My take on closed source is clear, openness at least allows people to search for issues, even though whether they actually do is still their own responsibility, and as for unpredictability, Apple is not known for backward compatibility, which may or may not be a good thing.

All in all, your statement is true, but responding to it appropriately seems to require a few PHDs in sociology, economy and ethnology, and addressing the consequences would require conscious effort of our civilizations, which I am afraid is a bit unlikely.

Social Capitalist, dreamer and wise enough to know I'm never going to grow up anyway... so not trying anymore.

 

http://m.ign.com/articles/2014/07/16/7-high-school-girls-are-kickstarting-their-awa...

Reply

Social Capitalist, dreamer and wise enough to know I'm never going to grow up anyway... so not trying anymore.

 

http://m.ign.com/articles/2014/07/16/7-high-school-girls-are-kickstarting-their-awa...

Reply
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: iPhone
AppleInsider › Forums › Mobile › iPhone › How Apple dodged the Heartbleed bullet