[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
|
|
Subscribe / Log in / New account

OpenSSL after Heartbleed

OpenSSL after Heartbleed

Posted Apr 29, 2017 12:01 UTC (Sat) by pizza (subscriber, #46)
In reply to: OpenSSL after Heartbleed by citypw
Parent article: OpenSSL after Heartbleed

I'm not exactly a fan of the Linux Foundation, but that article makes a number of assertions that are completely unsupported by the record -- even if you take its references to the PaX forums as gospel.

Kees gets credit for the upstreaming work because... wait for it... it is a *ton* of work. The CII/LF is paying for that work, and their PR amounts to little more than "things are better now than before, thanks to this work we're sponsoring."

PaX/etc could have been the ones funded to do this work, and in the process received the credit they claim they deserve. But getting things into the mainline kernel requires an ability to play well with others, something that PaX/etc has repeatedly shown themselves to be utterly incapable of.


to post comments

OpenSSL after Heartbleed

Posted Apr 29, 2017 14:27 UTC (Sat) by citypw (guest, #82661) [Link] (10 responses)

> I'm not exactly a fan of the Linux Foundation, but that article makes a number of assertions that are completely unsupported by the record -- even if you take its references to the PaX forums as gospel.

What's wrong with the reference from PaX/Grsecurity forum just simply reveal the truth? Maybe you are ok with what LF's marketing PR. Those better-than-none PR doesn't make any sense because it's not true. If you think it does, plz check those exploitable kernel bugs( which can be "massive" exp) lately, e.g: CVE - CVE-2017-0358, CVE-2016-1583, CVE-2016-0728, CVE-2017-6074, CVE-2017-7184. PaX/Grsecurity can mitigate tons of exploits does make sense to me.

> But getting things into the mainline kernel requires an ability to play well with others, something that PaX/etc has repeatedly shown themselves to be utterly incapable of.

Is that really what you think? PaX team has been helping upstreaming PaX/Grsecurity in multiple features since the day 1.

OpenSSL after Heartbleed

Posted Apr 29, 2017 17:16 UTC (Sat) by flussence (guest, #85566) [Link] (7 responses)

>PaX team has been helping upstreaming PaX/Grsecurity in multiple features since the day 1.
Can you produce any examples? LKML posts, actual patch submissions, anything like that? Forgive me if I'm a little skeptical of a project with an absolutely abhorrent track record of shit-flinging in public.

OpenSSL after Heartbleed

Posted Apr 30, 2017 3:33 UTC (Sun) by citypw (guest, #82661) [Link] (6 responses)

> Can you produce any examples? LKML posts, actual patch submissions, anything like that?

Okidoki, I'm giving you one example here and you can confirm with Kees Cook who is one of main KSPP maintainers:

http://www.openwall.com/lists/kernel-hardening/2017/04/26/17

You can find a lot of evidences about PaX team helped upstreaming stuff in kernel-hardening mailinglist:

http://www.openwall.com/lists/kernel-hardening/

> Forgive me if I'm a little skeptical of a project with an absolutely abhorrent track record of shit-flinging in public.

KSPP is the "hero" to most ppl now and it's not the fact. KSPP was supposed to be a good example but everything is too late for now. Can PaX/Grsecurity users get the test patch back? If not, Linux foundation should pay for all of this. From our very "narrow" perspectives( both FLOSS supporter and security consultant), we made our point very clear already:

https://hardenedlinux.github.io/announcement/2017/04/29/h...

OpenSSL after Heartbleed

Posted Apr 30, 2017 17:02 UTC (Sun) by flussence (guest, #85566) [Link] (5 responses)

It sounds to me like there was infighting within grsecurity, one part of it is trying to be a good citizen and reduce their technical debt and another shuts the project down the next day.

Who knows, maybe if they got rid of the toxic elements early on they might be earning a profit today.

OpenSSL after Heartbleed

Posted May 1, 2017 3:58 UTC (Mon) by citypw (guest, #82661) [Link] (4 responses)

Ah, now it becomes problem of PaX/Grsecurity within? Seriously? As a security consultant who has been through endless nightmares in data center for years. I know the very simple truth: PaX/Grsecurity was the only option to those who concerned their security in the age w/o SMEP/SMAP[1], and it's still the most effective defense solution for now and IMOHO it's going to keep ahead of the industry in the future.

[1] Linux kernel mitigation checklist:
https://hardenedlinux.github.io/system-security/2016/12/1...

OpenSSL after Heartbleed

Posted May 1, 2017 12:47 UTC (Mon) by pizza (subscriber, #46) [Link] (3 responses)

It takes a special sort of someone to deny that PaX/grsec's "woes" have a very strong self-inflicted component to them.

Meanwhile, As a SecurityConsultant(tm) you should also know well that outside of the likes of Nuclear weapons, security does not trump all other considerations, and that if grsec was integrated into the Linux kernel tomorrow and every single device updated to use it the day after, it wouldn't make but a small dent in the tide of data breaches, wouldn't have mitigated the likes of heartbleed or shellshock, nor would it prevented the growing pile of botnets running on the trashware we collectively call the IoT -- hardcoded backdoors, anyone?

....What good is a heavily-reinforced steel door to your house if you just leave all your valuables lying on the ground outside?

OpenSSL after Heartbleed

Posted May 2, 2017 2:51 UTC (Tue) by citypw (guest, #82661) [Link] (2 responses)

I trust PaX/Grsecurity only because they have a very good records. Speaking of IoT botnet or the evil things hide behind the surfaces, we've been working on core infrastructure protection for data center and been through a long-term study, observe and test and then finally figured that all I can tell is PaX/Grsecurity is the crucial building block of the defense-in-depth in the situational hardening solution. You can take a glance at the slide if u're interested although it doesn't contain much details;-):

https://github.com/hardenedlinux/hardenedlinux_profiles/b...

S0rry I'm very practical about security. I wouldn't believe what media/LF/CII bragging about how they are going to improve security in next years if you just see what they've done in past decade. Programmer will make mistakes and introduce more bugs. That's the simple reason why we need mitigation. Fortunately, PaX/Grsecurity is the most effective mitigation we had.

I don't have the problem with upstreaming stuff. How can you explain to the customers about those "massive" exploits defeated KSPP just in a couple of months?

https://lwn.net/Articles/721381/

OpenSSL after Heartbleed

Posted May 2, 2017 10:55 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> How can you explain to the customers about those "massive" exploits defeated KSPP just in a couple of months?

What does this have to do with OpenSSL/Heartbleed and grsec's utter inability to mitigate it or its effects?

> S0rry I'm very practical about security.

FWIW, you have yet to actually demonstrate this.

OpenSSL after Heartbleed

Posted May 2, 2017 14:14 UTC (Tue) by citypw (guest, #82661) [Link]

>> How can you explain to the customers about those "massive" exploits defeated KSPP just in a couple of months?
> What does this have to do with OpenSSL/Heartbleed and grsec's utter inability to mitigate it or its effects?
You didn't answer the question. Btw, I never said PaX/Grsec could mitigate Heartbleed-like issue. Speaking of OpenSSL, I think the media drew your attention on what they want you to see. I was an OpenSSL/GnuTLS maintainer for OpenSuSE/SLES for a while and I know( even I'm not good at crypto stuff) there are potentially bigger impact from some vulns has to be audited and then formed as part of security baseline in some data center. You can google it if your country don't block it though.

>> S0rry I'm very practical about security.
> FWIW, you have yet to actually demonstrate this.
Oh, this is so hard that I can't desmonstrate it. You win, congrats;-)

OpenSSL after Heartbleed

Posted Apr 29, 2017 19:54 UTC (Sat) by pizza (subscriber, #46) [Link] (1 responses)

> Those better-than-none PR doesn't make any sense because it's not true.

I'd be careful about making that argument that "better than nothing" is worthless -- because it applies equally to PaX if you don't turn on every feature it supports.

"All or nothing" (especially when combined with "my way or the highway") is not how anything has _ever_ been merged into mainline Linux.

> Is that really what you think? PaX team has been helping upstreaming PaX/Grsecurity in multiple features since the day 1.

Given that assertion is directly contradicted by PaX's own words on LWN, I'm going to have to respond with [citation needed].

OpenSSL after Heartbleed

Posted Apr 30, 2017 0:17 UTC (Sun) by PaXTeam (guest, #24616) [Link]

> Given that assertion is directly contradicted by PaX's own words on LWN[...]

[citation needed] ;)

OpenSSL after Heartbleed

Posted Apr 30, 2017 0:19 UTC (Sun) by PaXTeam (guest, #24616) [Link] (11 responses)

> The CII/LF is paying for that work
[citation needed]

> something that PaX/etc has repeatedly shown themselves to be utterly incapable of.

[citation needed]

OpenSSL after Heartbleed

Posted Apr 30, 2017 14:17 UTC (Sun) by pizza (subscriber, #46) [Link] (10 responses)

> [citation needed]

A quick google search for "PaX' site:LWN" came up with this thread from a couple years back:

https://lwn.net/Articles/663591/

There's links in there to several primary sources as well, so it's not just "he said she said" in LWN comments.

If one expands the search to include 'spender' many more results show up -- including this gem in which, inbetween quite a bit of poo slinging, he unequivocally states that he will never accept LF funding:

https://lwn.net/Articles/706310/

All in all, those Google searches produce a substantial body of evidence of "not playing well with others" (and as an added bonus, also strongly implies that the LF is funding Kees' mainlining work. I admit to not trying to fact-check that, but I wasn't the one who made the initial claim..)

OpenSSL after Heartbleed

Posted Apr 30, 2017 16:30 UTC (Sun) by PaXTeam (guest, #24616) [Link] (9 responses)

i can't find anything at those links that show that "The CII/LF is paying for that work" or that we're 'utterly incapable of' playing with others. care to cite specific examples? i'd also point out that the LWN comment section isn't exactly the typical playground for software development, you should probably look around at various kernel and other mailing lists, bugzillas, etc as well.

OpenSSL after Heartbleed

Posted Apr 30, 2017 18:36 UTC (Sun) by flussence (guest, #85566) [Link] (2 responses)

>i'd also point out that the LWN comment section isn't exactly the typical playground for software development
One of LWN's biggest draws is it contains a treasure trove of Linux history, culture and politics spanning decades that can't be “selectively enhanced” by PR firms or narcissists in the way social media, Wikipedia, or Amazon product reviews can.

That means the good posts are all genuine; the nasty ones are also genuine; and someone with years of obnoxious nitpicking and obtuseness to their name doesn't get to shrug it off by doubling down on feigned ignorance and playing innocent, when results 1 to 150 of 1020 say otherwise.

And because of the immutability and high signal to noise ratio, someone can use this site as a reliable point of reference (or refer their higher-ups to it, if they aren't already reading) when deciding whether to contribute {time,money,word-of-mouth} to a project, or to leave it for the people in hazmat suits to deal with.

OpenSSL after Heartbleed

Posted Apr 30, 2017 22:56 UTC (Sun) by amacater (subscriber, #790) [Link]

This comment from flussence has to be one of *THE* reasons for subscribing to LWN, urging others to subscribe, sharing the occasional free link to show others the quality here.

Independence, quality - and an archive that doesn't forget - absolutely indispensable.

OpenSSL after Heartbleed

Posted May 1, 2017 0:49 UTC (Mon) by PaXTeam (guest, #24616) [Link]

> someone with years of obnoxious nitpicking and obtuseness to their name doesn't get to shrug it off by doubling down on feigned ignorance and playing innocent[...]

to be honest, i didn't expect you to practice self-criticism, but hey, maybe you're able to behave better in the future. that said, you didn't answer my questions either...

OpenSSL after Heartbleed

Posted May 5, 2017 2:05 UTC (Fri) by tytso (subscriber, #9993) [Link] (5 responses)

As far as I know, the LF/CII is not paying for Kees Cook's work. There are a large number of engineers who are working on the Kernel Self Protection Project, and many of them are sponsored by the employers to do so as part of their day job. To the extent that many of these companies happen to be members of the Linux Foundation is really besides the point. Each of these companies have made their own, rational decision that it is in their best interest to collaborate together to make the upstream kernel better with respect to security.

Similarly, a few words about how the CII works. The CII was fundamentally about large companies getting together to donate money into a common pot to help fund work, that couldn't be done by various member company's own engineers. Again, each of the companies decided that it was in their own self-interest to fund work to make Linux and its core infrastructure more secure. This is probably why you didn't hear back from the LF as a small company. It wasn't worth their time to accept small change funding, when the same amount of time could be used to work with a company who was interested in donating half a million dollars or more.

I suspect that if you took a look at the amount of work that is being done by the KSPP, a very large amount of it is being done by engineers who are funded by their companies to work on these features. More importantly, whether these companies are helping the KSPP by assigning engineers to work on it, or by paying contractors to do various bits of works, what's important is this is simply _more_ security work to make Linux better. It is not within the Linux Foundation's power, or any corporate entity's power, to stop work being done by a volunteer or by an engineer working for another company.

What they _can_ do is work together on a solution that is good enough such that interest in supporting a more proprietary solution is decreased. This may be what is going on with grsecurity; as other says, I don't have enough transparency into the motivations of why grsecurity did what it chose to do. But this also no different from what happened when customers stopped purchasing Sun machines and switched from Solaris to Linux. Was Solaris technically better in some ways? Sure! But there is business value more than just "technical superiority". Once an Open Source operating system was good enough that it would work for companies and their customers, the openness was far more important than small, specific points where Solaris might be technologically superior.

The same is certainly true for grsecurity. There are various reasons why companies have not wanted to base their product on a fork of grsecurity. We can debate what those reasons are, or whether those companies are right in having come to those conclusions, but every company has the right to decide for itself where it wants to put development dollars, just as each volunteer can decide where he or she will devote her volunteer energies. If those companies choose to put their energy behind the KSPP, there is nothing intrinsically wrong with it, and it's nothing personal. grsecurity wasn't meeting their needs (and the need is not just absolute security), so they chose to do something else, and to support something else.

I understand that you feel part of the grsecurity community, and so it is easy to feel that this is all a great conspiracy which is somehow evil. That is, I suppose natural, but competition for supporters is a real part of the open source ecosystem. This is something where Linux has won, and NetBSD and Hurd have been, shall we say, less successful at attracting people who might be interested in sponsoring their development work. But again, there was no great conspiracy at work here. Linux was simply better suited for the needs of those companies that chose to support Linux, and to hire Linux developers to work full-time on making Linux better, and the network effect took over from there.

The final thing I will note is that closing off the sources is something that in the long run won't work for the embeeed and IOT market. That's because while grsecurity may have closed off source access on their website, Linux is still open source and under the GPL, which means that they can not prevent their downstream sub-licensees from redistributing the grsecurity changes. So for example, if grsecurity is used in a cell phone, and that cell phone is sold in the stores, anyone can buy the cell phone, request that they get sources to the kernel used in the cell phone, and then they can make it available on their web site. *Nothing* can stop them from doing that; if grsecurity/PaX tried to prohibit this, they would be in violation of the GPL. They could prevent this by choosing not to sell grsecurity to embedded, mobile, or IOT market --- but then (a) they would be cutting off a large segment of their market, and (b) it means, ipso factor, that grsecurity is worthless for those markets, and it becomes yet another reason why all of those companies who are supporting KSPP were right to do so. Montavista tried a similar approach (only making their fork of the kernel available to their direct customers, and no distributing the sources on their web site), but in the long run, that did not prove to be a winning business strategy. I suspect grsecurity/PAX team will find a similar dynamic at work.

OpenSSL after Heartbleed

Posted May 5, 2017 14:20 UTC (Fri) by paulj (subscriber, #341) [Link] (4 responses)

GrSecurity can not directly stop redistribution of their GPL patches. However, they can make it clear that anyone doing so will no longer receive further patches or support.

There are a number of entities with this business model, both around the Linux kernel and other GPL software.

OpenSSL after Heartbleed

Posted May 5, 2017 15:23 UTC (Fri) by tytso (subscriber, #9993) [Link] (3 responses)

Sure, but it only works when the subscribers are the end users. It doesn't work if the subscribers are manufacturers of cell phones, or IOT devices, because they are required to give sources if an end-user asks for the sources --- which will include grsecurity.

So for cell phones and IOT devices grsecurity is not the answer. Which is fine, I don't think it ever was the answer, because as a fork, it's not something that could be easily integrated into SOC vendor's fork of the kernel (which are so horrendous that good luck getting them even to build on another architecture; I've had the misfortune having to debug one of these kernels, and never have I seen such a wretch hive of hacks and villainy.)

But it just goes to show that grsecurity is not the answer for millions and millions of Linux systems --- cell phones and IOT devices. The only solution for those devices is KSPP.

OpenSSL after Heartbleed

Posted May 5, 2017 15:45 UTC (Fri) by paulj (subscriber, #341) [Link] (2 responses)

I'm glad to hear all the mobile phone and IoT device makers are so scrupulous about publishing the sources to the kernels they use.

GRSecurity can simply not sell patches to any vendors that intend to resell devices with binaries installed though. Simple.

OpenSSL after Heartbleed

Posted May 5, 2017 16:37 UTC (Fri) by tytso (subscriber, #9993) [Link]

.... and so GRSecurity is irrelevant to the vast majority, numerically speaking, of the systems and devices running Linux in the world.

This is certainly their right. And if they can make money doing that, fine. But they have made themselves completely irrelevant to Linux upstream development, and mostly irrelevant to the Linux ecosystem as a whole.

OpenSSL after Heartbleed

Posted May 5, 2017 17:59 UTC (Fri) by excors (subscriber, #95769) [Link]

> I'm glad to hear all the mobile phone and IoT device makers are so scrupulous about publishing the sources to the kernels they use.

Not all are, but some are. Not all care about security, but some do (a bit). I suspect there is a strong positive correlation between those groups. The people who would happily violate the GPL to use grsecurity wouldn't bother using grsecurity anyway, while the people who want to do the right thing can't use grsecurity. (The latter people probably wouldn't have used grsecurity anyway (for various reasons like difficulty integrating with obsolete SoC kernels etc) but now there's even less chance.)


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds