Patch Package: OTP 19.3.6.4

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Patch Package: OTP 19.3.6.4

Ingela Anderton Andin-4

Patch Package:    OTP 19.3.6.4
Git Tag:                OTP-19.3.6.4
Date:                    2017-11-23
Trouble Report Id:  OTP-14748
Seq num:
System:                  OTP
Release:                 19
Application:            ssl-8.1.3.1
Predecessor:          OTP 19.3.6.3

 Check out the git tag OTP-19.3.6.4, and build a full OTP system
 including documentation. Apply one or more applications from this
 build as patches to your installation using the 'otp_patch_apply'
 tool. For information on install requirements, see descriptions for
 each application version below.

 ---------------------------------------------------------------------
 --- ssl-8.1.3.1 -----------------------------------------------------
 ---------------------------------------------------------------------

 Note! The ssl-8.1.3.1 application can *not* be applied independently
       of other applications on an arbitrary OTP 19 installation.

       On a full OTP 19 installation, also the following runtime
       dependency has to be satisfied:
       -- stdlib-3.2 (first satisfied in OTP 19.2)


 --- Fixed Bugs and Malfunctions ---

  OTP-14748    Application(s): ssl

               An erlang TLS server configured with cipher suites
               using rsa key exchange, may be vulnerable to an
               Adaptive Chosen Ciphertext attack (AKA Bleichenbacher
               attack) against RSA, which when exploited, may result
               in plaintext recovery of encrypted messages and/or a
               Man-in-the-middle (MiTM) attack, despite the attacker
               not having gained access to the server’s private key
               itself. CVE-2017-1000385

               Exploiting this vulnerability to perform plaintext
               recovery of encrypted messages will, in most practical
               cases, allow an attacker to read the plaintext only
               after the session has completed. Only TLS sessions
               established using RSA key exchange are vulnerable to
               this attack.

               Exploiting this vulnerability to conduct a MiTM attack
               requires the attacker to complete the initial attack,
               which may require thousands of server requests, during
               the handshake phase of the targeted session within the
               window of the configured handshake timeout. This attack
               may be conducted against any TLS session using RSA
               signatures, but only if cipher suites using RSA key
               exchange are also enabled on the server. The limited
               window of opportunity, limitations in bandwidth, and
               latency make this attack significantly more difficult
               to execute.

               RSA key exchange is enabled by default although least
               prioritized if server order is honored. For such a
               cipher suite to be chosen it must also be supported by
               the client and probably the only shared cipher suite.

               Captured TLS sessions encrypted with ephemeral cipher
               suites (DHE or ECDHE) are not at risk for subsequent
               decryption due to this vulnerability.

               As a workaround if default cipher suite configuration
               was used you can configure the server to not use
               vulnerable suites with the ciphers option like this:

               {ciphers, [Suite || Suite <- ssl:cipher_suites(),
               element(1,Suite) =/= rsa]}

               that is your code will look somethingh like this:

               ssl:listen(Port, [{ciphers, [Suite || Suite <-
               ssl:cipher_suites(), element(1,S) =/= rsa]} |
               Options]).

               Thanks to Hanno Böck, Juraj Somorovsky and Craig Young
               for reporting this vulnerability.


 Full runtime dependencies of ssl-8.1.3.1: crypto-3.3, erts-7.0,
 inets-5.10.7, kernel-3.0, public_key-1.2, stdlib-3.2


 ---------------------------------------------------------------------
 ---------------------------------------------------------------------
 ---------------------------------------------------------------------


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Patch Package: OTP 19.3.6.4

books
To Ingela and if sverker also on the list:

This morning I just found OTP-19.2.3.1 release is available, for the
only changed application is erts-8.2.2.1;  I'm trying to understand
why is this needed? when you already have OTP 19.3.6.3 which included
erts-8.3.5.3;
how many users are there sticking with 19.2 and can upgrade
19.2.X.Y.latest but can't upgrade to 19.3.X.Y.latest  ?
as a downstream OS distribution packager, I want to know if this need
a packaging as well

Could you also talk on what are the Erlang OTP release rules? if not
have recorded on some link? and what's the maintenance plan for each
past release? how long will each release be supported? like 19 will be
supported till Month-Year? 18 till what Month-Year?   and is 17
already no longer maintained?


https://github.com/erlang/otp/releases
https://github.com/erlang/otp/releases/tag/OTP-19.2.3.1

=== OTP-19.2.3.1 ===

 sverker tagged this a day ago · 4766 commits to master since this tag

Changed Applications:
- erts-8.2.2.1

On Thu, Nov 23, 2017 at 7:26 AM, Ingela Anderton Andin
<[hidden email]> wrote:

> Patch Package:    OTP 19.3.6.4
> Git Tag:                OTP-19.3.6.4
> Date:                    2017-11-23
> Trouble Report Id:  OTP-14748
> Seq num:
> System:                  OTP
> Release:                 19
> Application:            ssl-8.1.3.1
> Predecessor:          OTP 19.3.6.3
>
>  Check out the git tag OTP-19.3.6.4, and build a full OTP system
>  including documentation. Apply one or more applications from this
>  build as patches to your installation using the 'otp_patch_apply'
>  tool. For information on install requirements, see descriptions for
>  each application version below.
>
>  ---------------------------------------------------------------------
>  --- ssl-8.1.3.1 -----------------------------------------------------
>  ---------------------------------------------------------------------
>
>  Note! The ssl-8.1.3.1 application can *not* be applied independently
>        of other applications on an arbitrary OTP 19 installation.
>
>        On a full OTP 19 installation, also the following runtime
>        dependency has to be satisfied:
>        -- stdlib-3.2 (first satisfied in OTP 19.2)
>
>
>  --- Fixed Bugs and Malfunctions ---
>
>   OTP-14748    Application(s): ssl
>
>                An erlang TLS server configured with cipher suites
>                using rsa key exchange, may be vulnerable to an
>                Adaptive Chosen Ciphertext attack (AKA Bleichenbacher
>                attack) against RSA, which when exploited, may result
>                in plaintext recovery of encrypted messages and/or a
>                Man-in-the-middle (MiTM) attack, despite the attacker
>                not having gained access to the server’s private key
>                itself. CVE-2017-1000385
>
>                Exploiting this vulnerability to perform plaintext
>                recovery of encrypted messages will, in most practical
>                cases, allow an attacker to read the plaintext only
>                after the session has completed. Only TLS sessions
>                established using RSA key exchange are vulnerable to
>                this attack.
>
>                Exploiting this vulnerability to conduct a MiTM attack
>                requires the attacker to complete the initial attack,
>                which may require thousands of server requests, during
>                the handshake phase of the targeted session within the
>                window of the configured handshake timeout. This attack
>                may be conducted against any TLS session using RSA
>                signatures, but only if cipher suites using RSA key
>                exchange are also enabled on the server. The limited
>                window of opportunity, limitations in bandwidth, and
>                latency make this attack significantly more difficult
>                to execute.
>
>                RSA key exchange is enabled by default although least
>                prioritized if server order is honored. For such a
>                cipher suite to be chosen it must also be supported by
>                the client and probably the only shared cipher suite.
>
>                Captured TLS sessions encrypted with ephemeral cipher
>                suites (DHE or ECDHE) are not at risk for subsequent
>                decryption due to this vulnerability.
>
>                As a workaround if default cipher suite configuration
>                was used you can configure the server to not use
>                vulnerable suites with the ciphers option like this:
>
>                {ciphers, [Suite || Suite <- ssl:cipher_suites(),
>                element(1,Suite) =/= rsa]}
>
>                that is your code will look somethingh like this:
>
>                ssl:listen(Port, [{ciphers, [Suite || Suite <-
>                ssl:cipher_suites(), element(1,S) =/= rsa]} |
>                Options]).
>
>                Thanks to Hanno Böck, Juraj Somorovsky and Craig Young
>                for reporting this vulnerability.
>
>
>  Full runtime dependencies of ssl-8.1.3.1: crypto-3.3, erts-7.0,
>  inets-5.10.7, kernel-3.0, public_key-1.2, stdlib-3.2
>
>
>  ---------------------------------------------------------------------
>  ---------------------------------------------------------------------
>  ---------------------------------------------------------------------
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Patch Package: OTP 19.3.6.4

Sverker Eriksson-4
All announced patches on 19 will have versions OTP-19.3.6.x

Any other pushed OTP-19 tag is some sort of special customer request
of backporting fix or feature.

If something is fixed for example on OTP-19.2.y.z, then it will also
be fixed or already have been fixed on OTP-19.3.6.x.

/Sverker


On tor, 2017-11-30 at 12:15 -0800, derek wrote:

> To Ingela and if sverker also on the list:
>
> This morning I just found OTP-19.2.3.1 release is available, for the
> only changed application is erts-8.2.2.1;  I'm trying to understand
> why is this needed? when you already have OTP 19.3.6.3 which included
> erts-8.3.5.3;
> how many users are there sticking with 19.2 and can upgrade
> 19.2.X.Y.latest but can't upgrade to 19.3.X.Y.latest  ?
> as a downstream OS distribution packager, I want to know if this need
> a packaging as well
>
> Could you also talk on what are the Erlang OTP release rules? if not
> have recorded on some link? and what's the maintenance plan for each
> past release? how long will each release be supported? like 19 will
> be
> supported till Month-Year? 18 till what Month-Year?   and is 17
> already no longer maintained?
>
>
> https://github.com/erlang/otp/releases
> https://github.com/erlang/otp/releases/tag/OTP-19.2.3.1
>
> === OTP-19.2.3.1 ===
>
>  sverker tagged this a day ago · 4766 commits to master since this
> tag
>
> Changed Applications:
> - erts-8.2.2.1
>
> On Thu, Nov 23, 2017 at 7:26 AM, Ingela Anderton Andin
> <[hidden email]> wrote:
> >
> > Patch Package:    OTP 19.3.6.4
> > Git Tag:                OTP-19.3.6.4
> > Date:                    2017-11-23
> > Trouble Report Id:  OTP-14748
> > Seq num:
> > System:                  OTP
> > Release:                 19
> > Application:            ssl-8.1.3.1
> > Predecessor:          OTP 19.3.6.3
> >
> >  Check out the git tag OTP-19.3.6.4, and build a full OTP system
> >  including documentation. Apply one or more applications from this
> >  build as patches to your installation using the 'otp_patch_apply'
> >  tool. For information on install requirements, see descriptions
> > for
> >  each application version below.
> >
> >  ----------------------------------------------------------------
> > -----
> >  --- ssl-8.1.3.1 --------------------------------------------------
> > ---
> >  ----------------------------------------------------------------
> > -----
> >
> >  Note! The ssl-8.1.3.1 application can *not* be applied
> > independently
> >        of other applications on an arbitrary OTP 19 installation.
> >
> >        On a full OTP 19 installation, also the following runtime
> >        dependency has to be satisfied:
> >        -- stdlib-3.2 (first satisfied in OTP 19.2)
> >
> >
> >  --- Fixed Bugs and Malfunctions ---
> >
> >   OTP-14748    Application(s): ssl
> >
> >                An erlang TLS server configured with cipher suites
> >                using rsa key exchange, may be vulnerable to an
> >                Adaptive Chosen Ciphertext attack (AKA
> > Bleichenbacher
> >                attack) against RSA, which when exploited, may
> > result
> >                in plaintext recovery of encrypted messages and/or a
> >                Man-in-the-middle (MiTM) attack, despite the
> > attacker
> >                not having gained access to the server’s private key
> >                itself. CVE-2017-1000385
> >
> >                Exploiting this vulnerability to perform plaintext
> >                recovery of encrypted messages will, in most
> > practical
> >                cases, allow an attacker to read the plaintext only
> >                after the session has completed. Only TLS sessions
> >                established using RSA key exchange are vulnerable to
> >                this attack.
> >
> >                Exploiting this vulnerability to conduct a MiTM
> > attack
> >                requires the attacker to complete the initial
> > attack,
> >                which may require thousands of server requests,
> > during
> >                the handshake phase of the targeted session within
> > the
> >                window of the configured handshake timeout. This
> > attack
> >                may be conducted against any TLS session using RSA
> >                signatures, but only if cipher suites using RSA key
> >                exchange are also enabled on the server. The limited
> >                window of opportunity, limitations in bandwidth, and
> >                latency make this attack significantly more
> > difficult
> >                to execute.
> >
> >                RSA key exchange is enabled by default although
> > least
> >                prioritized if server order is honored. For such a
> >                cipher suite to be chosen it must also be supported
> > by
> >                the client and probably the only shared cipher
> > suite.
> >
> >                Captured TLS sessions encrypted with ephemeral
> > cipher
> >                suites (DHE or ECDHE) are not at risk for subsequent
> >                decryption due to this vulnerability.
> >
> >                As a workaround if default cipher suite
> > configuration
> >                was used you can configure the server to not use
> >                vulnerable suites with the ciphers option like this:
> >
> >                {ciphers, [Suite || Suite <- ssl:cipher_suites(),
> >                element(1,Suite) =/= rsa]}
> >
> >                that is your code will look somethingh like this:
> >
> >                ssl:listen(Port, [{ciphers, [Suite || Suite <-
> >                ssl:cipher_suites(), element(1,S) =/= rsa]} |
> >                Options]).
> >
> >                Thanks to Hanno Böck, Juraj Somorovsky and Craig
> > Young
> >                for reporting this vulnerability.
> >
> >
> >  Full runtime dependencies of ssl-8.1.3.1: crypto-3.3, erts-7.0,
> >  inets-5.10.7, kernel-3.0, public_key-1.2, stdlib-3.2
> >
> >
> >  ----------------------------------------------------------------
> > -----
> >  ----------------------------------------------------------------
> > -----
> >  ----------------------------------------------------------------
> > -----
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > [hidden email]
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Patch Package: OTP 19.3.6.4

books

On Thu, Nov 30, 2017 at 1:06 PM, Sverker Eriksson <[hidden email]> wrote:
> All announced patches on 19 will have versions OTP-19.3.6.x

But wait, will there be more 19.3.7+.x versions?

>
> Any other pushed OTP-19 tag is some sort of special customer request
> of backporting fix or feature.

ok, so I think I can skip this OTP-19.2.y.z.

>
> If something is fixed for example on OTP-19.2.y.z, then it will also
> be fixed or already have been fixed on OTP-19.3.6.x.
>
> /Sverker


And Ingela or Sverker can comment on the long term maintenance plan? or generic rules

https://github.com/nodejs/Release#release-schedule   Something like this for nodejs, it clearly mentioned Maintenance LTS End for each major node version;

I just wonder when can I drop support of Erlang 17, 18, ... ?

>
>
> On tor, 2017-11-30 at 12:15 -0800, derek wrote:
>> To Ingela and if sverker also on the list:
>>
>> This morning I just found OTP-19.2.3.1 release is available, for the
>> only changed application is erts-8.2.2.1;  I'm trying to understand
>> why is this needed? when you already have OTP 19.3.6.3 which included
>> erts-8.3.5.3;
>> how many users are there sticking with 19.2 and can upgrade
>> 19.2.X.Y.latest but can't upgrade to 19.3.X.Y.latest  ?
>> as a downstream OS distribution packager, I want to know if this need
>> a packaging as well
>>
>> Could you also talk on what are the Erlang OTP release rules? if not
>> have recorded on some link? and what's the maintenance plan for each
>> past release? how long will each release be supported? like 19 will
>> be
>> supported till Month-Year? 18 till what Month-Year?   and is 17
>> already no longer maintained?
>>
>>
>> https://github.com/erlang/otp/releases
>> https://github.com/erlang/otp/releases/tag/OTP-19.2.3.1
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Patch Package: OTP 19.3.6.4

Rickard Green-2


On Fri, Dec 1, 2017 at 7:33 PM, derek <[hidden email]> wrote:

On Thu, Nov 30, 2017 at 1:06 PM, Sverker Eriksson <[hidden email]> wrote:
> All announced patches on 19 will have versions OTP-19.3.6.x

But wait, will there be more 19.3.7+.x versions?

>
> Any other pushed OTP-19 tag is some sort of special customer request
> of backporting fix or feature.

ok, so I think I can skip this OTP-19.2.y.z.

>
> If something is fixed for example on OTP-19.2.y.z, then it will also
> be fixed or already have been fixed on OTP-19.3.6.x.
>
> /Sverker


And Ingela or Sverker can comment on the long term maintenance plan? or generic rules

https://github.com/nodejs/Release#release-schedule   Something like this for nodejs, it clearly mentioned Maintenance LTS End for each major node version;

I just wonder when can I drop support of Erlang 17, 18, ... ?

>
>
> On tor, 2017-11-30 at 12:15 -0800, derek wrote:
>> To Ingela and if sverker also on the list:
>>
>> This morning I just found OTP-19.2.3.1 release is available, for the
>> only changed application is erts-8.2.2.1;  I'm trying to understand
>> why is this needed? when you already have OTP 19.3.6.3 which included
>> erts-8.3.5.3;
>> how many users are there sticking with 19.2 and can upgrade
>> 19.2.X.Y.latest but can't upgrade to 19.3.X.Y.latest  ?
>> as a downstream OS distribution packager, I want to know if this need
>> a packaging as well
>>
>> Could you also talk on what are the Erlang OTP release rules? if not
>> have recorded on some link? and what's the maintenance plan for each
>> past release? how long will each release be supported? like 19 will
>> be
>> supported till Month-Year? 18 till what Month-Year?   and is 17
>> already no longer maintained?
>>
>>
>> https://github.com/erlang/otp/releases
>> https://github.com/erlang/otp/releases/tag/OTP-19.2.3.1
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


See my mail to erlang-question with subject "OTP Versions and Maint Branches".

Regards,
Rickard

--
Rickard Green, Erlang/OTP, Ericsson AB

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions