openssl 1.0.2i security update

[Johann v. Preußen]

there are CVE's in the double-digits addressed by '1.0.2i' and openresty is
using '1.0.2h'. when will fixing all these security holes be implemented by
updating openresty-openssl?

openssl's own compendium is available here:
https://www.openssl.org/news/secadv/20160922.txt

--
Thank you,

Johann

[Robert Paprocki]

On Thu, Sep 22, 2016 at 8:48 AM, Johann v. Preußen <vonpr...@2secure.us> wrote:

there are CVE's in the double-digits addressed by '1.0.2i' and openresty is using '1.0.2h'. when will fixing all these security holes be implemented by updating openresty-openssl?

Considering that openssl1.0.2i was released, oh, a few hours ago, you might just want to be a bit patient. If you're _that_ paranoid, you can always recompile OpenResty yourself with the openssl source yourself.

It's also worth noting that there's only one HIGH vulnerability, and frankly it's not really earth shattering, so saying "all these security holes" is really a bit disingenuous.

[Matthew Glinski]

The worst openssl vunl disclosed amounts to an annoying Denial of Service attack at worst. There is no real need to panic update your apps unless your being attacked right now. This will likely be addressed in a future release, though I am not a project member and am just speaking from a common sense standpoint.

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Johann v. Preußen]

i addressed this "community" listserv because i will be converting a cluster to openresty. i was trying to research the status of openssl patches in openresty-openssl when the openssl version 1.0.2i came out. naturally, i wanted to know when i could have the latest openssl update available in openresty so that i could appropriately schedule things. why?

well, several reasons:

1. according to openresty's own words "This OpenSSL library build is specifically for OpenResty uses. It may contain custom patches from OpenResty.";
2. the fedora core 22 version of 'openresty-openssl-1.0.2h-5.el6.src.rpm' (against which all versions are compiled) is the latest src and it is a month old now;
3. openssl's version 1.0.2i is an updated release that incorporates patches to 1.0.2h going back four (4) months; and
4. openresty provides no doc's as to which -- if any -- openssl security patches [there are 11 of them (i.e., "all")] have been applied to its custom version of 1.0.2h.

i am a stolid practitioner of "common sense" and fully appreciate comments in this vein. i am far less likely to be impressed with snide and/or uniformed comments.

obviously, since there is no openresty-openssl custom src for 1.0.2i, self-compiling is not an option. due to the "custom" src requirement, one cannot compile openresty together with openssl's own src. this last fact must have escaped the attention of some.

although self-reporting/-assessing CVE vulnerability ratings involves subjectivity, the assessment is meant to include analyzing the degree of sophistication required, the likelihood that that sophistication may be applied, whether an exploit requires internal access to the system or may be implemented externally, whether the result is merely noisome or an instrumental compromise, the projection of the number of systems that might be affected, et cetera. thus low/medium/high has different meanings to different admins. also, a 'low' quickly becomes a personal 'high' when you are the one affected.

so, always wanting the "latest and greatest", my simple question re openresty-openssl 1.0.2i availability remains unanswered.

Thank you,

Johann

To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.

[Matthew Glinski]

Hello again!

obviously, since there is no openresty-openssl custom src for 1.0.2i, self-compiling is not an option. due to the "custom" src requirement, one cannot compile openresty together with openssl's own src. this last fact must have escaped the attention of some.

https://github.com/openresty/openresty-packaging/blob/master/rpm/SPECS/openresty-openssl.spec

This is the spec file that is used to build the openssl package that comes with the RHEL/CentOS/Fedora OpenResty Package. There seems to be one patch applied, and this patch file seems to apply correctly to the latest 1.0.2i openssl src, so it's likely that you can build it yourself if needed. You will still need to restart openresty after rebuilding/installing the newer openssl shared library if you take this route.

i am a stolid practitioner of "common sense" and fully appreciate comments in this vein. i am far less likely to be impressed with snide and/or uniformed comments.

No one that has replied here is being snide with you, or seems to be uninformed. I personally agree with the timing comments and severity assessment done by Robert Paprocki, there seems to be very little of immediate interest in the latest openssl patch and if you disagree you can download the latest src and build using the open-source package spec I linked for you above. Dist friendly packaged OpenResty is still very much an immature thing, this project has existed for years with zero official package support for any major distributions. I personally wanted to migrate my build/maint scripts to use the recently released packages if any become available for debian, but the dependence on a pre-packaged openssl binary is the largest thing holding me back from adopting the package dist and switching away from src building. 

As for package maintenance timetables, the main owner of this package lives in or near china and does not usually start responding to these lists until later in the day US Time. If you are using the openresty binary packages you will want to build in at the very least an expected 24h wait period before things like upstream changes from openssl are included/updated/notified. The openssl project like to hold back their final patches until they very last available second for general public consumption mainly to prevent people reverse-engineering their high-classified security patches from becoming active 0-days. The only people who get advanced notice of these critical fixes and the relevant source-code patches are the most trusted general package dist maintainers, and the largest consumers of their technology (companies like google, amazon, etc.), of which openresty's package does not qualify.

​

although self-reporting/-assessing CVE vulnerability ratings involves subjectivity, the assessment is meant to include analyzing the degree of sophistication required, the likelihood that that sophistication may be applied, whether an exploit requires internal access to the system or may be implemented externally, whether the result is merely noisome or an instrumental compromise, the projection of the number of systems that might be affected, et cetera. thus low/medium/high has different meanings to different admins. also, a 'low' quickly becomes a personal 'high' when you are the one affected.

While I don't want to discount your assessment of the severity of the recent openssl CVE disclosures, they seem very mild and should not concern the vast vast majority of system hosts unless you are seeing symptoms of an attack related to today's disclosures. Though it is possible as outlined above, there is no immediate need to patch/restart out of date systems out of band of normal scheduled maintenance.

I assume an updated build of openresty-openssl will be coming out "soon" ™,  but no one can really put a date on it. If you want to have more control over when updates like this take place, you can build directly from source and eliminate third party delays in your maintenance schedule.

-Matt

[Johann v. Preußen]

Glinski/Paprocki:

thank you for your time and attention.

i am familiar with Zhang from my interest in tengine several years back and before his lash-up with cloudflare. then he was in PRC with taobao and was working on his own "tengine version" ... openresty. however, now he is in San Francisco ... probably on an H-1B for nginx engineering. tengine was -- in my personal analysis -- too much of a departure from nginx. openresty was designed to be more true, but being without any effort to produce distro binaries coupled with the high state of flux made it too much effort to consider for my app's. as of now, his showing up late in the day may be because openresty is a "labor of love" during his free time from work and not a directly-sponsored cloudflare app.

i appreciate the spec file and the confirmation of the "work-ability" of the 1.0.2h openresty patch on 1.0.2i. is there a spec for the openssl devel pkg which seems to be required?

i actually do not disagree with your consensus re the import of the current batch of CVE fixes, but i am still hoping for a complete RHEL6 binary pkg as this is the only way i would want to put something into production on this first (or any other site's) cluster. however, i might try the compile-route for a dev server as an interim look-see project. in fact, with the production-release of 1.1.0a, skipping 1.0.2i might well be a better longer-term option for current binary inclusion. 1.1.0 natively had all the older CVE's and other mods and 1.1.0a has the CVE-2016-6304/5 patches applied.

i am aware of openssl's critical-release proc, but their interim patches in response to even mundane CVE's and other problems/clarifications seem to be turned around almost immediately and in complete transparency. believe me, they have a very wide-ranging and active listserv with their heavy-hitter dev-team members responding within hours if not minutes. moreover, the list handles everything from exposed problems down to a "how to" in order to integrate someone's app ... done patiently and in great detail if necessary.

Thank you,

Johann

[jona...@findmeon.com]

Here's a related question --the "openssl-openresty" release is simply a RPM package for compatible platforms. 

It has a single patch, which appears created in this commit:

   https://github.com/openresty/openresty/commit/97901f335709e8f3b2dec1c368bba20f3894fccc

Does anyone know if this is applied when building from source?  If not, shouldn't there be some docs on that?

We're on ubuntu and usually need the most-current openssl for some LetsEncrypt work, so I usually just build both from source (it took 4 minutes when upgrading the server today)... and it's been absolutely fine in a moderate-traffic production setting.   I had no idea about this patch until reading this.

[Johann v. Preußen]

yes, it is applied.

as with any rpm, you can get a gross picture from:
rpm -qilR --changelog --provides openresty-openssl;

NOTE: the 'openresty-openssl' has no changelog/provides output, but the description does highlight that patches are likely to have been applied. there also is the URL directly to the FC22 mother rpm.

you have apparently tracked down the spec file, but i do not see the one for openssl-devel. devel is in the openresty bundle. but, like you, i cannot find much for doc's and do not know if it is required for the base install or is just there for any potential tack-ons.

this patch works on the latest 1.0.2i openssl src release according to a prior email from Glinski. 1.0.2i is just a bunch of security patches dating back to 2016.MAY. the next major openssl step would be 1.1.0a (the new branch with a couple of the newest CVE patches). i have yet to try that one on in an openresty setting.

Thank you,

Johann

[Matthew Glinski]

Devel is generally not needed to rebuild because those are header files for the library. You need to download the latest openssl, apply the patch file linked above, compile zlib as the spec does, build openssl linked .so files and then move them into place. Then openssl will be upgraded after a restart of openresty.

To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "openresty-en" group.

To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en+unsubscribe@googlegroups.com.

[Yichun Zhang (agentzh)]

Hello!

We're still testing the new OpenSSL 1.0.2i release on our side. It's
expected to push the new openresty-openssl* packages to our official
yum repositories later today or earlier tomorrow if no regressions
caught in our tests.

Thanks for your patience!

Best regards,
-agentzh

[Johann v. Preußen]

your speedy attention is much appreciated.

Thank you,

Johann

[Yichun Zhang (agentzh)]

Hello!

On Sat, Sep 24, 2016 at 12:36 PM, Yichun Zhang (agentzh) wrote:
> We're still testing the new OpenSSL 1.0.2i release on our side. It's
> expected to push the new openresty-openssl* packages to our official
> yum repositories later today or earlier tomorrow if no regressions
> caught in our tests.
>

Just pushed the new packages to the repositories. Please run the
following commands to update:

yum clean expire-cache && yum update

Assuming that you've already configured the openresty yum repos [1].

Let me know if there's anything. Thanks!

Regards,
-agentzh

[1] http://openresty.org/en/linux-packages.html

[Johann v. Preußen]

got it.

looks like no rest for the wicked this week-end!

Thank you,

Johann

[Johann v. Preußen]

FYI, CVE-2016-7052 fix, infra. i have no idea how prevalent CRL-checking might be amongst openresty users, but a crash will certainly hurt some percentage.

This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016.
A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i.
As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception.

OpenSSL 1.0.2i users should upgrade to 1.0.2j

The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and Thomas Jakobi.
The fix was developed by Matt Caswell of the OpenSSL development team.

also, 1.1.0b has also been issued due to critical CVE-2016-6309 (<=1.0.2 are NOT affected).

Thank you,

Johann

On 2016.Sep.24 14:32, Yichun Zhang (agentzh) wrote:

[Evan Wies]

I'm pretty late to this thread, but I just updated the Docker images to OpenSSL 1.0.2j.

Also, the Docker images don't automatically pick up newer RPMs.  A new build should be triggered if any of the dependent packages are updated.  New builds for all images are happening now.

Regards,

Evan