Re: [OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[Bob Friesenhahn]

On Wed, 2 Mar 2016, Peter Tribble wrote:


IIRC, 1.1.0 has this change already. That's fine, as it's a new release and is 
allowed
to make incompatible changes.


Yes, that is why I mentioned it.


  Perhaps it is possible to tweak the library (or config file) so that 
SSLv2 won't acutally be used.


Actually, no. What would be ideal is that openssl provided stub functions that 
return
an error, so symbol resolution works fine (but anything actually calling SSLv2 
will fail).
As it is, they're yanking the functions and breaking binary compatibility by 
default.


As long as all SSLv2 code has been stripped out, this is safest. 
Otherwise it will be very difficult for OmniOS users to upgrade since 
programs will refuse to run.  There is still a question of what 
existing application code might do (continue on, quit, crash, 
lock-up?) if an error is reported by a stub function.



Things are made worse by the fact that consumers of the openssl library (things 
like wget,
libcurl) tend to blindly enable SSLv2 support if it's present in the openssl 
implementation
they're built against. Often without a way of disabling it otherwise. So you 
either have to
work out how to manually disable SSLv2 for those consumers, or build them on a 
system
that has openssl installed but with SSLv2 disabled. Then, of course, you have 
to make
sure that updated consumers get pushed out and updated by users *before* you 
push
out a "fixed" openssl. And if end users have built applications, then they're 
up the creek
without a paddle. It's just a mess.


OmniOS has decided to be responsible for the absolute minimum number 
of "consumers" so it is not in a position to correct the consumers. 
In contrast, Red Hat Linux provides a huge set of applications and so 
it can re-issue all those applications built against the new library.


Considering all sources of harm, it is likely safest for OmniOS to 
wait for the 1.1.0 release, and preserve the existing library (with 
SSLv2 functions as they appear in 1.0.2g or 1.0.1s) across upgrades. 
Then warn consumers to rebuild their applications.


This security problem primarily impacts SSL servers rather than 
clients.  Only a subset of OpenSSL consumers act as servers.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[Peter Tribble]

On Wed, Mar 2, 2016 at 12:08 AM, Bob Friesenhahn <
bfrie...@simple.dallas.tx.us> wrote:

> On Tue, 1 Mar 2016, Dan McDonald wrote:
>
>>
>> Bloody's fate remains up in the air. I'm contemplating removing SSLv2
>> support from bloody, and when it ships, r151018.  This will require,
>> however, some godawful bootstrapping, akin to the gcc version change I did
>> for r151015/6.  Anyone who's a fan of bloody should followup on this thread
>> to tell me what you think.
>>
>
> If you remove SSLv2 APIs without bumping the major interface of the
> library, then you will curse all already-built user applications with the
> same fate which befell Python.  If you bump the major interface of the
> library, then the old library still needs to be available to support
> existing apps.
>
> We are already on the latest OpenSSL release on the newest branch so until
> upstream makes a breaking release (e.g. the planned 1.1.0), then it is not
> so convenient for OmniOS to do so.  If you wait for 1.1.0, then it may be
> much easier.
>

IIRC, 1.1.0 has this change already. That's fine, as it's a new release and
is allowed
to make incompatible changes.


> Perhaps it is possible to tweak the library (or config file) so that SSLv2
> won't acutally be used.
>

Actually, no. What would be ideal is that openssl provided stub functions
that return
an error, so symbol resolution works fine (but anything actually calling
SSLv2 will fail).
As it is, they're yanking the functions and breaking binary compatibility
by default.

Things are made worse by the fact that consumers of the openssl library
(things like wget,
libcurl) tend to blindly enable SSLv2 support if it's present in the
openssl implementation
they're built against. Often without a way of disabling it otherwise. So
you either have to
work out how to manually disable SSLv2 for those consumers, or build them
on a system
that has openssl installed but with SSLv2 disabled. Then, of course, you
have to make
sure that updated consumers get pushed out and updated by users *before*
you push
out a "fixed" openssl. And if end users have built applications, then
they're up the creek
without a paddle. It's just a mess.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[Bob Friesenhahn]

On Tue, 1 Mar 2016, Dan McDonald wrote:


Bloody's fate remains up in the air. I'm contemplating removing 
SSLv2 support from bloody, and when it ships, r151018.  This will 
require, however, some godawful bootstrapping, akin to the gcc 
version change I did for r151015/6.  Anyone who's a fan of bloody 
should followup on this thread to tell me what you think.


If you remove SSLv2 APIs without bumping the major interface of the 
library, then you will curse all already-built user applications with 
the same fate which befell Python.  If you bump the major interface of 
the library, then the old library still needs to be available to 
support existing apps.


We are already on the latest OpenSSL release on the newest branch so 
until upstream makes a breaking release (e.g. the planned 1.1.0), then 
it is not so convenient for OmniOS to do so.  If you wait for 1.1.0, 
then it may be much easier.


Perhaps it is possible to tweak the library (or config file) so that 
SSLv2 won't acutally be used.


Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[John D Groenveld]

In message <15079dc7-d6c8-45d1-9ca5-b7be5cb18...@omniti.com>, Dan McDonald writ
es:
>First off, I apologize for breaking pkg(5) and who-know-what else.  I honestly
> didn't think SSLv2 would still be used, even just by software autoconf'ed to 
>detect it.

I hit this recently with a modern Perl module or Ruby gem that
raised hell about the lack of exported SSLv2 functions from
the modern openssl.

Oh s much cruft out there to either be stripped out or
exploited.

Thanks for trying...
John
groenv...@acm.org
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss

Re: [OmniOS-discuss] PHEW! OpenSSL 1.0.2g and 1.0.1s NOW OUT, albeit with SSLv2_* enabled

[Michael Rasmussen]

On Tue, 1 Mar 2016 18:06:26 -0500
Dan McDonald  wrote:

> Those also demonstrate pkg(5) working with latest OpenSSL.  :)
> 
I can confirm this working on r151014.

Thanks Dan - you deserve your good nights sleep;-)

-- 
Hilsen/Regards
Michael Rasmussen

Get my public GnuPG keys:
michael  rasmussen  cc
http://pgp.mit.edu:11371/pks/lookup?op=get=0xD3C9A00E
mir  datanom  net
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE501F51C
mir  miras  org
http://pgp.mit.edu:11371/pks/lookup?op=get=0xE3E80917
--
/usr/games/fortune -es says:
You can't break eggs without making an omelet.


pgpesA9xYZsz0.pgp
Description: OpenPGP digital signature
___
OmniOS-discuss mailing list
OmniOS-discuss@lists.omniti.com
http://lists.omniti.com/mailman/listinfo/omnios-discuss